There are several architectural challenges and security flaws inherent in the original design of the DNS protocol for external name servers.
Although most administrators recognize the importance of external name servers,
the occasional misconfiguration or operational mistake is inevitable, largely because of the complexity of managing most name servers. For example, nearly every administrator of a BIND name server—the preferred make of external name server— has made a mistake and introduced a syntax error into a named. Config file or zone data le (a similar risk of human-error is also high when using non-BIND solutions, like Microsoft). However, a syntax error in a zone data le, gone unnoticed, will render the name server unable to load that zone, and will result in a name server returning either old data or no data. Worse, a syntax error in the name server’s configuration le will prevent the name server from starting.
Many administrators don’t take the simple precaution of configuring their forwarders to process recursive queries only from internal IP addresses. This may be because they don’t know how or because they don’t understand the implications of leaving an external name server “open” to recursive queries.
For example, an inherent vulnerability occurs when a name server allows recursive queries from arbitrary IP addresses. This approach is vulnerable to cache-poisoning attacks, in which a hacker can induce the name server to cache fabricated data. In the most famous attack of this kind, Eugene Kashpureff poisoned the caches of hundreds of Internet name servers, leading them to direct users accessing www.intemic.net to the IP address of a web server run by an organization called the AlterNIC.
It’s difficult to overstate the damage an attack like this could cause today: a hacker could redirect traffic intended for a bank’s web site to a web server with a replica of the site’s content, and steal account numbers and passwords; or siphon off traffic meant for a web-based merchant to an identical web site and capture credit card numbers.
With BIND and Microsoft name servers, upgrading to a new version of the software
is non-trivial. Upgrading involves, at the very least, downloading new source code, compiling, testing, and installing it. In many cases, incompatibilities with previous versions force administrators to modify configurations or zone data or, worse, actually read the documentation. Consequently, many administrators put off the crucial task of upgrading their name servers when new versions are released.
This can have disastrous effects. Months after a buffer overrun was discovered and patched in the code, the LiOn worm exploited the vulnerability to infect hundreds
of name servers around the Internet. The worm also installed a “rootkit,” which the worm’s author (or anyone else familiar with the worm’s operation) could use to gain root access to the infected host. The hacker could have modified or destroyed zone data, or in some circumstances could have used the name server as a stepping-stone into the unprepared company’s network. Even today, it is highly likely there are still name servers on the Internet that were compromised during LiOn’s spread, unknown to their administrators.
Ever-Growing Attack Options
One of the biggest challenges for IT organizations is the varied and ever-changing options for DNS attacks. Common attacks include:
|TCP SYN Flood Attacks||A DDoS DNS attack, typically leaves “hanging” connections by flooding DNS server with new TCP connection requests until the target machine fails.|
|UDP Flood Attack||A DDoS DNS attack, sends a large number of UDP packets to a random port on the targeted host to confuse or overwhelm the target machine until it fails.|
|Spoofed Source Address/ LAND Attacks||A DDoS DNS attack, sends a spoofed TCP or UDP packet with the target host’s IP address to an open port as both source and destination. The reason this attack works is because it causes the machine to reply to itself continuously, therefore making it essentially unavailable to other applications.|
|Cache Poisoning Attacks||A core DNS attack, poisons DNS cache typically in order to send legitimate requests to malicious websites.|
|Man in the Middle Attacks||A core DNS attack, a compromised machine in the network can penetrate and take over the entire DNS structure and then route legitimate requests to malicious websites.|
There are many other ways a DNS server may be compromised, and newer, more complex methods are being devised all the time in the underworld of botnets, but these have happen with the most frequency and have characteristics common to many others.
Aren’t General-Purpose Computers Good Enough for DNS?
Most companies deploying external name servers have chosen computers running general-purpose operating systems as their platform. While this deployment may be inexpensive to deploy and may function, general-purpose servers have several major risks that actually increase the propagation of DNS attacks:
- General-purpose operating systems require significant knowledge and effort
to secure. Securing a UNIX OS requires understanding which network and system services should be disabled and how to disable them, which patches are necessary, which kernel modules and device drivers are needed and which are extraneous, how to configure UNIX packet filters, and much more.
- In addition to patching the OS, the name server code itself frequently needs to be upgraded to address vulnerabilities or simply to add new features. This usually must be done separately from upgrading the operating system.
- General-purpose OSs support user logins. Hackers can use these to gain administrator-level access to the operating system. Even in the best case, with secure logins and benign users, those users may inadvertently destabilize the operating system by installing software that consumes system resources, by filling disks, etc.
- Most general-purpose operating systems offer all-or-nothing administration, empowering administrators to either change any aspect of the name server’s configuration and zone data, or nothing. Giving a junior administrator only limited access to the name server is nearly impossible.
- Configuration of a name server’s internal security mechanisms is difficult, and consequently often ignored by even seasoned administrators.
Shortcomings of the conventional approach include:
- Many open ports are subject to attack
- Users have OS-level account privileges on server
- Requires time-consuming manual updates
- Requires multiple applications for device management
- Inconsistent or outdated security procedures
Securing Your DNS Infrastructure and Applications
Instead of relying on general-purpose servers and hoping your internal IT team will never leave a hole in the system, organizations can leverage purpose-built appliances with intuitive interfaces and embedded expertise to improve DNS availability and reduce the risk of DNS attacks.
Most IT executives understand the value of purpose-built solutions but implement general purpose servers because they think they are less expensive. However, the focused approach reduces the risk of configuration errors, supplies the expertise you need to have available, and reduces the cost of implementation and maintenance due to the risk reduction and staff empowerment.