Using the DNS Resolver to Protect Networks

Posted on

Smart organizations use the DNS Resolver to Protect Networks.  Here is why …

 

A typical story …..

Imagine 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 on the latest news.
  • Further research shows that a “malvertisement” was used 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.
  • A continued investigation uncovered all the domain names used for the exploit. All of the domain names were blacklisted at SPAMHAUS, SURBL, and other core blacklist providers. They were in the blacklist 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 use the DNS infrastructure for something more than 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 Resolver to Protect Networks – 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.

Essentials of DNS

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 “blacklist,” 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 blacklist 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 in 2005 (Xerocole – www.xerocole.com was originally Simplicita – which got bought by Sandvine, then spun back out in 2011 as Xerocole then bought by Akamai in 2015 to the foundation of the rDNS services and then synergized in 2017 with Nominum).  Simplicita pioneered a system that would take in multiple blacklists feeds from sources as diverse as Spamhaus, Team CYMRU, and Shadowserver. These blacklists 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 blacklist 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 blacklist first and if it was in the blacklist, 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 the resolution to local resources inside the enterprise.  Other DNS vendors explored DNS Firewall capabilities. For example, Nomimum created something similar in 2010 with their Network Protection Service (NPS). Endgame System – a small startup also created a “DNS Firewall” capabilities in 2010. Neither of these solutions gains 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 Blacklist. It is an 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, RBL) and RHSBL (Right Hand Side Block List)…. … with greater degrees of scaling and speed.

The following figures provide a walkthrough for how DNS RPZ works to rapidly push out standard and updated blacklist to devices who have their DNS resolvers configured for DNS RPZ. Some organization looking for domain names attacked to botnets, phishing, spam, malware, and other badness provide an DNS RPZ “zone” connection to the organization with the DNS Firewall. That RPZ blacklist is configured into the DNS Resolver. That DNS Resolver can then take action (i.e black access, give an NXDOMAIN, or redirect the end user).

DNS RPZ Basics

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 blacklist providers: SPAMHAUS, SURBL, and Internet Identity. Work continues to encourage more organizations to use DNS RPZ to distribute their blacklist. The best sources to find sources for RPZ feeds are:

  • Community DNS RPZ Resource Page – https://dnsrpz.info/
  • Open Source Threat Intelligence Feeds – http://senki.mystagingwebsite.com/operators-security-toolkit/open-source-threat-intelligence-feeds/
  • Herman Slatman’s awesome-threat-intelligence on Github – https://github.com/hslatman/awesome-threat-intelligence
  • SPAMHAUS’s RPZ Feeds – http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone and https://www.spamhaustech.com
  • SURBL – http://www.surbl.org/

 

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. Overall, 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

If other organizations are using the DNS Resolver to Protect Networks, what can use you do to get started? Here is a start:

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.

Line

Need Security Advice?

If you find your organization needs help and worry about the FUD from the industry, reach out and ask for help. You can reach me at bgreene@senki.org. Start with the Operator’s Security Toolkit. It is the no-nonsense security for all Operators. It provides details to help them build more security resilient networks. In the meantime, stay connected to the Senki Community to get updates on new empowerment and security insights.