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] [day] [month] [year] [list]
Date: Wed, 05 Apr 2006 07:32:43 +0100
From: Anton Ivanov <arivanov@...segv.cx>
To: Ross Wheeler <rossw@...ury.net.au>
Cc: Tim <tim-security@...tinelchicken.org>,
	gboyce <gboyce@...belly.com>, "Geo." <geoincidents@....net>,
	bugtraq@...urityfocus.com
Subject: Re: recursive DNS servers DDoS as a growing DDoS problem


Hi Ross,

[snip]

>acl "goodguys" {
>     (list of trusted peers who can request your zone files)
>	};
>
>  
>
>acl "locals" {
>        127.0.0.0/8;
>        (list of your subnets);
>	(list of TRUSTED hosts outside your network);
>	};
>
>options {
>        allow-transfer { goodguys; };
>        allow-query { locals; };
>        allow-recursion { locals; };
>};
>
>then in each zone you are authorative for:
>
>zone "mydomain.com" { type master;
>        file "zone.mydomain.com";
>        allow-query { any; };
>};
>
>(repeat for each authorative zone)
>
>
>
>This lets anyone on your network, and others you might trust, full
>recursive lookups, while simply denying recursion for everyone else, but
>allows others to query your nameserver for domains YOU are authorative
>for? Or am I missing something obvious... because this is how we've been
>doing it for years.
>
>RossW
>
>
>  
>
This as duly noted by Tim still allows poisoning.

Granted, you need to be a "good guy" to do this. If you are looking from
a service provider perspective there is no such thing as a "good guy".
All guys are "presumed bad" until proven otherwise. This is not a bad
approach to have in a corporate environment either.

Due to the flames I keep on getting it seems that many of the people on
the list do not know how to use split DNS to run recursive resolvers and
authoritative name servers so that they do  not clash (scary though
actually).

The correct setup recepy is:

1. Define two IP aliases on the machine lo:0 and lo:1 (using linux
notation for sake of clarity). Make them routable.

2. Copy the bind config fully so you have two copies. One in
/etc/bind-recursive and /etc/bind-non-recursive

3. Configure /etc/bind-non-recursive/named.conf to be non-recursive,
have the listen address of lo:0, query-source address the address of
lo:0 and most importantly control address for rndc of lo:0

4. Same for /etc/bind-recursive, but use lo:1 and turn recursion on.

5. Update the start up scripts and start two separate named instances
with either config.

Voila. Poisoning - begone (OK, possibly not completely but most cases).
In addition you get your authoritative and resolvers speaking from
different addresses which also allows you to use any of the network
tricks I have described in my previous posts on this thread. The overall
cost is 3-4MB RAM per machine and one extra IP address.

As a matter of fact if you are a service provider you may as well look
into using network tricks instead of the "locals" list everyone keeps
suggesting. Otherwise the list is too big and too "fluid" to be
maintainable in real life.

Further on that, as many people have noted the real thing should  be
fixing bind. Well, do we like it or not bind cannot cater to everyone's
needs. If used correctly it will do the job for what it has been
designed. Same for other usual suspects.

>From there on if someone needs corner cases like high performance
installations, efficiently dealing with restrictions that are expressed
as 2000+ entry bind ACLs, etc the person running it will have to resort
to using network and OS resources outside bind.

Restricting recursion in a service provider environment to mitigate 
DDOS attack amplification is only one of these cases. As a matter of
fact there are plenty of others. And we will be much better off if more
people start setting bind (and other dns system) correctly.

Cheers,

-- 

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

		



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