Linux Firewalls - Michael Rash [123]
[+] Found sid: 2281 in web-php.rules
Successful translation
[+] Logfile: /var/log/fwsnort.log
[+] Iptables script: /etc/fwsnort/fwsnort.sh
[iptablesfw]# /etc/fwsnort/fwsnort.sh
[+] Adding web-php rules
Rules added: 4
Now, when we launch the attack against the webserver again (after clearing the psad blocking rules from the previous attack with psad --Flush), our TCP stack receives a RST packet that forces the session to close:
[ext_scanner]$ lynx http://71.157.X.X/Setup.php
Alert! Unexpected network read error. Connection aborted.
Can't access 'http://71.157.X.X/Setup.php'
Alert! Unable to access document.
A packet trace captured on the external interface of the iptables firewall clearly shows the RST packet (in bold below) being sent back to the attacker:
[iptablesfw]# tcpdump -i eth0 -l -nn port 80
21:39:13.053057 IP 144.202.X.X.52092 > 71.157.X.X.80: S 1449291682:
1449291682(0)
win 5840 21:39:13.053177 IP 71.157.X.X.80 > 144.202.X.X.52092: S 1384965123: 1384965123(0) ack 1449291683 win 5792 21:39:13.073190 IP 144.202.X.X.52092 > 71.157.X.X.80: . ack 1 win 1460 21:39:13.078382 IP 144.202.X.X.52092 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 21:39:13.078442 IP 71.157.X.X.80 > 144.202.X.X.52092: R 1384965124:1384965124(0) win 0 Intercepting the Incoming RST In the attack example above, the client side of the TCP connection receives a RST, which is subsequently honored by the local TCP stack. But what if the attacker is running an operating system that contains a firewall (such as iptables) capable of filtering the incoming RST packet before the local TCP stack can see it? Will the session continue as if nothing happened? Fortunately, the answer is no. Although the session remains open (because the REJECT target only sends the RST packet to the source IP address that triggers the REJECT match), the offending packet is also dropped at the same time by iptables. Hence, this scenario becomes similar to the one in Combining fwsnort and psad Responses on page 199, where the DROP target is used instead of the REJECT target. Because the operating system run by the attacker in this case is Linux, we can investigate what happens when we filter the incoming RST after sending the attack with the lynx client. First we add an iptables rule on the ext_scanner system to filter all incoming RST packets from the target and then rerun the attack: [ext_scanner]# iptables -I INPUT 1 -p tcp --tcp-flags RST RST -s 71.157.X.X -j DROP [ext_scanner]$ lynx http://71.157.X.X HTTP request sent; waiting for response This results in a packet trace that shows the retransmission of the packet that contains the /Setup.php string by the attacker's TCP stack, which in turn indicates that the stack never receives the RST packet generated by the remote iptables firewall that protects the webserver. Because each retransmitted packet contains the same malicious string, every such packet matches the REJECT ruleset up by fwsnort all over again, so that each packet elicits a new RST from iptables. And, because the RST filtering rule is still active on the attacker's system, each RST is again never seen by the attacker's TCP stack. The RST packets are displayed in bold below. (Note that no RST packet contains the ACK bit.) [iptablesfw]# tcpdump -i eth0 -l -nn port 80 22:14:51.077639 IP 144.202.X.X.37788 > 71.157.X.X.80: S 3703393615:3703393615(0) win 5840 22:14:51.080797 IP 71.157.X.X.80 > 144.202.X.X.37788: S 3646903380:3646903380(0) ack 3703393616 win 5792 22:14:51.094852 IP 144.202.X.X.37788 > 71.157.X.X.80: . ack 1 win 1460 22:14:51.098181 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460