lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <718d032a0603070917o69188ffdn571ab73eb90a2df2@mail.gmail.com>
Date: Wed Mar  8 18:07:17 2006
From: vigour1 at gmail.com (Ventsislav Genchev)
Subject: Re: recursive DNS servers DDoS as a growing DDoS
	problem

Are you sure about that amplification process??

Actually if the packet reaches huge sizes it will be fragmented at the
attacker's own place cuz of the network equipment's mtu... or won't be
transmitted at all...

The concept of the smurf attack is in sending large amount of spoofed
packets to the sub-network's broadcast address. Thus resulting in a enormous
amplified traffic back to the spoofed address, which happens to be the
victim.

In the scenario you describe, I cannot see any actual amplification... Just
fragmentation. Either I misunderstood your words, of which I apologise if
the case, or you've got something wrong there...

Anyway.. i do not question the DDoS attack on the recursive DNS servers, but
find it not so scary as some folks may say.

Take care and best wishes,
Ventsi

On 2/28/06, Gadi Evron <ge@...uxbox.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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060307/d5972fdd/attachment.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