Книга: Fedora™ Unleashed, 2008 edition

DNS Security Considerations

DNS Security Considerations

Several configuration options exist for named that can make it more resistant to various potential attacks. The most common ones are briefly described next. For more detailed discussions of the syntax and use of these options, refer to the BIND 9 documentation.

Specifying network and IP addresses multiple times in a configuration file is tedious and error prone. BIND allows you to define access control lists (ACLs), which are named collections of network and IP addresses. You use these collections to ease the task of assigning permissions. Four predefined ACLs exist:

? any — Matches anything

? none — Matches nothing

? localhost — Matches all the network interfaces local to your nameserver

? localnets — Matches any network directly attached to a local interface

In addition, you can define your own lists in named.conf, containing as many network and IP addresses as you prefer, using the acl command as shown:

----------
acl trusted {
 192.0.2.0/29;   // Our own network is OK.
 localhost;      // And so is localhost.
 !192.0.2.33/29; // But not this range.
};
----------

Here you see that you can use an exclamation point (!) to negate members in an ACL. After they are defined, you can use these ACLs in allow-query, allow-transfer, allow-recursion, and similar options, as discussed next.

As mentioned before, most nameservers perform recursive resolution for any queries they receive unless specifically configured not to do so. (We suppressed this behavior by using dig +norec.) By repeatedly fetching data from a number of unknown and untrusted nameservers, recursion makes your installation vulnerable to DNS poisoning. (In other words, you get deliberately or inadvertently incorrect lists.) You can avoid this problem by explicitly denying recursion.

You can disable recursive queries by adding a recursion no statement to the options section of named.conf. It might still be desirable to allow recursive queries from some trusted hosts, however, and this can be accomplished by the use of an allow-recursion statement. This excerpt would configure named to disallow recursion for all but the listed hosts:

----------
options {
 ...
 recursion no;
 allow-recursion {
  192.0.2.0/29;
  localnets; // Trust our local networks.
  localhost; // And ourselves.
 };
};
----------

You can choose to be still more restrictive and allow only selected hosts to query your nameserver by using the allow-query statement (with syntax similar to allow-recursion, as described previously). Of course, this solution does not work if your server is authoritative for a zone. In that case, you have to explicitly allow-query { all; } in the configuration section of each zone for which you want to serve authoritative data.

You also can use queries to enable only known slave servers to perform zone transfers from your server. Not only do zone transfers consume a lot of resources (they require a named-xfer process to be forked each time) and provide an avenue for denial-of-service attacks, but also there have been remote exploits via buffer overflows in named-xfer that allow attackers to gain root privileges on the compromised system. To prevent this, add a section such as the following to all your zone definitions:

----------
zone "example.com" {
 ...
 allow-transfer {
  192.0.2.96; // Known slave.
  localhost;  // Often required for testing.
 };
};
----------

Despite all this, it might be necessary to single out a few troublesome hosts for special treatment. The server and blackhole statements in named.conf can be used to tell named about known sources of poisoned information or attack attempts. For instance, if the host 203.122.154.1 is repeatedly trying to attack the server, the following addition to the options section of named.conf causes the server to ignore traffic from that address. Of course, you can specify multiple addresses and networks in the black-hole list:

----------
options { ...
blackhole { 203.122.154.1; };};
----------

For a known source of bad data, you can do something such as the following to cause your nameserver to stop asking the listed server any questions. This is different from adding a host to the black-hole list. A server marked as bogus is never sent queries, but it can still ask questions. A black-holed host is simply ignored altogether:

----------
server bogus.info.example.com { bogus yes;};
----------

The AUS-CERT advisory AL-1999.004, which discusses denial-of-service attacks against DNS servers, also discusses various ways of restricting access to nameservers and is a highly recommended read. A copy is located at ftp://ftp.auscert.org.au/pub/auscert/_advisory/AL-1999.004.dns_dos. Among other things, it recommends the most restrictive configuration possible and the permanent black-holing of some addresses known to be popular sources of spoofed requests and answers. It is a good idea to add the following ACL to the black-hole list of all your servers:

----------
/* These are known fake source addresses. */
acl "bogon" {
 0.0.0.0/8; # Null address
 1.0.0.0/8; # IANA reserved, popular fakes
 2.0.0.0/8; 192.0.2.0/24; # Test address
 224.0.0.0/3; # Multicast addresses
 /* RFC 1918 addresses may be fake too. Don't list these if you
    use them internally. */
 10.0.0.0/8;
 172.16.0.0/12;
 192.168.0.0/16;
};
----------

Оглавление книги