I administer one server here in Bombay that was infected (quite some
time ago), so my tuppence...
Raju Mathur forced the electrons to say:
> 1. If you don't need to, DO NOT run a nameserver. If you absolutely
> have to, do the following:
> - Only allow queries from your local IP's. In the options
> section, put:
>
> allow-query 127.0.0.1 ;
>
> OR
>
> allow-query 192.168.0.0/24 ;
>
> [Or whatever your local IP addresses are]
This cannot hurt, but since the exploit I think uses a vulnerability in the
zone transfering code in bind, you should also put
allow-transfer 192.168.0.0/24;
in the options section of named.conf. Repeat for every network that is in your
LAN.
Another thing you can do is to ipchain out your internet interface to refuse
name server connections. I had used this to log the offending bind connections
(I have a list of about 30 IP addresses that tried to connect to my server,
from all over the world). Something like this in your rc.local or ip-up.local:
/sbin/ipchains -I input -p tcp -i ppp0 --dport 53 DENY
/sbin/ipchains -I input -p udp -i ppp0 --dport 53 DENY
(DENY is better than REJECT - let the scanner time out, wasting its time ;-)
> 2. Upgrade to the latest (9.x) BIND immediately. I cannot
> overemphasise the importance of this step.
I think the recommended upgrade is to 8.2.3. 9.x series still have
performance problems, I believe. All major vendors have 8.2.3 upgrades
(indeed, within hours of the original CERT advisory).
> 6. Use your package manager to verify checksums of all binaries.
> This will take some time, but it's worth it. With RPM, you can:
And also check in /etc/inetd.conf for unauthorized shell lines, like
31337 stream nowait root /bin/sh sh -i
(This is almost exactly what the worm puts in, only the port number changes).
> rpm -Va > /tmp/RPM-Va-OUT
>
> Pay special attention to files in executable directories which have
> the ``5'' (MD5 checksum failed) flag on: if you don't recollect having
> changed these files, someone else has!
Highly recommended. The worm does not affect the RPM database, it seems.
> 9. Store a tarball of /var/log/ on some safe system if you've been
> infected. Post-mortem analysis is as important as prevention.
Better still, log to a different machine as well, using syslog. Though the
worm kills syslogd as a side effect.
> This is not a comprehensive list, but on Sunday morning it's the best
> I can do at short notice -- I've only had 2 cups of tea so far and I
> don't really start thinking till about the 5th :) I'm sure Suresh
> would be coming up with a HOWTO on stopping mail going to China.com.
Lucky you ;-) Anyway, the mail sent to china.com bounced in my case (which is
what brought the worm to my attention) because the worm used the from
address as [EMAIL PROTECTED], which was rejected by china.com's
MX saying 'sender domain must exist'.
Also, download the worm detector from
http://www.sans.org/y2k/lionfind-0.1.tar.gz and run the program. It will give
out a list of suspicious files/directories on your system.
Binand
----------------------------------------------
Find out more about this and other Linux India
mailing lists at http://lists.linux-india.org/
