Flylib.com

Books Software

 
 
 

Chapter 7. Security


Chapter 7. Security

Section 7.1.  Introduction

Section 7.2.  Concealing a Name Server's Version

Section 7.3.  Configuring a Name Server to Work with a Firewall (or Vice Versa)

Section 7.4.  Setting Up a Hidden Primary Master Name Server

Section 7.5.  Setting Up a Stealth Slave Name Server

Section 7.6.  Configuring an Authoritative-Only Name Server

Section 7.7.  Configuring a Caching-Only Name Server

Section 7.8.  Running a Name Server in a chroot( ) Jail

Section 7.9.  Running the Name Server as a User Other than Root

Section 7.10.  Defining a TSIG Key

Section 7.11.  Securing Zone Transfers

Section 7.12.  Restricting the Queries a Name Server Answers

Section 7.13.  Preventing a Name Server from Querying a Particular Remote Name Server

Section 7.14.  Preventing a Name Server from Responding to DNS Traffic from Certain Networks

Section 7.15.  Protecting a Name Server from Spoofing


7.1 Introduction

Name server security is no great mystery. It's largely a matter of understanding the services a name server provides, then making sure it provides them only to authorized entities. Most name servers provide authoritative name service, recursive name service, and zone transfers, and some handle dynamic updates, too. Typically, you'll want to limit a name server to:

  • Accepting recursive queries from the resolvers that are authorized to use it

  • Accepting any nonrecursive queries in zones it's authoritative for

  • Providing zone transfers only to authorized slaves

  • Accepting dynamic updates only from authorized updaters

There are also a few operating system-level precautions you can take, such as running a name server in a chroot( ) "jail" and running it as a user other than root.

The trick, then, is identifying who's authorized to use the name server's services, and configuring the name server to enforce the necessary restrictions. This chapter helps you do both.


7.2 Concealing a Name Server's Version

7.2.1 Problem

Modern BIND name servers respond with their version to queries for TXT records attached to the pseudo-domain name version.bind in the CHAOSNET class. For example:

$ dig version.bind txt chaos

; <<>> DiG 9.2.1 <<>> version.bind txt chaos
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5096
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.2.1"

You want to conceal the version a name server returns.

7.2.2 Solution

The simplest way to accomplish this is to use the version options substatement. The version substatement takes it as a string to return to version.bind queries as an argument. For example:

options {
    directory "/var/named";
    version "None of your business";
};

Some folks, however, don't want their name servers to return anything , not even a bogus answer, to unauthorized queriers. Others want authorized queriers to see the real version instead of a bogus one.

To set that up, create a CHAOSNET zone called bind and a zone statement for it in named.conf . Then use allow-query to restrict queries to the zone. Here's a sample bind zone data file:

$TTL 1d
@    CH    SOA     ns1.foo.example.    hostmaster.foo.example.    (
     2002052600 86400 3600 604800 3600 )
     CH    NS    ns1.foo.example.

version.bind.    CH    TXT    "BIND 9.2.1"

Notice that the records in the bind zone are all in the CHAOSNET class, as you would expect.

On a BIND 8 name server, the zone statement for the bind zone might look like this:

zone "bind" chaos {
    type master;
    file "db.bind";
    allow-query { localnets; };
};

On BIND 9, the configuration is a little more complicated. Even if you don't explicitly use views, BIND 9 creates zones in an implicit "default" view in the Internet class. So you can't just create a CHAOSNET zone in the default view, because the zone and the view have different classes: you need to create a new CHAOSNET view and define the bind zone in it. And, if you weren't using views before, you need to create an explicit Internet view for your other zones and move their zone statements into the view.

For example, if your BIND 9 name server's named.conf file looks like this now:

options {
    directory "/var/named";
};

zone "foo.example" {
    type master;
    file "db.foo.example";
};

You might change it to look like this:

options {
    directory "/var/named";
};

view internet in {

    zone "foo.example" {
        type master;
        file "db.foo.example";
    };
};

view chaosnet chaos {

    zone "bind" {
        type master;
        file "db.bind";
        allow-query { localnets; };
    };
};

7.2.3 Discussion

Camouflaging a name server's version is no substitute for running an up-to-date version of BIND or for configuring the name server securely. About the best you can hope for is that concealing a name server's version will prevent hackers from identifying it as an obvious, first-choice target if the version of BIND it's running has a vulnerability.

7.2.4 See Also

"BIND Version" in Chapter 11 of DNS and BIND .