There’s been a lot of talk today about a massive DDoS attack that has been running for the past week or so. It has used DNS amplification in order to create a 300Gbps storm of traffic aimed at Spamhaus, the anti-spam site that distributes blacklists of known sites responsible for sending spam email.
What is incredible is the coverage that this attack has received in the media, with headlines such as:
“Global internet slows after ‘biggest attack in history‘” – BBC
“Web slows under ‘biggest attack ever’” – The Telegraph
Even “The Sun” got in on the act with:
“‘Biggest cyber attack in history” slows down worldwide web“
At it’s heart though is a very simple process that can be exploited by anyone due to the nature of the DNS protocol. Sending a DNS query normally only involves a few bytes of data, for instance 30-40 bytes, but the response is nearly always larger. For instance, just sending a query for www.bbc.co.uk results in a 75 byte response:
> dig www.bbc.co.uk
; <<>> DiG 9.9.1-P2 <<>> www.bbc.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3974
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.bbc.co.uk. IN A
;; ANSWER SECTION:
www.bbc.co.uk. 98 IN CNAME www.bbc.net.uk.
www.bbc.net.uk. 98 IN A 212.58.244.68
;; Query time: 23 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Mar 27 20:38:44 2013
;; MSG SIZE rcvd: 75
So it is normal for a DNS query to be amplified. However, this can be taken to extremes by querying for a name that has much more data associated with it. In this case, the attacker used ripe.net, and because RIPE have enabled DNSSEC there is a lot more data being returned:
> dig any ripe.net
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.9.1-P2 <<>> any ripe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55219
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ripe.net. IN ANY
;; ANSWER SECTION:
ripe.net. 3475 IN SOA pri.authdns.ripe.net. dns.ripe.net. 1364388301 3600 600 864000 3600
ripe.net. 3475 IN RRSIG NSEC 5 2 3600 20130426124732 201
30327114732 20877 ripe.net. gVrcxPAK38517Ys0LhVoYCLWB7hgadJhKk6CnL37Jjq6+FdDXnsS
nmya nHE9+u11J34LJ6xDipe6b6bGjvhdLfoXbuwx4Lfmjv0UEEymllm+RG2q bDmFe1iMTF9SyuayKy
5cF4ShEZF78aT9/Mu0wir9pcepgBtF1wpnummM KNI=
ripe.net. 3475 IN RRSIG DNSKEY 5 2 3600 20130426124732 2
0130327114732 60338 ripe.net. K7LOaSOKT3EqVOmRstt3AUSKhcsAtb66dZqXB95JFvL/er5oCO
swDfRG oI5QKcElKlYd1NaDPUBYgnYSMeoj6tELJkYgXvOVm2OBGqCEbz4otR2+ F4Vq3WE1PNHjCSqI
7r8uxpJ8LY4VQtv1ayBPewe2HVUF0RNVpjEL/Jfx K1ykH/KySBNzoVnOxdUuIXZCAl6UbcYRTUJvSjE
J4HJPwLk2SRR/UWIV H9DCH/B+Kfa9EPRkBdmI+RrxVb1eoX+xWPUnM23YYQApnraqk7+U6xqu MMxnW
Q0eT8fUFtTcwUt4LLvgePu1bu5BW38/8bx5xFnEWPs+leMYDLRg EDtuWA==
ripe.net. 3475 IN RRSIG SOA 5 2 3600 20130426124732 2013
0327114732 20877 ripe.net. eXKdSs28uekr/lVA/7kPmeGvqIJlgpx6ELc6SLn9gkPmUSl2AV/B4
X+R qvIYf2N6ypG6yoBjnIx9wZJordPoT+ytMmYlH6qrG17piCNSCU5TZHj0 e8C80J+IdlqDzJRA0HT
luglQOjyuw/PZAr1AxUEQT6tGlay7SMhgiptW XHI=
ripe.net. 175 IN RRSIG MX 5 2 300 20130426124732 201303
27114732 20877 ripe.net. dodhz97p8nc9iRawSswEA8ntNFo2pfutnO6Bkvxive6Ih4CdTkpsnSu
l YkAqg87avCCe4sQqlUEjWGwrvf7uMHGS6SLjzP66j/zqozQ8ws7HwAPI nHVMHA8AIUq9jBxS9kl7u
jy+3ppSWtTdkkGdXuHeBMNPPHZSza3O4Fp8 uQQ=
ripe.net. 3475 IN RRSIG NS 5 2 3600 20130426124732 20130
327114732 20877 ripe.net. Jx1r6kqPjttkTPtpidQQ/fEM63pfwboWT5Ze6Si6asds9Evf/VF8vU
c+ LaHDz33QjuQY1doGnhiLWg/ZTzLXHtPj52UecBeQ1/FQ/pC37+T8G8uf yLR+t6Vk0WVEHvfPdXNJ
bNGfugwkR2CGUgg2XLMno9xVtduFzD7y3Lrr o9k=
ripe.net. 175 IN RRSIG AAAA 5 2 300 20130426124732 2013
0327114732 20877 ripe.net. hCaB/KrvM7uV25T7IGpppgZZix1yNnq5ZVgy3YWfxVtsuimmkGzEU
2Ec W5iJYRIYNet4a96sN21FZTw/ZHkdQ4gYlFOamb7ZHNJ9HEQ318FcwK24 4BrdyWuZGIBdUoaKDML
3n4Yp7jJDzpHiuQ6l6ei3/dfJqd65N8oPv4cZ UKE=
ripe.net. 21475 IN RRSIG A 5 2 21600 20130426124732 20130
327114732 20877 ripe.net. A3Z/X+JsPKKf9CYyKTggzd13l3SNLZXPcvqujhYhznW6sKzTya0jiO
kK 97sKF8kW08zOYFkXdwOaKfqUC/421wtoXOYgHd5jMtj5QMdjEXTIWKZp b2bhssiqdLUmI6b3GQMw
rZerKmv+6EtNUjjybLpPl8kDB+7qCv9YA3k8 v/E=
ripe.net. 3475 IN NSEC 256cns.ripe.net. A NS SOA MX AAA
A RRSIG NSEC DNSKEY
ripe.net. 3475 IN DNSKEY 256 3 5 AwEAAY+/Zk7l+YLyBrqQYGIK
7vubCGf4Wj7OaazXiKhsYVuor2lx6HEx LD9im3wx+m+H0OJSkFGoypNGxm+iFSp0ySblqrYHI2xlT8V
pmGi5TCSw dqwgLsyDirONOEVSl6q6x0pdAXu8yBvgjk39U8V5KbHs25g+v+txbBiU bh59ouIv
ripe.net. 3475 IN DNSKEY 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy/k
ZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk+Y7vZCvSN1AcYy0/ZjL7cNlkc3Ordl2
DialFHPI6 UbSQkIp3l/5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i
958WZJ6LI0pOTNK+BIx8u98b+EVr7C08dPpr9V6Eu/7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtm
JxDT067oJoNBIK+gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XS
Cm5sNxrRk=
ripe.net. 3475 IN DNSKEY 257 3 5 AwEAAYSPd7+AJXOT1k1d6eUK
RCsw5cSGpzsWIjVCDjbWdNomt4mCh5of SSnf60kmNCJgeCvPYwlOWX08TPLpCHqvBh8UERkaym8oT0U
2lKrOt+0W EyksYc5EnLp7HQVvH+KaF8XiuPsemLLNbhosGofv5v0Jj2TKxJI/sgf1 n9WtkMY1bCTTa
SUn5GmjKDv0XRPKkzA4RCQv8sl8pZ2pzJvIxpN0aBgx WtRjWXXJ27mUq6+PR7+zgBvLkmSV4F1bNXOg
ikeN5KBlutEKBKYYcYRb fR5kDYYJ0mV/2uTsRjT7LWNXAYAJ88xuZ4WcBV01EuMzsZU21iGhRO1N Z4
HFSr9jb3U=
ripe.net. 3475 IN DNSKEY 256 3 5 AwEAAYu6fDlb5CmcCtu5fl8V
c1q5ie9PaKW2+/HuM/0Cx1wCBJjPhK2Y 905asBZBErFgh2LoWqLX2bXN8gypLORkfeZLu6bZRCiQ6/n
IrHlO0S8l 9ajOChoh/kEQlHbEJETJ9Pw9OBW0oFRytjxjjhFIEpWeJ/c27JC8/ITs kGhvFByx
ripe.net. 175 IN MX 200 postgirl.ripe.net.
ripe.net. 175 IN MX 250 postlady.ripe.net.
ripe.net. 3475 IN NS tinnie.arin.net.
ripe.net. 3475 IN NS sec1.apnic.net.
ripe.net. 3475 IN NS sns-pb.isc.org.
ripe.net. 3475 IN NS ns3.nic.fr.
ripe.net. 3475 IN NS sec3.apnic.net.
ripe.net. 3475 IN NS pri.authdns.ripe.net.
ripe.net. 175 IN AAAA 2001:67c:2e8:22::c100:68b
ripe.net. 21475 IN A 193.0.6.139
;; Query time: 213 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Mar 27 20:42:28 2013
;; MSG SIZE rcvd: 2509
So the response has grown from 75 bytes to 2509. With a 30 byte query that is an amplification factor of 83!
Now imagine if you had control of a botnet that could issue these queries and spoof the source IP address so that the replies go to your victim. That is your classic DNS Reflective Amplification (DNS RAMP) attack, and is something I have been lecturing and warning about for years whenever I have run a DNS training course, I am just surprised it has taken this long for a massive attack to come to the fore.
Unfortunately this is a side-effect of enabling DNSSEC. While DNSSEC is supposed to guarantee the authenticity of DNS replies (i.e. they are who
they purport to be and haven’t been tampered with), it make DNS RAMP attacks much easier to carry out.
So what can you do?
The truth is, “not a lot”.
One problem is the number of open DNS resolvers on the Internet. These are DNS servers that anyone can query. You might have heard of OpenDNS and Google Public DNS, and may be wondering why these aren’t implicated? Well they use rate limiting to prevent malicious use of their infrastructure, so you wouldn’t be able to generate much traffic if you used their servers as you would soon get blocked or severely limited. However, the Open DNS Resolver Project has counted at least 27 million open DNS resolvers, so you have quite a list to choose from that won’t be using any rate limiting!
If you operate a network then you could configure BCP-38 (ingress filtering) to prevent routing people that are spoofing their source IP addresses on your network, but this won’t prevent you from being attacked, merely prevent you from being the source.
If you operate a DNS server, then really make sure it is not acting as an open resolver, if you need to do recursion, then use an access list to ensure only your users/customers can perform lookups. And if possible implement rate limiting so that if your users/customers get infected with malware that attempts to abuse your DNS servers, then their traffic will be dropped or severely rate limited.
Also don’t forget to monitor your DNS servers and keep an eye on normal traffic patterns so you can spot when something suspicious is happening. There are products out there that will do high-water analysis and alert if the query traffic suddenly exceeds the high-water limit (I was product manager in a previous role for one such product).
Another option is to invest in a cloud-based DDoS protection solution – there are several out there, but it has to be done in the cloud so that your ingress connections are not saturated with this traffic.
The reality is that this is a difficult nut to crack, and unfortunately due to the publicity this attack has generated, similar attacks will probably become more prevalent.
If you are concerned about your DNS infrastructure and need some independent advice as to the best way to configure or protect your environment, please contact us and we will gladly help.
About Paul Roberts
