Recently I did some consultancy work with a client who was used as a second hop in a DNS amplification attack and I've taken a bit of an interest in this phenomenon. So much interest in fact that I ran some experimentation of my own as to how easy it is to carry out this kind of attack. The results of my experiment follow in the rest of this post. I should forewarn that this is an extremely techie blog post so isn't for the faint hearted!
Recently I did some consultancy work with a client who was used as a second hop in a DNS amplification attack and I've taken a bit of an interest in this phenomenon. So much interest in fact that I ran some experimentation of my own as to how easy it is to carry out this kind of attack. The results of my experiment follow in the rest of this post. I should forewarn that this is an extremely techie blog post so isn't for the faint hearted!
Microsoft's Security TechCenter offers a succinct definition of a DNS amplification attack:
A DNS amplification attack (aka DNS reflection attack) is a type of distributed denial of service (DDos) attack that takes advantage of the fact that a small DNS query can generate a much larger response.
Microsoft Security TechCenter
You can read a lot more about the theory of DNS amplification attacks there. This isn't a discussion of the general theory; I'm interested in how this could be used by a normal every day human with basic TCP/IP & C knowledge.
So from a bit of research I can create a DNS amplification attack as follows:
- We need a way to generate the correctly crafted request. A good example is easily 'findable' here.
- A list of open recursors is necessary for a full scale attack. I'm not interested in running a full scale attack in this experiment so will skip this step. However, anyone who runs their own DNS hosting has authoritative Name Servers who will respond to a request from anyone. These can be successfully used as second hop sources (the sources of the main attack). They are mostly in high bandwidth Data Centres and usually distributed over more than one Data Centre. Many owner-operators do this and don't have the experience to ensure the servers are properly protected / rate limited etc.
- We need a node to execute this from that does not belong to an upstream with Egress Filtering (BCP-38). I can confirm that any good UK Data Centre won't fit the bill here. I've also checked both Zen and Eclipse ADSL connections. No good. For most of us, we fail here. Presuming you succeed, 2 realisations will quickly follow:
- UDP packets from the original source will go at near line speed. This works well where your original source is an ADSL upstream you're not responsible for. Not so ideal if you are its connection. I found setting a usleep of 50-150ms between packets was enough to control the egress rate to between 1 to 5 Mbit/s.
- With the default (dnsdrdos.c) "A" rec request the multiplication factor is quite low, perhaps only two times the traffic you send. To achieve a better effect asking for an "ANY" record is the best I could come up with. That gave a multiplication factor of 6.
In my test I was able to saturate an ADSL downstream connection (@24Mbit this makes sense). Pings down the ADSL line showed 73% packet loss with latency of 150-200ms for the requests that were returned. This is shown in the graph snippets below where a TX of 4.8 Mbit/s the results in target receiving 24 Mbit/s:
So it turns out from my experiment that it is quite easy to start a DNS amplification attack. But how do you mitigate against such an attack?
Dealing with a DNS reflection attack
- If you're the source of the amplified traffic, i.e. the host of the recursive DNS server. Don't host your own DNS. If you must (e.g. say you have authoritative Name Servers) make sure that you rate limit requests.
- If you're the final target of a DNS amplification attack I believe the only real option is to null (i.e. blackhole) route traffic destined for your IP at the upstream provider. Obviously all the services that were on that IP would need to be moved!