Re: Iptables SYN and NEW packets

From: Baho Utot (baho-utot_at_philippines-island.org)
Date: 11/23/04 

Date: Tue, 23 Nov 2004 13:11:59 GMT

On Tue, 23 Nov 2004 03:11:12 -0800, Luke Robertson wrote:

> Baho Utot <baho-utot@philippines-island.org> wrote in message
> news:<pan.2004.11.22.14.06.46.580231@philippines-island.org>...
>> On Sun, 21 Nov 2004 21:37:24 -0800, Luke Robertson wrote:
>>
>> > Hi,
>> >
>> > Just a really quick question.
>> > What is the difference between a SYN packet, and a NEW state? If I
>> > were to match for either of those, would I get the same result?
>>
>> SYN is a tcp packet with the SYNC bit set NEW is a connection relating
>> to iptables
>>
>> example follows:
>>
>> #
>> # Connection state bypass
>> #
>> $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
>> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> What does the SYNC bit do?
> Why in your first iptables line do you match a new connection that is
> not SYN? Is it not a good idea to block SYN?

Because it is not a "new/not existing" connection. If you want iptables
to only match "new/not existing" connections then you need to do what I
have shown above. See Iptables Tutorial 1.1.6 by Oskar Andreasson which
will explain:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html

>From the Tutorial:

A TCP connection is always initiated with the 3-way handshake, which
establishes and negotiates the actual connection over which data will be
sent. The whole session is begun with a SYN packet, then a SYN/ACK packet
and finally an ACK packet to acknowledge the whole session establishment.
At this point the connection is established and able to start sending
data. The big problem is, how does connection tracking hook up into this?
Quite simply really.

And

B.2. State NEW packets but no SYN bit set

There is a certain feature in iptables that is not so well documented and
may therefore be overlooked by a lot of people (yes, including me). If you
use state NEW, packets with the SYN bit unset will get through your
firewall. This feature is there because in certain cases we want to
consider that a packet may be part of an already ESTABLISHED connection
on, for instance, another firewall. This feature makes it possible to have
two or more firewalls, and for one of the firewalls to go down without any
loss of data. The firewalling of the subnet could then be taken over by
our secondary firewall. This does however lead to the fact that state NEW
will allow pretty much any kind of TCP connection, regardless if this is
the initial 3-way handshake or not. To take care of this problem we add
the following rules to our firewalls INPUT, OUTPUT and FORWARD chain:

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \
     --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
    
    
Caution

The above rules will take care of this problem. This is a badly documented
behavior of the Netfilter/iptables project and should definitely be more
highlighted. In other words, a huge warning is in its place for this kind
of behavior on your firewall.

Note that there are some troubles with the above rules and bad Microsoft
TCP/IP implementations. The above rules will lead to certain conditions
where packets generated by Microsoft products gets labeled as state NEW
and hence get logged and dropped. It will however not lead to broken
connections to my knowledge. The problem occurs when a connection gets
closed, the final FIN/ACK is sent, the state machine of Netfilter closes
the connection and it is no longer in the conntrack table. At this point
the faulty Microsoft implementation sends another packet which is
considered as state NEW but lacks the SYN bit and hence gets matched by
the above rules. In other words, don't worry to much about this rule, or
if you are worried anyways, set the --log-headers option to the rule and
log the headers too and you'll get a better look at what the packet looks
like.

Relevant Pages

  • Re: is google probing my ports?
    ... >>> Connecting to groups.google.com, I notice in syslog, ... > what to slightly open up in my iptables then. ... to an established connection - and treated according to the rest of the ... it is again a packet that came "too late"... ...
    (comp.security.firewalls)
  • Re: peer to peer messaging
    ... attempts to open a connection to port 80 of the server at that IP address. ... For example a packet from my machine might have source IP ... Packets from the sever to my laptop would have those reversed. ...
    (comp.lang.java.programmer)
  • RE: managing a SYN flood
    ... the server sees that, it responds with a packet with SYN and ACK set. ... Connection tables are often of fixed size. ...
    (Security-Basics)
  • RE: managing a SYN flood
    ... the server sees that, it responds with a packet with SYN and ACK set. ... Connection tables are often of fixed size. ...
    (Security-Basics)
  • Re: Doubts with iptables (or ipchains)
    ... With iptables use the state module. ... > done with ipchains (using some alternative ... > of the connection would protect my LAN? ... Why would 'a packet' be 52 bytes? ...
    (comp.os.linux.security)
Quantcast