Focused IDS Sensor for DNS

Many enterprises have what is known as a split domain name system (DNS) configuration. Split DNS is where you serve your internal network with one (or perhaps a pair) of DNS servers, but forward all unresolved requests to another DNS server(s) that lives within your DMZ. Using split DNS provides some security protection for your internal DNS servers, and performance benefit in that the internal servers do not have to cache external network information.

Additional security protection can be provided by carefully controlling your network perimeter (anti-spoofing and bogon filtering for example), and carefully configuring your external DNS servers to only respond to DNS requests that are within your network domain.

In recent times, DNS cache poisoning has risen as a significant challenge yet again. It has been noted that DNS is fundamentally flawed due to it's weak reliance on a matching DNS identification and packet source information in query responses. Though widespread deployment of DNSSEC (secure) is the correct solution, it has not gained in popularity enough at this time.

Beyond ensuring that you have correct vendor patches, which are written to ensure significant entropy in the randomly chosen DNS identification field, and UDP source ports, there needs to be another method to indicate that your DNS cache may be poisoned.

The two methods I find effective are to use the CAIDA project's DNS statistics collector (DSC), and to also deploy a focused Intrusion Detection Sensor (IDS) with Snort running directly on my DNS servers.

First of all, I would recommend becoming a registered snort user at www.snort.org in order to stay within about one month's release of the up to date snort signatures. Then, assuming you are running a UNIX based system for your DNS server(s), download the latest snort source code which as of this writing is snort-2.8.3.1.tar.gz.

1. Compile and install snort.
2. After installation, you should have a /etc/snort directory which contains a basic snort configuration file and the base set of rules.
3. Download the latest registered user rule set from snort.org and extact it inside the /etc/snort directory.
4. Now, start editing the /etc/snort/snort.conf file with your favorite text editor. In some installations, this file might be located in /etc/snort/rules.

Key variables you must set in order to get snort functioning are as follows with examples:

• HOME_NET = $eth0_ADDRESS
• EXTERNAL_NET = !$HOME_NET
• DNS_SERVERS = [172.16.1.1, 172.16.2.1]

Since this is a focused sensor, I would suggest that the home network (HOME_NET) be set to the address of the DNS server itself. The external network variable can simply be anything that is not the home network.

With regard to snort's preprocessors, you will need to keep frag3 and stream5 for both framentation and stream reassembly. Most importantly, the only remaining preprocessor you must have configured is the DNS preprocessor.

To keep the sensor memory usage low, I would disable (by commenting out) all other preprocessors, such as ftp_telnet, http, dcerpc etc. You are deploying a sensor focused on DNS so lets keep it optimized and looking at DNS traffic!

Next, go down to where the include statements reside, and comment out ALL of the includes listed except the one that reads: include $RULE_PATH/dns.rules

Now, test your configuration:

snort -p -c /etc/snort/snort.conf -A cmg -u_snort -g_snort -t/var/snort -l/var/snort/log

You should watch the output and make sure that there are no errors. Also, please note that the above command line uses the -p flag to disable promiscuous mode on your DNS server interface card. Again, let's remember that this is a focused sensor that is looking at the traffic going to/from this specific DNS system so your network card does NOT need to see other system traffic.

Also, to be as secure as possible, always run as a non-root user, hence the use of the -u_snort and -g_snort to change the effective running user and group id respectively.

Once you have checked that your configuration is operating as expected, then setup snort to run at boot time, and start the process as follows:

snort -pD -c/etc/snort/snort.conf -u_snort -g_snort -t/var/snort -l/var/snort/log

I would additionally suggest adding output alert_syslog into your configuration. If things are setup properly, the false positive (noise) level should be very low, so I personally syslog ALL alerts to the console of the UNIX system itself as well as the root user to make sure that if any IDS alerts show up, I will see them.

Following all these steps now gives you the equivalent of the canary in the coal mine. Your snort sensor is optimally configured to start sqawking if there are events such as a large number of DNS NXDOMAIN replies indicating potential cache posioning.

The additional bonus is that you will quickly find applications on your network that are misbehaving and incorrectly beating on your DNS infrastructure when they should not be!

Happy hunting.