In the SSE CMM Framework: Monitor Security Posture /Monitor Security Safeguards.

• Not posted to honor anonymity request.

Secondary POC:
Yes, post this contact information with the publicly accessible BSP.

• Artch Griffin
  General Services Administration, Office of Governmentwide
  Policy, Electronic Commerce (GSA/OGP/ME)
  1800 F Street, Suite G-131
  Washington DC 20405
  Telephone: 202-219-2370
  Fax: TBD
  E-mail: artch.griffin@gsa.gov

1. Prevent unauthorized zone transfers from accessing the Domain Name Server (DNS) database (called a "zone" file),
2. Reduce the exposure to DNS content corruption through either dynamic updates to the zone file or "cache pollution" (also called DNS spoofing or cache poisoning),
3. Identify tools for checking the zone files and delegations for correct entries, and
4. Identify other useful DNS resources.

This BSP provides DNS operators, "hostmasters", with suggestions and techniques for securing and improving the operation of their servers. It also guides them to useful tool and information resources. This BSP has no applicability to networks that are not using DNS for host name resolution.

The references given offer sample configurations for most implementations of DNS, however several of the low/no-cost tools are written as "Un*x shell scripts" or are written in PERL.

The author welcome reports and reviews on commercial DNS tools.

• Run a current version of your name server
• Restrict zone transfers
• Restrict dynamic updates
• Protect against DNS spoofing (cache pollution)
• Check your zones and test your delegations
• Stay current

