My phone got a call recently from a systems administrator whose network was under attack. I was busy getting my twice-weekly dose of humility, but a couple hours later, my phone delivered the message.
The attacker was flooding their primary DNS server with requests for isc.org. This is a not-uncommon attack. As DDos attacks go, it’s not terribly effective; it can overwhelm the DNS server’s resources, but doesn’t utterly destroy the victim’s network. You can easily defend against this by controlling which hosts can perform recursive lookups on your server.
This particular sysadmin was running a DNS server that didn’t permit access control for recursive lookups. It ran fine for years, until someone wanted to attack it, much as your house doesn’t need a lock on the door until someone tries to break in. We discussed various ways he could blunt the attack, and a strategy for moving to a public-facing DNS server that supported access control lists.
I could start with “here’s a nickel, kid, go buy a better operating system.” But that’s not exactly helpful. A lot of Unix sysadmins are just as guilty of offering insecure services on their networks, thinking that nobody is going to attack their petty little operation. But you never know when you’ll anger some dweeb who cannot express their emotions in any way other than clicking a few buttons and giggling. This particular sysadmin had run his server for years without difficulty. But you only need to lock your car when someone tries to steal it.
If you’re running a DNS server, use one that supports ACLs. I’ve written about unbound as a recursive DNS server. Or, if you’re running BIND, you can use an ACL:
options {
...
allow-recursion {our_stuff; };
};
acl "our_stuff" {
192.0.2.0/24;
};
Poof! Recursion attacks are stopped.
Nobody wants to attack you? Nobody will EVER want to attack you? You are such an awesome human being that you will never accidentally annoy someone? Fine. I believe you. Wholeheartedly But did you know that open DNS resolvers can be used to amplify DNS-based DDos attacks? And these attacks are growing more common? And that a large number of Internet appliances have open resolvers? Do you issue those devices to your clients? Open resolvers are the new open mail relays.
Today is a good day to check your network for open resolvers. Or you can use a free shell account to run dig against your servers. Check your appliances, too.
This principle applies to services other than SSH, of course. Use keys to authenticate via SSH, or at least restrict the IP addresses that can log in via passwords. Apply your patches regularly. Think about what you’d do if you were under attack, and the points on your network where you could defend. You probably already know about some security holes on your network. Quit playing Angry Birds and go fix them.
But if you run an open resolver, you are ruining another sysadmin’s weekend.
I just checked… mine are closed… supposedly.
Hello Michael,
the configuration example might not be correct for all versions of BIND. the Administrators reference manual (ARM 9.7) Section 6.2.2 says (and that is my experience with ACLs): “Note that an address match list’s name must be defined with acl before it can be used elsewhere; no forward references are allowed.”
Also, ACL names must not be quoted. If they are quoted, the quotes are part of the name.
I would recommend:
acl our_stuff {
192.0.2.0/24;
};
options {
…
allow-recursion {our_stuff; };
};
— Carsten
BIND version < 9.5.0 had an implicit 'allow-recursion { any; };' setting, thus allowing recursive services to anyone. All BIND versions 9.5.0+ have an implicit 'allow-recursion { localnets; localhost; };' which restricts recursion to all locally attached networks (build-in ACL 'localnets') and all IP addresses of the local machine (build-in ACL 'localhost').
Anyone running a BIND version older then 9.6 should upgrade ASAP, as older versions are vulnerable to the 'Kaminsky style' DNS cache poisoning attack, and other security issues. The most current versions of BIND as of today (March 9th, 2011) are 9.7.3 and 9.8.0. The sourcecode for BIND can be downloaded from ftp://ftp.isc.org/isc/bind/
Binary pre-compiled packages are available for free from some places on the Internet. If you use a binary package, make sure it comes from a trusted source.
If you upgrade your BIND from a pre-9.5.0 version, and you offer recursive DNS services to clients, please check the 'allow-recursion' setting to match your networks.
ISC has more information on the DNS DDoS issue: http://svsf40.icann.org/meetings/siliconvalley2011/presentation-dns-amplification-ziegast-13mar11-en.pdf
Hello I’m attacked by this recursive dns ddos no one can help me?
14:33:21.958930 IP (tos 0x0, ttl 54, id 24754, offset 2960, flags [none], proto: UDP (17), length: 79) 213.92.5.193 > 174.127.100.67: udp
14:33:21.958931 IP (tos 0x0, ttl 52, id 11765, offset 0, flags [+], proto: UDP (17), length: 1500) 64.78.227.126.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 27/0/6 isc.org. SOA[|domain]
14:33:21.959034 IP (tos 0x0, ttl 49, id 57369, offset 1480, flags [+], proto: UDP (17), length: 1500) 137.82.1.1 > 174.127.100.67: udp
14:33:21.959036 IP (tos 0x0, ttl 49, id 57369, offset 2960, flags [none], proto: UDP (17), length: 795) 137.82.1.1 > 174.127.100.67: udp
14:33:21.959037 IP (tos 0x0, ttl 49, id 57369, offset 0, flags [+], proto: UDP (17), length: 1500) 137.82.1.1.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 28/5/9 isc.org. Type46[|domain]
14:33:21.959219 IP (tos 0x0, ttl 54, id 2405, offset 0, flags [none], proto: UDP (17), length: 64) 204.111.1.35.53 > 174.127.100.67.25345: [udp sum ok] 10809 Refused- q: ANY? isc.org. 0/0/1 ar: . OPT UDPsize=4096 (36)
14:33:21.959221 IP (tos 0x0, ttl 53, id 12185, offset 0, flags [none], proto: UDP (17), length: 735) 207.45.187.10.53 > 174.127.100.67.25345: 10809- q: ANY? isc.org. 0/13/23 ns: . NS[|domain]
14:33:21.959247 IP (tos 0x0, ttl 54, id 24755, offset 1480, flags [+], proto: UDP (17), length: 1500) 213.92.5.193 > 174.127.100.67: udp
14:33:21.959249 IP (tos 0x0, ttl 54, id 24755, offset 2960, flags [none], proto: UDP (17), length: 79) 213.92.5.193 > 174.127.100.67: udp
14:33:49.649189 IP (tos 0x0, ttl 244, id 49264, offset 2960, flags [DF], proto: UDP (17), length: 218) 216.228.160.3 > 174.127.100.67: udp
14:33:49.649197 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 844) 140.186.1.4.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 8/5/3 isc.org. Type46[|domain]
14:33:49.649199 IP (tos 0x0, ttl 245, id 61022, offset 1480, flags [DF], proto: UDP (17), length: 1260) 167.206.7.3 > 174.127.100.67: udp
14:33:49.649253 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto: UDP (17), length: 999) 66.7.142.78.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 10/5/2 isc.org. Type46[|domain]
14:33:49.649264 IP (tos 0x0, ttl 57, id 330, offset 0, flags [DF], proto: UDP (17), length: 816) 64.136.164.66.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 8/5/2 isc.org. Type46[|domain]
14:33:49.649266 IP (tos 0x0, ttl 245, id 61022, offset 0, flags [+, DF], proto: UDP (17), length: 1500) 167.206.7.3.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 25/0/4 isc.org. TXT[|domain]
14:33:49.649463 IP (tos 0x0, ttl 54, id 56940, offset 0, flags [+], proto: UDP (17), length: 1500) 208.72.120.204.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 27/0/6 isc.org. NS[|domain]
14:33:49.649465 IP (tos 0x40, ttl 55, id 0, offset 0, flags [DF], proto: UDP (17), length: 51) 68.87.64.154.53 > 174.127.100.67.25345: [udp sum ok] 10809 Refused [0q] 0/0/1 ar: . OPT UDPsize=4000 (23)
14:33:49.649571 IP (tos 0x0, ttl 55, id 31247, offset 0, flags [none], proto: UDP (17), length: 64) 82.96.64.2.53 > 174.127.100.67.25345: [udp sum ok] 10809 ServFail q: ANY? isc.org. 0/0/1 ar: . OPT UDPsize=4096 (36)
14:33:49.649621 IP (tos 0x0, ttl 54, id 56940, offset 1480, flags [+], proto: UDP (17), length: 1500) 208.72.120.204 > 174.127.100.67: udp
14:33:49.649622 IP (tos 0x0, ttl 54, id 56940, offset 2960, flags [none], proto: UDP (17), length: 30) 208.72.120.204 > 174.127.100.67: udp
14:33:49.649670 IP (tos 0x0, ttl 52, id 36728, offset 0, flags [none], proto: UDP (17), length: 713) 66.54.147.122.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 3/6/13 isc.org. Type46[|domain]
14:33:49.649671 IP (tos 0x0, ttl 111, id 6506, offset 0, flags [none], proto: UDP (17), length: 1203) 192.219.63.253.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 17/0/7 isc.org. A 149.20.64.42, isc.org. NS[|domain]
14:33:49.649682 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto: UDP (17), length: 64) 65.87.16.20.53 > 174.127.100.67.25345: [udp sum ok] 10809 Refused q: ANY? isc.org. 0/0/1 ar: . OPT UDPsize=4096 (36)
14:33:49.649685 IP (tos 0x0, ttl 56, id 16089, offset 0, flags [+], proto: UDP (17), length: 1500) 209.183.192.65.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 30/4/8 isc.org. Type46[|domain]
14:33:49.649816 IP (tos 0x0, ttl 53, id 28153, offset 0, flags [+], proto: UDP (17), length: 1500) 206.169.105.253.53 > 174.127.100.67.25345: 10809 q: ANY? isc.org. 27/4/8 isc.org. Type99, isc.org.[|domain]
14:33:49.649855 IP (tos 0x0, ttl 56, id 16089, offset 1480, flags [+], proto: UDP (17), length: 1500) 209.183.192.65 > 174.127.100.67: udp
this attack appears to reach about 8 gigabits