Imagine trying to call someone or a business without having access to the Internet, a phone book, an operator or your contact list. How would you figure out the number to dial? Perhaps you’d call a friend who might know the number you need. That would be a crazy process. This is why from the beginning, telephone services were very dependent on directories. Similar to telephone services, Internet communications are dependent on a directory called the Domain Name Server (DNS).

Since nearly the beginning of the Internet, we have been depending on the DNS to convert the names we send it to IP addresses. Without it, many websites would be completely unreachable for most of us. Although it has evolved to a very reliable service, its security hasn’t. As a result, both vendors and cyber villains have exposed consumers to numerous types of abuses and hacks, many of which compromise our privacy and our security.

Common DNS abuses

The crimes below are still prevalent in the wilds of the Internet today.

  • LINUX/MOOSE: Users are tricked into visiting websites containing malicious code which attempts to access the admin interface of their home or small business router. If the cyber villains are able to change the device’s DNS settings, they can intercept data and control some of what is displayed in the user’s browser, which can lead to further infections.
  • DNSCHANGER TROJAN: When computers are infected, this code redirects browsers trying to access sites like Google, Yahoo! and Facebook to other malicious websites.
  • INTERNET SERVICE PROVIDERS: Users who mistype domains are rerouted by Internet service providers to alternate search engines which display ads, collect statistics and possibly even censor Internet activities.

Our Internet experience is extremely crippled without the DNS. Because of this and its inherent vulnerabilities, it is frequently the target of data leak contagions that can be very difficult to detect and stop.

DNS Tunneling

DNS tunneling is a method where excessively long labels in a Fully Qualified Domain Name (FQDN) are used to tunnel sensitive information out of computers. For example FQDN: fast.downloads.oftop40.music.for.free.megastore85.com is an eight level domain. The first level domain is .com. The second level domain is megastore85.com and so on. Each level is called a label and an FQDN can have up to 13. If a machine is infected with a bot that is trying to slowly upload data from the local device to the Internet, it may encapsulate the data in a long FQDN that looks like 38H2K.K87L9S.W928NVX.T16ZM4.8QCOYP.megastore85.com. This seven level domain is actually an encrypted message that the DNS will try to resolve to an IP address. When the authoritative DNS for the domain megastore85.com receives the encrypted FQDN, it will parse it, decrypt it and store the message locally, plus it may not respond to the requesting DNS. Since many firewalls will not intercept DNS traffic, this form of data theft often occurs undetected. Reputable companies such as Dell, Apple and McAfee have been known to leverage this DNS tunnel tactic to remove information from their customers as it is a very effective method for getting past the local firewall. In fact, the DNS on most networks today is being abused by both malware and vendors who use it to extract sensitive and often confidential information out of our organizations.

Monitoring DNS Requests

To stop some of the abuse outlined above, firewalls or access lists can be configured to monitor for DNS attempts outside of the approved DNS servers. Security solutions often utilize constantly updated lists of domains which are used to watch for internal hosts reaching out to known compromised Internet sites. Another method of DNS monitoring is to count the number of NXDomain messages sent back to individuals’ systems.

In order to perform the above, security monitoring systems need logs that contain details about the individual DNS transactions. Often these messages come in the form of traditional syslogs or more recently in NetFlow or IPFIX datagrams. Major network and security vendors such as Barracuda, Cisco, Citrix, F5, Gigamon, Ixia, Juniper, ntop, Palo Alto and Plixer export DNS details in their IPFIX export. These flow logs can be monitored in real time for suspicious DNS activities and trigger alerts that can lead to notification or mitigation of the traffic.

Not Just for DNS Monitoring

Due to the increase in the volume of Internet traffic headed to Content Delivery Networks (CDN), sites like akamaitechnologies.com and amazonaws.com, the network traffic visibility afforded by NetFlow and IPFIX monitoring has become limited. This is because often times, in order to save money, services provided by YouTube, LinkedIn and various news stations are hosting content on these CDNs. When viewing Internet bound traffic in the flow reporting system, visibility into the actual application behind CDN destined traffic is lost.

To compensate for the blindness, some IPFIX and NetFlow collectors are performing a deeper form of network traffic analysis by correlating the FQDN extracted from the DNS requests with the flows received from the vendors mentioned above.

DNS flow reports

This strategy allows security teams to regain visibility into connections headed to CDNs. Both DNS abuse and Internet bound application visibility are two great reasons we all need to start capturing and monitoring DNS transactions. It is also important for cloud service monitoring.

Michael

Michael

Michael is the Co-Founder and the product manager for Scrutinizer Incident Response System. He can be reached most hours of the day between work and home. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer. Feel free to email him.

Related