Eduardo Fernández wrote:
Hi!
Some computers in my network are flooding the dns server with mx
queries generated by some virus, at a rate of 2/second or so. I can't
use the string match as suggested before because of my kernel version.
I can't forbid MX queries in the server because there could be valid
queries, so the only way to match the virus is the speed or number of
queries. I've tried the following to match only the virus but not the
normal clients (people surfing the web mainly):
iptables -A INPUT -p udp -d server_ip --dport 53 -m limit --limit
40/minute --limit-burst 2000 -j ACCEPT
But it doesn't work. Any ideas?
I don't know why this doesn't work, but I would probably take a whole
different route. As you say you could have matched with the string
match, you can write a tcpdump capture expression for those packets.
Feed the output to a short script that extracts the IP address and adds
a rule to deny any traffic to that IP address. This has the added
advantage that it breaks functionality on the client, so people will
complain. This makes it easier to spot the infected machiens. And maybe
slow the rate of spreading, who knows.
If those addresses are assigned by DHCP, make sure to clear the blocks
occasionally. Any (still) infected machine will simply readd itself in
no time.
Obviously, you hav to make sure that you add an address only once. This
also means that adding and deleting IPAs should probably coordinated
with a lock, though you may get away without.
Something along these lines (untested):
# iptables -N VDROP
# iptables -I INPUT -j VDROP
# mkdir /var/state/sumtin
# tcpdump -n -i <intf> <filter> | sed -P
's/^.*(\d+\.\d+\.\d+\.\d+).*/\1/' | while read ip; do
> if [ ! -f /var/state/sumtin/$ip ]; then touch /var/state/sumtin/$ip;
iptables -A VDROP -s $ip; fi
> done
(The ipset match is better suited for this, but if you don't have
string, you probably don't have ipset.)
BTW, you probably get better results with the limit match if you use a
shorter time and a lower limit.
HTH,
M4
