DNS Reflection

From Colin Hardy
Jump to: navigation, search

TL;DR


DNS Reflection is one of the most common network attack types seen across organisations. Bad guys can launch a DNS Reflection attack pretty easily as it uses the UDP transport layer meaning that packets are 'fire and forget'. It is also very straight forward for a bad guy to spoof a DNS packet without any trace of who they are. Pretty cool if you're a bad guy. Investigating the source of a DNS Reflection attack therefore is a pretty impossible task given the bad guy can spoof the source of the packet in order for a server to reflect its reply. The server that reflects the traffic is used as a middle man to deliver the unwanted traffic to the victim's server. Using this attack vector, Threat Actors can deliver very large volumes of data to the victim, with very little overhead on their end. This is known as bandwidth amplification, and I'll demonstrate an example below.

Example


Let's take a look at an example to make things a little easier to imagine:

Dns-reflection.png

A bad guy crafts a DNS packet and spoofs the source address within the packet to be victim.com. He then sends the packet to a an Open DNS Resolver, which is a DNS server in the wild that will happily return a response to a DNS query from most any IP range. In best practice, network operators would restrict who can use their DNS resolver to be from IP's of authorised clients, but LOTS of network operators do not and therefore the internet is literally littered with DNS servers that will resolve openly.

Of course, in reality Threat Actors don't just send one or two packets, but many hundreds of thousands, if not millions and likely employ the use of a botnet to distribute their requests. Using open source tools, it is very simple for bad guys to craft their packets, spoof the source and direct very large volumes of data at the victim's front end.

Amplification


The overall aim of the DNS Reflection Attack is to consume bandwidth on the victim's server, rendering it unusable for legitimate traffic. Bad guys can achieve this by flooding the servers with large volumes of data. DNS is perfect for this as it's easy to generate very large responses from very small inputs (known as amplification). Take the following request:

dig ANY google.com @8.8.8.8

This is a 64 byte query. Pretty small. It yields the following response (note, I've used the IP of Google's DNS Resolver, this is safe to use by anyone and has protection mechanisms to prevent bad guys from utilising it in attacks).

; <<>> DiG 9.8.3-P1 <<>> any google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8124
;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.			IN	ANY

;; ANSWER SECTION:
google.com.		299	IN	A	31.55.166.217
google.com.		299	IN	A	31.55.166.214
google.com.		299	IN	A	31.55.166.212
google.com.		299	IN	A	31.55.166.213
google.com.		299	IN	A	31.55.166.215
google.com.		299	IN	A	31.55.166.219
google.com.		299	IN	A	31.55.166.216
google.com.		299	IN	A	31.55.166.218
google.com.		3599	IN	TXT	"v=spf1 include:_spf.google.com ~all"
google.com.		21599	IN	TYPE257	\# 19 0005697373756573796D616E7465632E636F6D
google.com.		21599	IN	NS	ns3.google.com.
google.com.		21599	IN	NS	ns1.google.com.
google.com.		21599	IN	NS	ns2.google.com.
google.com.		599	IN	MX	30 alt2.aspmx.l.google.com.
google.com.		599	IN	MX	20 alt1.aspmx.l.google.com.
google.com.		599	IN	MX	50 alt4.aspmx.l.google.com.
google.com.		21599	IN	NS	ns4.google.com.
google.com.		59	IN	SOA	ns3.google.com. dns-admin.google.com. 128604794 900 900 1800 60
google.com.		599	IN	MX	40 alt3.aspmx.l.google.com.
google.com.		599	IN	MX	10 aspmx.l.google.com.

;; Query time: 38 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 27 19:51:48 2016
;; MSG SIZE  rcvd: 461

The response is 461 bytes. So, 64 bytes in, 461 bytes out. Not bad.

But bad guys can do better. What about querying a domain which has a lot more information in the DNS record. Maybe the domain uses DNSSEC and publishes they crypto keys in the record:

