Discuss mailing list

[Larry Brower <larry AT maxqe.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/28/2010 09:51 PM, Jeff Taylor wrote:
> Today I have been seeing more varied traffic causing similar problems. 
> I seem to get a flood of traffic every now and then, and then it will
> disappear for a few hours.  Initially I was blocking by IP again to
> regain my connection, but that is such a heavy-handed approach and I'm
> not happy with it.
> 
> I've been digging into this more, and found some interesting info. 
> First off, in every case (both the other day and today), the queries
> always have this specific string in common:
> 
> query: isc.org IN ANY +ED
> 
> I started digging on google and immediately found some interesting
> info.  First off, isc.org is the group responsible for BIND.  Second,
> there are MANY reports of DNS based DDOS attacks, always pointed at
> isc.org, and always using the ANY flag in their query.  The nature of
> the attack is that for a very small query, it returns a huge amount of
> data.
> 
> This brings up a question: Is this attack (using the OpenNic DNS servers
> as the attacker) aimed at isc.org, or is it geared towards rendering
> opennic servers inoperative?  I don't know that we have a way to answer
> this question.
> 
> So what do we do about this situation?  Judging by the info from google,
> the attacks are being propagated by botnets, so we can't just simply
> start creating a list of blocked IP's, or it would quickly get out of
> hand.  Since there is such a specific message being shown in my log
> files, I thought perhaps something like fail2ban may be useful... block
> the offending IP for a set period of time, then clear the ban. 
> Unfortunately I wasn't able to find any useful info on how to create my
> own rules under fail2ban... perhaps someone else would have experience
> with this?
> 
> My next option is using a rule under iptables.  It has the ability to
> limit traffic to a set number of packets within a timeframe.  This seems
> like a good option to do real-time traffic limiting without permanently
> banning and trying to manage a list of IP's.  So at the moment I am
> testing the following rule:
> 
> iptables -A INPUT -p udp --dport 53 -m limit --limit 20/s --limit-burst
> 40 -j DROP
> 
> This rule should limit DNS packets to 20 per second, but allows an
> initial burst of up to 40 packets.  That should be more than enough for
> any normal traffic to come through, but still limit how much traffic the
> server is willing to handle from a single source.  During one of the
> 'attacks' earlier today, I tracked a single IP requesting around 4,000
> queries per minute for over 6 minutes -- well over any reasonably
> expected traffic.
> 
> Now I say this rule 'should' limit traffic, because as I type this I am
> seeing another wave coming through from two IP's that prompted my blocks
> earlier today.  Apparently the rule is not doing what I expect as my
> bandwidth jumped from about 10Kb/s to over 1800Kb/s (two IP addresses
> slamming me with about 16,000 queries in 3 minutes).  So again, if
> someone else has more experience with iptables, I've love to see a
> proper rule for this situation.
> 


This sounds like a DNS Amplification attack which has been going on for
years. The IP you are seeing is most likely spoofed because the attacker
sends a small query to you as a recursive server and you send back the
entire RR set for ISC.org. This is part of the reason the ICANN root
servers do not do recursive DNS and authoritative servers are not
supposed to do recursive dns.

You may want to view the NANOG presentations on the subject at
http://nanog.org/presentations/archive/index.php

Just search for dns amplification



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJNGrLnAAoJEBgaXYoZ++873AcIAKeH4vkaojx9noNq0qkt6Gta
hdrMFbvuN5yaMV5g0gy/sXbllcOZg7+jhi86Arv59CgmxRVdXcEjIMLayR3gthIz
4ppRgUSIQqAeY8eRSug5IDwdXLK+pQ1xl0fbPF/TXiOVDH11JazvZ6qR1mFivTuF
uEIMR3B1hBvxHXuxAknTooRaj5TjnpYvD3AZqW87b66tA1vd/iJZP6F1Xm7/8O2+
7xHfT3EBZdI8AQCPjddcrfktxFoN2HO6AY02o60/6UC+DdlRWBK2P6ugmWKyTh0z
3/gxdsM4Aerl6yoPsYzgOh/QY1M0mHwRzN7SCG1zRBy5u6fNAlujnKe+MSz5cUQ=
=Xtfv
-----END PGP SIGNATURE-----