Step 1 – Check that you are using the latest version appropriate to your specific situation. For BIND, the most commonly used implementation of DNS, the official version as of 3/31/2000, from the Internet Software Consortium (ISC, http://www.isc.org/ ) is 8.2.2-P5. ISC offers the following advise:

If you are running a version of BIND prior to 8.2.2 patchlevel 3, we recommend you upgrade to the current version for security reasons. If you are running BIND 8.2.2-P3, and compiled it yourself, we recommend you upgrade to 8.2.2-P5 to correct a named-xfer problem. If your vendor-provided BIND is 8.2.2-P3, you should consult their documentation and confirm that the named-xfer bug has been patched.

If you are using Microsoft’s DNS Server, check for information at: http://www.microsoft.com/ntserver/nts/downloads/recommended/ .

While the newest version doesn’t guarantee your server’s security, it is likely to reduce the risk of getting hit by old and known problems. Virtually all older server versions have widely known holes.

See http://www.cert.org/advisories/CA-99-14-bind.html and, in particular, the summary table at the end of: http://www.isc.org/products/BIND/bind-security-19991108.html for additional information on which versions have which problems. Be sure to check for newer advisories as well.

One way to check the version being run at a particular site is to check the system start-up logs if you have access to that system. To check on remote systems try the following sequence of name server lookup commands:

> nslookup
> server dns_server_to_test
> set type=txt
> set class=chaos
> version.bind.

You should get a response something like this: VERSION.BIND text = "8.1.2"

Another way to ask is to use the "dig" command like so:

dig @dns_server_to_test. txt chaos version.bind. The answer section would look something like this: VERSION.BIND. OS CHAOS TXT "8.1.2"

The sample data above was taken from a test of a major ISP currently under contract to several agencies. The reply 8.1.2 is disappointing as it reflects, if accurate, the use of a version with four known exploits (see the cert.org and isc.org URLs listed above). Note that not all BIND implementations correctly respond (i.e., the query is not supported) and, furthermore, it is possible to configure newer versions of BIND to report whatever you wish. This can be done using the "version" sub statement, for example:

options {
version "surely you must be joking" ;
};

Organizations that wish to operate "honey-pots" which imply the existence of an apparently broken version of BIND may wish to use this option to report an appropriately deceptive version string.

Step 2 – Restrict zone transfers to reduce the load on your server and network. This also prevents folks from collecting "G2" about your network and services. While the "crackers" can find out a lot without doing zone transfers, there is no reason to make their work easier. If you use BIND, use the allow-transfer sub-statement:

options {
allow-transfer { address_match_list; };
};

or, for specific zone:
zone "some.zone" {
type master;
file "db.some.zone";
allow-transfer { address_match_list; };
};

If you use Microsoft’s DNS, use the Notify tab of the Zone Properties dialog box and check the Only Allow Access From Secondaries Included on Notify List box.

Remember to restrict zone transfers from secondary (slave) name servers in addition to the primary (master) server. This can be a problem if your ISP is hosting your secondaries. Some ISPs do not know how to restrict zone transfers. If yours doesn’t know how, its time to train them or get a new one. To test, use the command nslookup ls domain.to.be.tested if you have a Un*x type system. The "ls’ option is implemented as a zone transfer.

Step 3 – Restrict dynamic updates to only authorized sources and be choosy about it. Dynamic updates are both useful and dangerous. Useful because you can keep your zone up-to-date, but risky since an authorized user can completely change your zone to any thing they want, including erasing it completely. If your needs dictate the use of dynamic updates, then be sure to restrict its use a tightly as possible. This means use individual IP addresses in the access control list. However, you now have another reason to be sure that your border router or firewall/proxy has strong anti-IP-address-spoofing rules in place. (See BSP xx-xxx-xxxx Blocking Spoofed Source IP Address with Ingress Filtering. This BSP is based on IETF RFC 2267, Network Ingress Filtering: … Get your router/firewall administrators to take a look at it.)

At this time (3/31/2000) only BIND provides dynamic updates, however the capability is scheduled for Microsoft’s Windows 2000 offering. BIND’s default is to reject dynamic updates. To activate it, it has to be specified using the allow-update sub-statement.

zone "some.zone" {

type master;

file "db.some.zone";

allow-update { address_match_list; };

};

See Mr. Liu’s online presentation for more details; http://www.acmebw.com/paper.htm .

Step 4 – Protect against DNS spoofing (cache pollution). If you allow your name servers to respond to recursive requests from the Internet, then you run the risk of having your server tricked into learning "false" information. The technique of providing false data to inquisitive name servers has been used in a number of so-called web site cracks. One of the more recent events involved the RSA web site. What the cracker did was to inject false IP address information about RSA’s web site into a name server. The false IP address pointed to a web site in Columbia that had been cracked to display a faked RSA web page. The crackers can do this by sending a recursive query to a target name server asking it to find information about a domain name that is foreign to it. The name server will respond to the recursive request by asking other name servers if they know the answer. By tricking the target name server into asking a name server under the cracker’s control, the cracker can send any answer they want back to the target. Now the target has false information, its cache where it keeps learned information has been polluted. As more web masters improve the security of their sites, crackers are turning to DNS spoofing as a way to make it look like a site has been cracked. While it is true that a site has been broken into (the one in Columbia, in the RSA case) the actual targeted web site has not. Unfortunately the victim still suffers an embarrassment since a web surfer, whose browser looked up the spoofed IP address, will be sent to a corrupted page.

Many agencies appear to be running what is sometimes called a "split DNS" configuration. This is a "Good Thing."ä A split configuration means that two (possibly more) agency zone files are served by two different sets of name servers. One set offers DNS services to the Internet and serves up a limited set of names and IP addresses suitable for public use. It is this set of name servers that should not accept recursive queries. The other set of name servers generally has the full agency domain and is the set of name servers that are pointed to by the client software that the agency provides on its desktops. This internal set of name servers must support recursion.

Cricket Liu, co-author of DNS and BIND has this to say about turning off recursion (Copyright 1997-1998 Acme Byte & Wire LLC).

Disabling recursion puts your name servers into a passive mode, telling them never to send queries on behalf of other name servers or resolvers.

• A non-recursive name server is very difficult to spoof, since it doesn’t send queries, and hence doesn’t cache any data
• You can’t disable recursion on a name server if any legitimate resolvers query it, or if other name servers use it as a forwarder
• If you can’t disable recursion, restrict the queries the name server will accept, shown later

To turn off recursion with BIND 8.*.*, use the recursion substatement:

options {
recursion no;
};

To turn off recursion in Microsoft’s DNS Server use the regedit tool (or regedt32) to add the value NoRecursion to the Registry Key, HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services\DNS\Parameters. Set the value type to REG_DWORD with a value of 1.

One of the features of BIND 8.*.* is its ability to restrict which queries it will respond to. This is useful if you cannot turn off recursion. If this is the case, then you should restrict the queries that the name server will accept to: 1) the source (IP address) they should come from and 2) the zones that they should be asking about. Again quoting from Cricket Liu,

On most name servers:

• Queries for records in authoritative zones can come from anywhere, because the zones are delegated to the name server
• Queries for records outside of authoritative zones should only come from internal addresses

You can implement query restrictions with the allow-query substatement:

acl internal { [<network>/<bits>; | <address>;]
[<network>/<bits>; | <address>; …]
};
options {
directory "/var/named";
allow-query { internal; };
};
zone "some.zone" {
type master;
allow-query { any; };
};

See Mr. Liu’s online presentation for more details; http://www.acmebw.com/paper.htm .

Step 5 – Collect and apply zone-checking tools. Three useful "free" tools are DNSWALK, dlint, and DOC (the Domain Obscenity Checker). They can be found at several different locations:

