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.
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,"
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
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,"
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,"
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.
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
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".
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
- 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
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,"
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