On Mon, Dec 17, 2012 at 02:57:28PM -0500, Patrick, Robert (CONTR) <[email protected]> wrote a message of 36 lines which said:
> mitigation is available at the O/S and network layer. As an > example, there are connection limits that can be enforced with > iptables on Linux. The attached mini-HOWTO may be interesting to some.
[Not public] If you have a DNS server used for reflection+amplification attack *and* it is a Linux machine *and* you have Netfilter >= 1.4 *and* you cannot or does not want to install the patches for BIND or NSD to do rate-limiting (they may provide a better result) *and* the attack is over IPv4 *and* the attacker uses only a few domain names, you could be interested in this technique. Disclaimer: it works for us, it will not work for ever, it works now. The idea is to use the Netfilter u32 module to recognize the attack, then to rate-limit it with the Netfilter hashlimit module. First, get the iptables rules generation script <http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py>. Then, look at the traffic so see the pattern: what query type (typically ANY), what query domain name, etc. In the examples, we'll assume QTYPE=ANY, QNAME=example.net. Then, generate the Netfilter rule: iptables -A INPUT -p udp --dport 53 -m u32 \ --u32 $(python generate-netfilter-u32-dns-rule.py --qname example.net --qtype ANY) -j RATELIMITER The RATELIMITER chain can be: iptables -A RATELIMITER -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP or you can replace -j RATELIMITER by -j DROP of you want to be radical. There are more options in the generate-netfilter-u32-dns-rule.py script, such as --bufsize=NNN if the attacker uses a fixed EDNS buffer size (some do). There are several ways for the attacker to work around this technique (some obvious and some not so obvious). I will not describe them here but my point is that it works *today*, with *actual* attacks. So, it definitely helps but keep your eyes open, have alternative solutions in place and do not put all your eggs in one basket
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
