Iptables Connection Tracking - TCP
A tcp connection is initiated via a three-way handshake involving a synchronization request from the client, a synchronization and an acknowledgement from the server, and finally an acknowledgement from the client. Subsequent traffic flowing between server and client is acknowledged in all cases. The sequence looks like:
Client Server
SYN ---->
<---- SYN+ACK
ACK ---->
<---- ACK
ACK ---->
.....
.....
SYN and ACK refer to flags set in the tcp header. There are also 32 bit sequence and acknowledgement numbers stored in the tcp header which are passed back and forth and updated during the session. To get connection tracking to work for a tcp connection you need a rule that looks something like this:
iptables -A INPUT -p tcp -m state –state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m state –state NEW,ESTABLISHED -j ACCEPT
Walkthrough
What we are going to do now is walk and talk through the establishment of a normal tcp connection and look at the state table at each stage:
-
Once an initial SYN is sent in the OUTPUT chain, and accepted by out rule that allows the NEW connection, the connection table entry may look something like:
tcp 6 119 SYN_SENT
src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 [UNREPLIED] src=207.46.230.218
dst=140.208.5.62 sport=80 dport=1311 use=1The tcp connection status is SYN_SENT and the connection is marked UNREPLIED.
-
We are now waiting for a SYN+ACK to arrive at which point the tcp connection state changes to SYN_RECV and the UNREPLIED disappears:
tcp 6 57 SYN_RECV
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 use=1 -
We are now waiting for the final part of the handshake, an ACK. When it is seen by the connection tracking module, we check that it’s sequence number matches the ACK of the SYN+ACK handshake from the server to the client. The tcp connection state now becomes ESTABLISHED and the state table entry is marked ASSURED (ASSURED connections are not dropped from the state table when the connection is under load). Here we see the ESTABLISHED connection:
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
Click below to read more …
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