-1

I have a business need to provide an open and recursive DNS. This DNS has of course been heavily abused by DNS amplification attacks, resulting in 5-10 Mbps sustained outbound load only caused by spoofed ANY requests. I thus had to find a solution to cope with this at least to a point where abuse is minimal. I'm assuming there are other people out there having the same problem, so I'd like to share my approach as it seems to be the only publicly shared approach that goes beyond the usual advice of "don't operate an open recursive DNS"... which isn't helpful at all.

I'm thus looking for approaches that allow me to maintain an operating open recursive DNS, while at the same time minimising the impact any attempted exploits might have.

Does anyone know of any other solutions?

My approach is simply to automate what I do by hand when I discover an amplification attack:

  • run tcpdump to determine the characteristics of the outgoing traffic. Once you've convinced yourself that it is indeed DNS ANY requests, capture them using e.g. this: tcpdump -n udp dst port 53 | grep ANY

  • then use iptables to drop the outgoing traffic with said characteristics.

I discovered that the vast majority of script kiddies use what I can only surmise is some out of the box DNS amp template script which probably has a "insert destination port here" line... thus limiting the output to one specific target port. When that is the case, it's as simple as identifying that port, and blocking any UDP traffic that originates from port 53 (DNS) to that target port. Failing that, you can drop all traffic to destination IP addresses that your tcpdump has revealed to be "requesting" repeated ANY DNS queries - there's not much legitimate use of that anyway.

There is a chance that you block legitimate traffic with this, there also is a chance to still allow some abuse inbetween the tcpdump capture times. But that's a minor price to pay considering the alternative.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
John
  • 73
  • 1
  • 5
  • I've reworded the question to be a bit more obvious, thanks for pointing that out. – John Jan 03 '17 at 00:56
  • Response rate limiting will still allow the abuse just at a lower but still substantial rate. My method stops it cold in its tracks. As to your second suggestion, refer to my first paragraph... all of IPv4 needs to be able to use this DNS. – John Jan 03 '17 at 01:45
  • 11
    You haven't explained *why* you have a legitimate business need to do this, and are asking us to take it at face value that you have no choice but to be a bad netizen. :/ I'm really uncomfortable with that as a starting assumption. – Andrew B Jan 03 '17 at 07:09
  • 2
    I second @AndrewB here and vote to close since this is not best practice in any way, shape or form. – Jenny D Jan 03 '17 at 11:36
  • 1
    I'm also editing out the script as it is too easily gamed to block all possible source ports from a given spoofed target. In general, automated approaches with spoofable sources are not tenable, and you should not attempt to write one of these unless you are an expert in the applicable field. (admittedly a catch 22, since experts would also avoid the approach) – Andrew B Jan 03 '17 at 19:21
  • 1
    [DNS cookies](https://tools.ietf.org/html/rfc7873) is AFAIK the only real solution anybody have implemented against amplification attacks. Everything else is workarounds, though some of them can be quite effective. – kasperd Jan 05 '17 at 23:27

1 Answers1

1

You don't mention which nameserver software you run, but if it has some response rate limiting scheme, that could be a good start for helping the situation.

Another option would be to introduce some additional layer to do rate limiting/blocking, but I would suggest using some deeply DNS-aware tool rather than rolling your own.
Have a look at dnsdist, a very flexible DNS proxy/load balancer (documentation / configuration examples).

Of course, if at all possible it would be much easier to simply lock down recursion access to known clients.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • That's very useful, thanks! unbound is the DNS software in use. I'm now considering running dnsdist in front of it. – John Jan 03 '17 at 04:06
  • This is actually the way to go. I still keep the iptables based approach up my sleeves, but dnsdist is really quite powerful (and relatively straight forward to configure). Thanks again. – John Jan 03 '17 at 07:34