Date: Tue, 04 Apr 2006 07:43:03 +0100
From: Anton Ivanov <arivanov@...segv.cx>
To: Tim <tim-security@...tinelchicken.org>
Cc: gboyce <gboyce@...belly.com>, "Geo." <geoincidents@....net>,
	bugtraq@...urityfocus.com
Subject: Re: recursive DNS servers DDoS as a growing DDoS problem


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim wrote:

>> All it takes is to throttle traffic from the resovers to outside
>> the ISP network to a reasonably low value. Depending on the ISP
>> this is usually in the low Kbits. All it takes is a moderate
>> amount of competence in the ISP:
>
>
> I don't believe this would help the problem. One of the notable
> features of many reflected attacks is that no single reflector is
> hit with a large amount of traffic. It is spread out amongst many
> many reflectors so that the reflectors don't notice the issue, and
> so that the victim has a harder time filtering the traffic.

Correct. By itself it will not. As a matter of fact no approach will
do it by itself alone.

Still, let us suppose that antispoofing is largely reduced (there are
too many access designs out there where it cannot be fully eliminated)
and running open recursive DNS servers on a customer machine is
treated the same way we treat open SMTP relays nowdays.

This still leaves larger ISPs and Telcos who have large DNS resolver
installations that have to serve customers. It will be possible to use
these for aplification for years to come unless something is done.

>
> If your goal is to eliminate the recursive resolution reflection
> amplification, then you must disable it for all but trusted
> subnets. This also defends the server from the more trivial of
> cache poisoning attacks (assuming your own systems use the resolver
> as well).

    This is feasible only for corporate networks where the allocations
are constant and change once in a few years.

    It is not feasible in any ISP/Telco above a certain size. In fact,
considering the consolidation over the recent years it is not feasible
for most ISPs or Telcos.

    In an ISP you will have to provision and reprovision the
nameserver ACLs on a daily basis to match your current customer
allocations and reload it like there is no tomorrow. One mistake in
provisioning and you will have a large chunk of customers shouting
down the support line why their internet does not work. It becomes
even more entertaining if you use RFC3258 or clustering to load
balance DNS traffic. In that case you often end up with a lottery
where one server replies, other servers deny or vice versa. Debugging
that  is even more entertaining. Frankly, expecting any large ISP to
deploy anything like this is not realistic.

   Using QoS to limit queries coming from the outside world can be
done in a manner where it does not require any extra provisioning and
modification to the nameserver config. On top of that, for most well
designed large ISP/Telco DNS server deployments this is just a simple
config change. Once it has been rolled out it maintains itself. After
all, if your customers have no network access having or not having DNS
is largely irrelevant.

    By the way, nothing prevents you from putting the limit at 0 or
filtering based on route tag so that you completely block recursive
queries from outside your network. Personally, I would not do it
(there are failure cases which will not be covered), but nothing
prevents an oversealous BOFH from doing it.

- --

A. R. Ivanov
E-mail:  aivanov@...segv.cx
WWW:     http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <ai1-n@...segv.cx>
    Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715

        
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEMhV3/NpXLt3l5xURAkeQAJ9S1IUxoJYDEAlqsJ5nPq6xZELoCwCgnHDJ
BnUYwhfLTD6eU20cF09aA/U=
=hL61
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists