I don't have a testing tool to suggest, but I can suggest some good
practices to consider.
Because my DNS server gets used as a middleman in DOS attacks against
other sites, I added some new rules recently that I think are a good
idea.
A nameserver set up on a specific machine to cache for that specific
machine should only listen on 127.0.0.1 and should only accept queries
from 127.0.0.1. As a generalization, a nameserver set up for internal
use should only listen on the intended network, and should only accept
queries for the intended network.
A nameserver that has to be accessible from the internet at large should
not answer requests from outside the network except for zones which it
is authoritative.
For example, my mail server has its own DNS server for performance and
stability reasons. In its named.conf I have:
options {
listen-on {127.0.0.1;};
allow-query { localhost; };
};
My primary name server needs to answer queries about nmt.edu to outside
hosts, but not about the rest of the world. It also doesn't want to
AXFR its zones to anyone who doesn't have a legitimite need for them.
The documentations for bind 9 suggests blackholing certain special
networks. In my primary nameservers named.conf I have:
// these are bad machines that we want to spank (suggested by the ISC)
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0 .0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
options {
/*
** Restrict zone transfers, recursion, and queries. Remember to
** explicitly allow queries for zones we are auth for later on in
** the zone file.
*/
allow-transfer { nmt;nmsu;unm;friendly; };
allow-recursion { nmt;nmsu;unm;friendly; };
allow-query { nmt;nmsu;unm;friendly; };
blackhole
{
bogusnets;
};
};
The acl's for nmt, nmsu, unm, and friendly correspond to networks and
addresses which are special and we answer queries to. Later on, each
zone for which the nameserver is authoritative has this:
zone "nmt.edu" {
type master;
file "nmt.edu";
allow-query { any; };
};
A query from outside against anything in the zone "nmt.edu" will be
answered, but everything else is explicitly denied.
Remember that most sites have authoritative DNS servers in other
organizations that might have different policies than the primary, so
check all DNS servers listed in the SOA for the domain.
Our hosts have HINFO records, and often TXT records telling all about
them. I consider that info to be pretty public since it can be easily
gleaned in other ways without using DNS, so we don't bother to hide it.
Some people say you shouldn't do recursion for outside queries. If you
block all outside queries, it doesn't matter. If you don't block them,
I don't think blocking recursion helps much. Recursion can be forced by
sending packets to an inside address that cause that machine to do a
"legitimite" lookup.
On Wed, Mar 07, 2001 at 10:36:56AM -0300, Laura Nuņez wrote:
> I am trying to find any tool to pen test a DNS server, or
> documentation about best practices to set it up.
> I have this, by the moment
> - Disable Zone Transfers
> - Assign reverse DNS to only those host that require it
> - Split DNS for internal hosts
> - Apply fixes, version upgrades to avoid known
> vulnerabilities
> - Don't include additional info records,
>
> Thare is something else i should account? Or tools to check this
> automatically? I have been using SamSpade for Zone Transfers.
>
> Thanks in advance for any info,
>
> Saludos, Laura
> ---------------------------------------
> Laura Nuņez
> mailto:potus_at_glacyar.com.ar
> PGP Fingerprint: 995C 89F3 DAF5 F106 4D6C C4B4 8A0C 832F A2FD 1BBA
> PGP Public Key: http://www.glacyar.com.ar/potus.asc
> Sitio web: http://www.glacyar.com.ar
> Lista Glacyar InfoSec: http://glacyar.listbot.com/
> ---------------------------------------
--
William Colburn, "Sysprog" <wcolburn_at_nmt.edu>
Computer Center, New Mexico Institute of Mining and Technology
http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn
Received on Mar 07 2001
Intro
