Internet Security

Domain Not Secure

The Domain Name System is subject to threats that could potentially crash servers and thereby disrupt your business. Here are some tips to protect the DNS. by Clement Teo

To say that the Domain Name System (DNS) is vital to the Internet would be an understatement. The Internet as we know it would be completely overwhelmed if the DNS did not provide a distributed and fairly robust mechanism that resolves Internet host names into IP addresses, and vice-versa. In addition, the DNS also supports other Internet activities such as information retrieval from DNS Name servers, canonical names, mail exchanges and so on.

While this is fine and dandy, threats to the Internet, and as a consequence, the DNS, have burgeoned over the past few years. Instances of 'phishing' or stealing sensitive data such as credit card information, have been widely reported. Even website spoofing has gone beyond juvenile mischief. Due to a lack of authenticity and integrity checking of the data held in the DNS, and exacerbated in part by other protocols that use host names as an access control mechanism, the dangers that threaten the DNS are real and fundamental.

Huge Impact

How does the lack of DNS server security impact the Internet then? Ian Tribble, security consultant, TruSecure Asia-Pacific, says that the impact is huge because DNS servers need to be open to all Internet users. "Firewalls cannot restrict access to DNS ports because DNS services need to be open. Also the more commonly used DNS protocol is BIND, the source code for which is widely available for many BSD-derived operating systems. The fact that source code is available means programming flaws are also available," he points out.

BIND is short for Berkeley Internet Name Daemon, which is a popular open source implementation of DNS on the Internet.

Whenever a new vulnerability (disclosed or otherwise) is discovered, the potential is there for worms and other malicious code to exploit this vulnerability. This may lead to a wide variety of undesired effects such as loss of data integrity, denial of service, loss of confidentiality, or privacy violations.

Agreeing, Richard Bussiere, CTO, Enterasys Asia-Pacific, says that at a high level, DNS servers are subject to two different types of attacks: attacks against the server itself, and attacks which impact 'normal' operations of the server. "An attack against the DNS server itself has the obvious impact of being a powerful Denial of Service (DoS) attack. A more subtle attack would be the 'poisoning' of the cache, which means that the cache contains false information about the true IP address of a given site," says Bussiere.

Shields up

So what should be done to harden DNS servers? Dr. Bill Hancock, vice-president--Security Practice and Strategy, and Chief Security Officer, Savvis, suggests that the most common defence is to over-engineer the DNS server so that any spoofed or DoS/DDoS attack is basically ineffective due to server over capacity.

Concurring, Anthony Lim, Computer Associates' brand director of Security, Asia South, says that the server hardware, components, OS, RAM and resources should be adequately robust for its heavy-duty cycle. "This helps ensure not only its extended operating integrity but also its security. At best, such a critical server should have a 'hot' active 'mirror' or 'high-availability' server in tow. The security accorded to this server too should be a hot HA solution."

Graeme Le Roux, director at Australian IT Consultancy firm, Moresdawn, argues that we fall into the trap of considering the DNS as something in a class of its own. "It's not. The DNS is nothing more than a single application on a distributed database and as such, protecting it from attack requires pretty much the same strategy as protecting any other distributed database from a similar attack. The unique issue with the DNS has to do with a difference in scale, not in kind," he says.

According to Le Roux, attacks on the DNS fall into three basic categories:

1. Making it unavailable. e.g. DDoS attacks or gaining root access to a host and crashing it.

2. Corrupting the data held by one or more hosts. e.g. re-writing the database.

3. Fraud. e.g. another host masquerading as an authoritative DNS server for one or more domains.

"Attacks of types 1 and 2 happen at the TCP/IP level and thus have nothing to do with the DNS itself, anymore than they would have with a mail server or a Web server, and you defend a DNS server against such attacks in the same way you would defend any other server type," says Le Roux.

Defending against attacks of type 2 requires both securing the DNS server's host OS and the service application providing the DNS. In a typical Unix environment, says Le Roux, the DNS is provided by BIND, so you have to restrict administrative/root access to the host, to BIND's database and to the administrative interface of BIND itself.

In a Windows environment, Le Roux elaborates that DNS services will correspond to a published subset of the objects in the Active Directory. In other environments, for example, the DNS service publishes a subset of objects in an X.500 directory service. "The bottom line is that you have to secure the physical host, its OS and whatever application is providing DNS services. This is no different from securing, for example, the company SQL server," he argues.

TruSecure's Tribble cautions that each vendor has their support structure for its own BIND implementation, and matters such as patch release may vary from vendor to vendor. Tribble cites Microsoft as a vendor that has its own implementation of DNS, which the software giant says is not based on BIND. "But it should not be assumed that problems with BIND do not affect Microsoft's DNS server," says Tribble.

Bind 9

With BIND into its 9th revision, Andrew Namboka, technology consultant at Nokia Enterprise Solutions, highlights that BIND 9 removes a number of vulnerabilities, such as DoS, by introducing support for multithreaded operation, so service failures can be isolated to a single thread and not cause the entire system to go down. "BIND 9 also introduces sophisticated use of signing technologies in the form of Transaction Signatures (TSIG), a real-time message authentication mechanism for verifying source and integrity of zone transfer exchanges," says Namboka.