DNSWALK is now hosted at SourceForge ( http://www.sourceforge.net ), but the link to its prime maintainer is: http://www.visi.com/~barr/dnswalk/ .

dlint can be found at: http://www.domtools.com/dns/dlint.shtml . dlint’s author has this to say:

Are you a DNS database maintainer? Have you ever wished there was an easy way to check your database for subtle errors like "PTR" records that don't point back to the right "A" records? Now you can check for this and many other problems with this useful utility, dlint.

DOC can be found at: http://www.shub-internet.org/brad/dns/ . Two other DNS tools that Brad Knowles maintains can also be found at this site.

It is important to be sure that you have the latest tool version that matches up with the new (8.*.* series of BIND). Which is a reminder that your should be running a current version of what every DNS server you chose.

Step 6 – Review on-line DNS resources and "sign-on/up" as appropriate. While CERT/Fed-CIRC are useful site for the broad spectrum of security issues and should be checked regularly, the comp.protocol.dns.* newsgroup hierarchy is specific to DNS. The Internet Software Consortium is the home of the reference implementation of BIND and, as such, is the authoritative source.

If you have DNS questions you can search the "Ask Mr. DNS" archive at http://www.acmebw.com/cats.htm first and if you don't find your answer there, then go-ahead and Ask Mr. DNS or post your question to the appropriate comp.protocol.dns.* newsgroup.

A newly published annotated list of BIND (named) messages is available at http://www.acmebw.com/askmrdns/bind-messages.htm .

1. DNS servers which can be tested to see if they respond to zone transfer, dynamic updates, or recursive requests from systems that should not be allowed.
2. The reports for tool like DNSWALK and dlint will show how well a domain and the zone files are being maintained.
3. Interested hostmasters can "subscribe" to news-groups or lists of interest.

An number of federal DNS configurations fail to follow the IETF Best Current Practice for selection and operating secondary (slave) DNS servers. While this is not a material security issue there are security implications and definite network performance consiquences for failing to follow the recommendations. This to-be-written BSP XX-X-nn.n.o, Selection and Operation of Secondary DNS Servers will be based upon IETF RFC 2182 (BCP 16).

There are several IETF Best Current Practices (BCP) related to DNS that hostmasters should be aware of:

• RFC 2219 (BCP 17), Use of DNS Aliases for Network Services, M. Hamilton and R. Wright. The IANA name for a protocol should be used as the domain name for the machine that supports that protocol at a site. An HTML version is available. Oct-1997
• RFC 2182 (BCP 16), Selection and Operation of Secondary DNS Servers, R. Elz, R. Bush, S. Bradner and M. Patton . How to select secondary servers. An HTML version is available. Jul-1997.

Time per System/Device:

• Preparation Time up-front: 2 - 4 hours identifying the current condition of the configuration and downloading the appropriate patches in preparation for the on-site activities.
• On-Site Time: 4 - 8 hours depending on the status of the device. Four hours to verify a previously configured device, and up to 8 hours to configure a newly installed device.
• Final Report Preparation Time: 4 hours; this includes the documentation of activities by the reviewer and also the transfer of the documentation by the report writer into the final report.

• General Goal: To eliminate those security vulnerabilities associated with DNS configuration and zone file maintenance.
• Performance Goal: No name server, whether it is BIND, Microsoft DNS, or some other, that supports the .mil, .gov, or fed.us domains and any sub-delegation thereof will allow "foreign" zone transfers, dynamic updates, or inappropriate recursive queries.
• Outcome Goal: Hostmasters will have configured their systems to block un-authorized use.
• Output goal: Hostmasters will review [security] log summaries for unauthorized attempts and will report unusual activity as required by agency policy. The newly published annotated list of BIND (named) messages is available at http://www.acmebw.com/askmrdns/bind-messages.htm can be very helpful in figuring out what log entries mean.

• DSNWALK at http://www.visi.com/~barr/dnswalk/
• dlint at http://www.domtools.com/dns/dlint.shtml/
• DOC at: http://www.shub-internet.org/brad/dns/
• DNS tools for Windows with Mark Symons’ reviews at http://www.dns.net/dnsrd/mark/wintools.html

• DNS and BIND 3^rd edition [comments below Copyright 1994-2000 by András Salamon]

Indispensable tutorial style DNS reference for anyone using BIND. Covers BIND version 4 and 8 while providing a solid background to DNS theory. The DNS is the foundation of nearly all Internet functionality, so this book has become a must-have for Internet administrators of all descriptions. Well-thumbed copies are also common on the shelves of network operations staff, Internet systems integrators, in fact almost all IT practitioners involved with Internet systems. Highly recommended!

This book is also useful for those running the freeware NT port of BIND 4, but note that it does not provide instructions for NT-specific operations issues such as installation, event logging, and the control panel version of ndc.

Published: September 1998.
Authors: Paul Albitz and Cricket Liu
Publisher: O'Reilly & Associates
ISBN: 1-56592-512-2

Errata are available for this book.

• DNS on Windows NT [comments below Copyright 1994-2000 by András Salamon]

Version of the cricket book with the same DNS theory but covering the Microsoft NT 4.0 DNS server instead of BIND. Highly recommended if you need to run the Microsoft DNS server.

Published: October 1998.
Authors: Paul Albitz, Matt Larson and Cricket Liu
Publisher: O'Reilly & Associates
ISBN: 1-56592-511-4

• http://www.dns.net/dnsrd/ DNS Resources Directory (DNSRD) by András Salamon.
• http://www.acmebw.com Ask Dr. DNS and training.
• http://www.isc.org Documentation included with the BIND distribution and training.