Using DNS to Protect Your Network and Your Customers

(Last Updated On: August 20, 2012)

In cased you missed it, Xerocole & Damballa released two press releases on their new partnership:

The Xerocole-Damballa partnership is another evolution of a security technique where the DNS recursive resolver is used as a “DNS Firewall” – keeping devices from going to known “bad sites.” Why is a DNS Firewall important for all network enterprises? Let look at a typical story …..

A typical story …..

Imaging walking in to work the first thing in the morning. Your staff comes into the office. They get their coffee, fire up their computer, and check out the morning industry news. Your staff is alert, applies all the patches sent to keep the computers up to date, insures the anti-virus updates are installed, and follows all the “safe browsing” recommendation. In essence, an ideal “security mindful” workforce. Yet, later that day you receive an E-mail report from one of the third party malware systems you use to keep an “outside in” view of your network. This third party reports 25 systems in your network communicating with a BOTNET command and control system. These are new infections. You take this information, match it against the firewall/NAT logs, and then trace back the DHCP leases to the people who have been violated with malware. All the systems are pulled from the network and examined.  This is what your INFOSEC Team finds:

  • All the systems were infected with the same malware.
  • All the systems were up to date with all the relevant system patches.
  • All the systems were using the latest anti-virus patch.
  • All the users of the systems were reading a popular tech site – catching up with the latest news.
  • Further research shows that a “malvertisement” was uses on this popular tech site. This malvertisement would have the computer do a DNS lookup to a drive-by malware site, pull down the graphic, and start a “conversation.” That “conversation” would not be noticed by the user.  The only thing they would notice is the “advertisement” graphic. They would not see the “drive-by” site infecting the computer with malware through a zero-day exploit unknown to the community.
  • Continued investigation uncovered all the domain names used for the exploit. All of the domain names were black listed at SPAMHAUS, SURBL, and other core black list providers. They were in the black list for over a month.

Bottom-Line: Your staff took every security precaution and still got infected! The infection was quickly caught (thanks to public benefit “outside in” – 3rd party monitoring). Yet, the lost time, productivity, and cost (hard drives being replaced) is not what your organization needs.

The situation described above is based on a true story. It is a very common story encountered by network throughout the world – with one modification. Most organizations do not monitor their network with 3rd party security tools – meaning their users get infected and the organization does not know it. Organizations are getting hit with malware for which there is no effective defense. Yet, the techniques used to get this malware onto your team’s computer all depend on the Domain Name System (DNS).

What if there was a way to us the DNS infrastructure for something more that an address to name translation tool? What if there was a way to use your DNS infrastructure to keep your staff’s computers from being pulled to malware-metasploit sites – returning an alarm to let everyone know you have some cyber-criminal trying “phish,” spam, or malvertize into your network?

DNS as a Security Tool – DNS Firewalls

The vast majority of DNS Resolvers perform its one core function – taking a unique domain name and resolved queries for these names into IPv4/IPv6 addresses for the purpose of locating computer services and devices worldwide. This is why DNS is Internet critical. Every device is dependent on a DNS Resolver for normal Internet functioning – creating a critical dependency and choke point. This choke point is one of the reasons why DNS is an attractive policy enforcement point – preventing the resolution to domains which have been identified with miscreant activity.

Imagine your network’s DNS recursive resolver checking on a list of bad/suspect domain names before it completes the resolution. If the domain name is in that “black list,” it would return a response that warns the user – preventing the computer from going to a site that might try to “drive-by exploit” without the user’s knowledge. This would prevent devices from getting IP addresses to suspect sites – minimizing the chance of infection. The DNS servers would become a “DNS Firewall,” protecting customers before there was a chance of infection.

Now, the industry has been using DNS lookups as a tool to check black list for anti-spam activities.  The principle of using DNS as a security enhancement tool is not novel or new. In fact, one of the first organizations to put serious effort into using the “DNS Firewall” principle as a tool to protect customers was Simplicita (now Xerocole) in 2005 (Xerocole – www.xerocole.com was originally Simplicita – which got bought by Sandvine, then spun back out in 2011 as Xerocole).  They developed a system that would take in multiple black list feeds from sources as diverse as Spamhaus, Team CYMRU, and Shadowserver. These black lists would be pulled into their Reputation Knowledge System (RKS). This list would then be used by the DNS Recursive Resolver (Xerocole’s eXtensible DNS Resolver (XDR)) to check if a domain is good or bad. When a device asked the XDR for a DNS resolution, it would check the black list and if there is a match to respond with the appropriate action.

