Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.arcetri.astro.it/irlab/doc/library/linux/lasg-www/servers/dns/index.html
Дата изменения: Tue Jan 18 09:28:00 2000
Дата индексирования: Tue Sep 14 22:58:50 2010
Кодировка:

Поисковые слова: р п р п р п р п р п р п р п р п р п р п р п р п р п п р п п р п
LASG - Network services - DNS

Network services - DNS

Overview

DNS servers

Overview

DNS is an extremely important service for IP networks. I would not hesitate to say probably the MOST important network service (without it no one can find anything else). It also requires connections coming in from the outside world, and due to the nature and structure of DNS the information DNS servers claim to have may not be true. The main provider of DNS server software (named, the de facto standard) is currently looking at adding a form of DNS information authentication (basically using RSA to cryptographically sign the data, proving it is 'true'). If you plan to administer DNS servers I would say that O’Reilly and Associates “DNS & BIND” is required reading.

DNS servers

Bind

Most distributions are finally shipping bind 8.x, however none (to my knowledge) have shipped it setup for non-root, chroot'ed use by default. Making the switch is easy however:

-u
specifies which UID bind will switch to once it is bound to port 53 (I like to use a user called 'named' with no login permissions, similar to 'nobody').

-g
specifies which GID bind will switch to once it is bound to port 53 (I like to use a group called 'named', similar to 'nobody').

-t
specifies the directory that bind will chroot itself to once started. /home/named is a good bet, in this directory you should place all the libraries and config files bind will require. 

An even easier way of running bind chroot'ed is to download the bind-chroot package, available as a contrib package for most distributions, and install it. Before installation you will need a user and group called named (which is what the bind server changes it UID/GID to), simply use groupadd and useradd to create the user/group. Some packages uses holelogd to log bind information to /var/log/messages (as bind would normally do). If this isn’t available you will have to install it by hand, which is a chore. In addition to this the default configuration file for bind is usually setup securely (i.e., you cannot query bind for the version information).

Another aspect of bind is the information it contains about your network(s). When a person queries a DNS server for information, they typically send a small request for one piece of information. For example what is the IP address for www.seifried.org? And there are domain transfers, where a DNS server requests all the information for say seifried.org, and grabs it and can then make it available to other (in the case of a secondary DNS server). This is potentially very dangerous, it can be as or more dangerous then shipping a company phone directory to anyone that calls up and asks for it. Bind version 4 didn't really have much security, you could limit transfers to certain server, but not selectively enough to be truly useful. This has changed in Bind 8, documentation is available at http://www.isc.org/bind.html. To make a long story short in Bind 8 there are global settings and most of these can also be applied on a per domain basis. You can easily restrict transfers AND queries, log queries, set maximum data sizes, and so on. Remember, when restricting zone queries you must secure ALL name servers (master and the secondaries), as you can transfer zones from a secondary just as easily as a master.

Here is a relatively secure named.conf file (stolen from the bind-chroot package at ftp://ftp.tux.org/):

options {
// The following paths are necessary for this chroot
directory "/var/named";
dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE
pid-file "/var/run/named.pid"; // _PATH_PIDFILE
statistics-file "/var/tmp/named.stats"; // _PATH_STATS
memstatistics-file "/var/tmp/named.memstats"; // _PATH_MEMSTATS
// End necessary chroot paths
check-names master warn; /* default. */
datasize 20M;
};
zone "localhost" {
type master;
file "master/localhost";
    check-names fail;
    allow-update { 
        none; 
    };
    allow-transfer { 
        any; 
    };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "master/127.0.0";
    allow-update { 
        none; 
    };
    allow-transfer { 
        any; 
    };
};
// Deny and log queries for our version number except from localhost
zone "bind" chaos {
type master;
file "master/bind";
    allow-query {
        localhost; 
    };
};
zone "." {
type hint;
file "named.zone";
};
zone "example.org" {
type master;
file "zones/example.org";
    allow-transfer {
        10.2.1.1;
        10.3.1.1;
    };
};

DNS runs on port 53, using both udp and tcp, udp is used for normal domain queries (it's lightweight and fast), tcp is used for zone transfers and large queries (say dig www.microsoft.com). Thus firewalling tcp is relatively safe and will definitely stop any zone transfers, but the occasional DNS query might not work. It is better to use named.conf to control zone transfers.

ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 53
ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 53
ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 53

or

ipchains -A input -p tcp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 53
ipchains -A input -p tcp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 53
ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53

would block zone transfers and large queries, the following would block normal queries (but not zone transfers, so if locking it down remember to use both sets of rules)

ipfwadm -I -a accept -P udp -S 10.0.0.0/8 -D 0.0.0.0/0 53
ipfwadm -I -a accept -P udp -S some.trusted.host -D 0.0.0.0/0 53
ipfwadm -I -a deny -P udp -S 0.0.0.0/0 -D 0.0.0.0/0 53

or

ipchains -A input -p udp -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 53
ipchains -A input -p udp -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 53
ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 53

Chroot'ing DNS

http://www.etherboy.com/dns/chrootdns.html

Dents

Dents is a GPL DNS server, currently in testing stages (release 0.0.3). Dents is being written from the ground up with support for SQL backends, integration with SNMP, uses CORBA for it’s internals. All in all it should give Bind a serious run for the money, I plan to test and evaluate it, but until then you’ll just have to try it yourself. Dents is available at: http://www.dents.org/.

Back

Security Portal

Written by Kurt Seifried