[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=bUzdq0NKrJJEF6VztUZ_JxAzXqw@mail.gmail.com>
Date: Fri, 20 May 2011 03:30:56 -0700
From: Kristian Erik Hermansen <kristian.hermansen@...il.com>
To: "Dobbins, Roland" <rdobbins@...or.net>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: New DDoS attack vector
On Thu, May 19, 2011 at 7:24 PM, Dobbins, Roland <rdobbins@...or.net> wrote:
> The assertion that 'previous Denial of Service attacks against the DNS servers received either malformed, fragmented, ICMP messages or TCP SYN, with invalid length, or oversized and some of these can be filtered by the firewalls or security appliances' is demonstrably false. DNS servers have been targeted by bogus queries intended to exhaust the DNS server resources directly, or via spoofed queries which are intended to generate reflection/amplification attacks, but which also have a deleterious effect on the performance of the abused open recursors, for many years.
>
> The posited scenario is unnecessarily complex. It's a heck of a lot easier to simply bombard targeted authoritative DNS servers with spoofed bogus queries from botnets and/or hit them with reflection/amplification attacks, rather than go through this elaborate steps of registering a domain, pointing the NS/MX records at the target, then generating lots of spam.
>
> The proximate attack method described - layer-7 DDoS via excessive queries - isn't new or unique, and the NS-record-related steps are unnecessary. There's simply no need to go to this amount of trouble to launch a DDoS attack against authoritative DNS servers, nor is such an attack as difficult to defend against as is claimed in the write-up, meaning that this attack methodology has no unique advantages to justify the extra steps regarding re-targeting NS/MX records and spam generation.
Agreed. But I have seen this exact attack in action too, so it is
being used effectively to cripple DNS servers. Whether or not the
attacker chooses this method or the botnet vector, the more
interesting aspect is what happens when a DNS server's cache hit ratio
vastly deceases while this attack is in progress. From my specific
calculations during a known attack of this type, a DNS server cluster
was reduced in efficiency to 10% of the expected normal operating
capacity. Losing 90% of your expected DNS capacity will ruin anyone's
day especially during lunch time when DNS queries peak. The
in-real-time fix is very simple and can be done in one iptables
command. However, if you were really smart, you would buy Arbor to get
very specialized DNS protection out-of-the-box. They have some DNS
protocol-specific options that block/limit clients during these type
of attacks. Go Arbor...
--
Kristian Erik Hermansen
http://www.linkedin.com/in/kristianhermansen
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists