The Domain Name System (DNS) is a distributed resource used by most every
network application. DNS data is generally trusted implicitly; false data
therefore can jeopardize the integrity of network traffic and allow attackers to
play manin- the-middle with all traffic. DNS security depends on the client,
server, and their respective trust relationship. Securing the trust relationship
and building a reliable server can create a reliable and secure DNS structure
for the system administrator behind your corporate and private communication
requirements. Security of a DNS server varies according to its active role and
name resolution requirements. Server responsibilities can be classified as one
of three types. Depending on the need of the server, one specific role should be
chosen; in particular situations, multiple roles can be supported simultaneously
on one physical server. In this shared configuration, authoritative and resolver
servers are generally together. Running an individual server for each DNS role
is ideal, specifically in a large production environment. After understanding
the individual roles and mechanics between each server and experiencing problems
individually, an administrator can securely and reliably maintain multiple DNS
roles on a single system. DNS security is custom for each type of server, each
type of communication, and each common software distribution, all of which will
be explained in this article via an in-depth walkthrough
Showing the Mechanics of DNS
Understanding the mechanics behind
DNS is important when securing your DNS server. DNS is robust and full featured;
understanding what resources each DNS action requires will allow administrators
to disable unnecessary features, therefore achieving a minimalist and secure DNS
server. This section reviews the basics of DNS mechanics. Domain name
information is stored in flat text files called zone files. User requests and
server replies are simple text-file searches and take very few system resources.
Some newer DNS technologies allow for write access to update record data and
other configurations remotely. However, unless write access is explicitly
enabled, from an end user perspective DNS should be referred to as a read-only
service. DNS is mechanically broken up into records, servers, and their
respective chains of authority from the root servers.
DNS
Records
DNS terminology can be very confusing, though
mechanically DNS works on the basis of authority and records: The server with
authority is the trusted server based on the chain of trust delegated from root
servers.
Zone records are the different types of information each domain
can hold.
NS Name server This record will return the name of the
authoritative server for the requested domain. SOA State of authority This
record gives information about the zone, such as administrator
contact,etc PTR Pointer records This record associates an IP address with a
canonical name. CNAME Canonical name This returns a host or canonical
name. TXT Text Displays possible comments about the requested domain. AAAA
IPv6 Similar to an A record but returns the IPv6 address of the requested
domain.
The demand for new technology has pushed DNS to support a
plethora of additional DNS records. Recently, the new AAAA record was added for
IPv6 addresses; new records are added over time as necessary.The primary DNS
technology has been manipulated over the years to support everything from
virtual private networking (VPN) and domain controller entries to trusted Public
Key Infrastructure (PKI) exchanges.The primary DNS structure has sustained the
test of time and will be included in the core data communication structures for
years to come.
You should easily be comfortable with a dig query like the
following one. Dig is a recent replacement for nslookup, common on most
Unix-based systems. Dig organizes lookup results as they are originally
organized in the DNS packets. DNS packets are broken up into four
sections:
; DiG
9.2.2-P3 www.linuxexposed.com ;; global options: printcmd ;; Got
answer: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL:
2
;; QUESTION SECTION: ;www.linuxexposed.com. IN A
;; ANSWER
SECTION: www.linuxexposed.com. 86400 IN CNAME
linuxexposed.com. linuxexposed.com. 86400 IN A 213.193.220.188
;;
AUTHORITY SECTION: linuxexposed.com. 86400 IN NS
ns.linuxexposed.com. linuxexposed.com. 86400 IN NS
ns2.linuxexposed.com.
;; ADDITIONAL SECTION: ns.linuxexposed.com.
86400 IN A 213.193.220.188 ns2.linuxexposed.com. 86400 IN A
213.193.220.189
Packet-Level Communication
Reviewing
DNS communication at the packet level allows a better grasp of what rules to use
for packet filtering or intrusion detection systems (IDSs) and what normal DNS
traffic should look like when troubleshooting. DNS traffic uses port 53 via
either the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP).
Normal queries will use UDP.TCP is preferred for large packets.The historical
maximum guarantee for unfragmentable packets on a network has been 576 bytes. If
a query is larger then 576 bytes, a truncated (TC) bit is added to the response.
If a TC bit is detected by the client software, it will resend the query over
TCP for reliability. Zone transfers and abnormally large queries are the only
time TCP is used.The breakdown of a DNS packet is very straightforward, in
keeping with the simplicity of the DNS protocol.
Normal DNS packet
contains:
- Transaction Identification Random number used to match client
queries with name server responses - Number of Questions The amount of DNS
queries in the packet - Number of Answer RRs Amount of non-authoritative DNS
responses in the packet payload - Number of Authoritative RRs Amount of
authoritative DNS responses in the packet payload - Number of Additional RRs
Amount of other DNS responses in the packet - Questions and Answer Fields
DNS queries and DNS server responses.
DNS Lookup
Process
The primary goal of DNS revolves around the lookup process.
End users visiting a Web site or receiving mail all depend on DNS to receive the
correct information. DNS records are referenced for 99 percent of all Web
transactions.This makes the DNS lookup process a core infrastructure of the
Internet.The lookup process is important to the integrity of a query
response.The trust relationship between a forged reply and a reply authorized by
the root server authority is the only thing dividing an attacker’s server from
a valid trusted server. DNS is the dot (.), or symbolic beginning. All record
authority is based on a trust relationship starting from the root servers, which
control the dot. Domain trust works backwards, reading a domain name right to
left starting with the initial dot.
The initial dot is hidden from
everyday use to ease domain usage, this is commonly assumed if not already a
part of a query. Performing DNS queries including the unnecessary dot can
sometimes be used for information disclosure. Common administrative practice or
proof of concept root server troubleshooting are the only common times that use
the initial dot in queries.The dot is the symbolic beginning, which is
controlled by 13 physical root servers. Contrary to belief, many of these 13
servers are actually clusters of many load-balanced machines. All root servers
are owned and operated by separated entities to minimize single points of
failure with the historical exception of root servers A and J.These two servers
were located and operated by VeriSign, which also controls the central politics
over all 13 root servers and root server IP blocks. Due to the semisuccessful
distributed denial of service (DDoS) attack that occurred on the night of
October 21, 2002, root server J was moved 15 days later to a secret physical
location.
Viewing a domain address from right to left, after the initial
dot is the top-level domain (TLD), of which there are three general
categories.
gTLD General top-level domains ccTLD Country code
top-level Includes 247 country code domains
(www.iana.org/cctld/cctld-whois.htm). .arpa Used for technical This
infrastructure TLD is for reverse infra purposes DNS and
rootservers.
Most of the general top-level domains (gTLD) are the
original TLDs issued in 1995. Over the years, many TLD entries have been added
when the required justification had been approved.
Among the TLDs,
delegated authority is in effect.TLDs are not always directly served on root
servers, they are commonly hosted on TLD operator-controlled systems that
receive delegation from the root servers.You can obtain a listing of the
specific TLD servers via dig.
Prior to September 2001, a complete list of
gTLD zones could be downloaded. Due to many information privacy problems, many
of the popular zone files were pulled offline and were available only by
personal request.
Reverse DNS is most commonly used for identification
reasons. Reverse domain names are a worthy aid while troubleshooting. Traceroute
and ping both depend on reverse DNS lookups to display additional information
about hosts. In addition to ping and traceroute, Secure Socket Layer (SSL),Tap
ident Authentication (IDENT), and Simple Mail Transfer Protocol (SMTP) rely on
reverse DNS. Though most may not halt on DNS errors, their performance is
impacted due to failed reverse DNS timeouts.
Authoritative
Answers
Any server can be configured to give query replies.The
difference between a forged and authoritative reply closely resembles a chain of
command. If a query response is needed, the lookup request works its way through
its local server all the way to the top of the chain of command.The servers at
the top (that is, root servers) don’t have an answer but know which servers
would, and they know their path of delegated trust.
Using the dig
command, you can go through and find the authoritative DNS server for
www.example.com.
The resolver displayed the correct IP
address. Let’s walk through how it happened. First, the resolver server
checked its local zone files.With no data for this zone on the resolver, it
needs a hint. All DNS servers contain a file, usually named root.cache.This file
has a list of the root servers that can help find the authoritative server with
the query answers. When you contact the root servers and request an IP address
of www.example.com, the request is ignored, and you receive a list of servers
that host the .com TLD:
;; AUTHORITY SECTION: com. 172800 IN NS A.GTLD-SERVERS.NET. com.
172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS
H.GTLD-SERVERS.NET. com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN
NS I.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. com. 172800
IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS L.GTLD-SERVERS.NET. com.
172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS
J.GTLD-SERVERS.NET. com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN
NS E.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET.
The root
servers cannot keep track of every domain name or TLD, so they reply with
servers that are authoritative delegates. In this example, you received a list
of servers who are authoritative for the .com TLD.You’ll contact these servers
to continue the search for the IP address of www.example.com.These servers will
also be used to find any answer for domains ending with .com (such as
ibm.com).
;; AUTHORITY
SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800
IN NS b.iana-servers.net.
Again the request is not answered, but you
receive the list of servers that have received delegated authority over
example.com. When you are following the authoritative answers from the
beginning, you receive the two servers that are authoritative over every domain
that ends with example.com. One more step and you will have an
answer.
dig @a.iana-servers.net www.example.com ; DiG 9.1.3
@a.iana-servers.net www.example.com ;; global options: printcmd ;; Got
answer: ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL:
2
;; QUESTION SECTION: ;www.example.com. IN A
;; ANSWER
SECTION: www.example.com. 172800 IN A 192.0.34.166
You now have
received an authority reverse DNS answer.The server replied with an answer
because it has a local physical zone file with the A record. If you wanted to
know the IP address of www.subdomain.example.com, you would issue the query to
these servers; it is up to the server to answer or to delegate authority to
another server.
Domain and IP Registrars
To become an
authoritative server, you must host and register a domain and/or IP address
ranges with an authorized registrar. Initial top-level domains were first
approved in 1995. Since 1995, general end user domains can be registered with
general registrars.You can easily find an unofficial listing of general domain
registrars by searching the word registrar on any major search engine Specific
TLD extensions were reserved for organizational purposes. Currently only .mil
and .gov strictly enforced this policy.With correct approval, .mil and .gov
domains can be registered through government registrars. (www.nic.mil and
www.nic.gov, respectively). End user domains (also known as second-level
domains) can be purchased through their specific approved registrars. Depending
on the purpose of the domain, many registrar options are available. When domains
are purchased, registrars keep contact information on file.You can see the
contact information for the example.com domain by searching at
www.networksolutions.com/cgi-bin/whois/whois, shows.The contact information
contained in the registrar database is commonly the best contact method for
abuse or direct technical contact.
Exploiting DNS
Depending
on the skill level of an attacker, exploiting DNS can be trivial.Advanced
vulnerabilities such as cache poisoning, DoS, and buffer overflows can
manipulate server response, or even compromise an entire system. Simplistic
vulnerabilities, zone transfers, and version lookups, however, are only
information disclosure risks and usually do not breach DNS
security.
Name: Zone transfer
Vulnerabilitie: Information
disclosure of hosted domain names
Vulnerabilitie
Rating: Low
Atack Method:
Performing an unregistered zone
transfer or forge appropriate approval.
---
Name: Version
lookups
Vulnerabilitie: Disclosure of software
version
Vulnerabilitie Rating: Low
Atack
Method:
Performing lookup of version file to aid future
exploitation.
---
Name: DoS
Vulnerabilitie: Overworking
a system’s limited resources, leading to system or service
inaccessibility.
Vulnerabilitie Rating: Medium
Atack
Method:
Sending or requesting more resources than
available
---
Name: Cache
poisoning
Vulnerabilitie: Process of injection forged data into the
cache of the DNS server.
Vulnerabilitie
Rating: Medium-high
Atack Method:
Performing a lookup on an
attacker’s DNS server. Attackers server reply contains additional injected
information.
---
Name: Buffer
overflow
Vulnerabilitie: Sending specific data that overflows a
variable and allows memory execution
Vulnerabilitie
Rating: High
Atack Method:
Sending specially crafted packet
types can overflow buffers and cause a complete daemon crash.
Zone
Transfers
When a single server is not sufficient to handle a DNS
load, multiple servers can be deployed. Zone transfers were invented because it
is important for data on all servers to be identical. Zone transfers are a
proprietary type of data sharing capability included in DNS.A server downloads
all information about a specific zone from another server and saves it
locally.Transfer access is not always limited, however, for even though they are
bad administrative practice, public zone transfers are common.
When a DNS
server mirrors a primary DNS server’s data, it initiates a zone transfer.A
slave server issues a zone transfer command and downloads records from a master
server. Depending how zone transfers are restricted, results can vary.A
successful zone transfer will display all zones and the respective records. Many
records that include names such as vpn or mssql can help an attacker identify
specific targets and internal network addresses without a large detectable
footprint.
If zone transfers are not possible, an attacker still has the
ability to traverse DNS records. Several underground tools are available to
brute force DNS names. Common host names such as vpn or intranet can be guessed
manually. Depending on the goals of an attacker, proprietary information can
almost always be discovered in DNS.
Version
Discovery
Discovering software versions helps attackers profile a
server.Version lookups are commonly overlooked information disclosure
vulnerabilities. Even with a pessimistic security viewpoint; versions give a
friendly invitation to a hacker. Software version information is rarely needed
and should be changed or blanked out.The Berkeley Internet Name Domain (BIND)
DNS Daemon responds to many dig version queries and commonly allows remote
attackers to identify its version.The following is a server running BIND; notice
the version and daemon information disclosure:
Depending on the DNS server, version files’ syntax can be
named differently. A universal filename is chaos.txt or version.txt, though the
version.daemonname syntax is prevalent.
DoS
Attacks
DNS servers are susceptible to DoS attacks, and freely
available tools can make DoS an easy option by an attacker. Flooding a DNS
server with spoofed SYN packets can fill up a system’s limited available TCP
ports, thereby preventing communication to the server via TCP. Brute force DoS
of bandwidth resources can fill available upstream access and halt all
communication by clients. Networkintensive DoS attacks can use up network
resources.
Spoofed source distributed DoS (DDoS) attacks are by far the
hardest DoS attack to protect against; servers under DDoS attack have been
reported to receive upwards of 1 million packets per second. Attacks of this
magnitude will cripple any server upstream even in the most strategic network
locations. Alan Paller, SANS Institute Research Director, states, Only the
richest [companies] can defend themselves against this type of attack, and most
of them can’t withstand a concerted attack.
Cache
Poisoning
In November 2000, Infosec (www.info-sec.com) asserted
that one in three organizations with an Internet presence were vulnerable to DNS
spoofing.The capability to alter DNS responses augments the entire DNS chain of
authority, therefore making DNS untrustworthy. Cache poisoning was, and still
is, popular with IRC hackers, and although daemons vulnerable to common cache
poisoning have decreased, many servers are still vulnerable and cache poisoning
is still a possible exploit.
Common cache poisoning affects caching DNS
resolver servers. When an end user submits a DNS query, (for example,
hacker.com) to a resolver, the resolver server attempts to find an answer from
the authoritative server for hacker.com (ns1.hacker.com).The cache poisoning
occurs when the resolver server receives an authoritative DNS response from an
authoritative server that includes extra information.This extra information
commonly is an extra authoritative record, which says ns1.hacker.com is
authoritative for the yahoo.com domain. From this point forward, any queries on
yahoo.com will be sent to ns1.hacker.com.This is due to the resolver blindly
caching the falsified results from ns1.hacker.com without verifying
them.
A second, more difficult cache poisoning technique is also
possible. Because DNS operates over UDP, a DNS query packet attack is possible
where by an attacker guesses the query or transaction ID number. If an attacker
can guess this sometimes easy number, spoofed packets and forged data can be
accepted by a resolver server and the forged data injected into its cache
table.
Buffer Overflow
Just like any other
application, DNS is susceptible to memory overflows.The authoritative
underground buffer overflow paper by Aleph One is recommended reading on the
subject (www.insecure.org/stf/smashstack.txt). By its nature, authoritative DNS
servers are available to interact with anyone on the Internet, so DNS has been a
popular target of buffer overflow vulnerabilities. Due to BIND’s overwhelming
popularity as a DNS daemon, it has had several buffer overflow vulnerabilities
over the years.The latest discovery was found by the ISS X-force Team
(www.iss.net). ISS discovered that if an attacker could get a target server to
cache a malformed SIG record, a overflow could be achieved.
This
particular BIND vulnerability is due to a flaw in the datagram_read() function
of BIND.Transaction signature (TSIG) records are initially checked by
ns_find_tsg(); when ns_find_tsg() approves the record that contains a signature,
find_key() checks to see if the TSG key is valid.The possibility of a buffer
over- flow exists when a transaction signature is discovered but a key is NULL.
In this case, msglen computes the beginning of request before the signature. An
attacker can include his own extra code after the signature, which will be
executed without error due to the false judgment of length by msglen.Although no
public exploit code has been released, code has been proven successful and
provided remote root shell of a target server.
Alternative
Compromise Techniques
If traffic sniffing is available to an
attacker, all bets are off. Spoofed zone transfers, spoofed query replies, and
man-in-the-middle attacks can all be easily performed. A network breach is a
higher risk vulnerability. For a malicious attack, hacking a DNS server is like
working backwards. DNS query spoofing via man-in-the middle is completely in the
hands of an attacker. Query traffic is normally UDP and exchanges only public
information if an attacker gains access to spoof or sniff server traffic, the
attacker can do what they wish to manipulate DNS. Intercepting DNS traffic and
forging query replies will allow a hacker to redirect all traffic through them,
allowing further compromise.
Securing DNS
Uncommon secure
configurations can limit exposure and limit risk.The most common safety measure
within the DNS services deals with limiting who can access it resolver servers
only need to speak with a limited amount of end clients. Limiting access keeps
unauthorized users from using your server, possibly blocking them from checking
your level of vulnerabilities.
To minimize exposure to vulnerabilities ,
all ports should be blocked from Internet access except for authoritative
servers that require inbound and outbound UDP port 53 open to the world.
Resolver servers should allow packets with a destination of port 53 to leave the
server but restrict inbound port 53 connections to a limited end user list. In
some special instances,TCP port 53 is also required, though it’s worthy of
blocking if possible. Host-based packet filters should always be used as
secondary filtering and packet throttling. Redundant blocking of unnecessary
ports and packet filtering/throttling can minimize the effects of a DoS or other
potential attacks.
Restricting Zone
Transfers
Restricted zone transfer will keep the data integrity
of DNS records, and logged unsuccessful zone transfer attempts will be red flags
that note a potential attacker. Overall, zone transfer actions can be disabled
and file syncing can be performed with rsync software (http://rsync.samba.org)
over a secure path. Encrypted SSH tunnels are commonly used, though any private
secure tunnel is sufficient. Zone file syncing over encrypted tunnels outside of
a DNS daemon gives a nice separation between daemon operation and data syncing.
If zone transfers are disabled, a nosy attacker will receive a Transfer failed
message. If proper logging has been enabled, the attacker’s attempt to profile
your data will be logged.
Restricting Version
Spoofing
Profiling the software version of a remote host is
commonly available via a version lookup, but providing access to your software
version is the equivalent of distributing your server blueprints to an
attacker.You may think you have nothing to fear, but it is in your best interest
to restrict the available information you give out.
Alleviating DoS
Damage
DoS may be the single vulnerability that is outside of
your control. Many OS features can throttle SYN packet attacks, and similar
network devices can verify packets and drop spoofed packets. Choosing a reliable
network location that can receive large DoS attackers may keep a server online
throughout a small to medium attack. For information regarding spoofed packet
tracking, see http://www.secsup.org/Tracking/
The best way to defend
against DoS is to have an incident response plan in effect and IDS sensor data.
Detection of an attack is relatively easy. Once you have detected an attack,
manually notifying network upstream providers and throttling traffic at a
network backbone can alleviate most small network
strains.
Protecting Against Cache Poisoning
Cache
poisoning is easy to protect against. All DNS daemons have the option to turn
off caching. If caching is not enabled, forging replies to a server is
worthless. Most up-to-date daemons already have patches against poisoning.
Currently, packets received with authoritative records are verified before
inputting them into the cache.
Preventing Buffer
Overflows
Buffer overflow mitigation can be very successful. Many
tools have been developed that aid in preventing unauthorized overflow
techniques. Anti-buffer over- flow compilers such as stackguard http://www.immunix.org/stackguard.html) should be used in
conjunction with the newest DNS daemon version. However, although running a
daemon within a chroot environment and restricting resolver access can limit
exposure, truly stopping buffer overflows requires a secure platform from the
ground up.A secure OS such as OpenBSD and daemons such as DJBDNS are the best
tools to decrease the risk of overflow. OS customizations by Theo de Raadt and
hardened DJB daemon software may seem extreme, but based on their track records,
they are worthy of the administrative time and effort.
Using Bogon
Filters
Blocking invalid and unused Internet IP addresses can
reduce the load during DoS attacks and help notify administrators of network
problems. Use of the Bogons List by Rob Thomas
(www.cymru.com/Documents/bogon-list.html) at network borders, firewalls, and
within application Access Control Lists (ACLs) can reliably clean away unwanted
traffic and prevent misuse.
Summary
This article covered
many different DNS environments, some internal, others with services open to
every attacker. As mentioned, very simple steps can decrease the chances of a
security breach.Despite the fact that DNS exploitation is relatively low, if
exploited, every system in your establishment would be at risk.With such a heavy
dependency on DNS, specific steps should always be taken to keep your systems
protected. Constant log monitoring and limited exposure will reduce the system
administration headache associated with day-to-day production. Keep up to date
on current events via mailing lists and/or newsgroups. Using the correct
application for each situation helps future expansion plans. Although many
suggested security techniques rely on security through obscurity, they do aid in
monitoring potential attackers who are profiling your systems. Emphasis on
solitary purpose machines and redundancy to administer DNS is recommended,
especially in a high-volume environment.
Be first to comment this article
