Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: recursive DNS servers DDoS as a growing DDoS problem

Subject: Re: recursive DNS servers DDoS as a growing DDoS problem
Date: Tue, 7 Mar 2006 19:26:19 +0200
Are you sure about that amplification process??
Actually if the packet reaches huge sizes it will be fragmented at 
theattacker's own place cuz of the network equipment's mtu... or won't 
betransmitted at all...
The concept of the smurf attack is in sending large amount of spoofedpackets to 
the sub-network's broadcast address. Thus resulting in aenormous amplified 
traffic back to the spoofed address, which happensto be the victim.
In the scenario you describe, I cannot see any actual amplification...Just 
fragmentation. Either I misunderstood your words, of which Iapologise if the 
case, or you've got something wrong there...
Anyway.. i do not question the DDoS attack on the recursive DNSservers, but 
find it not so scary as some folks may say.
Take care and best wishes,Ventsi
PS: sorry if duplicated...
On 2/28/06, Gadi Evron <ge@linuxbox.org> wrote:> 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.>

<Prev in Thread] Current Thread [Next in Thread>