|
|
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
2008-01-07, 09:23 PM | #1 |
The only guys who wear Hawaiian shirts are gay guys and big fat party animals
|
Top server security issue from 2007 and how to fix it
According to SANS Insititute, the single most frequently attacked vulnerability in 2007 was
PHPs "allow_url_fopen" setting. allow_url_fopen is a PHP setting which tells PHP to treat a URL as a file and potentially run a PHP script on your server that the cracker has put on his site. Combined with suexec, running PHP as your FTP user name, these two settings are virtually the same thing as giving all visitors to your site SSH shell access into your server. The number one thing you can do to secure your server today in five minutes or less is to turn off allow_url_fopen in /etc/php.ini. allow_url_fopen is used by crackers to install root kits on Linux and FreeBSD servers and to totally take control of Windows servers by using PHP’s SMB file wrappers. Once rooted in this way, the server is essentially trash and has to be completely re-installed. There is no other way to clean up the server and secure after such a breach. Several of the other top security issues in 2007 are PHP related and can be avoided with some simple configuration changes in /etc/php.ini, so I highly recommend securing your PHP by following a howto such as: http://aymanh.com/checklist-for-secu...-configuration Once your PHP is secured, some scripts may give errors. This is, in my opinion, a flaw in those scripts which should be fixed. Fixing a script to run in a secure environment is normally a pretty quick and easy job for the script's author, so I would insist that they fix the insecure lines in the script before using it. Another big problem we saw in 2007 is a lot of SQL injection attacks. There are a couple of reasons for the rise in SQL injection attacks and the number of PHP related attacks generally. One is that PHP makes it very easy to write scripts using MySQL, even when MySQL isn't the best tool for the job. Because PHP makes writing scripts easy and makes using MySQL pretty easy, the combination attracts "scripters" who are not qualified programmers. These individuals have not taken classes in programming or security and have read few if any books on the subject, so while they manage to make the script "work", they are not educated in how to do so securely and other aspects of quality programming and systems design. Another reason for the rise in attacks is the rise of "Web 2.0", user generated content. Blogs, message boards, wikis and many other technologies allow any visitor to your site to modify your site, generally by using PHP scripts which run off a MySQL database. While much of the user generated content is valuable, a certain perecentage is added maliciously, with crackers using your site to attack your visitors browsers or submitting carefully crafted submissions which do harm to your database or other parts of your site. A common example of what we call an SQL injection attack takes advantage of code that looks like this, which is supposed to check to see if the user is an admin: SELECT is_admin WHERE username='$user' The idea is that the visitor enters a username such as "Dave" and PHP sends the following query to the database to see if "Dave" is an admin: SELECT is_admin WHERE username='Dave' However, consider what happens if I enter my username as "nobody' or is_admin='true" Subsituting that "username" into the query ends up doing something entirely different from what the script author wanted: SELECT is_admin WHERE username='nobody' or is_admin='true' Using that fake username I'll ALWAYS be granted admin access! This is the type of attack that we were able to use in testing to get admin access to this very forum a couple of years ago. (We fixed it after that, of course, so don't bother trying it now - it won't work here.) To avoid SQL injection attacks and other similar attacks, ensure that any script you have which accepts ANY type of input from the user is always up to date with the latest security pataches. Especially for any custom scripts, insist that the programmer properly sanitizes all user input and uses a php function called mysql_real_escape_string() for all SQL queries involving user input. Note that mysql_real_escape_string is NOT enough by itself - the script must first check the input for disallowed characters such as the equals sign, etc. Perl has a similar function that is slightly more secure than PHP's mysql_real_escape_string(). When using Perl, ensure that all qeries are first prepare()d using question marks for values with any user input passed into the execute() call to avoid SQL injection. That's the new information this week, covering the top server security issues of 2007. Remember, though, always the number one best way to secure a script is to get rid of it. A cracker can't use a script that you've deleted, so take a look in your FTP and get rid of any unused or unnecesary scripts, and be sure that you have a SOLID back up plan in place so that you can recover from any security breaches. We can help you with some of the best back up in the world. CloneBox creates an exact replica of your server just as it was 24, 48, and 72 hours ago, ready to take over at a moments notice in case of any problems with your main server. |
|
|