dig ANY cpsc.gov @8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> any cpsc.gov @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52223
;; flags: qr rd ra; QUERY: 1, ANSWER: 22, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cpsc.gov.			IN	ANY

;; ANSWER SECTION:
cpsc.gov.		9264	IN	SOA	auth00.ns.uu.net. hostmaster.uu.net. 994577 1800 600 1728000 21600
cpsc.gov.		9264	IN	RRSIG	NSEC3PARAM 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. Mk+p1CZXv8WnE8AAN9IfW11XFkBjfy7mh69LHBlLc3yvGTuyAMCglk9X dTUveSFQ0mhoWf2QMJ4s1rbX1uP1vkP7WcxjLPVa49t+a015bKIRzuGw JMClYpsswNGGjV8bsENnC1kpKPMhyAd42ctMmk2orDqQas+TlRWav/Kc Nm9+hUGI19cUjes2nLtVcvowPZYeng3STOJyHxGCNjohE8EA0kCK1Z1P iQnE1kRoRDvVedrFY/vf+Oqb9H6GriB3VsVNK5KWhwP9ltIEubGTXl5u Cyu7SU66ybOA+Yw4HDXUPMkShRbPRJEbjnls080/lVP+rMW8vFCTUvz6 gzXTtg==
cpsc.gov.		9264	IN	RRSIG	DNSKEY 7 2 21600 20160803030502 20160727020502 4696 cpsc.gov. RNPyMnqbe3MLjoq4SjdJJ5tCrBRjCTy0vhty45uJyWZY6TkhHdhHr/fL JrE3Y/MmiSQEf8UzT7bts/iv7FzLvi/S4RwuDIZ4sd+lnoo5HVBb0iay b47KoUTD7podn8G9kwI6NRHb2xOQTOnC21joJJUzw8cdII3WA0ZrApPm OhuSSTmi+OooF056HBqUxjQST0kBec38mzx/V+Qw+azGE6wbNP9kcPEu i9QWlTQmaUaWmfcmI3BJYhXQyIj1Wzkzu0lQdmmiI7ids+RVERjHQdit Z288KjvOvYtvIZSl0zhbeEJSbtIm92MPwtHPgxmEwXkJ6y6ryLVBGmrG /XmOMQ==
cpsc.gov.		9264	IN	RRSIG	DNSKEY 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. G/Y0b6a+j0Od/5unpi+XHmWJi668ZK6gDB7PN92ARCDICUqQZRqr3vMx 9o7gShNj/E/yWPf8bBU/5KdomtWqCPBqobQiOnHTjzRJC/QJ8MSgLXHI Ulu+aq01MsZ/Nt3PhUrP6ujnMc0P18xNpEqYFt71dnHBuV+0rgOFEM9m MeYJeYnHYvfa0MnDQ0g3pBmwEPrXEM5YVuvGccA783LV9152Kyti0jV1 PECvkfUGgAVOnErGbnodw+aI0q6Dtwu7TM0WiTFo+UDJ6PnME3aeyo+X Za9kUig7hLGEL901EhYSdPythV4/JPiPxmd5rxop8Af6kH86MbI5LiPs mQ8jPA==
cpsc.gov.		9264	IN	RRSIG	SOA 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. kFwoB292+8QXQXjmsFE70++cBS73itnY3ATB87tJDmQJLRSE7ApoAszF wOId/FGcmfbTp5nrqxPevvQjum55URh6Ht0JZNvr+VrGkIeW6AWKEuuc 0Qzv4u2wEyyuZrCPxJTgA1s4MX4HzIHWVejKdQkQBL3vLfzV1xyMdj77 MjT0tnyjWjzOp1NPx9PkGBd6cw8SCYEe3OsQkY7JXFHKu+SLIrQA0kYW pW8sdt+abn7VEoOYSOsMzYQ6mQ7MEvqLOIKi6EwRZBl9kTAhJ4hU1uwM 8jo6Isg/fm3O5TCdcGvS9fYIfFAHa/jGSUDYIaEqN8GouEMlgZu/cRgF zuMKWA==
cpsc.gov.		9264	IN	RRSIG	AAAA 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. aItUxMnMZ2rAROkFqqpmWg2SVsncMDQX85w8Mq4cMJmG0lj1ZLyFy3dY 7lOzIfu1NKxAf0uLWaZ5WWjkBryvTrajJBMLrEt7g0dPCt3fYcBL9aey S4GJJlRTjegDDn/UCZ25W2oNa+q6ZrhWForIRAOmmbqRyeqSYA/FlC9G ZynghKKONAH1jjjr7JccVvl0hZXTHb5CwxDGcWVLTq+oHGnLUoJnU3VE cfxFq1rInLmYyQxmLn2cOxhF9qgbY5CsoZZTSICXW22Lv10xwJ5iQif1 nCw8O6bNeKkHU659WxjFRmc/Hu5mFkYYXikXY9UQDi67NANT+zn8nFbB nDhEXQ==
cpsc.gov.		9264	IN	RRSIG	A 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. IRvYeGp53k7tDfnFXN1jtVA2leA+/Fmox9/auzNe5h/fzGia4JWwPdKo +brGF/uhWsh5l+6fp8pIa4auKodTPuOxoDF8Yru4hue/koc77Nln9psO EhMA4usvtXREny6DGW8+2h1QyTg2RfCMWE16SCZT9AFtuAY8cJCUL/Ox BNGUrrXHUyWIARNrMVTIrnxy2Ry2/rv28OF0eE8eYSC5H/9kvESkp+j3 06Wz3fuEa4bawidBU6SnBgfE7xwWZgIgW2pCJGJS2QNHtGnggSvrF2zl z32REsjhXzd4ESjnKnF+M/A0OGba7cn/Pugh+PRPOJlKvxxU88OaBrKp h3iffA==
cpsc.gov.		9264	IN	RRSIG	TXT 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. aXi5eSG9qNrFA1F38oTjW+MEJN8bfeMjuyX/GIiNkdGUZ9uBwApbScnk o5V0idDMRn+dZvDPJqwzP77hl9je6Jiw7l3QDZLaahxXRlnJwQHX0VF2 7I94bdZ0GRU2pOFkUaMV7ObRTzINTIPIZeFIzZ0PMr5EW4nw7T8lVhHu NZcsNFgh/4FmMuaqRR7JzLc8OXypQo++wID9uDgqvVwS3GMSiDwMJDWY N7WQOoKjYOFI/4dy8SqfXI7CTEkUtNIkV2LE+JvlAX4TjG9ZO2gLY1WE f0oDhR7Al0K3pf/czygutLKH3bBLXVrEMTnRgtzwDPiXHKAzgL7Rs8ur VczYAA==
cpsc.gov.		9264	IN	RRSIG	MX 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. j0keXD7nNxrcjaRuzgktehvCEsru6B4y3gSXBaXc7zzLVAEGA0oZPtQH rnTcbkT4CqzpoRyAG5gHzrRysgzgz808USpTAU9EJdpeq3yY8J7BU6yt 0Jg+LYve+5Vqjbaauk1L4Z+wTtXcFsWZi/ZHTlD3YeK+lGinaS8uz6l/ Mwj5kesgADi52bCyuSxvUquSn8teD2/ZNEYUq6LrME7T3T90UXM6+MyJ m9X5SYdBQbK5uzTEMQ+s21GI+MaSMWXn4GzwigRlZHHIlrTmlFtRV0Y5 vcQsHcVEfBwbnW6MT79OqO8l3FApuvbhSvVd0PqS6y7YKIYMtS9AX7at qOW0ZA==
cpsc.gov.		9264	IN	RRSIG	NS 7 2 21600 20160803030502 20160727020502 25157 cpsc.gov. Mc9dSPEP703FSqxm6IS1CAwX4ReHNEX5RuQdD7pQTDdxVJQMiacaTjHb TuKSGWRNBftYOYPfaqM2/YfiRqjNdGmVmgHU/H0ynYBWt4slBDTwi8zg LYAS3WxzhcFEeDYti9Jraq0loGDWJRirvok0BAPuhV7rU1ayD+vx12na GYjSNwspGZ2AZ1lhcdUYlrbQBwJnoj8LvHXD99RrEX5AryeYbRkb4vdr u1GpK44KCg3zW/NagFLrga7ki+qtkpBkrduvsNsYYgBNoTs9IdPkqtJi EGrRX5/DtM9PHIkdEj5TZrSOdTG+//x/OeqzIerIp7nKVNlJ//7HDA+X psbLJA==
cpsc.gov.		9264	IN	NSEC3PARAM 1 0 12 AABBCCDD
cpsc.gov.		9264	IN	DNSKEY	257 3 7 AwEAAX5Tor9V7TnhfUMAL67reT+IFYd+4ciQv/UnvZbNgj7DgDuJPpcl Owh6ypAldCYgTXkF2Qt+an9WVp+Khsp2wRCCOhvGIUR9sOGdzxumDUCT Uru2dxHAqIn1QYSjuT8huMDDyBJmnoA4AY1Te86mcE1Jwpo+S9KoB23Z JgnMedU+6i8Qm9cdGLNM7nqEXhgKgmKc/387UFdh25jltsg0d2gOK//q k2HfLdDqv8XlrlacfMsSXniVwK7E6mtqcfbF518M2bl6UFJWXuxp+cU8 0WdmGiQfxmLvm62a2aVs9IzR6qGg0Ce5bxbx68v6gYTgIOUBm8ERytZ3 T2jzc0QOKQc=
cpsc.gov.		9264	IN	DNSKEY	257 3 7 AwEAAZJY5dIAm8QsM2sBBsOoYkeMhk1sUHBqMOAlxQ8VBhoVNoDN0vVz OpLAGVTEThzvOllLX2WxCpkU8AKioO4l188RjBf5wjs/Aj2i1uI8QIyh aMxZS/ifWgR4bBA4d4NgGDpHZElr0Cn2OlDJwhGENOr9kxhgDXT97UVn I2F7JptQZgeAIlGowVPMUpSz4v610ueyOgYWNYN03+IitYOWHMDBm4t3 oYhrCKnqPuauG1oulWS9y5eaYNR82j/WnCzAK/gb5XTcHi02JB98PiAX UO7+CNji9ZRt/yFDqpogoKh3oqvEC+lPNAP9CZ/DuUp+RDL41mm5vKvp F9geIq5XGFE=
cpsc.gov.		9264	IN	DNSKEY	256 3 7 AwEAAZsegFp320vpchs5BqSQz0dIsW4aoQSvX5UPeyGEDaFk6lmVxTh2 Q1aWOvh2qPJ9ZmXK4Eya5q0ST6bsyWWNGv/+3X5GlL+LaRRxen/47py+ Wvp0Rd/hRJuOeI5p0KTPXVGuyvl8F8LZpmTWc0D0CBGds26xNRmVFi4W hLAZg+ez8kaR6H3vh32qwxS2P3JzGvKwBMnaKUSFsyUU5metNJ5AvDvi FKPJP4SC7aSps8mb426EEkic5/WfDRgudBnq09Hcn44DzrJROqrQyH/g Sp73lisQ3P2PEVcSQMrJFxZ8bmDKr2RKzfOrlZ1ICCppL7TC6UsoSw1H d0GQxsKi2cc=
cpsc.gov.		9264	IN	DNSKEY	256 3 7 AwEAAbpeSszphwwkOIJn1ha6DE/W3YRXFR2vsMi0RKhq5x9t487UJc0c eamz5TZj6KV5/tzL8/Qr2jnTaQmpWtJHbnF0kqpxeZIR+wzaNbMtEH30 UF5BDv9Bya0W9I+40dS48996kedhEvL6KwmMelB7FH6QPd0ixyhp0+ci 5vew9lzTESEsJ2X2uJrCqo3UacsHyYIzaTSXPpfwizQCql4VySq6+im1 74QaYw/FU4aADAv3R2KQvsR/uI0a7oOihxDDAvtYG7SZvotW3ASZFscd 4B6Yd84RMZC3yGdGtyrSD6tZsiJZoXhLQkkf0kOTWCjPvD8oPm+yYiGI Cm64eM3kflU=
cpsc.gov.		9264	IN	AAAA	2600:803:240::2
cpsc.gov.		9264	IN	A	63.74.109.2
cpsc.gov.		9264	IN	TXT	"v=spf1 ip4:63.74.109.6 ip4:63.74.109.10 ip4:63.74.109.20 mx a:list.cpsc.gov -all"
cpsc.gov.		9264	IN	MX	5 hormel.cpsc.gov.
cpsc.gov.		9264	IN	MX	5 stagg.cpsc.gov.
cpsc.gov.		9264	IN	NS	auth00.ns.uu.net.
cpsc.gov.		9264	IN	NS	auth61.ns.uu.net.

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 27 19:55:45 2016
;; MSG SIZE  rcvd: 4095

