DDOS attack Bind 9.9 - P2

Vernon Schryver vjs at rhyolite.com
Tue Apr 30 23:15:26 UTC 2013


> Patch BIND to include the RRL (Response Rate Limiting) patches
> (http://www.redbarn.org/dns/ratelimits), blackhole/ignore those
> clients requesting.

The fact that Response Rate Limiting (RRL) does not blackhole/ignore
clients is a feature and why it is a better mitigation for DNS
Reflection DoS attacks than mechanisms that do blackhole/ignore
clients.  The apparent DNS clients in DNS reflection attacks is
usually not the source of the evil requests, but forged by bad guys
trying to attack the nominal clients.  Because RRL limits rate of
any particular response sent to any particular client address block,
the client is generally able to get responses for its legitimate
requests and often will not notice the attack.

Naively blackholing/ignoring the forged client as with common
firewall rules does stop attacks, but lets the bad guy deny name
service to the client.  Breaking host name resolution has been a
part of many security attacks over the years.

  ...


} > I have isc.org attack." isc.org internet *?". It comes from my own clients 
} > that I have allowed in my ACL. the question is how to stop this attack? 

} If the queries are really from your clients, find & fix them.  They are 
} probably attacking others in addition to you, so you'd be doing the rest of 
} the Internet a favor while solving your own problem.

Simple request flooding with forged DNS client IP addresses sounds
unlikely, because there are many other DoS attacks that are more
effective and harder to filter.  In other words, the smart money bets
on the requests not really coming from the apparent clients, but that
they are forged and intended to attack the apparent clients.


} If the traffic is spoofed as being from your clients, stop accepting traffic 
} from elsewhere sourced from your client address space.

That is best, if possible and relevant, as with closed recursive
resolvers.  It is generally irrelevant and impossible for authoritative
DNS servers.

The RRL patch is intended for authoritative servers, but can be used
as better than nothing on recursive resolvers.  The best mitigation
for open recursive resolvers is to close them except to trusted clients.
When that is not possible, RRL can be used at the cost of significantly
slowing applications such as browsers and SMTP servers (mail receivers)
that make large bursts of identical requests.

   ...

] Many people will not compromise critical daemons by using third party
] *unofficial* patches.

I don't know the status of the CZ-NIC Knot DNS or the NLNetLabs NSD
RRL code.  Perhaps that either of those is "third party" or "unnofficial,"
although I have the impression that is at least partly wrong.

The BIND RRL patch on http://www.redbarn.org/dns/ratelimits are
unofficial, and so it is reasonable to be skeptical and wait for an
official release.  However, for obvious reasons it is not really
accurate to label the BIND RRL patch as "third party."  "Pre-pre-release"
is a more accurate characterization of the BIND RRL.  Please note that
users of the FreeBSD bind98 and bind99 ports can get the RRL code
without messing with the patch command.  See
https://www.google.com/search?q=site%3Afreebsd.org+bind+rrl


] iptables does just as good of job.

That is widely known to be false in general.  In principle one could
write iptables rules that do as good a job as RRL.  However, the
common iptable rules that rate limit incoming requests based entirely
on either query types or DNS client IP addresses block ilegitimate
queries and so are distinctly inferior to RRL.


Vernon Schryver    vjs at rhyolite.com


More information about the bind-users mailing list