In 2005, the new innovation was the use of the DNS Resolver as the enforcement point – checking to see if a domain was in the black list first – and if it was in the black list, taking policy action to protect the user. But, once Simplicita was acquired, the solution “disappeared” from common view. Only a few in the industry knew of their DNS Firewall capabilities. OpenDNS – who in 2006 started anti-phishing capabilities to protect their customers. But OpenDNS’s solution would have a network “outsource” the resolver functionality to the “Cloud.” Depending on the Cloud DNS works well as long as  the connection to the Internet keeps working. If the connection goes down, all DNS resolution capability stops – including resolution to local resources inside the enterprise.  Other DNS vendors explored DNS Firewll capabilities. For example, Nomimum created something similar in 2010 with their Network Protection Service (NPS). Endgame System – a small start up also created a “DNS Firewall” capabilities in 2010. Neither of these solutions gain market traction. It wasn’t until 2011 that two events resuscitated the function of a DNS Firewall – Xerocole spinning out of Sandvines and ISC’s create of the DNS Response Policy Zone (RPZ).

 

DNS Response Policy Zone

In 2010, the Internet Systems Consortium (ISC) added a new code to BIND’s resolver to allow it to be used as a DNS Firewall. Vernon Schryver and Paul Vixie created a technique that would use the existing Authoritative Transfer (AXFR) and Incremental Zone Transfer (IXFR) zone transfer techniques to push a “DNS Black List” zone into the DNS Resolver. This Response Policy Zone (RPZ) solves a fundamental problem with distributing DNS Black list . It is a open specification and capable of being used in any DNS implementation (or other security devices which will use the list).  DNS RPZ enables DNS reputation data producers and consumers to cooperate in in real time – coupling the new abilities to track cyber-criminal activity via DNS and then push that updated list to DNS Firewalls spread throughout the Internet. In essence, DNS RPZ turns the recursive DNS server into a security hammer … provide the same capabilities of an anti-spam DNSBL (DNS Block List, ne RBL) and RHSBL (Right Hand Side Block List)…. … with greater degrees of scaling and speed.

The following figures provide a walk through for how DNS RPZ works to rapidly push out standard and updated black list to devices who have their DNS resolvers configured for DNS RPZ:


Integrated DNS RPZ as open source in BIND 9.8.1. This provides all DNS implementations a reference to see how they would integrate RPZ into their code. ISC is posting a collection of Knowledge Base articles here: Building DNS Firewalls with Response Policy Zones (RPZ).

There are currently three known RPZ black list providers: SPAMHAUS, SURBL, and Internet Identity. Work continues to encourage more organizations to use DNS RPZ to distribute their black list.

  • http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone
  • http://www.surbl.org/
  • http://www.internetidentity.com

What is needed to push this DNS Firewall deployment forward?

Today, network operators have an open source solution (BIND), a commercial solution (Xerocole), and over the top DNS solutions (OpenDNS). DNS Firewalls do work. They prevent users from getting infected. If the solution works, why are there poor adoption? First, the vast majority of CIOs and CISOs do not view their DNS resolvers are “security tools.” So the concept is new and not top of mind. Second, there are many firewall and deep packet inspection (DPI) companies who get top of mind influence with these CIOs/CISOs – drowning out the small marketing effort to advertise the capabilities of DNS Firewalling. Finally, the persistent and loud marketing to push out the capabilities of DNS Firewall capabilities have been weak. OpenDNS has had the most successful outreach over the past year. Over all, DNS Firewall – using the existing DNS infrastructure as part of comprehensive security defense – needs more effective outreach (hence this article).

What can you do to help the effort? Start using a DNS Firewall – Start with BIND

Step 1 – Pull down the papers and materials on DNS Firewalls.

Step 2 – Deploy a BIND Based DNS RPZ Resolver instance in your network. You can select which computers use the DNS RPZ configured resolver. All three DNS RPZ providers provide trial RPZ feeds to test the technology.

Step 3 – Select the DNS Firewall solution that best fits for your organization. Be it a commercial solution like Xerocole, an open source solution like BIND, or a Cloud solution like OpenDNS, DNS Firewall is a tool that will protect your users while “taking back DNS” from the criminals.