Recently we went through an exercise which turned our DNS into a firewall for a well-maintained list of requested hostnames.  It was designed to work with our host reputation feed that is provided to our FlowPro Defender customers who use it to uncover internal end systems that are reaching out to Internet systems that are known to host malware.

Infoblox Competitor

By adding a configuration file to Bind within our DNS server, we were able to get our DNS to actually firewall and mitigate attempts.  The solution worked well enough that we have decided to share the work with the Internet community.

DNS Firewall Features

  • Creates a zone filed called plixer.blockzone with a short Time To Live (TTL). This is done because many Fully Qualified Domain Names are stored locally on end systems for 24 hours. A short TTL allows FlowPro Defender to report more frequently on the attempts to reach out to the malicious domain.  Ultimately this escalates the infection as it increases the Threat Index more quickly.
  • This DNS firewall feature builds a deduplicated domain zone declaration file called plixer-dnsblocklist.conf
    • Note: The success of this list loading is correlated to the amount of server memory available.  YOU MAY NEED MORE MEMORY TO USE THIS UTILITY.
  • BIND becomes the authoritative name server for all malicious domains and does not behave recursively for these blacklisted domains.
  • Responds to requests it doesn’t like with a non-routable IP address: 127.0.0.127

How to Implement the DNS Firewall

  • Place plixer-dnsblocklist.pl on your bind server and run with privileges
    • sudo perl /home/dns/plixer-dnsblocklist.pl
    • Bind is automatically reloaded after zones are loaded
    • Adds include “/etc/bind/plixer-dnsblocklist.conf”; to named.conf
  • Schedule plixer-dnsblocklist.pl to run frequently to get list updates. Also, this ensures that domains are removed from BIND configuration if they are no longer present in threat list.

We attempted to add a similar process to a Microsoft DNS server but, the process ended up being kind of messy. As a result, we dropped the project into /dev/null.

Future Work

  • While currently designed to work with Plixer’s domain threat list, it could be easily converted to work with other custom lists.
  • Add domain checking of special characters
  • Add named-checkconf to identify configuration errors
  • Add back-off function to remove added configuration files in the event of error
  • Currently, notification of the event is sent via our FlowPro Defender but, we could easily send the alert out as a syslog or IPFIX message.

If you are looking for an alternative to commercial DNS Firewall solutions or a potential Infoblox competitor, you might want to give the above a try.  If you are interested in a copy?  Reach out to our team.

 

 

Thomas

Thomas

Thomas Pore is the Director of IT and Field Engineering at Plixer. He developed and leads, the Malware Incident Response and Advanced NetFlow Training programs which are being offered in cities across the USA. He is also an adjunct professor at the local community college and teaches ethical hacking. Thomas travels the globe meeting with customers and trying improve the Scrutinizer network incident response system. He helps clients optimize threat detection strategies and aids in the configuration of custom incident response solutions. He has a Bachelor of Science in Computer Science from Dickinson College.

Related