Blocking Malware with DNS Sinkhole
The DNS sinkhole method can be used to prevent malicious software from communicating with the command center or to detect infected systems. The sinkhole method can also be used to detect or neutralize the impact of botnets. In this article, the use of the DNS sinkhole method to prevent malware in corporate networks is discussed.
The logic of the method is to prevent the malware from deciphering the real IP address of the domain it wants to access by giving fake answers to DNS requests. An example configuration for this can be obtained by following the steps below.
On a system with Linux installed (Ubuntu in the example)
Bind DNS server is installed with the “apt-get install bind9” command. Then respectively
“mkdir /etc/bind/zones”
The “nano /etc/bind/zones/malware.db” commands are run and a record as follows is entered in the content of the blacklist.host file.
$TTL 3600
@ IN SOA ns1.malware.com. root.malware.com. (2012041615 10800 3600 604800 86400)
INNS ns1.malware.com.
INNS ns2.malware.com.
IN A 192.168.41.1
* IN A 192.168.41.1
Depending on the configuration, the address to which the malware will be directed is entered instead of 192.168.41.1 in the last two lines. In addition, the access rights for the bind user of the newly created zones directory must be "rwx". For this process
“chown bind /etc/bind/zones”
“chmod u+rwx /etc/bind/zones” commands can be used.
Moreover
The accuracy of the record created can be checked with the “named-checkzone malware.com /etc/bind/zones/malware.db” command.
Later
The domain names that you want to sinkhole are added to the “/etc/bind/named.conf.local” file in the following format.
zone "malware.com" {
type master;
file "/etc/bind/zones/malware.db";
};
zone "malicious.com" {
type master;
file "/etc/bind/zones/malware.db";
};
Finally
With the “service bind9 restart” command, the bind9 service is restarted and made ready for use. In this section, configuring the Bind DNS server only as a sinkhole is explained, and in order to provide valid answers to ordinary DNS requests, the necessary settings must be made separately according to the network configuration.
Whether the DNS server is working properly or not can be checked on a Linux system with the dnsutils package installed.
It can be checked with the command “dig malware.com @192.168.41.142”. Malware.com here should be an address in the blacklist, and 192.168.41.142 should be the address of the DNS server. The output of this command with the configuration in the example is as follows.
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> malware.com @192.168.41.142
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50892
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;malware.com. IN A
;; ANSWER SECTION:
malware.com. 3600 IN A 192.168.41.1
;; AUTHORITY SECTION:
malware.com. 3600 IN NS ns2.malware.com.
malware.com. 3600 IN NS ns1.malware.com.
;; ADDITIONAL SECTION:
ns1.malware.com. 3600 IN A 192.168.41.1
ns2.malware.com. 3600 IN A 192.168.41.1
;; Query time: 2 msec
;; SERVER: 192.168.41.142#53(192.168.41.142)
;; WHEN: Wed Apr 23 13:23:45 2014
;; MSG SIZE rcvd: 113
As seen in the response, when the DNS request was made, the address was resolved as 192.168.41.1.
Verification can also be made by changing the DNS server to 192.168.41.142 in the network settings of the Windows machine and trying to access an address in the blacklist.
Domains that need to be blacklisted can be accessed at “http://www.malwaredomains.com/”. Access can be prevented by matching domain names in the blacklist with inaccessible IP addresses such as "0.0.0.0", or infected systems can be detected by directing them to a local machine and examining the traffic of this machine, as in the example. During the detailed examination of malicious traffic, the articles "Management of Malware Traffic with Fake Services" and "Routing and Examining Malware Traffic Using SSL" can be used.
