PHP Perils
Alas, the meanies have finally started to invade bostoncoop.net, my own little web/mail/email list server. I knew it would happen sooner or later, but I just wish attackers would focus on the bad guys.
First, I’m starting to see more and more spam in the various wikis hosted at bostoncoop.net. Apparently, the spammers have developed bots that insert commercial links into common wikis that don’t restrict access. I’ve gone through and manually removed the commercial links (although of course they persist in the wiki history).
I feel like I deeded my back yard as an open nature conservancy in public trust, and people are leaving cigarette butts all over the place.
I’m also experiencing fairly regular attempts to crack into the system by people who scour the web for PHP vulnerabilities. None of them have been successful, and I’ve been learning more and more about what I need to do to better lock down the system, but it’s still sad to have more and more volunteer sysadmin time going to these sorts of “nonproductive” uses.
A word of advice to any server admin newbies out there: if you have any place where people are allowed to upload files on your site, don’t call it “upload.php,” “upload.html,” or anything similar. I expect I could have avoided 99% of the PHP-based cracking attempts just by renaming the upload URL to something nonobvious. (I know this isn’t “real” security, but just about every attack I’ve seen starts with a google search for upload.php or something similar).
Another tip: most Apache/PHP installations run PHP as an Apache module rather than as a CGI script. This means that the standard means for controlling CGI—Options ExecCGI in httpd.conf and .htaccess—are ineffective. If you allow anything with a .php extension to run by default, you are inviting trouble (trust me). You would think it would be well documented and easy to find how to turn off PHP execution except where enabled, but in fact it wasn’t. The best solution I found was to put the following in httpd.conf for your site’s directories:
php_flag engine off
Then any user who needs PHP enabled can enable it on a directory-by-directory basis by putting the following in .htaccess:
php_flag engine on
I tried disabling PHP per-directory with RemoveType .php RemoveHandler .php in the .htaccess file, but this apparently had no effect.
As GNU/Linux and other free software enters the mainstream, it’s important for all of us to do what we can to maintain proper hygiene. There are plenty of people interested in exposing security failures in the free software world, and we should give them as little fodder as possible. The recent Mozilla shell glitch (affecting only Mozilla on Windows systems) may be only the tip of the iceberg.