Items 0

Domain Blacklisting and Sinkhole with DNS BIND RPZ

Summary

You can import a list of malicious or undesired domains that you need to Block, Redirect, Monitor, and/or Report with your current DNS Servers; whether your DNS Server is an Active-Directory Integrated DNS, Standalone Microsoft DNS Server, or Unix BIND Server.

You can as well create a custom response of the requested domains that you want to control access to; such that you can identify the devices that are trying to communicate with the domains and URLs you want to monitor or control access to. Besides, you can make a use of your current network security solutions such as IPS, IDS, Honeypot, Next Generation Firewall, SIEM, or simply just log it with syslog or packet capture tools.  

Briefly; when a computer requests a URL or access to one of these undesired domains by sending a DNS query request, which could be even triggered by a malware/spyware, a customized response is sent by your DNS Server, thus enforcing and controlling access to the listed domains. 

This is also commonly known as RPZ (Response Policy Zone).

Introduction

One of the essential and critical techniques for mitigating, identifying, and preventing malwares/spywares among users is through the use of DNS, which can be configured with custom/synthesized responses such as redirection, blocking, and reporting.

Most commonly this will be achieve by importing the blacklisted or undesired domains into an Internal DNS Server. It can even be implemented on a DNS Caching Server, which will act as Authoritative DNS for only the undesired / blacklisted domains and Zones. Yet using a DNS Caching Server in this case will prevent you from identifying the source IP addresses and devices sending the DNS query requests. 

The DNS Server, which will be used, could also be configured as a “primary” or “master” resolver for domains associated with malicious malware, spyware, botnets, or any other domains that you need to control.

The DNS server will be “Authoritative” for these zones, which will answer the query instead of forwarding or recursion them with other DNS servers.


Once the domains that you need to control are added to your DNS Server, the requested clients will start receiving a custom response that you have specified.

These custom responses can be resolved to IP addresses that relates to one of the following:

1) A loopback address (127.0.0.1) or 0.0.0.0
2) An internal Web Portal or a Wall Garden configured to “redirect” all web requests to a warning web page.

3) An existing security device such as an IPS, IDS, Next-Generation Firewall, Honeypot….etc

4) A reporting solution such as a logging system, packet analyzer, SIEM, etc such that it will identify the device trying to access the listed domains.  

The last two options have the added advantage of logging the requesting device for inspection as well as enable an IPS, NG-FW, or IDS system to continue monitoring suspension traffic.

 

Configuring your DNS server: Bind format

A standard format for DNS files are usually saved in a “Bind Format”.

In most instances of BIND, there are two files of interest: the master config file (called named.conf on most machines) and the “zone” file associated with each administered domain (usually called something like “domainname.zone.dns“).

BIND9 Configuration files are stored in:

/etc/bind/

The main configuration is stored in the following files:

/etc/bind/named.conf  (This is the main BIND configuration file, which will call the zone files.)

/etc/bind/named.conf.options (This is mainly used to turn on and configure DNS Caching.)

/etc/bind/named.conf.local (This is mainly used to turn on and configure Primary Master DNS Server.)

 

There is usually one zone file per domain, included in “/etc/bind/named.conf “, but since we will specify one action (such as redirect, block, or monitor) for all imported domains then we would only need a single zone file to be associated with these multiple undesired/malicious domains.

Debian, Ubuntu, and other Linux distros already have a file called “named.conf.local” so we’ll use that as an example. Make sure the file is located in the same working directory as the named.conf file or add the full path to the file (such as /etc/bind/named.conf.local).

For example, the following entries in the named.conf.local will add the domains “badsite.com” and “botnet.com” to the local DNS server.

named.conf.local file :

zone badsite.com  {type master; file /etc/bind/actionfile.hosts;};

zone botnet.com  {type master; file /etc/bind/actionfile.hosts;};

 

You will then create /etc/bind/actionfile.hosts, which will contains the action/type of the custom response, and also called as Record or Zone File. The content will look something like:

$TTL    86400   ; one day

 

@       IN      SOA     ns1.xxxxnameserver.net. xxxxnameserver.net. (

                          1

                          28800   ; refresh  8 hours

                          7200    ; retry    2 hours

                          864000  ; expire  10 days

                          86400 ) ; min ttl  1 day

                  NS      ns1.xxxnameserver.net.

 

                  A       127.0.0.1

 

*               IN      A       127.0.0.1

Also know as Record File.

The * in the line * IN A 127.0.0.1 is a wildcard, which means that 127.0.0.1 will be returned for any hostname within that domain:
www1.badsite.com, www2.badsite.com, malware.badsite.com, anything.badsite.com will all be resolved to 127.0.0.1.

This single file will be used for the custom response action for all associated domains.

Most of the actual content of this file is not important, as it is not serving up information for a “production” domain. You should probably change the “ns0.example.net.” and “ns1.example.net” to your own information.
You may also specify an IP address for other security or logging solutions instead of 127.0.0.1 to 0.0.0.0, as discussed earlier.

Instead of querying an upstream DNS server for the answer, your local DNS server believes it is a “master” for the “badsite.com” domain.
It will therefore “answer” any queries for a host within that domain with 127.0.0.1 or whatever IP address you placed in the zone file.

In “production” domains, the values for TTL, refresh, retry, etc. may need to be
tweaked for your configuration. In addition, when a change is made (such as adding or modifying a host), the serial number needs to be incremented. However, since this “dummy” file should never change, the serial number is not important.

Testing the new zone

Start (or stop/restart the DNS server). Once DNS is running, change a desktop’s DNS settings to use this server.
If DNS is configured correctly, then, due to the wildcard entry (*) above, any and all queries to the “badsite.com” domain (such as www1.badsite.com, xyz.badsite.com, etc) will resolve back to 127.0.0.1 or whatever you changed it to.
You can test this with tools such as “ping”, “dig”, or “nslookup” (from the command line):

Testing the new zone:

ping www.badsite.com    
ping anyrandomstring.badsite.com    
ping hsdsdshgdhsgd.badsite.com    
nslookup www.badsite.com    
nslookup ihatebrowserhijackers.badsite.com

All of the above should reply with 127.0.0.1, or whatever address you placed in the blockeddomains.zone.dns file. You can
also attempt to reach the sites through a web browser (with sufficient precautions, such as making sure the sites you are testing are in your restricted zone, or use firefox with the all scripting disabled via the Web Developer Extension.)

 

DNS Related Tools and Articles:                                

DNS Centric Solution

Identify Threats with DNS Logging

DNS Domain Blacklisting and Sinkhole Overview

Configure Unix BIND DNS Server for Domain Blacklisting and Sinkhole

Configure Microsoft DNS Server for Domain Blacklisting and Sinkhole

Convert Microsoft DNS Debug File to CSV Table Format

          

Start using the tool by selecting your DNS server type from the following list:  

Please Login to your account or Register for a new account in order to use this tool.



Target Audience

1- DNS Administrators 

2- Systems Security Team

3- IT 

Prerequisites

1- BIND DNS 

2- List of Domains that you need to block, monitor, redirect, and control

3- Optional attributes

Comments
Comment