CertiGuide to Security+  9  Chapter 3:  Infrastructure Security (Domain 3.0; 20%)       9  3.5  Security Baselines            9  3.5.3  Application Hardening

3.5.3.4  FTP Servers 1 2 3.5.3.6  NNTP Servers

DNS Security Issues

There are a number of historical flaws in DNS that have begun to be addressed by new protocols such as DNSSEC (DNS Secure), which provides for more authentication than the original DNS protocol, and is implemented in BIND 9.

One of these issues, present in BIND 8 and other versions, is the availability of unauthenticated zone transfers. Zone transfers are used to update secondary DNS servers with the changes made to a zone’s DNS information on the primary DNS server. Hosts involved in the zone transfers do not authenticate themselves in any way. Most DNS servers allow administrators to restrict zone transfer operations to specific hosts. The way that this should be used is that you should restrict zone transfers from your primary name server to only your secondary name servers. No other servers need to perform this action. Since too many zone transfer requests can also cause a DoS condition, it is in your best interests to not allow any other machines to perform zone transfers.

Another issue is that of spoofing, through which you can feed bogus DNS data to other servers (or, it can be fed to you!). Fortunately, the more recent versions of BIND, the DNS server commonly run by UNIX machines, are not susceptible to this. (So, if you’re running a version of BIND less than 8, upgrade now!).

If you’re running a server that does not yet incorporate anti-spoofing enhancements, you’ll have to take other measures such as placing your DNS server behind your firewall or turning off recursive DNS queries (which leads to its own problems)³⁷⁵.

Related to spoofing is indirect DNS cache poisoning, in which an attacker takes some action that causes your name server, to query a name server under his control, for DNS information. If the information his name server provides to your server is bogus, he has managed to get your server to load bogus information into its cache.

Since a DNS server, if attacked in these or other ways, can be used to provide false mapping data (possibly causing sensitive data to be redirected to unintended locations, like an attacker’s personal machine) or cause a denial of service to your network, it is important to safeguard it by making sure that the OS and DNS software is securely configured and that you are running with the latest updates.

To allow for continued name service in the event of the failure of one server, you should carefully consider your DNS architecture. DNS should be configured redundantly, with both primary and secondary name servers (for example, with your own organization’s DNS server as primary, and your ISP’s as secondary). That way, you have created some redundancy to minimize the effects of DNS server downtime. Similarly, a large company should have multiple internal DNS servers, on separate subnets, to avoid the single point of failure that locating all of them on the same subnet can create. On this subject, a survey conducted by Men & Mice in June, 2002, revealed that 27% of Fortune 1000 companies have all their DNS servers on the same subnet.³⁷⁶

Since attackers have been able to crash various name servers by overwhelming them with data in various ways, it is safest to run the name server with the minimum necessary permissions. Should a buffer overflow exploit be found in your DNS server of choice, and should an attacker get to your machine before a patch is available, you’d be better off if the user compromised is a relatively unprivileged user with limited system access rather than an administrative user.

This litany of issues is why the Internet wizards are hard at work at developing a more secure DNS protocol. Until then, we take the precautions that we can and watch for vulnerability reports and patches.

3.5.3.4  FTP Servers 1 2 3.5.3.6  NNTP Servers