What measures should I take after I find one of my scripts being vulnerable?

Question

I maintain a few PHP-based websites for a small company on a LAMP server. The scripts include CMS such as Joomla or Wordpress, as well as SilverStripe and Drupal installations.

A week ago, I found the sites to have been compromised. The only actual causes of the problems were that all .php files had been deleted in the attack. Restoring those from backup put everything back in a normal state.

Of course, the security hole still exists somewhere. Here's what I did immediately after the attack:

• The sites are all saved in /var/www, and the files and folders used to all belong to www-user. I now created a user for every site, e.g. drupal, and ran chown -R drupal:www-data . on the Drupal folder.

• I checked the permissions so files would be u=rwx,g=rx,o=, and directories u=rw,g=r,o=. This, I assume, will make it impossible for an attack through PHP to actually be able to delete files or modify them in any way.

Now my questions:

• Are these assumptions about permissions correct and will they at least save me from an imminent attack?

• What other precautions can I take, apart from upgrading the scripts to the latest version and making sure my backups are working fine?

Answer 1

You really need to identify how the attacker got in. If it was through the webserver, it's actually relatively easy:

1. Determine when the files disappeared. You've already put the files back, so we can't look at the directory's modification time. Instead, look to the webserver logs for 404 errors from those files.
2. Determine what requests came into the webserver immediately before the files disappeared. Look through the webserver logs ... if it was via a GET or HEAD request, there will be something quite obvious in the logs. Look for things other than GET / HEAD & POST. If you still don't find anything, it was a POST, and unless you're running mod_security or spit out ad-hoc debugging output, you won't have any logs of what they actually did. You might look for IP addresses that seem to be doing abnormal requests, or check the error logs to see if there are any clues in there.

As has already been mentioned, you really need to change every password. I'd also suggest changing the ownership of the webserver directory so that the user that the webserver runs as does not have permission to change any files. If do file uploads or other user-derived content, give it a sub-directory that it can write to, but not the top level. (and make sure that the sub-directory in question can't contain CGIs, PHP or anything that would be served in a manner other than as a static file). You'll want to watch your webserver's error logs to see if there's something that needs (wants?) more permissive permissions, and then either give it those permissions, or change how it behaves.

If you want an even higher level of security, if you're willing to take the resource hit and have a second server, you store all of the files on a completely different server, and then NFS mount them read-only on the webserver. This means that if (when?) there's a vulnerability, they have to work much harder to do lasting harm.

You should also look over the CIS benchmarks for Apache which is a guide for hardening your server (they also have OS and database guides) -- but be warned that you should understand each step, as you will often break an existing site, especially for clients with older browsers, if you apply them blindly. This is another one of those times when you need to watch the error logs for a week or so after making the changes.

Answer 2

The fact that you made additional users for each of the site is great since if one gets hacked/exploited the rest is unlikely to be affected however you could go one step further.

Vhosts in Home Folders

You can move the hosts actually into their home folders so they are jailed so to speak which will add a little bit of extra security. You can setup the vhosts so that the paths are in /home/drupal/public_html for example, and then setup so each user can't enter other users homes.

Chmod

I'm sure you done this already you seem to have your head screwed on about the security but the key files that are injected in most exploits are the template files, index file, config file and the .htaccess file. So CHMOD these files are extremely important.

While setting the CHMOD is key there is also some other key elements which you can secure your site.

SQL Injections

SQL injections are still very popular and using good security measures can prevent this, turning off things like error_reporting in the php.ini file can help as well as setting up secure .htaccess to add an extra layer. But you should always try to see if your placing of data into the SQL is sanitized, It's important that you check to see the plugins that you are using are using mysql_real_escape_string or pg_escape_string (if using PHP) or use prepared statements on all queries using variables from a POST or GET. This will help SQL injection, its pretty loan winded to list exactly how to do this but your need to search Google and learn a bit more about SQL injections to prevent them fully.

PHP Security

You should consider using a php.ini for each of your sites in their home directorys so you can disable things they don't need to operate. The more things you disable the less hackers have to use against your site.

I consider to disable these though depending on your site you may need things like fopen to do updates, or do the manually and you can most likely disable it.

allow_url_fopen = Off
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /home/yourUserID/public_html/phperr.txt
expose_php = Off
magic_quotes_gpc = Off
magic_quotes_sybase = Off
register_globals = Off 

Robots.txt

Robots can add a minor a bit of security to your site by preventing search engines access to your plugins folders, a lot of security issues are caused by outdated, exploitable plugins and most often hackers use Google to find these sites. Ensure that your blocking plugins so people can't find them on your site.