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 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 is
server.example.com. You open your remote management tool and initiate a session. Your client queries a DNS server to "resolve" the name
server.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.
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