-3

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.

closed as off-topic by Andrew B, Iain, Jenny D, EEAA Jan 3 '17 at 13:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions should demonstrate reasonable business information technology management practices. Questions that relate to unsupported hardware or software platforms or unmaintained environments may not be suitable for Server Fault - see the help center." – Andrew B, Iain, Jenny D, EEAA
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I've reworded the question to be a bit more obvious, thanks for pointing that out. – John Jan 3 '17 at 0:56
  • 3
    Why is response rate limiting in the actual domain name server software not an option? Why is limiting access control for recursive queries to an audience smaller than "all of IPv4" not an option? – anx Jan 3 '17 at 1:22
  • 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 3 '17 at 7: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 3 '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 3 '17 at 19:21
0

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.

  • That's very useful, thanks! unbound is the DNS software in use. I'm now considering running dnsdist in front of it. – John Jan 3 '17 at 4: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 3 '17 at 7:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.