Protect your network against mailicious websites

Internet is a dangerous place. And more often also very controversial, just like the following article. Today I’m going to describe a little bit controversial way how to protect our network against malicious websites by changing replies to DNS requests to these sites.

This article is not supposed to discuss moral aspects of network neutrality. It only shows a way how could be something done using a little bit of Linux. You can use this article and take the whole thing further or just ignore it.

The situation is as follow. Let’s say we have a network, where we have our recursive DNS server managed by us. It doesn’t matter wheter our clients use our DNS server via DHCP assignment or by manually setting the correct server. Provided if we use Bind (or how it’s called either) as a DNS server we can affect the responses our clients receive.

We are going to use the DNS-BH Malware Domain Blocklist project. It collects infos about suspicious websites and then regulary updates these informations in Bind and MS DNS Server format. First, let’s create the zone file for these domains. I’m currently using this file stored in /etc/bind/db.block.

$TTL    86400   ; one day
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2013050201       ; serial number YYMMDDNN
                        28800   ; refresh  8 hours
                        7200    ; retry    2 hours
                        864000  ; expire  10 days
                        86400 ) ; min ttl  1 day
                NS      ns1.example.com.

                A       127.0.0.1
                AAAA    ::1

*       IN      A       127.0.0.1
*       IN      AAAA    ::1

Of course, you can change the info in zone file as you wish.

The domain list in form for Bind is downloaded from DNS-BH. This configuration file has a disadvantage, because it has incorrect path to our zone file. Therefore we create a script, which will download the list, update the confing and reload the server. We can run it periodically at night, e.g. from Cron.

#!/bin/bash

wget -O /etc/bind/named.conf.block http://mirror1.malwaredomains.com/files/spywaredomains.zones
sed -i 's/\/etc\/namedb\/blockeddomain.hosts/\/etc\/bind\/db.block/' /etc/bind/named.conf.block
awk '{ if($0 !~ /^\/\//) { for(i=1;i< =NF;i++){ if($i ~ /zone/){ print " "$(i+1)" "; } } } }' /etc/bind/named.conf.block | tr -d "\"" > /etc/bind/blockeddomains.txt
/usr/sbin/rndc reload

At the end of /etc/bind/named.conf we add following line

include "/etc/bind/named.conf.block";

and run our script. By this the new domainlist will be downloaded, parsed to our format and server will be reloaded. The whole functionality can be tested e.g. by dig. In this case, 172.17.110.7 is the IP address of our DNS server.

lukas@adminstation ~ $ dig @172.17.110.7 yunaks.ru

; < <>> DiG 9.9.2-P2 < <>> @172.17.110.7 yunaks.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 38186
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;yunaks.ru.			IN	A

;; ANSWER SECTION:
yunaks.ru.		86400	IN	A	127.0.0.1

;; AUTHORITY SECTION:
yunaks.ru.		86400	IN	NS	ns1.example.com

;; ADDITIONAL SECTION:
ns1.example.com.	3600	IN	A	172.17.110.7

;; Query time: 0 msec
;; SERVER: 172.17.110.7#53(172.17.110.7)
;; WHEN: Tue Nov 12 22:43:57 2013
;; MSG SIZE  rcvd: 145

If you were attentive enough, you could see that after the update script there is one new file - blockeddomains.txt. It's a list of the blocked domains, which we can use to make statistics about clients accessing them. If we have query logging turned on into /var/cache/bind/bind9-query.log, that can be easily done.

lukas@adminstation ~ $ fgrep -f /etc/bind/blockeddomains.txt /var/cache/bind/bind9-query.log
12-Nov-2013 21:41:53.851 client 1.2.3.4#53859: query: i.txtsrving.info IN A +
12-Nov-2013 21:41:54.084 client 1.2.3.4#51561: query: i.txtsrving.info IN A +
12-Nov-2013 21:42:15.117 client 1.2.3.4#48011: query: www.dhgate.com IN A +
12-Nov-2013 21:42:15.139 client 1.2.3.4#60612: query: www.dhgate.com IN AAAA +
...

Processing the statistics is now up to you 🙂

Hope today’s article was useful to you.