Security Guideance

Tue Feb 23 23:19:11 UTC 2010

> The problem is that a user on this box appears to be launching high
> traffic DOS attacks from it towards other sites.  These are UDP based
> floods that move around from time to time - most of these attacks only
> last a few minutes.
> 
> 
> 
> I've done tcpdumps within seconds of the attack starting and to date
> been unable to find the source of this attack (we know the server, just
> not sure which customer it is on the server that's been compromised).
> Several hours of scanning for php, cgi, pl type files have been wasted
> and come up nowhere...

As others have suggested turning off remote file includes is a good start in
php.ini. PHP5 has some rather nice settings to allow more flexible
configuration of this (while still allowing PHP programmers to be lazy and
do things like file('http://foo/index.php') but I digress).

Plesk uses open_basedir by default on its Apache config which will help
limit what the hacker has access to via the web daemon. However it still
allows unrestricted access to /tmp for obvious reasons. We generally set
/tmp to be noexec and nosuid for our disk images. This helps make things
more difficult for the script kiddies, but doesn't stop them completely.

Most likely since you are dealing with customer data that must be maintained
from each instance of the server and that is most likely the attack vector
being exploited (since it is common to each instance of the server). Either
a PHP based shell, something as simple as a file uploader/shell script, or
the aforementioned remote file include is likely the cause. 

They are most likely uploading a perl script to /tmp, firing it off with a
shell command via the apache user, then removing it from /tmp and masking
its program name so that it doesn't appear obvious in a report from ps (I
have seen httpd most of the time, which is fairly obvious to spot on a
Debian server thankfully - apache runs as apache(2) on Debian rather than
httpd on RedHat/CentOS).

If you are able... I would create a noexec,nosuid /tmp mount and if at all
possible... limit perl to only be accessible for the root user (chmod 700).
This is a tad extreme, but it has helped me in the past. Another thing (if
that isn't possible) is to place a wrapper around perl that will log what
user accessed perl, at what time, and which script was executed. This
information will prove to be invaluable in helping narrow down where the
attack is originating. Once you have a timestamp, it's just a matter of
going through your logs to find what was going on where at that specific
instant on the server.

Also take a look at the server wide apache logs (in /var/log) as there might
be valuable information in there perhaps leading you closer to a culprit.

Good luck, these sorts of issues are difficult to track down and take time
and patience to clean up.

If you would like please contact me off-list for more assistance. I have
been using Plesk since 1.0 so I am pretty familiar with its ins and outs.

Warm regards,

Tom Walsh