Linux Firewalls - Michael Rash [116]
[iptablesfw]# grep SID2001842 /var/log/messages | tail -n 1
Jul 7 22:31:43 iptablesfw kernel: [1] SID2001842 IN=eth1 OUT=eth0 SRC=192.168.10.4
DST=234.50.X.X LEN=38 TOS=0x00 PREC=0x00 TTL=62 ID=36070 DF PROTO=UDP SPT=16408
DPT=53 LEN=18
Because we did not supply either the --ipt-drop or --ipt-reject command-line arguments to fwsnort when we translated the cache-poisoning signature, iptables made no effort to prevent the suspicious packet from exiting the network. We can confirm this by running a packet trace on the external interface of the firewall and executing the same Perl command above:
[iptablesfw]# tcpdump -i eth0 -l -nn port 53 and host 234.50.X.X -s 0 -X
tcpdump: verbose output suppressed, use -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:41:22.683862 IP 71.157.X.X.16414 > 234.50.X.X.53: [|domain]
0x0000: 4500 0026 64fc 4000 3e11 fce1 0000 0000 E..&d.@.>.......
0x0010: 0000 0000 401e 0035 0012 86e50537 7369 D0..@..5.....7si
0x0020: 7237 0363 6f6d r7.com \
In the tcpdump output shown in bold above are the hex codes that show the exact application layer data associated with the cache-poisoning signature. This proves the packet is forwarded through the iptables firewall.
But fwsnort does not need to remain complacent and just log the DNS cache-poisoning attack above. In this example, we instruct it to drop the DNS request to the cache-poisoning domain, redeploy the resulting iptables policy, simulate the request from the dnsserver system once again, and examine the iptables log:
[iptablesfw]# fwsnort --snort-sids 2001842 --ipt-drop
[+] Parsing Snort rules files...
[+] Found sid: 2001842 in bleeding-all.rules
Successful translation.
[iptablesfw]# /etc/fwsnort/fwsnort.sh
[+] Adding bleeding-all rules.
Rules added: 2
[dnsserver]$ perl -e 'print "\x057sir7\x03com"' | nc -u 234.50.X.X 53
[iptablesfw]# grep SID2001842 /var/log/messages |tail -n 1
Jul 7 22:33:42 fw kernel: [1] DRP SID2001842 IN=eth1 OUT=eth0 SRC=192.168.10.4
DST=234.50.X.X LEN=38 TOS=0x00 PREC=0x00 TTL=62 ID=36070 DF PROTO=UDP SPT=16408
DPT=53
LEN=18
This time, the logging prefix has changed. Instead of just
[1] SID2001842
we now have
[1] DRP SID2001842
The DRP string indicates that iptables has dropped the DNS request in addition to logging it. This is confirmed by once again running a packet trace on the external firewall interface and seeing that the request never makes it through.
Note
Instead of DROP and REJECT, fwsnort uses DRP and REJ because there is a 29-character limit imposed by the iptables LOG match for logging prefixes. You'll find additional information about what is going on behind the scenes with the --ipt-drop and --ipt-reject options in Chapter 11.
* * *
[62] 4 See http://isc.sans.org/presentations/dnspoisoning.php for a comprehensive write-up of the DNS cache-poisoning attack and the strategy used by the attackers.
Setting Up Whitelists and Blacklists
Any software that can block network communications based on application layer data should also be able to exclude certain networks or IP addresses from any blocking actions based on a whitelist. At the same time, it should be able to force all packets to or from certain networks or IP addresses to be dropped according to a blacklist.
Whitelists and blacklists are supported by fwsnort with the WHITELIST and BLACKLIST variables in the /etc/fwsnort/fwsnort.conf file. For example, to ensure that fwsnort never takes action against communications that originate from or are destined for the webserver (IP address 192.168.10.3 in Figure 1-2), and to DROP all packets to or from the IP address 192.168.10.200,[63] include the following lines in fwsnort.conf:
WHITELIST 192.168.10.3;
BLACKLIST 192.168.10.200;
When you use fwsnort to build the fwsnort.sh script, two new sections are added:
############