Securing Name Servers on UNIX
BIND statements such as xfernets, allow-transfer, allow-query and allow-update statements define ways of restricting many features by IP addresses. This type of configuration does not provide any protection if the IP addresses are spoofed. To protect against IP spoofing, network administrators must establish proper IP spoofing controls on the firewalls, bastion hosts and intrusion detection systems (IDS).
Some other measures that can be used to secure the name servers include the use of split-brain name servers and removing unnecessary information from the DNS database.
A split-brain name server consists of two separate name servers. These are quite common in a firewalled environment. Typically, one name server (sometimes referred to as the external name server, outside the firewall) provides information on the web servers, the MX records, other name servers and names associated with any other services offered by a location. The other name server, inside the firewall, contains information on the other name servers in the enterprise. As you can see, the external name server is the interface to the outside world and therefore provides only minimal information. To provide further protection, the external name server can be configured to turn off recursion.
The idea is to differentiate between name servers that permit recursion and those that do not. It is necessary to permit recursion on some name servers so that clients issuing recursive queries continue to operate. In such situations, one name server can be configured with recursion turned off. Such a name server is authoritative for its zone and will reject recursive queries. Typically, this is the type of server registered with the network domain registries. The other name server permits recursion; however, it permits such queries from only a few authorized hosts/networks. This allows only authorized resolvers to query the recursive name server.
Unnecessary data in the name server makes it easier to gather intelligence from the name server. Information such as the names of users and administrators, phone numbers and detailed information about the host's make and model, if unnecessary, may be omitted from the name server database.
BIND normally runs as root. Running BIND as root may allow an intruder to exploit vulnerabilities, allowing them to run commands and read/write files as root. BIND server 8.1.2 and later provide you with the option to run BIND as a user other than root. In addition, BIND 8 also provides the option to chroot the name server. The u and t options to the name server daemon accomplish this.
Significant security enhancements and improvements have been made in the BIND implementation of DNS. At a minimum, install the most recent version of BIND to protect against commonly known BIND vulnerabilities. To further secure your environment, use the security configuration options in the latest release of BIND. Be careful when you apply BIND updates to your environment, especially if you obtain them from the ISC web site as opposed to your OS vendor. Proper care must be taken when applying vendor patches. Often, vendor patches will overwrite the BIND executable and other related files. The result may be a broken or vulnerable name server.
To keep up with the latest developments in BIND, read the BIND newsgroups, periodically check the ISC web site, and review all DNS-related announcements from your OS vendor. BIND 8.2 includes DNS security features as specified by RFC 2065 (DNSSEC, DNS Security Extensions). The DNS security features use public key cryptography to provide data origin authentication and data integrity. Each zone has its own private/public key and uses its private key to sign the resource records. The DNSSEC extensions are currently not widely deployed. Under DNSSEC, the public key of a zone needs to be signed by its parent zone. As of this writing, the Internic does not yet sign the child zone keys.
Finally, it is most important to say that DNS is only a service, meaning you will be able to access a resource if you have its IP address. Your name server is only as secure as the network and other servers on the network. It is thus paramount that you have suitable network and server security measures in place before trying to protect your name servers.
Nalneesh Gaur (Nalneesh.Gaur@gte.net) is a manager in the eRisk Solutions practice of Ernst & Young LLP in Dallas, Texas. He has specialized in UNIX and Windows NT systems, integration and Internet/intranet security issues for a number of years.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development