RE: we were attacked
Hi!
I had similar problems in the past and two this week.
So what it is? People (no, they aren't hackers :) try to use your resources
for their "actions". These scripts are mainly irc bots waiting for commands
and can perform actions like googling for other vulnerable servers, doing
udpflood and so on. So part of the solution is to block port 6667 in
firewall :) It's not enough, because not all irc servers use this port, but
it sometimes prevents the running script from consuming your bandwidth and
lot of CPU.
Another script was something which sent more than 7000 spam emails using
php... Not good...
And how these scripts came to your/my server? The answer is PHP. There are 2
main possibilities:
1) command injection - for example in phpbb or mambo cms - badly written
scripts... It's relatively easy to block it using mod_security (just block
something like cd%20/tmp) and it's relatively easy to find it in logs - look
for "wget", "/tmp"...
2) also badly written scripts, which allow inclusion of remote files -
example: <?php require($a); ?> Just imagine what happens if
$a=http:///bad_server/bad_script.gif
This script's content (code) gets executed on YOUR server. It's hard to
find, because the actual commands executed (wget, tar, ...) are not in logs,
only url of the evil script. And there are log of URLs in apache logs :) I
found it by looking for "=http" in logs, but also many other lines matched
(lines with google as referer, ...)
And it's not so easy to block - only solution is to turn allow_url_fopen
off. But a lot of scripts make use of it. It would be better if it could be
turned off only for include/require and not for fopen()/file().
Register_globals won't help here, because many scripts (badly written) make
use of that require. And you can't control all your customers php scripts.
Example:
Index.php?frame=about.php
In index.php, there is require($frame), but script does not validate if only
valid filename was passed.
Solutions (please contribute if you have any ideas):
1) /tmp noexec, better also /var/tmp (not useful if evil executes "perl
/tmp/.evilscript")
2) allow_url_fopen off (on only when requested by customer)
3) mod_security
4) use wrapper for emails - I have one which includes special headers to
mails sent from php, I'm going to modify it to support limits on no. of
mails sent in timeframe
Oh and what "attack" look like: download tar archive to /tmp, uncompress it,
run script. In script itself, usually change $0 so that in "ps" it looks
like mysqld or inetd. Also destroys environment to make it hard determine
from where the process started.
> -----Original Message-----
> From: danilo lujambio [mailto:danilo@tau.org.ar]
> Sent: Friday, April 07, 2006 4:50 PM
> To: debian-isp@lists.debian.org
> Subject: we were attacked
>
> Hi,
>
> in one of our servers with Sarge we are suffering an attack
> wich put a perl script and two executables in /tmp with owner
> www-data.
> We couldn't find any data in messages , syslog, apache.log
> which help us. We have a shorewall with very few ports open
> (ssh , ftp and web) .
> Can someone help us in how to looking for the source of the attack ?
>
> thanks in advance
>
> d.l.
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
Reply to: