BIND 9 DoS attacks in the wild
Earlier today Marc posted a short diary about a vulnerability in the Internet Systems Consortium's BIND 9 (all versions). As you almost certainly know, BIND is the most popular DNS service application running on majority of DNS servers today – and DNS is one service that we *really* need.
As the DoS attacks have been seen in the wild, and simple scripts that can be used to reproduce the attack are also easily available, this is not really surprising.
I wanted to draw your attention to this vulnerability (if you are running a BIND DNS server) – although the vulnerability exists in the dynamic update feature of BIND, even installations that have dynamic updates disabled are affected! This makes this vulnerability especially dangerous.
Only servers hosting master zones are vulnerable though, so even if the master DNS servers are down, all slaves should still continue to work (I'm not sure what happens if those slaves are masters for some other zones and they are subsequently taken down).
No workarounds exist – you might be able to create some firewall rules that will drop these packets though. In any case, it is recommended to upgrade your BIND DNS servers urgently from https://www.isc.org/node/474
--
Bojan
Web App Penetration Testing and Ethical Hacking | Munich | Oct 14th - Oct 19th 2024 |
Comments
ThreatSTOP
Jul 29th 2009
1 decade ago
Also they are BCP and part of Team Cymru's secure bind template. ;-)
ZaphodB
Jul 30th 2009
1 decade ago
BTW: the public Threatstop.com zones, and the servers that serve them, are not protected in this way. W're in the same boat as everyone else eon that one.
So, if you're using the Dshield lists in public DNS (basic*.threatstop.com), I'd recommend signing up for the basic ThreatSTOP service. It's free to try, and since the original team is now back in control (as of yesterday), we're going to keep Basic/DShield free (as in beer, you'll have to send logs) forever.
ThreatSTOP
Jul 30th 2009
1 decade ago
iptables -I INPUT -p udp --dport 53 \! -f -m u32 --u32 "0>>22&0x3C@8>>11&0x05=5" -j DROP
iptables -I INPUT -p tcp --dport 53 \! -f -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@2>>11&0x05=5" -j DROP
this is working for me, but small fragments still can slip by probably
tk
Jul 30th 2009
1 decade ago
vom
Aug 1st 2009
1 decade ago
anyway it's working (in lab), it's the same, just in 0x
#iptables -I INPUT -p tcp --dport 53 \! -f -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x2>>0xb&0x5=0x5" -j DROP
# iptables -nvL
Chain INPUT (policy ACCEPT 462 packets, 36250 bytes)
pkts bytes target prot opt in out source destination
6 636 DROP tcp !f * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 u32 0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x2>>0xb&0x5=0x5
tk
Aug 2nd 2009
1 decade ago
vom
Aug 3rd 2009
1 decade ago