Linux Firewalls - Michael Rash [122]
Now we restart psad with /etc/init.d/psad restart, and we are ready to simulate the attack against the webserver again. The first lynx command below (which is not malicious) shows that we have uninterrupted connectivity to the webserver, but the second command fails to elicit the 404 Not Found error because the malicious packet never reaches the webserver—it is dropped by fwsnort:
[ext_scanner]$ lynx http://71.157.X.X
Internal webserver; happy browsing
[ext_scanner]$ lynx http://71.157.X.X/Setup.php
HTTP request sent; waiting for response
A packet trace on the external interface of the iptables system gives more detail about what really happens on the wire. The attacker's TCP stack retransmits the packet that contains the string /Setup.php because the webserver TCP stack never receives it (and so never sends an acknowledgment back to the attacker's stack for this packet). Each retransmitted packet contains the string /Setup.php and so is dropped by iptables before it reaches the webserver. In the trace below, the packet retransmissions are displayed in bold. (Only three such packets are displayed, although TCP will continue to attempt to deliver the packet for two minutes.)
[iptablesfw]# tcpdump -i eth0 -l -nn port 80
13:32:24.839585 IP 144.202.X.X.59651 > 71.157.X.X.80: S 653660994:
653660994(0)
win 5840 13:32:24.841747 IP 71.157.X.X.80 > 144.202.X.X.59651: S 612132055: 612132055(0) ack 653660995 win 5792 13:32:24.868471 IP 144.202.X.X.59651 > 71.157.X.X.80: . ack 1 win 1460 13:32:24.869285 IP 144.202.X.X.59651 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 13:32:25.097233 IP 144.202.X.X.59651 > 71.157.X.X.80: P 1: 229(228) ack 1 win 1460 13:32:25.552535 IP 144.202.X.X.59651 > 71.157.X.X.80: P 1:229 (228) ack 1 win 1460 13:32:26.464527 IP 144.202.X.X.59651 > 71.157.X.X.80: P 1:229 (228) ack 1 win 1460 This covers the DROP response in fwsnort, but psad has also acted to instantiate a set of blocking rules against the attacker. If we now attempt once again to get the index.html page from the webserver on the attacking system, we are greeted with stark silence: [ext_scanner]$ lynx http://71.157.X.X HTTP request sent; waiting for response Indeed, psad has severed all communication with the attacker's IP address for one full hour. The DROP rules are added to the three psad blocking chains to which packets are jumped from the built-in INPUT, OUTPUT, and FORWARD filtering chains, thus providing an effective DROP stance against the attacker's IP address: [iptablesfw]# psad --fw-list [+] Listing chains from IPT_AUTO_CHAIN keywords... Chain PSAD_BLOCK_INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 144.202.X.X 0.0.0.0/0 Chain PSAD_BLOCK_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 144.202.X.X Chain PSAD_BLOCK_FORWARD (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 144.202.X.X 0 0 DROP all -- * * 144.202.X.X 0.0.0.0/0 DROP vs. REJECT Targets In the packet trace of the above section, the retransmission of the packet containing the string /Setup.php is a manifestation of the attempt to guarantee delivery of data that is built in to TCP after the DROP target refuses to forward the packet to the destination TCP stack. The TCP session is forced to close, rather ungracefully, after a time-out expires. However, fwsnort can use the iptables REJECT target instead of the DROP target so that the attacker's TCP stack receives a RST[66] in addition to not being able to forward the malicious packet through the iptables firewall: [iptablesfw]# --fwsnort --snort-sid 2281 --ipt-reset [+] Parsing Snort