In addition, it offers syntax checking in zone transfers, error logging and integrity verification capabilities, resulting in the reduced possibility for DoS exploits through overwhelming error log volumes, and a lower possibility of compromise through more rigorous field validity checking, such as in checking TTL existence and value.

"[Some] practical steps that can be taken by the IT Administrator include implementing a 'no user account' policy, dedicating a single machine or a computer to the task of Name Resolution, [and having] other applications on the machine legitimize interaction with applications that may be somewhat less securely deployed and subject to different security measures," Namboka adds.

DNS Security

The Internet Engineering Task Force (IETF) has in the past few years introduced DNS Security (DNSSEC) extensions to the existing DNS protocol to beef it up. Also, the Internet Software Consortium (www.isc.org) has released updates to its BIND 9 software to support all features of DNSSEC.

Bernie Trudel, Cisco System's Asia-Pacific security consultant, believes that DNSSEC will help in detecting false or spoofed zone data. "DNSSEC is the latest standard that addresses many of the critical shortcomings of DNS," says Trudel. "Purchasing software which implements DNSSEC, based on a hardened-server platform with a solid maintenance contract should be an organization's buying criteria."

While DNSSEC may be seen as the panacea for shoring up weaknesses inherent in the DNS, Enterasys' Bussiere is uncertain about its adoption. Says Bussiere: "[Using DNSSEC] involves leveraging PKI to 'digitally sign' responses so that the recipient can be certain that a response comes from a legitimate source.

"Unfortunately, DNSSEC has not been widely deployed due to the additional burden on processing resources that would occur due to the PKI computations."

In addition, Kang Meng Chow, Chief Security and Privacy Advisor, Microsoft Asia Pacific and Greater China, points out that there are many initiatives proposed by various bodies to implement secure DNS infrastructure, but "retrospective replacement of existing implementation appears to be too challenging".

Some Tips

While that may be the case, other experts offer tips to defend your DNS servers. Some suggestions from Moresdawn's Le Roux:

• Split DNS. Basically you separate your public and private DNS databases and only publish the public one. A variation of this is to use another network as your public face. For example, the DNS records for Moresdawn.com.au point to the ISP. Relevant servers at the ISP know the network's actual public IP address so, for example, mail is forwarded transparently but the DNS used on the network is hidden-in fact, it is unreachable behind a firewall.
• Hard code host files on your servers. If you have a server farm whose hosts' IP addresses do not change, then you can hard code these addresses into each server's host files. This means your server farm will still run even if your DNS service goes down, though clients who depend upon the DNS will have a problem. This approach may also give you an incidental performance increase in your server farm.
• Multiple DNS servers. Many large companies do this by accident: the DNS servers for .com, .com.au, .com.sg, .co.uk are typically in different places in the Internet; however they may all hold records which point at a single, specific IP address which will return, say, .com.au when you do a reverse look up. If you use this arrangement rather than, say having all DNS records point to a primary domain and then have that domain's DNS server return an IP address, then attacks of types 2 and 3 (see above) are much more difficult to pull off 100% successfully. Users all around the world would also get faster lookups.
• Use DNS cache servers. If you don't want to maintain multiple DNS servers, you can use a series of cache servers. Clients make DNS requests of the cache which makes initial requests of the real DNS server on your network (or the Internet) and responds to clients. If the DNS server is unreachable, the cache simply uses old information. Depending upon how your caches are set and how quickly your DNS database changes, you can buy between a couple of hours and a couple of days to fix a dead DNS server.

Real world advice

Juniper's Asia-Pacific director of marketing, Andy Miller, adds that redundancy, filtering, spoofing protection, and filter-based forwarding can be used to separate the common short UDP requests from TCP. "Also, as it's a well-known service and one that must be reachable by many, host security must be rigorously maintained. The routers and firewalls in front of the host can then do their part in protecting the service," he says.

Enterasys' Bussiere adds that administrators could consider using different software on primary and secondary DNS servers. "For example, have the primary server Linux-based and the secondary Windows-based; that way, it is impossible for a common vulnerability to take your network down," he says.

TruSecure's Tribble also advises to not disclose DNS information to those who do not need to see it, and to only permit zone transfers between primary and secondary servers. "With BIND, ensure 'chrooted jail' configurations. Some architectural considerations: separate internal private DNS usage from Internet DNS usage. The DNS server that is authoritative for the organization can be maintained by a third party outside of the corporate perimeter."

While these steps can serve to increase the DNS security posture, a discussion about DNS security cannot be limited to just servers, network access control matters and software levels, adds Tribble. "Consideration for physical security, malicious code protection, logical access control, and so on must be introduced."

Computer Associates' Lim also advises that the DNS Server must be vigilantly and strictly secured by firewall and anti-virus services, and if applicable, IDS/IDP and authentication services. "Put a specific host access control service on it as well, [and] make a member of the staff own the security and working integrity of the DNS server," he adds.

Microsoft's Kang also advocates the use of IPSec to implement logical network zones at the network layer. "Enable DNSSEC functionality through implementation of a secure DNS architecture to provide for trust assurance on DNS services," he adds.

More importantly, keeping abreast of updates is just as crucial. Says Matthew Syme, product marketing manager, Nortel Networks Asia-Pacific, good security management includes a process of monitoring and staying current and up to date with the latest patches and known security vulnerabilities. "Keeping yourself educated and informed is therefore very important," he says.

Courtesy: CMP Business Media