Virtually all networked applications use Internet Protocol (IP) communications and rely extensively on the Domain Name System (DNS) to determine the IP address to connect. DNS provides the mapping of human-readable fully-qualified host names to IP addresses. If you inspect the DNS queries taking place over a network you can gain an understanding of which systems are communicating with each other. Forensically inspecting this DNS query traffic provides valuable insight into malware infected hosts and other malicious behavior on a network. Security systems can utilize this data to detect and prevent security incidents.
DNS is a Target
DNS is a critical component of the networking infrastructure. Without DNS, nothing in the environment will function. Attackers are acutely aware of the security implications of DNS and the value it represents to their hacking business ecosystem. Attackers target DNS by performing Distributed Denial of Service (DDoS) attacks, trying to poison the cache and many other threat vectors. Hardening DNS servers and using DNS Security (DNSSEC) can go a long way toward security, but they do not add any operational intelligence to how DNS is being used in an environment.
DNS Gives Clues about Malware
The reason that this DNS information is so valuable at catching malware is that botnets and other malware change their IP addresses frequently. The attackers want to hide themselves among many public IP addresses while using the same URL for their malware. The attackers change their DNS entries frequently using a low Time-To-Live (TTL) value for the DNS A/AAAA record. The malware is encoded with a single URL to query, but it can end up communicating to any one of many IP addresses that is ultimately the server that serves up malware installations or the IP address of the botnet command-and-control (C&C) system. The attacker does not want their IP addresses to show up persistently on “block lists” so they move around frequently. This technique of rapidly changing the IP address is called “Fast Flux”.
Reputation Filtering Based on IP Address
The down side for many of these reputation filtering systems is that they use the IPv4 address to track the malicious sites. With the impending deployment of Carrier Grade NAT (CGN)/Large-Scale NAT (LSN) systems, attackers are likely to move their malware to systems that maintain a consistent public IP address. Today, many content filtering systems that are inspecting IP addresses in connections only work with IPv4 and do not work with IPv6. Furthermore, many reputation filtering systems do not yet use IPv6 prefixes in their lists of known bad locations on the Internet. This is true for traditional firewalls, Web Application Firewalls (WAFs), e-mail spam filters, web content filters, and Intrusion Prevention Systems (IPSs).
Two Techniques for DNS Inspection
The key to performing this type of forensics on DNS query and response traffic is the ability to capture these packets off the network. DNS queries are sent from end-nodes to their recursive DNS resolver, and then from the resolver to the Internet-based root and Top Level Domain (TLD) servers or to forwarding DNS servers.
One way that DNS inspection can be deployed is to add intelligence to all the internal caching DNS servers within an organization. The drawback to this technique is that not all systems in your environment may be using your enterprises internal DNS resolvers. There could be other systems in your environment, like BYOD mobile devices, that are using external DNS servers on the Internet. For example, there could be systems using Google’s Public DNS servers (8.8.8.8, 8.8.4.4, or 2001:4860:4860::8888, 2001:4860:4860::8844)
The problem with this internal caching DNS server detection technique is that malware can modify the DNS settings on the client. This DNS server modification is made without the end-user being aware of change because it does not affect their experience. Malware like “DNSChanger” changes the recursive DNS resolver for the infected client to another rogue Internet-based DNS server that can redirect users to alternate destinations. The rogue DNS servers could redirect users to web sites that are hosting malware, or to fake Man-In-The-Middle (MITM) sites that look like the real sites and capture usernames, passwords, or credit card data. If you intend that all your enterprises’ internal users use the same caching DNS server, then identifying internal systems that are using other external DNS resolvers could also be a clue to find compromised systems.
A second method for performing DNS query inspection is to deploy an inspection system at the Internet perimeter choke point. This capability could be implemented similar to an Intrusion Detection System (IDS) where a simple tap/SPAN/mirror of the Internet-bound traffic is captured and analyzed for DNS “funny-business.” However, this approach only has the ability to detect issues, (it’s powerless to stop the connections by blocking the DNS query/response). If the DNS security system was implemented in-line with the Internet traffic path, then the system would have the ability to stop the undesirable DNS queries/responses and thus stop the connection from taking place.
For an enterprise, the logical place to capture this traffic is at the enterprise’s Internet perimeter. However, if you have these DNS forensic capabilities built into all an organization’s DNS servers in addition to those DNS servers at the perimeter, it provides better visibility to all types of DNS queries and responses.
Summary
It is important to be aware of the ways that attackers try to leverage DNS for their means. The DNS servers can be the target of the attack. The malware can also target the way that DNS is being used on the infected end-user computer. Gaining deeper visibility into your DNS traffic can give you insight to these types of attacks.
In the second part of this blog series we will cover the techniques for mitigating these security issues. We will cover techniques that give you visibility to these threats and give you the ability to automatically block these malicious communications.
Scott
