[122944] in North American Network Operators' Group
Re: Security Guideance
daemon@ATHENA.MIT.EDU (Chris Adams)
Tue Feb 23 15:56:04 2010
Date: Tue, 23 Feb 2010 14:55:40 -0600
From: Chris Adams <cmadams@hiwaay.net>
To: Matt Sprague <msprague@readytechs.com>
Mail-Followup-To: Chris Adams <cmadams@hiwaay.net>,
Matt Sprague <msprague@readytechs.com>,
Ronald Cotoni <setient@gmail.com>,
Paul Stewart <pstewart@nexicomgroup.net>,
"nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <386FCF83D8086E4A89655E41CD3B53D359DF35766F@rtexch01>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
