[LINK] Open recursive nameservers used for DoS attacks

[Kim Holburn]

I think it's easier and more secure to run two separate instances on  
separate IPs than to do the views thing.  Just running one server so  
the external queries are non-recursive means it may still answer for  
stuff in its cache.  A separate instance which only answers your for  
domain will not cache anything.


If you don't need an internal DNS namespace you could also just run  
one, the non-recursive service for your namespace and use opendns for  
everything else ie your internal network.  If you run the bind server  
for your internal network just for caching, maybe it's not really a  
big saver and you could ditch it.

Several solutions in the following web pages.  Really the best and the  
only one which I think really solves the DDoS problem is using  
fail2ban.  You might have to look at the logs to get the regex right.   
All other solutions end up with some packets being sent to the DDoS  
target.

http://isc.sans.org/diary.html?storyid=5713
> If your Bind 9 is authoritative-only, globally deny queries and  
> recursion (in the options section), and then allow queries in each  
> zone definition. Queries for the \".\" hint zone are implicitly  
> denied.

> Getting hit by most of the listed ips too. \"Solved\" the issue by a  
> new regex for fail2ban (bans after 10 failures of regex \"Not  
> authoritative for(.*), sending servfail to <HOST>(.*)\" - this regex  
> works for powerdns. Its a dynamic solution, so you dont need to  
> update iptables rules by hand on any new ip involved.

Discussion here:
http://www.secureworks.com/research/threats/dns-amplification/
> Nameserver is a "master"
>
> If one's nameserver is a "master" for some zones, the root hints are  
> required to correctly send NOTIFY messages to the slave nameservers.  
> To prevent upward referral responses, the global BIND configuration  
> option "additional-from-cache no;" can be used, so that a query like  
> ". IN NS" will result in a REFUSED response, which is much smaller  
> than the answer containing all of the hint information for the root  
> nameservers.
>
> Alternatively, you can use access controls to accomplish the same  
> thing by denying all queries globally and then allowing queries for  
> each zone.

> Nameserver is both authoritative and caching
>
> These two function should be separated! Caching nameservers are  
> susceptible to poisoning and other types of attacks. This will make  
> you authoritative nameserver susceptible to the same attacks.  
> Separate hardware is not required, only a separate IP address and  
> nameserver configuration. Additionally, it may be advised to  
> configure the authoritative nameserver to use an external address  
> while configuring the caching nameserver to use an internal address,  
> typically a suitable private, non-routable (RFC 1918) address.



On 2009/May/15, at 8:22 AM, Robin Whittle wrote:

> Hi Barrie,
>
> Thanks very much for pointing this out:
>
>> The problem with this solution is that Bind 9 still returns your  
>> "hints"
>> file with this query. I have ended up black holing the spoofed  
>> address.
>> (I don't have a solution for BIND9).
>
> Indeed it does.  The reply with the hints file is 686 bytes - an
> improvement on the previous total of 4149 bytes, but still an
> amplification of the attacker's effort of 71 bytes.
>
> More information on the problem is here:
>
>  http://bitfolk.com/orns.html
>
>     If your nameserver is an authoritative server for your domains
>     then it should not offer recursion at all. If your nameserver is
>     a caching resolver for your own use then recursion should be
>     restricted to questions from your own IPs only. Also consider
>     firewalling off your resolver to only allow access from IPs that
>     should have it.
>
>     It is not recommended to use a single nameserver as both a
>     caching resolver and an authoritative server.
>
> This server is my gateway machine between the LAN and the Net, on a
> single IP address from my fixed IP address DSL service.
>
> On the LAN site, queries arrive at 10.0.0.1.
>
> I suppose I could run two instances of bind 9, one to be the
> authoritative server for queries from the outside world - to respond
> only to queries on the public IP address - and the other to respond
> only to 10.0.0.1 and act as a recursive caching nameserver.
>
> This is contemplated in:
>
> https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful
>
> but running two instances of bind sounds like trouble to me.
>
> Another approach is "split views":
>
> http://www.knowplace.org/pages/howtos/split_view_with_bind_9_howto.php
>
> This suggests having two copies of the zone files, which seems odd.
> I guess one set could be symlinked from the other.
>
> Do you think this would stop the nameserver sending back responses
> with the hints file when a request arrives from the outside Net for a
> domain it is not authoritative for?
>
>  - Robin
>
>
>
>
>
>
> _______________________________________________
> Link mailing list
> Link at mailman.anu.edu.au
> http://mailman.anu.edu.au/mailman/listinfo/link

-- 
Kim Holburn
IT Network & Security Consultant
Ph: +39 06 855 4294  M: +39 3494957443
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request