The resp option provided by the flexresponse and flexresponse2 Snort detection plug-ins allows Snort to actively respond to network traffic that has triggered a signature match. Available responses include sending TCP RST/ACK packets into a session in order to tear it down (recall that the flexresponse and flexresponse2 plug-ins always send RST/ACK packets instead of RST packets; see the discussion "RST vs. RST/ACK" on page 63), and generating ICMP Net, Host, or Port Unreachable packets in response to UDP traffic. The iptables REJECT target supports these functions through the arguments -j REJECT --reject-with tcp-reset for TCP connections, and -j REJECT --reject-with icmp-*-unreachable (where * can be net, host, or port) for UDP packets.
One difference in the REJECT target versus the Snort response capability is that TCP RST packets can only be sent to one side of a connection. That is, if a packet matches an iptables REJECT rule, a TCP RST packet will only be sent against the source IP address that is contained within the matching packet, and this IP address may either be the client or the server side of the connection. If the TCP stack never receives the incoming RST packet because of a local kernel-level filtering mechanism (or because an intermediate hop drops it), then the session will not be properly closed. Fortunately, however, the REJECT target also drops the matching packet, so the TCP session will not proceed any further.
NOTE A future version (or a patch provided by the fwsnort project) of the REJECT extension will support sending TCP RST packets to both sides of a TCP connection. If one side misbehaves and filters the incoming RST because it is trying to continue a TCP connection regardless of whether the other side tries to close it, then the RST sent in the opposite direction will still force the connection to close (presumably only one side is being unruly).
The following iptables command combines the use of the string match extension to RST any web sessions that contain the string "/etc/passwd":
[iptablesfw]# iptables -A INPUT -p tcp --dport 80 -m string --string "/etc/ passwd" --algo bm -j REJECT --reject-with tcp-reset
Additional detail on the usage of the REJECT target in conjunction with fwsnort rulesets can be found in Chapter 11.
TEARING DOWN "/ETC/PASSWD" WEB SESSIONS
Malicious systems can filter incoming RST or RST/ACK packets generated by remote iptables firewalls, and we will discuss this in depth in "DROP vs. REJECT Targets" on page 201. Here we briefly illustrate the REJECT target in action against an iptables firewall that is filtering the incoming TCP RST packet, we set up two systems (client and server) as follows: On the server system we use Netcat to run a TCP server on port 80, and on the client system we use Netcat to send the string "/etc/passwd" across to the server. On the server, iptables is configured to match the /etc/passwd string and RST the connection:
[server]# iptables -I INPUT 1 -p tcp --dport 80 -m string --string "/etc/ passwd" --algo bm -j REJECT --reject-with tcp-reset
On the client, the incoming RST packet is dropped before the local TCP stack receives it:
[client]# iptables -I INPUT 1 -p tcp --tcp-flags RST RST -j DROP
Now we fire up Netcat and tcpdump on the server system and send the /etc/ passwd string across to the server from the client. The packet at is the first RST packet from iptables on the server, and the remaining packets show that even though the client has filtered in the incoming RST, the session is unable to proceed because the packet that contained the /etc/passwd string was dropped.
When the client TCP stack retransmits the /etc/passwd packet over and over, iptables on the server responds to each packet yet again with another RST (see , for example):
[client]# echo "/etc/passwd" | nc 192.168.10.1 80
01:10:24.479149 IP 192.168.10.2.32655 > 192.168.10.1.80: S
2179395558:2179395558(0) win 5840 <mss 1460,sackOK,timestamp 47589526
01:10:24.479216 IP 192.168.10.1.80 > 192.168.10.2.32655: S 2434738187:2434738187(0) ack 2179395559 win 5792 <mss 1460,sackOK,timestamp 10356968 47589526>
01:10:24.481620 IP 192.168.10.2.32655 > 192.168.10.1.80 <nop,nop,timestamp 47589527 10356968>
01:10:24.481843 IP 192.168.10.1.80 > 192.168.10.2.32655 5792 <nop,nop,timestamp 10356969 47589527> 01:10:24.488910 IP 192.168.10.2.32655 > 192.168.10.1.80 5840 <nop,nop,timestamp 47589527 10356968> ©01:10:24.488941 IP 192.168.10.1.80 > 192.168.10.2.32655: R 2434738188:2434738188(0) win 0
01:10:24.490785 IP 192.168.10.2.32655 > 192.168.10.1.80 <nop,nop,timestamp 47589528 10356969>
01:10:24.490820 IP 192.168.10.1.80 > 192.168.10.2.32655 5792 <nop,nop,timestamp 10356971 47589527> 01:10:24.496571 IP 192.168.10.2.32655 > 192.168.10.1.80 <nop,nop,timestamp 47589530 10356971>
01:10:24.683462 IP 192.168.10.2.32655 > 192.168.10.1.80 5840 <nop,nop,timestamp 47589578 10356971> ©01:10:24.683506 IP 192.168.10.1.80 > 192.168.10.2.32655: R 2434738190:2434738190(0) win 0
. ack 1 win 5840 P 1:2(1) ack 1 win P 1:13(12) ack 1 win
. ack 2 win 5840 P 2:3(1) ack 1 win . ack 3 win 5840 P 1:13(12) ack 3 win
Was this article helpful?