So that's pretty huge, 64 bytes in = 4095 bytes out which equates to 64x amplification. Nice.

Reflection


So the bad guy now has their packet, they spoof the source of the query to be victim.com and they send the request to an Open Resolver. The open DNS resolver replies to the source address in the packet, which is victim.com. This means the bad guy remains anonymous to the victim as the victim sees the packet being sent from the DNS resolver which in this instance is just a middle man. This is what is known as reflection.

Defences


This biggest challenge in coping with amplified attacks is being able to cope with the bandwidth. No matter what rules and ACLs you have deployed at your perimeter, if the pipes feeding your data center are overwhelmed with bad guy traffic then no legitimate customer traffic will be able to make it through. The key defence here then is ensuing you have great bandwidth.

In terms of perimeter rules, a key implementation would also be to drop all UDP based traffic. A simple example of how to configure your firewall to drop UDP is as follows.

If you're using a Linux server you can configure the in-built firewall to accept only TCP traffic on the ports you require. If you are a larger organisation with dedicated Firewall hardware, the same principle applies but will require further configuration.

To install ufw which is the Linux front-end to iptables, it's default firewall, run the following:

sudo apt-get install ufw

You'll likely find it's already installed. Check the current status of ufw:

sudo ufw status

Now, assuming ufw currently has default configuration (which will be to block all incoming traffic, and allow all outgoing) you can define some basic rules:

sudo ufw allow 80/tcp

This allows Port 80 web traffic over TCP.

sudo ufw allow 443/tcp

And this allows HTTPS traffic also. Note, there is no mention of UDP, you are only allowing incoming traffic over Port 80 or 443 and specifically over TCP. Simples.

Now, enable ufw by running:

sudo ufw enable

and disable if required:

sudo ufw disable

You can also re-run the status check to view your rules:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)

Summary


So, you've seen a brief walkthrough on a DNS Reflection attack, how bad guys spoof their sources to keep themselves hidden, whilst using a man-in-the-middle approach to sending large amounts of traffic to a victim's server.

We've also seen how easy it is to amplify the amount of traffic sent to a victim and the likely impact for doing so. Also, we've seen how simple techniques on the Firewall can help protect you against this form of attack. Dropping all UDP packets at your perimeter is a key line of mitigation and ensuring you have sufficient bandwidth capacity at your fingertips is absolutely critical.

Even though you now drop UDP packets at your perimeter, it would still be good to know if a bad guy is targeting your environment. Obviously if you're running a Network Intrusion Detection System then this will be able to alert you, and to get an early warning about this type of attack should also monitor for ICMP Backscatter. Don't know what that is? Check out my post here.