Section 4.6 DNS (named, a.k.a. BIND) | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

4.6 DNS (named, a.k.a. BIND)

graphics/fourdangerlevel.gif

The named program, meaning the name daemon or DNS daemon, is the program that converts a fully qualified host name, such as

www.realworldlinuxsecurity.com

to its numeric IP address like

 192.168.57.8

Without it there would be no www.cute-name.com; there would be only 63.236.72.248 and the Internet would be harder to deal with and less flamboyant. Many leaf nodes that do not route traffic for other systems do not need to run it. Instead they simply specify the numeric IP addresses of their name servers in /etc/resolv.conf and any program, such as sendmail, telnet, ftp, and Netscape simply will read /etc/resolv.conf and make the request for DNS lookup directly to the remote name server system's named. Small "internal only" networks may not use DNS at all, instead they will rely on each system's /etc/hosts file being set up correctly.

4.6.1 Limiting Consequences of a Named Compromise

graphics/threedangerlevel.gif

Starting in version 8.1.2, named no longer needs to be run as root. The only reason it needed to run as root was to open TCP and UDP ports 53. Now one can use the -u flag to have it do a setuid() call to the specified user after it opens the ports. The argument may be either a user name or a numeric UID. Similarly, there is the -g flag to request a setgid(). Making use of -u and -g is strongly encouraged to eliminate almost all root vulnerabilities in named if another buffer overflow bug is encountered, like the one in named versions 8.2 and 8.2.1.

The user and group that named should be run under should be different from anything else in the system to isolate it; dns is a fine choice. Certainly, an encrypted password of "*" as the second field in a user's entry in the /etc/passwd will prevent logins on this account. Specifying /dev/null as the user's login shell will further lock down the account.

Recall that named's job is to determine the IP for a host name and so all it needs to do is to talk on ports 53 and read and write a few of its own files. Thus, it is an excellent candidate for being put in a chroot jail so it cannot harm anything (other than possibly lying about IP addresses). On Red Hat, Mandrake, and other distributions that use the /etc/rc.d/*.d scheme, edit the /etc/rc.d/init.d/named file and change the line reading

 daemon named

to read

 daemon named -u dns -g dns

The user and group dns should be created having a UID and GID that is not otherwise used, with a disabled password, a shell of /dev/null, and its own home directory, for example, /home/dns with mode 700.

The -t flag may be used to specify a directory to have named chroot itself to during startup. /home/dns makes a fine argument to -t. You will need to copy any dynamic libraries to /home/dns/lib that named will need, as well as the configuration files that it requires, typically /etc/named*. Because root can break out of a chroot "prison," it is critical that you also use the -u and -g flags to cause named to switch to be an unprivileged user and group after opening ports 53.

4.6.2 To Serve Man

Like The Twilight Zone episode,^[3] you need to decide how other systems might use your systems' services. You do not want systems outside your network to be able to see the names and IP addresses of all your internal systems because that would be an invitation for cracking. At the same time you will want all your inside systems to see each other.

^[3] In "To Serve Man," aliens come to Earth and offer to help the human race to become better, stop war, etc. and invite exchange trips much like foreign exchange students. They leave behind a book written in alienese and they translate the title rather quickly to To Serve Man and everyone is happy. But when the protagonist, the head of the government code branch that is trying to translate the book, is boarding a spaceship for one of these exchange trips, his assistant calls out to him, "It's a cook book!" but it is too late for him.

The solution is to have two name servers, one for inside use and one for the rest of the world to use. The name servers that you specify to your domain registrar (such as Network Solutions) would be the servers for external use. Their configuration files would list only externally visible systems such as the corporate mail, Web, and FTP servers and any other systems that receive e-mail directly or which will allow SSH access.

A useful "implementation detail" is that small requests, such as converting a host name to a numeric IP, are done via UDP and larger requests such as dig requests and zone transfers are done via TCP.

You almost never want external sites to do zone transfers and dig commands of your site. This is because a zone transfer will allow an external site to learn the names and IP addresses of all your internal systems. This would enable a cracker to know what systems are there for the cracking. Additionally, the host names might reveal confidential information.

For example, a host name of afradar.r_d.pentacorp.com might be a Research and Development project for radar systems for the Air Force. Assume that the spy doing this cracking knew that Pentacorp people recently had met with Lockheed people and that Lockheed is the prime contractor for the new Air Force YF22 fighter. This implies that pentacorp.com is either the subcontractor for the radar work or is trying to win that contract. That is a whole lot of information that was garnered from just a host name.

All you need to do is to block TCP requests to port 53 of your "external" name server from systems outside your network. For large organizations, such as a Fortune 500 company or large government bureau, a DNS server may hold the names of hundreds or thousands of systems.

One DoS attack is to repeatedly request a zone transfer from your name servers. This ties up your name servers as well as bandwidth. By blocking TCP port 53, you prevent this attack. A better solution is to use the access controls supported by recent versions of named.

The IP addresses that you tell people in your organization to specify in their /etc/resolv.conf files would be the name servers for internal use, of course. Access to the internal name server's ports 53 (both TCP and UDP) from outside the organization should be blocked by IP Chains. This blocking is to prevent crackers from trying to "suck" DNS information from port 53 of every IP in your domain and encountering your internal name server.

Even though your firewall may block access to these internal systems, there are some recent exploits that allow tunneling through firewalls. Additionally, just knowing the names of systems might allow your competition to learn about your development activities. Firewalls are discussed in great detail in "Firewalls with IP Chains and DMZ" on page 514.

Top