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)
3 Recall from Chapter 3 that this RST packet from iptables does not have the ACK bit set because the malicious packet that triggered the rule match is part of an established TCP connection and therefore itself has the ACK bit set, and RFC 793 mandates that any RST packet generated in response to such a packet will not set the ACK bit. A RST/ACK is sent only if the previously received packet did not set the ACK bit.
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 <mss 1460,sackOK,timestamp 3247837780 0,nop,wscale 2>
22:14:51.080797 IP 71.157.X.X.80 > 144.202.X.X.37788: S 3646903380:3646903380(0) ack 3703393616 win 5792 <mss 1460,sackOK,timestamp 2302908153 3247837780,nop,wscale 2>
22:14:51.094852 IP 144.202.X.X.37788 > 71.157.X.X.80: . ack 1 win 1460 <nop,nop,timestamp 3247837784 2302908153>
22:14:51.098181 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 <nop,nop,timestamp 3247837785 2302908153> 22:14:51.098233 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0
22:14:51.313974 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 <nop,nop,timestamp 3247837839 2302908153> 22:14:51.314043 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0
22:14:51.748920 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 <nop,nop,timestamp 3247837947 2302908153> 22:14:51.748969 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0
22:14:52.610322 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 <nop,nop,timestamp 3247838163 2302908153> 22:14:52.610396 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0
The NF_DROP Macro
A look at the source code confirms that the iptables REJECT target drops matching packets. Specifically, if you look at the file linux/net/ipv4/netfilter/ ipt_REJECT.c in the kernel sources, you will see the following return statement at three places in the reject() function (and there are no other return statements):
Thus, the macro NF_DROP is the only possible return value for the reject() function, and it instructs iptables to drop any matching packet on the floor. A matching packet is prevented from continuing up the stack or being forwarded on to its intended destination. Therefore, in our attack example, even if the attacker filters the incoming RST, the webserver still never sees the incoming /Setup.php attack.
Was this article helpful?