Avoiding being used as DDoS reflector.

[Nathan Ollerenshaw]

Hi,

I've searched around a bit, and noticed some others have similar  
problems as this but nobody has come up with a decent solution, or at  
least, I've not found one.

I have an Authoritative BIND server. It is configured to only allow  
recursive queries from localhost, with recursion disabled for any  
remote clients.

If you attempt to perform a recursive query against this server, it  
will respond with a "query refused" packet, as this is what BIND does  
if you try to recursively query a server configured to disallow  
recursive queries.

Kiddies, however, are exploiting this behaviour to provide a level of  
indirection in their DDoS efforts.

Jan 19 10:12:34 mars named[7683]: client 69.50.142.110#40346: query  
(cache) './NS/IN' denied
Jan 19 10:12:35 mars named[7683]: client 76.9.16.171#47713: query  
(cache) './NS/IN' denied
Jan 19 10:12:37 mars named[7683]: client 76.9.16.171#53205: query  
(cache) './NS/IN' denied
Jan 19 10:12:38 mars named[7683]: client 76.9.16.171#2340: query  
(cache) './NS/IN' denied
Jan 19 10:12:39 mars named[7683]: client 76.9.16.171#53417: query  
(cache) './NS/IN' denied
Jan 19 10:12:41 mars named[7683]: client 76.9.16.171#38593: query  
(cache) './NS/IN' denied
Jan 19 10:12:43 mars named[7683]: client 69.50.142.110#61075: query  
(cache) './NS/IN' denied
Jan 19 10:12:43 mars named[7683]: client 76.9.16.171#54721: query  
(cache) './NS/IN' denied
Jan 19 10:12:45 mars named[7683]: client 76.9.16.171#12764: query  
(cache) './NS/IN' denied
Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#59043: query  
(cache) './NS/IN' denied
Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#55282: query  
(cache) './NS/IN' denied
Jan 19 10:12:49 mars named[7683]: client 76.9.16.171#54628: query  
(cache) './NS/IN' denied
Jan 19 10:12:51 mars named[7683]: client 76.9.16.171#34097: query  
(cache) './NS/IN' denied
Jan 19 10:12:52 mars named[7683]: client 69.50.142.110#63662: query  
(cache) './NS/IN' denied

Each of these requests send back a packet to the IP the spoofed query  
coes from. I've contacted network operators (not necessarily those  
ones listed for these IPs) and they've confirmed, separately, that  
they've been under attack for several weeks by these DNS reply packets.

Obviously the amount of load here is negligible to me, and if I didn't  
care about anyone else, then I could just suppress the log messages  
and move on with my life. But, I don't think thats the appropriate  
response.

Even though my nameserver seems to be correctly configured, there  
seems to be no way for me to ignore these spurious requests or rate  
limit them, so therefore I'm aiding the attackers, however obliquely,  
in their efforts.

I've considered using views blackhole recursive requests, but  
blackholes can only be specified in the global configuration, not in  
views. I've considered using iptables/netfilter and the u32 extension  
to match the specific DNS flags that denote a recursive query, and  
then apply a rate limit; but I really don't know the best way forward.

I currently manage these attacks by adding a blackhole entry for each  
IP that the kiddies try to attack, but this is a stop-gap, and I'd  
prefer something that can work in an automatic way to deny kiddies the  
use of my authoritative nameserver as a reflector.

The ideal solution for me, would be a bind configuration option that  
could rate limit responses based on type; so you could specify that a  
"REFUSED" reply will only be sent to a given host once per hour, or  
something like that.

Any ideas? Anyone facing this same problem found a solution? I'd be  
glad to hear it :)

-- 
Nathan Ollerenshaw :: http://www.stupendous.net/
"Anyone who has never made a mistake has never
  tried anything new." - Albert Einstein