Iptables Connection Tracking - TCP
Connection tracking’s perspective on the state table
We just talked a lot about tcp connection states. Now let’s think about this from the perspective of the connection tracking:
Connection tracking only knows about NEW,ESTABLISHED,RELATED and INVALID, classified as described above. To quote Joszef Kadlecsik, who helped me out with a confusion I had initially about this very subject:
When a packet with the SYN+ACK flags set arrrives in response to a packet with SYN set the connection tracking thinks: “I have been just
seeing a packet with SYN+ACK which answers a SYN I had previously seen, so this is an ESTABLISHED connection.”
The important point here is that the conntrack states are not equivalent to tcp states. We have already seen that a connection doesn’t achieve the tcp connection status of ESTABLISHED until the ACK after the SYN+ACK has been seen by the connection tracking module.
The representation of the tcp connection states in the state table is purely for timeouts. You can prove this to yourself by sending an ACK packet through your firewall to a non-existent machine (so that you don’t get the RST back). It will create a state table entry no problem because it it is the first packet of a connection and so is treated as NEW (the entry will not be marked as ASSURED though). Checkpoint’s Firewall-1 version 4.1 SP1 allows connection initiation by ACK packets too (see Lance Spitzner’s whitepaper for details).
In the light of the fact that ACK packets can create state table entries, the following contribution from Henrik Nordstrum is insightful: To make sure that NEW tcp connections are packets with SYN set, use the following rule:
iptables -A INPUT-p tcp ! –syn -m state –state NEW-j DROP
Note that doing this will prevent idle sessions from continuing once they have expired from the conntrack table. In the normal “relaxed” view such connections initiated from the correct direction (i.e. the direction you allow NEW packets through) can normally continue even if expired from conntrack, provided that the first data/ack packet that resumes the connection comes from the correct direction.
Timeouts
Something to note is that timeouts are reset to the maximum each time a connection sees traffic. Timeouts are set in the kernel at compile time.
Connection Termination
Connection termination occurs in two ways. Natural termination at the end of a session occurs when the client sends a packet with the FIN and ACK flags set. The closure proceeds as follows:
Client Server
.....
.....
FIN+ACK ---->
<---- ACK
<---- FIN+ACK
ACK ---->
Sometime during, or at the end of this sequence the state table connection status changes to TIME_WAIT and the entry is removed after 2 minutes by default.
Another way for connection termination to occur is if either party sends a packet with the RST (reset) flag set. RST’s are not acknowledged. In this case the state table connection status changes to CLOSE and times out from the state table after 10 seconds. This often happens with http entries, where the server sends an RST after a period of inactivity.
Recommended Reading
Pages: 1 2
hi
i am looking for redirect TCP connection if number of connection exceed 100 is their any way i rediect packets as number of connection exceed more then 100
please reply soon
thnaks
Himanshu Nagpal
Network Administrator
Comment by Himanshu Nagpal — February 21, 2006 @ 11:59 am
Here’s a way to limit connections to 100, with a maximum of 10 per second. Is this what you had in mind?
The default here is to drop the extra connections but you could do something else.
iptables -N syn-flood-$iface
iptables -A INPUT -i $iface -p tcp –syn -j syn-flood-$iface
iptables -A syn-flood-$iface -m limit –limit 10/s –limit-burst 100 -j RETURN
iptables -A syn-flood-$iface -j DROP
Best,
James
Comment by James Stephens — February 21, 2006 @ 12:38 pm
Hi
I wonder if you know of any way to redirect only the tcp connections with a given payload at the beginning of the first data packet. I try to redirect only the CONNECT calls to a webproxy.
Best regards
Matthias
Comment by Matthias Loepfe — February 28, 2006 @ 9:33 am
Matthias,
Hmmm. Tricky to examine the payload.
There’s a string match patch, detailed here:
http://www.netfilter.org/projects/patch-o-matic/pom-extra.html#pom-extra-string
An example would be:
iptables -A INPUT -m string –string ‘*.exe’ -j REDIRECT
.. which redirects upon locating the string ‘.exe’ in the payload.
Will that do?
Best,
James
Comment by James Stephens — February 28, 2006 @ 11:17 am
Hi James
Sorry for the long delay of this answer! I was working on other projects..
No. I had tried this out before writing to you. I think it is impossible to do what I wanted, because of the way TCP/IP sessionhandling works.
The routing/redirect decission must be made on the first packet and then all the following will the handled the same way. But the first payload packet is the third tcp packet in the session, what means it would be possible to drop the connection but not to redirect the already established one.
Thaks anyway for your help
regards
Matthias
Comment by Matthias Loepfe — March 17, 2006 @ 7:49 am
Matthias,
Hi. Yes I think you are right. There’s no way to do it.
Best,
James
Comment by James Stephens — March 20, 2006 @ 8:05 pm
I was just wondering, does anyone know the meaning of “use=1″ field visible in each and every output? For example:
tcp 6 431995 ESTABLISHED
src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 src=207.46.230.218
dst=140.208.5.62 sport=80 dport=1311 [ASSURED] use=1
Thanks in advance for any help.
bc
Comment by bc — May 31, 2006 @ 10:07 pm
With your ruleset I was finding at some webservers but not others my client-side FIN-ACK from Firefox-1.5.0.5 were being logged & dropped by the firewall. I am presuming the server sent the final packet in an envelope stamped “Your done, I’m outta here” (FIN-ACK), causing IP to tear the connection down and my browser’s FIN-ACK response output to no longer be from an ESTABLISHED connection. I added a rule to accept packets with those flags, and send them anyway, but it seems a bit cludgy. Comments?
Comment by Paul Rogers — August 13, 2006 @ 12:54 am
i need some help on network security,i also heard ab the people who cracks the pix security if u know some thing related to the topic please let me know
thanks
Tarun
Comment by tarun — April 19, 2007 @ 4:50 am
Hi James,
I have a problem with this iptables entry.
iptables -A INPUT -p tcp ! -–syn -m state –-state NEW -j DROP
Every packet with a syn will be let through even the synack. But how can i build a rule that only allows syn with state new (without syn+ack and state new)?
I tried this but it wont work.
iptables -A INPUT -p tcp ! -–tcp-flags SYN SYN -m state –-state NEW -j DROP
Would you help me pls?
regards
Jens
Comment by Jens — September 6, 2007 @ 11:00 am