ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá














     áòèé÷ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] recursive DNS servers DDoS as a growing DDoS problem



> ------------------------------
> 
> Message: 15
> Date: Tue, 28 Feb 2006 13:05:22 +0200
> From: Gadi Evron <ge@xxxxxxxxxxxx>
> Subject: [Full-disclosure] recursive DNS servers DDoS as a growing
>       DDoS    problem
> To: bugtraq@xxxxxxxxxxxxxxxxx
> Cc: "full-disclosure@xxxxxxxxxxxxxxxxx"
>       <full-disclosure@xxxxxxxxxxxxxxxxx>
> Message-ID: <44042E72.7010602@xxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi guys.
> 
> We discussed recursive DNS servers before (servers which 
> allow to query 
> anything - including what they are not authoritative for, 
> through them).
> 
> The attack currently in the wild is a lot bigger and more complicated 
> than this, but to begin, here is an explanation (by metaphor) 
> of that part:
> Spoofed ICMP attacks have been around for a while. How many 
> of us still 
> get quite a bit of ICMP echo replies stopped at our borders? These 
> replies come to us due to spoofed attacks using our addresses.
> 
> Now, imagine it - only bigger:
> Smurf.
> 
> Introduce an amplification effect.
> 
> As bigger UDP packets will be fragmented by the servers, and UDP 
> obviously does not do any handshake and can easily be spoofed...
> The server receives a large packet, breaks it down to several 
> fragments 
> and moves the query on.
> That's where the amplification effect _starts_.
> 
> Both the attacked server and the unwilling participant in the attack, 
> the recursive servers, experience a serious DNS denial of 
> service that 
> keeps getting amplified considerably.
> 
> One of the problems is obviously the spoofing. Let us, metaphorically 
> and WRONGLY treat it for a minute as the remote exploit.
> 
> The second part of this problem is the recursive server, 
> which for the 
> moment we will WRONGLY treat as the local exploit.
> 
> Obviously both need to be fixed. Which is easier I am not so sure.
> 
> In the past, most network operators refused to implement best 
> practices 
> such as BCP38 (go Fergie!) because they saw no reason for the hassle. 
> Returning back to: "if it isn't being exploited right now, 
> why should I 
> worry about it?"
> 
> Well, it is being exploited now, and will be further exploited in the 
> future. Combating spoofing on the Internet is indeed 
> important and now 
> becoming critical.
> 
> Removing the spoofing part for a second, the attack vector 
> for this can 
> easily be replaced, as one example, with a botnet.
> 
> A million Trojaned hosts sending in even one packet a minute 
> would cause 
> quite a buzz - and do. Now amplify the effect by the 
> recursive servers 
> and...
> 
> So, putting the spoofing aside, what do we do about our 
> recursive servers?
> 
> There are some good URL's for that, here are some:
> http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf
> http://cc.uoregon.edu/cnews/winter2006/recursive.htm
> http://dns.measurement-factory.com/surveys/sum1.html
> 
> The recursive behaviour is necessary for some authoritative 
> servers, but 
> not for all. As a best practice for organizations, as an example, the 
> server facing the world should not also be the one facing your 
> organization (your users/clients). Limiting this ability to 
> your network 
> space is also a good idea.
> 
> If you would like to check for yourselves, here is a message 
> from Duane 
> Wessels [1] to the DNS-operations [2] mailing list where this is 
> currently being discussed:
> -----
> If anyone has the need to test particular addresses for the
> presence of open resolvers, please feel free to use this tool:
> 
> http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl
> 
> It will send a single "recursion desired" query to a target address.
> If that query is forwarded to our authoritative server, the host
> has an open resolver running at that address.
> -----
> 
> Dan (DA MAN) Kaminsky and Mike Schiffman have done some 
> impressive work 
> on this subject, outlined in Dan's latest ShmooCon talk.
> They found ~580K open resolvers:
> http://deluvian.doxpara.com/, http://www.doxpara.com/
> 
> I suggest those of us who need more information or help go to the 
> DNS-operations mailing list from OARC (see below) and ask the experts 
> there, now that this is finally public.
> 
> Thanks,
> 
>       Gadi.
> 
> [1] Duane Wessels - DNS genius and among other accomplishments the 
> author of dns top.
> [2] DNS-operations - 
> http://lists.oarci.net/mailman/listinfo/dns-operations
> 
> -- 
> http://blogs.securiteam.com/
> 
> "Out of the box is where I live".
>       -- Cara "Starbuck" Thrace, Battlestar Galactica.
> 
> 
> ------------------------------
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> 
> End of Full-Disclosure Digest, Vol 12, Issue 50
> ***********************************************
> 



 




Copyright © Lexa Software, 1996-2009.