• Login
• Become a member
• RSS
• Part of the TechTarget network

Layer 7 of the OSI model is the application layer. This is the top layer of the OSI model. The application layer interfaces directly to applications and application processes. Applications play a critical role in network security; they can be designed so they are completely insecure, somewhat secure, or very resistant to attacks.

Many applications, such as file transfer protocol (FTP), Telnet, Simple Mail Transfer Protocol (SMTP) and Domain Name System (DNS), have been around so long that the threats they face today were never envisioned when they were originally designed. As two of the 13

core DNS servers were attacked on February 6, 2007, DNS will be the focus of this article.

How DNS works

Let's start by reviewing some basics of the DNS. No single location on the Internet holds all of the information contained within the DNS database. At the root level, there are 13 DNS servers; most of these are located in the United States in physically secure facilities. DNS is a distributed database that holds information for mapping host names to IP addresses. DNS provides a method for querying information held within the database. DNS uses both UDP and TCP, depending on the particular action being performed. UDP is typically used for queries unless the lookup or response is greater than 512 bytes. TCP is used for both larger lookups and for zone transfers.

More on this topic RSA Conference: Officials say DNS servers stood up well to attack

When you check your mail or go to a Web site, you are usually relying on DNS to translate a host name to an IP address. Therefore, if you open your browser and go to SearchNetworking.com, DNS translates a fully qualified domain name (FQDN) to the correct IP address.

This process starts by sending the request to a service on the local host called the resolver. The resolver will typically first check the local cache that holds the responses of recent requests. In addition, it may also check the host's file, which is a local file that contains mappings of hostnames to IP addresses. If the requested information is not available from any of these locations, the resolver will send a request to the DNS server that the host's TCP/IP network interface is configured to use. In order to increase performance and decrease network traffic caused by DNS, name servers will cache replies from requests made for a period of time. How long the information in a response remains cached is determined by the time-to-live (TTL) specified in the response.

DNS exploits

When a DNS server replies to a request, the reply message contains a transaction ID and answers to the user query. If DNS records are not available or have been tampered with, you may not be able to reach the site you are attempting to go to, or you may even end up connecting to an attacker's Web server. This is possible because the protocol may be attacked in several ways. These include:

• Exploiting zone transfers
• DNS cache poisoning
• DNS cache snooping
• Man-in-the-middle attacks

Zone transfers are used to copy a domain's database from the primary server to the secondary server. If an attacker is able to perform a zone transfer with the primary or secondary name servers for a domain, he will be able to view all DNS records for the domain. This can expose sensitive information such as internal addressing schemes. In addition, it is possible for the attacker to determine which IP addresses are used by the Web server, email, or file transfer, for example.

DNS cache poisoning is the second technique we will discuss. Both DNS clients and servers cache responses for a period of time in order to increase performance and cut down on network traffic. If attackers are able to spoof a response for a DNS request, they may be able to contaminate the DNS cache with an incorrect record. By poisoning the caches of DNS clients and servers, an attacker can redirect traffic to malicious hosts, which can lead to further compromise. Previous attacks on root DNS servers have attempted this technique, as well as denial-of-service attacks.

DNS cache snooping is the process of determining whether a given resource record is present in the cache. DNS cache snooping can be useful for determining which sites a target visits, who their clients and customers are, and other information that would be potentially useful for an attacker. It may even be possible to see what software a target is using by checking for the presence of resource records for software update addresses.

More network security advice Get more tips from Michael Gregg in his OSI: Securing the Stack series Guide to network security

Finally, man-in-the-middle (MITM) attacks occur when an attacker intercepts and modifies DNS messages on the wire. In this situation, the attacker can obtain the source port and transaction ID from the intercepted traffic. MITM attacks can be used to redirect victims from legitimate addresses to malicious sites. This can be especially useful for attackers attempting to steal personal information if DNS requests for banking, financial and e-commerce sites are targeted. Instead of enticing a user with an email such as those used in common phishing scams, the attacker can target the DNS records for the legitimate sites.

Defending DNS

These attacks pose real threats, but there are some defenses. DNS cache poisoning can be made more difficult by requiring DNS to use a random transaction ID and source port. Without the correct value for these fields, the attacker will not be able to spoof a reply in an attempt to poison the server's cache. Zone transfers were a real problem a few years ago, as Windows 2000 servers would allow anyone to obtain this information by default. This default setting no longer exists in Windows Server 2003. Even the recent attacks against the root DNS servers might have been prevented if ISPs had performed better egress filtering. A solution to just this problem is being proposed in RFC 3704.

While the countermeasures discussed above are a good start at making DNS more secure, we cannot stop there. Failure to address the problems associated with DNS leave us vulnerable to attacks that affect our business-sensitive applications, Web traffic, email and VoIP communication, all of which must traverse the Internet.

About the author:
Michael Gregg has more than 15 years of experience in IT. Michael is the president of Superior Solutions Inc., a Houston-based training and consulting firm. He is an expert on networking, security and Internet technologies. He holds two associate degrees, a bachelor's degree and a master's degree. He presently maintains the following certifications: MCSE, MCT, CTT, A+, N+, CNA, CCNA, CIW Security Analyst and TICSA.

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

All Rights Reserved,Copyright 2000 - 2013, TechTarget