Cloud Computing Strategies for the CIO
In this tip, the sixth in our series of technical tips on cloud security, we focus on exposures in the domain name system (DNS) and how they can negatively affect Infrastructure as a Service (IaaS) offerings.
While our previous tips on Infrastructure as a Service covered threats in underlying operating system and services
Requires Free Membership to View
and threats
from remote management solutions, this tip explains the domain name system and how corrupted IP
address translations or returning erroneous data can pose a threat to an Infrastructure as a
Service offering.
A quick DNS primer
The domain
name system translates names in to IP addresses. In order to access a server on the Internet,
you need to know its IP address, and it is often easier for people to remember a name (i.e.,
www.techtarget.com) than an IP address (i.e., 192.168.134.235). The DNS infrastructure provides
that translation. It does so with a hierarchy of servers and domain owners (i.e., those that own
the DNS names) providing "authoritative" mapping of those names to IP addresses. As part of the
system, there are secondary and caching servers that help in distributing the load of name
translation requests.
Another fact to note is that the main query-response request is done using the User Datagram Protocol (UDP), which is, by default, insecure, stateless, and unreliable.
What are the DNS threats that affect IaaS?
Since we rely on DNS to tell us the IP address of the name we are trying to reach, anything that
can be used to block the translation or return erroneous data must be noted and mitigated whenever
possible. The latter, bad data, is arguably the biggest threat to address. Let's look at this
scenario:
You want to manage your IaaS server, whose DNS name isserver.example.com. You open your remote management tool and initiate a session. Your client queries a DNS server to "resolve" the nameserver.example.comto the IP. At the same time, an attacker has set up a malicious DNS server to look for DNS queries and respond with the IP address of a system he controls. Your client then connects to the IP address returned (the malicious server). The attacker can now attempt a man in the middle attack on your client.
At this time, there are four main threats associated with DNS that are most applicable to IaaS services:
- Cache poisoning: When a DNS server does not have information on a name-to-IP mapping, it must find another DNS server that does. When it receives the answer, it typically caches it for later use (there are timeouts and limitations, but they have limited effect). Cache poisoning is when the server receives an answer that contains incorrect information. Malicious cache poisoning is also referred to as DNS spoofing.
- Insecure dynamic updates: This is another mechanism to get malicious data into a DNS server, which would then be returned in any query for that information. A similar effect as cache poisoning.
- Information leakage: An attacker performs a DNS zone transfer to gather DNS domain names, computer names and IP addresses in the hope of identifying sensitive network resources.
- Denial-of-service: An attacker floods DNS servers with recursive queries to render them unavailable to answer legitimate queries. Without a name-to-IP translation, you will not be able to access your IaaS resource.
So what can you do?
Mitigating these threats could be performed manually, if a user controlled the DNS servers, or
something that may need to be addressed by your provider. Here are my recommendations for
mitigation:
- Use IP addresses only or a local host file: If you do not use DNS to make name-to-IP translations, the DNS issues described above will be irrelevant. While this may seem impractical, if you have a limited number of IaaS instances and can assign static IPs, it is a realistic solution.
- Random transaction IDs: Ensure the DNS servers have a properly randomized transaction ID (most current DNS servers do this). Each DNS query is assigned an ID, and randomizing the value makes the attack harder to perform.
- Source port randomization: Configure your DNS server to use "query source port randomization." The attacker will now need to know the transaction ID as well as the port from which the transaction was sent (i.e., a random source port other than 53). Note that this may affect firewall rules.
- Secure dynamic updates: Configure your DNS server and clients to accept only secure dynamic updates. You can also limit the IP address range that dynamic updates can originate from.
- Limit zone transfers: This will prevent an attacker from being able to easily gather information on the IPs and hostnames of your IaaS instances.
In closing
DNS is a foundational Internet protocol. The Internet, and any service that exists on it, could not
function adequately without DNS. Like electricity, however, people do not seem to think about it
until it malfunctions. Keep the importance of this service, and the security issues surrounding it,
in mind when working with Infrastructure as a Service offerings.
ABOUT THE AUTHOR:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.
His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).
Phil holds a BS in Computer Science from the College of Charleston
This was first published in January 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation