By exploiting this vulnerability the attacker can launch different types of attacks like Cache Poisoning, DNS Spoofing, Protocol corruption, Zone corruptions, Session Hijacking, etc. Although the use of UDP makes the system faster, ye, it is suggested that all DNS based communications should be TCP based rather than UDP.
Trang 1Simplified TCP Based Communication Approach towards Domain Name
System for Improving Security
Alok Pandey1, Dr Jatinderkumar R Saini2
1
Sr Systems Manager, Department of Computer Science Engineering, Birla Institute of Technology Mesra,
Jaipur Campus, Rajasthan, INDIA e-mail :alokpandey1965@yahoo.co.in
2
Director (I/C) & Associate Professor, Narmada College of Computer Application, Bharuch,
Gujarat , INDIA e-mail: saini_expert@yahoo.com
Abstract
Using DNS, domain names can be assigned to
groups of Internet resources independent of their
physical location Without DNS, the only way to
reach other computers on the Internet is to use the
numerical network address The use of IP address
for locating and connecting to remote systems is
tedious and is not very user friendly A preferable
and much relied upon service for retrieving an IP
address just by referencing a FQDN is DNS
Several types of DNS based communications take
place on the internet which are exploited by the
cyber criminals for attacking systems Although
different mechanisms have been suggested by the
research community to secure the DNS based
communications yet it is still not fully secure
Since DNS does not necessarily require the
establishment of a TCP connection it allows the
attackers to redirect the response to the victims host
by spoofing the source IP address as the victims IP
address By exploiting this vulnerability the attacker
can launch different types of attacks like Cache
Poisoning, DNS Spoofing, Protocol corruption,
Zone corruptions, Session Hijacking, etc Although
the use of UDP makes the system faster, ye, it is
suggested that all DNS based communications
should be TCP based rather than UDP
Keywords : DNS, DNS Spoofing, DNS Poisoning
1 Introduction
Computers communicate with each other on the
basis of IP Addresses Each device on the network
needs a unique IP address to enable data packets to
reach their destinations Initially there were only a
few hundred computers making up the ARPANET,
the military / educational precursor to the Internet
in the early days It may be easy to remember a few
IP addresses on local network, but is difficult to
keep track of the addresses of remote systems that
might be often used Thus came the concept of host names Host names provide a more “friendly” way
to name the systems and resources, making it easier for humans to remember them The hostnames of the frequently visited web based resources can be recorded with their respective IP addresses
Initially when the number of nodes was small, then
a single text file could easily map host names to their corresponding IP addresses This text file is called Hosts.txt and used to be managed by the Stanford Research Institute (SRI) This Hosts.txt file contained all of the name-to-address mappings for all nodes on the ARPANET Operating systems use the Hosts.txt file to map host names to IP addresses System administrators copied the Hosts.txt file from SRI to their local systems periodically to update their address maps
As the number of nodes on the network increased and the use of this static text file for providing mapping, became impractical The networks were growing and the new hosts were being added at a very high rate Soon neither SRI nor the system administrators could keep pace with the necessary frequent updating procedures There was an urgent need of an automatic translation mechanism that could manage the mapping of IP Addresses to their respective Host Names Thus the Domain Name System (DNS) was developed in the mid-1980s to provide a dynamic means of updating and resolving host names to their IP addresses It is one of the
basic services on the Internet
DNS was originally specified in 1983 by Paul
Mockapetris in RFCs 882 and 883 It is described
as a distributed database with the purpose to replace the HOSTS.TXT file that maps the hostnames to IP addresses and vice versa The Domain Name System (DNS) provides translation from human-friendly names to data in other formats
Due to its ability to map system names into
numeric IP addresses hierarchically and its
distributed nature & robustness, DNS has evolved
into a globally distributed database and is a critical
component of the Internet
DNS is commonly used of the translation from names like “www.mysite.com” to the “dotted-quads”
of IPv4 addresses, such as 192.168.1.64, or “colon separated hex” of IPv6 addresses like fd63:fad8:482a:65d3::0:f0cc The DNS also acts as a form of assistance operator for both
Trang 2human-to-machine and human-to-machine-to-human-to-machine interactions In
addition to IP addresses, the DNS is also used to look
up for mail servers, cryptographic keys and
retrieving information related to other DNS Name
Servers, Canonical Names, etc Several internet
based services rely on DNS for their operation
Hence if DNS fails or is slow, then the web sites
cannot be located
DNS works both as a set of protocols and as a
globally distributed database that is used heavily on
the Internet The database is a network of several
million servers, which actively cooperate to provide
a globally distributed service that translates between
human-oriented alphanumeric labels and
machine-oriented numbers Any large-scale disruption of the
DNS would make the Internet unusable
The Web and email traffic would grind to a halt
since the Internet users and systems would not be
able to use human-friendly names for
communication and would be forced to use IP
addresses for everything Any accidental or
intentional DNS failures would take companies such
as Microsoft [1] and Amazon [2] and countries such
as Sweden [3] and Germany [4] partially or fully off
the Internet
Ever since DNS came into existence three decades
ago, it has been continuously improved for making it
more reliable and secure Even today DNS is subject
to a variety of threats and attacks One of the goals of
this document is to help readers understand today‟s
threats to the DNS infrastructure and how to mitigate
these threats using the inherent capabilities of the
DNS or by implementing policies for operational
practices
1.1 History of the DNS
In the earliest days of the Internet, names of systems
connected to the network were assigned locally and
there was no DNS The Network Information Centre
(NIC) kept track of the names
In December 1973 RFC 597, “Host Status,” was
published, which became the first official collection
of hostnames The system manager was expected to
use RFC 597 and keep their local list of
host-to-address mappings up to date
Soon an online file was maintained by the NIC for
containing the official name to address mappings and
subsequently the RFC 606, “Host Names On-Line,”
was proposed and published in December 1973 by L
Peter Deutsch Early names as defined in RFC 606
were simple labels Like, the system at MIT‟s
Artificial Intelligence lab was called “MIT-AI.” This
simple label approach of naming hosts on the
network was used for almost a decade and could not
work forever
In September 1981, D L Mills published RFC 799,
“Internet Name Domains” wherein he suggested that
in the long run, it will not be practicable for every internet host to include all internet hosts in its address tables hence some sort of hierarchical name-space partitioning should be devised to deal with recording and maintaining such details of every internet host
Based upon the decision to move to a “Hierarchy of Domains” in a meeting in February 1982 the RFC
805, “Computer Mail Meeting Notes,” was published
In August 1982 with the publication of RFC 819, by Zaw-Sing Su and Jon Postel, this new approach of host naming, described as the “Domain Naming Convention for Internet User Applications” was codified and introduced The new Domain Naming Convention was intended to use hierarchy for distributing administrative management of the namespace that would eliminate duplicity of names
RFC 819 provided the general outline of the DNS, including the ideas of naming authorities, registrars and iterative and recursive resolvers It suggested that the Internet names be used to form a tree-structured administrative dependent hierarchy, rather than topology dependent, hierarchy It also defined the first top-level domain, ARPA, as “The Set Of Organizations involved in the Internet system through the authority of the U.S Defence Advanced Research Projects Agency.”
In October 1982, RFC 830 “A Distributed System For Internet Name Service” was published by Zaw-Sing Su It described an architectural view of a name resolution service provided through the cooperation among a set of domain name servers (DNSs) and discussed system components like database, caching of names, application interfaces and protocols for inter-process communication necessary to implement a distributing naming system
By November 1983, Paul Mockapetris had published RFCs 882 “Domain Names - Concepts and Facilities” and RFC 883 “Domain Names - Implementation and Specification,” giving the initial specifications for the DNS as we know it today The structure of names in the DNS was also defined very early in the history of the Internet
In October 1984 Jon Postel and Joyce Reynolds published RFC 920, “Domain Requirements,” which defined the original top-level domains (ARPA, GOV, EDU, COM, MIL, and ORG), the two letter country domains and opened the possibility of other top-level domains for “multi organizations,” large international organizations-of-organizations, etc
Trang 3
In 1987 the original DNS RFCs 882 and 883 were
replaced by RFCs 1034 and 1035 respectively and
updated the DNS specifications based upon
implementations of RFCs 882 and 883 Both the
RFCs 1034 and 1035 are the core standards upon
which the DNS is based DNS has been modified to
address new requirements time and again to
incorporate changes to the DNS operational
environment
2 Literature Review
Steven Cheung et al in their paper “
Formal-Specification Based Approach for Protecting the
Domain Name System” [5] formally specify a DNS
wrapper that examines the incoming and the
outgoing DNS messages of a name server to detect
messages that could cause violations of the security
goal, cooperates with the corresponding
authoritative name servers to diagnose those
messages, and drops the messages that are
identified as threats Based on the wrapper
specification, they implemented a wrapper
prototype and evaluated its performance
Xunhua Wang, Yih Huang et al In their paper
“Enabling Secure On-line DNS Dynamic Update”
[6] point out two difficulties in the current
DNSSEC (DNS Security Extension) standards in
the handling of DNS dynamic updates:
a) On-line storage of a zone security key,
creating a single point of attack for both inside &
outside attackers,
b) Violation of the role separation principle,
which in the context of DNSSEC separates the
roles of zone security managers from DNS server
administrators
To address these issues, they propose a secure DNS
architecture that is based on threshold
cryptography They show that the architecture
adheres to the role separation principle without
presenting any single point of attack and also show
experimental results revealing that, in terms of
signature computation times, their architecture
incurs negligible performance penalty when using
RSA/MDS signatures but significant overhead
when using DSA signatures They believe that the
high level of security can be achieved by their
proposed architecture, especially for critical DNS
zones, such as the com zone
Yih Huang Yih et.al in their paper “Securing DNS Services through System Self Cleansing and Hardware Enhancements” [7] try to develop a secure DNS architecture that contains the damage
of successful, undetected attacks They achieve this
by constantly cleansing the servers and rotating the role of individual servers Moreover, the server rotation process itself is protected against corruption by hardware They show the advantages
of our design in the areas of protection of the DNS master file and cryptographic keys, incorruptible intrusion tolerance, high availability, and scalability, the support of using of high degrees of hardware/server redundancy to improve both
system security and service dependability
Suranjith Ariyapperuma et al in their paper
“Security vulnerabilities in DNS and DNSSEC “ [8]highlight some of the security vulnerabilities in the Domain Name System (DNS) and the DNS Security Extensions (DNSSEC) DNS data that is provided by name servers lacks support for data origin authentication and integrity by using digital signatures Although DNSSEC provides security for DNS data, it suffers from serious security and operational flaws They point out with DNS and DNSSEC architectures, and consider the associated security vulnerabilities
Christof Fetzer et.al in their paper “Enhancing DNS Security using the SSL Trust Infrastructure”
[9] point out some of the shortcomings of the current secure DNS (DNSSEC) standard like, online updates and denial of service attacks etc which are serious obstacles that might prevent DNSSEC from replacing the traditional DNS To address these issues, they propose a simple extension to the existing DNS It is SSL based and individual domains can decide independently of each other if and when to adopt the extensions
They show how to implement these extensions with the help of a simple proxy DNS server
Yong Wan Ju et al in their paper “Cache Poisoning Detection Method for Improving Security of Recursive DNS” [10]propose a new detection method for cache poisoning attack on the recursive DNS The proposed method overcomes the weak-points of the previous researches such as DNSSEC and DoX system which are hierarchical
or vertical additional deployments of several DNS servers, accordingly overall performance of the system is decreased and additional traffic cost is needed That is to say, the proposed method sets forth independent cache poisoning detection method with the similar security level of DNSSEC, notwithstanding the the improvement, there is little
Trang 4influence on DNS performance and additional
traffic
Daniel Massey et al in their paper “ Public Key
Validation for the DNS Security Extensions “ [11]
say that t he deployment of DNS Security
(DNSSEC) can only succeed if there is an effective
mechanism for DNS public key validation This
paper compares three potential approaches to DNS
key validation A tree based approach utilizes the
existing structure of the DNS tree to form highly
structured key signing rules This makes following
chains of trust simple, but it allows no flexibility
for individual zones and makes incremental
deployment impossible A pure web of trust based
approach imposes no structure what so ever on the
key signing process This lack of structure provides
a high degree of local control, but also makes it
difficult to find trusted chains or specify security
policies The third approach is a new proposal
based on a the concept of a fault-tolerant mesh of
trust The mesh approach utilizes some structured
elements from the tree-based approach while
maintaining the local flexibility found in the web of
trust Our analysis shows the hybrid mesh approach
has the best chance of succeeding in the Internet
David Conrad in his paper “Towards Improving
DNS Security, Stability and Resiliency” [12]
discusses in detail about some of the attacks how to
mitigate them
3 The DNS in Operation
DNS is a distributed database system spread across
multiple DNS servers which allows the resolution of
domain names into their respective IP addresses
The queries result in responses in the form of IP
addresses which are stored in the DNS databases in
the form of Resource Records abbreviated as RRs.
A domain name may consist of several strings
separated by dots which represent administrative
boundaries For example, the dot between “gmail”
and “com” in the domain name “www.gmail.com”
represents the administrative boundary between the
“com” top-level domain and Gmail, the company
responsible for “gmail.com.” The Internet‟s DNS is
a single large tree, read right-to-left, with
progressively more specific administrative units to
the left.7
Within a DNS tree, each administrative unit is called
a „zone‟ For example, the “wikipedia.org” zone is
the piece of the DNS tree including all names ending
in “.wikipedia.org.” Further subdivisions are
possible like “wikipedia.org” might have multiple
zones, such as “en.wikipedia.org” The DNS lookup
occurs each time a user enters a URL in a web
browser The application typically uses an
intermediate system called a resolver to navigate
The DNS database to procure the information required
3.1 DNS organization and infrastructure
Beneath the seemingly simple DNS look-up service lies a complex logical and administrative infrastructure The DNS name resolution service uses a data repository, organized as a globally distributed database that‟s largely structured after the hierarchical domain name space, or DNS tree
At the top of the hierarchy is the root, a single domain represented by a dot (“.”) Below the root are top-level domains (TLDs), whether generic (for example, com, gov, or edu) or country-specific (such ccTLDs include de, uk, and so on)
The next level consists of enterprise level domains (ELDs) owned by commercial, government, or academic organizations such as nist.gov or mit.edu
A large enterprise generally has administrative control over a given zone, classified as an ELD, and a set of sub-domains Thus, a zone refers to an administrative entity in the DNS that provides DNS services for a group of domains The term “zone”
has percolated up to the top levels, and the terms root zone, TLD zone, and ELD zones are often used The information flow in the DNS takes place primarily among three distinct system entities:
authoritative name servers, stub resolvers, and caching name servers, also called resolving / recursive name servers or resolvers Different type
of DNS Servers work together to provide the replies
to the DNS lookups performed by majority of the applications
3.2.Authoritative servers
Every authoritative name server is associated with
a zone and, as its name denotes, is the authoritative source for DNS data pertaining to that zone To provide fault tolerance, effective administration, and efficient name resolution, several geographically and logically distributed authoritative name servers exist for each zone
These are further classified into primary name servers, which maintain authoritative DNS data in zone files, and secondary name servers, which frequently refresh their contents from the primary name servers The Authoritative servers respond to the query in one of the following ways:-
A positive response with an answer
A negative response indicating the answer does not exist
A referral response where to find further information
The authoritative servers are typically operated by or
on behalf of zone administrators ISPs, DNS registrars, and hosting providers often operate authoritative servers on behalf of their customers
The authoritative DNS infrastructure, particularly for
Trang 5“high value” zones such as top-level domains, are
generally outsourced to DNS-focused service
providers, such as Verisign, Afilias, and Neustar
3.3 Stub resolvers
Stub resolvers are lightweight clients that formulate
DNS look-up queries on behalf of applications,
such as Web browsers or email servers and send
them to caching name servers Stub resolvers don‟t
usually have any caching features Caching name
servers each serve multiple stub resolvers
Depending on the zone or domain requested, they
either query the appropriate authoritative name
servers or serve responses from their own caches
built from previous queries
3.4 Resolver
The DNS clients use a resolver to request resolution
of a host name to an IP address The resolver is an
application which acts as an intermediary between
name servers and various applications such as Web
browsers, e-mail applications, etc that need name
resolution A DNS resolver acts on behalf of client
software to retrieve information about a particular
domain name For example: Assuming that your
browser has to connect to www.abc.com Then local
resolver creates a DNS query and sends it to the
name server(s) listed in the local computer‟s TCP/IP
settings In the case of smaller enterprises and end
users, Internet service providers typically operate
resolvers In the case of larger enterprises, the
resolvers are usually operated by the enterprises
themselves or by large-scale DNS hosting providers
4 How DNS works
DNS functions as a distributed database using a
client/server relationship between clients and the
servers that maintain DNS data This distributed
database structure enables the DNS to be dynamic
and decentralized, allowing control over their own
portion of the DNS database by local domains and
also enabling clients to access the database
At the topmost level there are the root servers (.)
which represent the period They are 13 in numbers
(ROOT-SERVERS.NET) and are distributed across
the globe The root servers maintain the database
for the top level domains (gTLDS-SERVERS.NET)
i.e com, net, org, mil, edu, gov, int etc These
top level domain servers typically maintain data
only about the name servers which are authoritative
for a particular domain The authoritative name
servers, contain data about primary name servers or
delegated name servers for that particular domain
Finally these name servers maintain data for the
These authoritative name servers maintain the
records for a domain or delegate some of or the
domain to other name servers The root servers know the name servers for domain1.com and within those name servers the west.domain1.com domain
is delegated to another set of name servers that manage that portion of the overall domain1.com domain In most cases, domains and their records are either managed directly by the organization owning the domain or by the ISP that provides the Internet connection for the organization
Image source: Verisign Domain Name Industry Brief, June 2007 (PDF), last page
There are two parts in the DNS Tree namely - a root zone file and different name servers that act as the
“Root Servers” The root zone file is small and lists all top-level domains along with name servers for respective domains The root zone file is managed
by three different organizations: ICANN, the U.S
Dept of Commerce and Verisign ICANN [13] is responsible for accepting and validating changes from various top-level domain authorities and then suggesting the necessary changes in the root zone file which are then authorized by the U.S Dept of Commerce‟s National Telecommunications and Information Administration (NTIA) and then Verisign finally applies the updates, signs the zone using DNSSEC and publishes the revised root zone file on a “distribution master” server
Trang 6The 13 root name servers are operated by the 12
independent organizations [14] These root name
server operators fetch the root zone file from the
distribution master server which is maintained by
Verisign and then publish the information on the root
name severs which they operate independently
Many of these root name servers are clusters of
machines which are distributed globally at multiple
locations/sites and share information using
“Anycast” routing technique The summary of these
servers are as follows:-
B University of Southern California,
Information Sciences Institute
1
D University of Maryland, College Park 1
E U.S NASA Ames Research Center 1
G U.S Department of Defense,
Network Information Center
6
H U.S Department of Defense, Army
Research Lab
2
4.1 How DNS lookup works
The DNS clients use a resolver to request
resolution of a host name to an IP address The
resolver is an application which acts as an
intermediary between name servers and various
applications such as Web browsers, e-mail
applications, etc that need name resolution A DNS
resolver acts on behalf of client software to retrieve
information about a particular domain name Let us
say that, a browser has to connect to
www.abc.com then its local resolver creates a
DNS query and sends it to the name server(s) listed
in the local computer‟s TCP/IP settings
The sequence of events to get the IP address for
www.abc.com are - First the computer queries the
name server (DNS server) it is set up to use This is
the recursive name server shown above If the
name server doesn‟t know the IP address for
www.abc.com, so it will start the following chain
of queries before it can report back the IP address
to the calling computer
1 Query the Internet root servers to get the
name servers for the com TLD
2 Query the com TLD name servers to get
the authoritative name servers for
abc.com
3 Ask the authoritative name servers for abc.com to finally get the IP address for the host www.abc.com, then return that IP address to your computer
4 Finally the computer has the IP address for www.abc.com, it can access that host
If there is a connection to the ISP then the ISP‟s name servers resolves the query The resolver sends the DNS resolution request to the first of the name servers as specified in the local TCP/IP settings The server checks its cache of previously resolved names, for abc.com so, that name server sends a DNS query to the root server for the com domain The root server responds with the addresses of the name servers that are authoritative for the abc.com domain
The ISP‟s name server then builds another request for www.abc.com and submits it to the abc.com‟s name server, which responds with the IP address of www.abc.com This information is passed back to the resolver, which gives it to the calling application As a result abc.com‟s Web site appears
in the browser Resolving a host name to an IP address is called forward lookup
Caching is an important part of the operation of the DNS At each stage along the way, from application
to resolver to name server, information may be cached In normal DNS operation, to improve performance, the resolver will store the responses and referrals it has received so that future lookups for the same information can be answered immediately Caching is used to avoid sending queries across the network to DNS servers, speeding response time Because caching is an expected part
of DNS operation, each domain name response (resource record) includes a “time to live” (TTL) value indicating how long information may be cached
4.2 DNS Security Extensions (DNSSEC)
DNSSEC (DNS Security Extensions) is an important tool in increasing the security of the Internet‟s Domain Name System
It is a set of extensions to the DNS for providing authentication and performing integrity checking of DNS data Authentication ensures that zone administrator can provide authoritative information for any particular DNS domain and integrity checking ensures that information cannot be modified accidentally or maliciously while in transit
or in storage in the DNS DNSSEC provides a strong cryptographic signature of DNS data that the DNSSEC compliant resolvers can verify to ensure that the data received over the network hasn‟t been modified since it was originally DNSSEC-signed
Trang 7In DNSSEC, the server and the resolver both have to
be security aware as the DNS server is required to
support some additional types of DNS records
Likewise the resolver should be able to detect the
new DNSSEC extensions and must check DNS data
for authentication and data integrity Any
modification of the DNS data from what was
originally signed at the authoritative source can be
detected, thereby allowing a security-aware DNS
resolver to discard corrupt or unauthorized data
Although DNSSEC was standardized in 2005, it is
not commonly used However, adoption of DNSSEC
is expected to accelerate as the root DNS zone was
signed in July 2010
5 DNS Threats
Since DNS is critical to the operation of the Internet,
it must be secure from different types of threats and
risks This portion provides information on some of
the existing threats which lead to DNS failure and
their counter measures for mitigating such risks A
variety of threats have been seen to the DNS system
including threats to the DNS infrastructure itself The
most common types are :-
5.1 DNS Spoofing
DNS spoofing means that a computer on the
Internet has been able to advertise a false IP
address for itself This is due to the easy setting up
of one s DNS resolver and feeding it with false
information It can also be done by the following:-
1 A malicious DNS advertises false IP
address to a victim Subsequent DNS
queries are sent bogus IP address, traffic is
sent to wrong host
2 Java applets could be created to spoof IP
address in order to penetrate into insecure
server This unprotected server in a
network thinks that it being contacted by a
trusted host but in fact, the machine on the
end of the connection is operated by some
malicious users
DNS Spoofing is a serious attack based on the
strong trust relations between client machine and
their DNS server The DNS server can be attacked
in many different ways but all rely on the
translation between Domain Name and IP address
5.2 Cache Poisoning
Another security concern regarding to DNS is the
process of Cache Poisoning It is a process where
attacks are launched on cache data of DNS in order
to misdirect and intercept packets on domain name
servers One simple type of attack is where bogus
data from a remote name server is offered to a
genuine name server, which in turn stores the
misleading data in its cache By providing false
host name and mapping information, the attacker
can misdirect name resolution mapping, opening network data to capture inspection and potential corruption
Many other types of threats have also been seen in which DNS system is used to carry out attacks on the other assets These different types of threats to the DNS, can be broadly categorized as below:
• Denial of Service – In this type of attack the Internet users are kept away from using the DNS
• Data Corruption - In this case there will be unauthorized change of information in the DNS)
• Information Exposure – Here the information is disclosed about Internet users after examining their DNS traffic
5.3 Denial of Service
It is the most significant threat to the DNS and also the hardest to defend against In DOS, The attacker purposefully tries to disrupt service by creating failure / mistakes, in the DNS infrastructure itself by performing some malicious activities This results in DNS becoming slow or inaccessible and is often called a Denial of Service (DoS) attack In many a cases, both human as well as automated systems users of the DNS face increased delays, timeouts, and other performance related issues.The worst-case may a complete disruption of all related and DNS-dependent services Denial of Service threatens the DNS security, integrity and stability of its internal sub-component
Within this category two different types of DOS have been seen:-
(1) Resource Starvation – Insufficient resources here the attacker tries to misuse the system resources like server CPU, memory, internet bandwidth etc because of which the DNS service becomes slow The attacker tries to flood the network, switches, routers etc with bogus traffic
or tries to block the legitimate DNS requests and replies and disrupt the normal working of the DNS infrastructure
(2) Resource Disruption – The attacker tries to disrupt the normal working by creating events which make the resources unavailable until some external event restores the resource - typically creates intentional electrical power failure which will bring down the servers till the power is restored
The threat of DoS covers all components of the DNS including:
1 Physical & network infrastructure - buildings, power supplies, network connections
Trang 82 Server infrastructure - servers and related
system that allow for DNS queries to be
sent and received
3 Management infrastructure - processes that
allows for the creation, modification, and
deletion of DNS content
4 Administrative infrastructure - support
agreements and procedures, staffing,
invoicing, and similar arrangements
5.4 Data Corruption
Data Corruption in DNS can happen because of
different reasons Some of the reasons are:-
1 When DNS responses don‟t match the
intended, published data
2 When someone has intentionally or
accidentally changed the data in DNS
servers in un-authorized ways
3 As DNS queries and responses pass over
the Internet, over an intermediate DNS
server (resolver) which might have corrupt
or incorrect data inserted into their cache
because of attacks called as cache
poisoning
4 When an attacker sends answers to queries
faster than the legitimate servers can,
providing erroneous data to the application
5.5.Information Exposure
The DNS protocol was originally designed as a
mechanism to associate named resources to
addresses without any concern for Privacy
protection DNS queries and responses are
transmitted without any form of encryption, and
hence can be observed at multiple points DNS
operators may also be capable of correlating requests
and using them for other purposes At the same time
there is a requirement that individuals should be able
to use the DNS and the related WHOIS protocol in
an anonymously as it would let the individuals
perform DNS queries without having their requests
observed and correlated with their identity
Besides the above mentioned threats some more
types which are not immediate operational type have
been observed as follows:-
5.6 Ossification
Issues related to maintaining backward compatibility
and implementing future upgrades resulting due to
technological improvements is a critical problem
Such a situation has been broadly termed as
ossification [15] Due to ossification DNS has lesser
ability to adjust to future changes in the Internet
Ossification has also delayed the deployment of
upgrading of technologies which are needed for
security, stability of the DNS
5.7 Threats from the DNS
Since DNS is a core component of internet hence
minimum security restrictions are imposed by the routers and firewalls on its traffic As a result, DNS traffic has been used for several forms of attack
5.7.1 Fast Flux DNS
As defined by ICANN‟s Security and Stability Committee “Fast flux” is an evasion technique used
by the cyber-criminals and Internet miscreants to evade their identification, location and shutting down such web sites that are used for illegal purposes.28 In Fast Flux DNS, networks of typically compromised servers by malware are used as name servers This allows for rapid changes to DNS-related data, and helps attackers to delay or evade detection and mitigation of their activities
5.7.2 DNS as a Hidden Channel
DNS requests and responses can be used as a hidden channel for communications [16] Several cases have been documented in which DNS has been used as the mechanism for communications between botnet command and control servers of the systems that make up the botnet.. Some tunnelling protocol like IP over DNS and TCP over DNS have been developed
by the cyber criminals that allow arbitrary data to be passed over the DNS protocol Thus using such techniques DNS can be used by attacker to bypass network security mechanisms and compromise other internal systems
5.7.3 Application Corruption Attacks
Similarly maliciously created DNS responses can be used to corrupt some applications In some cases, DNS responses can cause unexpected application behaviours They may be used to compromise systems As has already seen in web application, huge amounts of SQL injection and cross-site scripting attacks can lead to different types of attacks
on the network resources It may be assumed that any data obtained over a network channel could be intentionally malicious or accidentally malformed
In cases where application or library source code is unavailable [17], some caching resolvers have configuration options that allow filters to be applied
to responses to reduce the risk of malicious data being supplied to applications
6 Mitigating DNS Threats
The DNS has a number of features as part of the original design or incorporated later on that make it resilient to many forms of disruption and attack
Some such recent additions to the DNS system are
“DNS Security Extension” also known as the DNSSEC and operational practices such as the deployment of “Anycast” [18] which provide increased protection against many of the common threats to the DNS
6.1 Denial of Service Threats
The mitigations for all forms of DoS attacks can be done by:
Trang 9a) By way of over-provision the infrastructure
to withstand attacks
b) Spreading out the infrastructure to different
geographic locations, using independent
facilities, systems and other technologies to
remove the choke points
c) Utilizing operational best practices that
apply to other core IT systems, with
well-documented and mature processes and
procedures that are reviewed and updated
regularly
6.2 Stub Corruption
Trusted stub resolver and its network path should be
used It should be verified that the IP Address for
DNS resolution services that are mentioned at
/etc/resolv.conf on Unix-related systems and in the
registry in Windows systems are the correct
expected values Using DNSSEC will mitigate some
of corrupted resolution paths
6.3 Caching resolver corruption
Timely application of security packs and systems
updates ensure that they are guarded against the
known threats Although implementation of name
server allows a server to act as caching resolver and
also as an authoritative server, they should not be
hosted on the same box As a best practice,
separation of authoritative name service from
caching resolution service should be done as it will
mitigate various forms of data corruption such as
cache poisoning and inappropriate responses to the
authoritative queries
6.4 Intermediate systems
Intermediate systems are critical as they play an
important role in DNS resolutions and hence should
be updated timely By using DNSSEC any
modifications of data in transit can be detected by
the validating resolver Unfortunately, the use of
DNSSEC is hampered by middle-boxes that inhibit
used of DNSSEC by incorrectly handling requests
that ask for DNSSEC-signed responses or the
responses themselves [19]
mitigation
In addition to mitigations previously discussed, it is
important to ensure the DNSSEC keying material is
managed to minimize the chance that an attacker can
steal keying material and impersonate an
authoritative server Best practices for DNSSEC
deployment use “offline signing keys” minimizing
the possibility of key theft
6.6 Protocol Corruption
Protocol Corruption takes advantage of limitations
or vulnerabilities in the DNS protocol itself to
corrupt DNS data There are three broad categories
of Protocol Corruption:
6.7 Query Prediction
As discussed in “DNS Threat Analysis” [20], every message in the DNS has a 16-bit query identifier that
is used to match responses to queries In combination with the 16-bit source port, this gives a total of 32 bits to uniquely identify a DNS transaction between any given source and destination As early as 1986, it was recognized that this provided only a weak defence against injection
of bogus responses by a malicious third party In particular, it is possible to take advantage of “the Birthday Paradox”, to predict a query identifier and then inject a response [21]
6.8 Man-in-the-Middle
DNS traffic is not encrypted An attacker with control over the intermediate network can implement
a variety of man-in-the-middle attacks
6.9 Cache Poisoning
Predicting queries and man-in-the-middle attacks allow for an attacker to insert bogus data into a cache, an attack known as cache poisoning, discussed in detail above The key mitigation for all
of these protocol corruption attacks is DNSSEC, which allows a security-aware resolver to verify that the DNS data have not been modified in transit
With this capability, it no longer matters that an attacker can predict query identifiers, can sit in the middle of a DNS transaction, or can attempt to poison the cache since any attempt to modify the DNS data will be detectable
6.10 Data Corruption
DNSSEC can be used to guard against data corruptions as it was primarily designed for this reason Other techniques like constant vigilance of the system resolvers and application of necessary security patches should be done
6.11 Information Exposure
Information Exposures are unauthorized releases of personal and other data associated with the DNS and DNS queries These exposures can occur at both the administrative level as well as at the network and system level with attacks known as “Cache Snooping” and “Zone Walking” Protecting against Cache Snooping related to authoritative servers
General protection of data including secure data paths and methods to protect against system compromise are the countermeasures
6.12 Mitigating DNS as a hidden Channel
Mitigation of hidden channel use of DNS requires detection Constant monitoring may help to detect unusual use patterns, such as a large number of TXT responses being sent to a particular server Analysis
of DNS traffic within an enterprise can provide a baseline to detect the hidden channel DNS problems
Trang 107 Our Approach
Internet supports both TCP based (port no 53) and
UDP based (port no 53) transport mechanism for
DNS However majority of the communication is
UDP based Since DNS does not necessarily require
the establishment of a TCP connection it allows the
attacker to redirect the response away from its
network to the victims host by spoofing the source IP
address as the victims IP address By exploiting this
vulnerability the attacker sends a small request to the
DNS server to which the server may respond with a
very large reply This large reply can be redirected
by the attacker to the victim machine and thus
consume most of the victim‟s resources Daniel
Bernstein has reported that a 36-byte DNS query can
result in a 3995-byte DNS response
Such attacks are classified as DNS amplification
attacks as it amplifies the attacker‟s ability to
consume resources on the victims system Since
DNS queries are small, the attackers queries can go
undetected which might lead to a distributed denial
of services attack on the victim‟s system Since a
spoofed IP address is used by the attacker it becomes
very difficult to trace such attacks.DNS has been
used for amplification attacks for some time, DNS
Amplification attacks make use of either
authoritative servers or resolvers to reflect data
towards a target
As per the frame format defined for DNS in RFC
1035 there is a 16 bit field called identifier which
can be assigned value by the program that generates
any kind of query This identifier is copied in the
corresponding reply and can be used by the
requester to match up replies to outstanding queries
However there is no provision for any kind of
sequence numbers
As most of the communications are UDP based
hence there is no mechanism to check whether the
packets coming in or going out are legitimate nor
not This forms the basis for generating different
types of attacks like DNS Spoofing, Cache
Poisoning, Zone corruptions, Session Hijacking,
Data corruption, Protocol corruption etc Although
the use of UDP makes the system faster yet it is
suggested that all DNS based communications
should be TCP based rather than UDP
When TCP is used for communication then a
three-way handshake will take place for graceful
communication to happen The sender will send a
SYN packet which will be acknowledged by the
receiver by sending back the SYN ACK packet
which is again acknowledged by the sender by
sending an ACK packet after which the data
transfer phase begins
When a TCP connection closes gracefully then also
a proper handshake actually takes place The sender sends the FIN packet which is acknowledged by the receiver by an ACK packet and if the receiver also wants to terminate the connection at the same time
it also sends a FIN packet to the sender This FIN packet is once again acknowledged by the sender
by sending ACK packet
By using the above concept it can be ascertained that the communications to the DNS servers are being send by legitimate DNS Resolvers and servers Hence it is suggested that all DNS based communication TCP should be used as the transport mechanism rather than UDP as it will greatly improve the security aspects of DNS
References:-
1 http://www.microsoft.com/presspass/press/2001/jan01/
01-24dnspr.mspx 2.http://www.pcworld.com/businesscenter/article/185458/
dd os_attack_on_dns_hits_amazon_and_others_briefly.html 3.http://www.iis.se/en/pressmeddelanden/felaktig-dns- information-2
4 http://www.securityweek.com/content/reports-massive- dns-outages-germany
5.“Formal-Specification Based Approach for Protecting the Domain Name System By Steven Cheung, Department of Computer Science, University of California, Davis, CA 95616, and Karl N Levitt, Department of Computer Science, University of California, Davis, CA 95616
6 “Enabling Secure On-line DNS Dynamic Update” by Xunhua Wang, Yih Huang, Department of Computer Science, George Mason University, Fairfax, VA
22030 USA , Yvo Desmedt, Department of Computer Science, Norida State University, Tallahassee,
FL 32306 USA and David Rine, Department of Computer Science, George Mason University, Fairfax,
VA 22030 USA
7 “Securing DNS Services through System Self Cleansing
and Hardware Enhancements” by Yih Huang, David Arsenault, and Arun Sood , Department of Computer Science and Center for Image Analysis, George Mason University, Fairfax, VA 22030
8 “Security vulnerabilities in DNS and DNSSEC” by Suranjith Ariyapperuma and Chris J Mitchell, Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX,
UK
9 “Enhancing DNS Security using the SSL Trust Infrastructure”by Christof Fetzer and Gert Pfeifer, Dresden University of Technology, Department of Computer Science, Institute for System Architecture,
01062 Dresden, Germany and Trevor Jim, AT&T Labs-
Research, 180 Park Ave., Florham Park, NJ, 07932, USA
10 “Cache Poisoning Detection Method for Improving Security of Recursive DNS” by Yong Wan Ju, Kwan
Ho