Advanced BIND Security: TSIGS and DNSSEC

Most of the security controls we've examined so far in this chapter have involved limiting what data the DNS server provides and when. But what about authentication? For example, what's to stop an attacker from masquerading his host as a trusted master server for your domain and uploading bogus zone files to your slaves, using spoofed packets (i.e., with forged IP source addresses) to get past your ACLs? And what about data integrity: what's to stop such an attacker from using a "man-in-the-middle" attack to alter the content of legitimate DNS queries and replies?

Fortunately, Transaction Signatures (TSIGs), which are described in RFC 2845 and were originally implemented in BIND 8.2, can provide authentication and some measure of data integrity to transactions between DNS servers. Unfortunately, TSIGs don't guarantee that DNS information hasn't been compromised prior to transmission. If an attacker successfully "roots" a DNS server or somehow acquires a copy of its TSIG, bogus DNS information can be signed.

For several years, though, the IETF has been working on DNS Security Extensions (DNSSEC, described in RFC 2535 and other documents developed by the IETF's dnsext working group). This set of extensions to DNS (mainly in the form of new resource records for keys and signatures) provides a means of

cryptographically signing and verifying DNS records themselves. Combining TSIG and DNSSEC functionality should make for much more trustworthy DNS on the Internet.

However, DNSSEC is still a work in progress. Despite being mostly implemented in BIND v9, DNSSEC is a bit complicated and unwieldy as it stands today. Since BIND’s TSIG functionality is more mature, easier to use, and supported in both BIND v8(.2+) and BIND v9, we’ll end our discussion of BIND with a description of how to use TSIGs.

If you’re interested in the cutting edge of DNS security with DNSSEC (I hope that many people are, to help drive its development and eventual widespread adoption), I highly recommend Chapter 11 of Albitz and Liu’s definitive DNS and BIND (O’Reilly). Anyone who’s serious about DNS security should own the newest edition of this book.

6.4.6.1 Transaction Signatures (TSIGs)

To use TSIGs to sign all zone transfers between a zone’s master and slave, all you need to do is this: 1. Create a key for the zone.

2. On each server, create a key{} entry in named.conf containing the key.

3. On each server, create a server{} entry in named.conf for the remote server that references the key declared in Step 2.

Step 1 is most easily done with BIND’s dnskeygen command. To create a 512-bit signing key that can be used by both master and slave, type the following:

dnskeygen -H 512 -h -n keyname

The output will be saved in two files named something like Kkeyname.+157+00000.key and

Kkeyname.+157+00000.private. In this case, the key string in both files should be identical; it will look something like ff2342AGFASsdfsa55BSopiue/u2342LKJDJlkjVVVvfjweovzp2OIPOTXUEdss2jsdfAAlskj==. Steps 2 and 3 create entries in named.conf like those illustrated in Example 6-10. This must be done on each server, substituting keyname with whatever you wish to name the key — this string must be the same on both servers.

Example 6-10. key{} and server{} syntax key keyname {

algorithm hmac-md5;

secret "insert key-string from either keyfile here"; }

server IP address of remote server {

transfer-format many-answers; # (send responses in batches rather than singly)

keys { keyname; }; };

Even without a corresponding server{} statement, a key{} statement tells a DNS server to sign replies to any requests it receives that have been signed by the defined key. A server{} statement tells named to sign all requests and updates it sends to that server, using the specified key. Note that key{} statements must always precede any other statements that refer to them; e.g., server{} statements. I therefore recommend putting key{} statements at the top of your named.conf file, along with your ACL definitions.

After you've created the key and added corresponding key{} and server{} statements to both hosts' named.conf files, all you need to do is restart named on both servers by issuing one of the following commands on both servers: kill -HUP, ndc restart (on BIND v8), or rndc restart (BIND v9).

All subsequent zone data exchanged between these two servers will be cryptographically signed using the shared TSIG key. Unsigned or improperly signed zone data will be rejected.

6.4.6.2 Additional uses for TSIGs

A key specified by a key{} statement in named.conf may also be used in acl{}, allow-transfer{}, allow- query{}, and allow-update{} statements in each statement's element list. This gives you much greater flexibility in building element lists and the statements that use them, and thus more granular control over named's behavior. It also provides a criterion besides IP source address for authenticating client requests, therefore mitigating BIND's exposure to IP-spoofing attacks.

Example 6-11. A TSIG key in an access control list key mon_key { algorithm hmac-md5; secret "ff2342AGFASsdfsa55BSopiue/u2342LKJDJlkjVVVvfjweovzp2OIPOTXUEdss2jsdf AAlskj=="; }

acl goodmonkeys { 10.10.100.13; key mon_key ; };

An English translation of this acl is "the label goodmonkeys refers to the host with IP address 10.10.100.13 whose data is signed with the key mon_key." The key keyname ; syntax used in the acl’s element list is the same whether used in an acl{} or in an allow-transfer|query|update{} statement.

Suppose in the fictional named.conf file excerpted in Example 6-11 we see the following: allow-transfer { goodmonkeys; };

This statement, which could be nested in either an options{} statement or a zone{} statement (depending on whether it’s global or zone specific), says that zone-transfer requests will only be honored if they match the acl goodmonkeys, i.e., only if the requests come from 10.10.100.13 and are signed with the key mon_key.

6.4.7 Sources of BIND (and IS Security) Information

The guidelines and techniques we’ve covered here should give you a good start on securing your BIND server(s). For more in-depth understanding of these techniques, I strongly recommend you read the BIND v8 Operators’ Guide and the BIND v9 Administrators’ Reference Manual. For me at least, these are among the most useful documents provided in any OSS package. Another excellent source of BIND security

information is Liu’s "DNS Security" slideshow. Section 6.6 at the end of this chapter lists information about these and other BIND resources.

Equally important, every BIND user should subscribe to at least one security-advisory email list. BUGTRAQ is my personal favorite, since it’s both timely and inclusive (but it’s also high volume; I recommend the digest version). See http://www.securityfocus.com/cgi-bin/subscribe. pl for an online subscription form. Another excellent list is VulnWatch, which has no digest but is much lower volume than BUGTRAQ. See http://www.vulnwatch.org/subscribe.html for more details.

I also recommend that you look up and read the CERT advisories listed in Section 6.6 at the end of this chapter. Understanding past BIND vulnerabilities is essential to understanding BIND security.

6.5 djbdns

If after reading or skimming my BIND hints you’re still suspicious of BIND’s size, complexity, and history, you may wish to try djbdns, Daniel J. Bernstein’s lightweight but robust alternative. My esteemed colleague and friend, Bill Lubanovic, a web consultant and designer of note, is such a person. He’s written most of what follows.

While this section makes particular note of djbdns’ security features, our intent is to provide a general primer on djbdns use. This is justified (we hope) for two reasons. First, the very act of choosing djbdns rather than BIND has positive security ramifications, if for no other reason than it "diversifies the DNS gene pool." Second, while widely used, djbdns hasn’t yet received much treatment in the print media, so this primer is one of the first of its kind (if not the first).

If neither of these assumptions seems compelling to you, you needn’t feel guilty for sticking with BIND (provided you run Version 9 and take the time to configure, secure, and maintain it carefully). For what it’s worth, I’m a BIND v9 user myself.