[dns-operations] DoS with amplification: yet another funny Unix script

[Vernon Schryver]

> From: Klaus Darilion <klaus.mailinglists at pernau.at>

> On 10.09.2012 19:48, Paul Vixie wrote:
> > please don't do, or promulgate, this. ddos filtering in order to do more
> > good than harm has to be based on the attack's answer, not on its query.

> > vernon schryver and i explain this in the technical note at
> > <http://www.redbarn.org/dns/ratelimits/>.

I fear that the technical note linked from that page fails to emphasize
enough the drawbacks of firewall defenses against DNS reflection
attacks.  I was recently asked about a proposed security advisory about
some consequences of using iptables to defend against DNS reflection
attacks.  My response was that it's not entirely the fault of the DNS
server if a user's iptables facilitate denying DNS service.  As I think
that technical note says, any rate limiting has some danger of being
exploited by bad guys, but simplistic firewall 'deny' rules are far
too blunt and much too easily exploited.  Any firewall rule that doesn't
compute DNS responses about as good as a DNS server is simplisitic.
If your firewall is smart enough to know that a stream of DNS requests
will generate 1600 byte NXDOMAIN responses, why don't you turn off the
DNS server and let the firewall do all of the DNS work?


> Is it correct that filtering based on responses is better only for 
> NXDOMAIN responses or error responses. If the forged requests are 
> requests for valid domain names, then analyzing the request should be 
> fine too.

Because each request implies its response, in theory there is no
difference between filtering based on requests or responses.  In
practice it is impossible for anything except a DNS server to know the
response that a request will generated.  How can anything but the DNS
server or its doppleganger know that a request will generate NXDOMAIN,
SERVFAIL, REFUSED, or be dropped by an ACL in the DNS server?  How can
anything but the server know about variations in non-error responses
due to views?

There are few reason to forge requests that reflect as SERVFAIL or
REFUSED, but you can get large amplifications with DNSSEC NXDOMAIN.
If your defense works against non-error reflections attacks but not
NDXDOMAINs, what will your adversaries do and how quickly?

The party line that the BIND RRL only looks at responses is not entirely
accurate.  For obvious efficency reasons (and ease of coding), it looks
at the RRsets or error code that would be used to generate the response
instead of the final, on-the-wire response.  Analyzing cooked instead
of raw DNS responses is related to my main question about some of the
suggested firewall schemes.  How can you convert every incoming DNS
packet to text and then run it through awk or grep and handle a
non-trivial load?


> Of course it is easiest to track the states in the name server, but I do 
> also see advantages in doing the filtering in an external node (upstream 
> firewall, local iptables). For example I do not have to worry about the 
> used name server software and I can use the same rules for bind, 
> powerdns, nsd ... backends. I also suspect that filtering in kernel 
> space may be faster. As a personal preference I try to separate 
> functionality into dedicated nodes.

That's an argument for all reasonable DNS server implementations having
rate limiting knobs instead of a reason for bad and dangerous rate
limiting in firewalls.  As Paul said, the BIND RRL code is open.

Why not remove all ACLs, views, and related mechanisms from your DNS
server and put them in your IP firewall?


> The tuple <mask(IP), imputed(NAME), errorstatus> is used to select a 
> state blob. In the amplification attacks on our authoritative servers we 

> Thus, it may take some time until the attacker starts with domain1.com 
> again. If I understand the Responder Behavior correct, this would mean 
> that filtering is never triggered if a domain is not queried 
> RESPONSES-PER-SECOND times per second. Or do I miss something here?

I'm not sure I understand.  If that points out that an attack that is
too diffuse to be noticed by the BIND RRL code might be noticed by a
firewall rule, then I agree.  I'd also say that can be seen as a feature
instead of a defect, because during less diffuse attacks, legitimate
requests from the forged CIDR block will still be answered.


Vernon Schryver    vjs at rhyolite.com