NEW vs INVALID

NEW vs INVALID

[Jens Lechtenbörger]

Hi there,

using stateful packet matching I wonder how an INVALID tcp packet is
defined.  In particular, I set up a rule to log inbound NEW ssh
connections to port 22:
iptables -A INPUT  -m state --state NEW -p TCP --dport 22 -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: "

What confuses me, is that this rule not only logs initial SYN
packets but also (initial) packets with SYN and FIN set. 
I thought that such packets should be INVALID...
Is this a bug or a feature?

Jens

Re: NEW vs INVALID

[Anders Fugmann]

Jens Lechtenbörger wrote:
> Hi there,
> 
> using stateful packet matching I wonder how an INVALID tcp packet is
> defined.  In particular, I set up a rule to log inbound NEW ssh
> connections to port 22:
> iptables -A INPUT  -m state --state NEW -p TCP --dport 22 -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: "
> 
> What confuses me, is that this rule not only logs initial SYN
> packets but also (initial) packets with SYN and FIN set. 
> I thought that such packets should be INVALID...
SYN-FIN??? Are you sure of this? I would suspect some ACK-FIN when the 
connection closes, but not SYN-FIN.

Anyhow, AFAIK, the INVALID target only matches  ackets which are 
malformed. a SYN-FIN packets is not malformed as such. (But yes, SYN-FIN 
is an illegal combination, and should be dropped, though this is not the 
purpose of the INVALID match (IMHO, this can easily be done using 
standard netfilter rules).

Regards
Anders Fugmann

-- 
Neo: 'Can you fly that thing?'
Trinity: 'Not yet'.
$ apt-get install pilot-prg-v212helicopter.

Re: NEW vs INVALID

[Cedric Blancher]

Le lun 30/09/2002 à 12:18, Jens Lechtenbörger a écrit :
> using stateful packet matching I wonder how an INVALID tcp packet is
> defined.  In particular, I set up a rule to log inbound NEW ssh
> connections to port 22:
> iptables -A INPUT  -m state --state NEW -p TCP --dport 22 -j LOG
> --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: "
> What confuses me, is that this rule not only logs initial SYN
> packets but also (initial) packets with SYN and FIN set. 
> I thought that such packets should be INVALID...
> Is this a bug or a feature?

Definitly a feature ;)

States a completly different concept than TCP connection, for it must
also apply to UDP, or other layer 4 protocols, which can be
connectionless.

A NEW packet is a packet for which Netfilter cannot find an existing
state in conntrack table. This packet, if TCP, can be SYN, as it should,
but also ACK, or any flag combination you want. This packet, if allowed,
create a state that will match following packets.

An INVALID packet is a packet for which Netfilter cannot guess its
state. Most of the time, it is ICMP errors that cannot be associated
(i.e. RELATED) to an existing connection. You can also have ressources
lack or bugs.

So, a packet why strange flags combination, such as SYN+FIN, is wrong
from TCP point of vue, but is a valid packet from state tracking point
of vue. This behaviour allows you to define exactly want you want to
match. As an example, you can consider match Xmas or Null scans :

	iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL ALL -j LOG
	iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL NONE -j LOG

To be strict, your iptables command should be :

	iptables -A INPUT  -m state --state NEW -p TCP --dport 22 --syn -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: "

My 2 cents of euro.

-- 
Cédric Blancher
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: NEW vs INVALID

[Jens Lechtenbörger]

Cedric Blancher <blancher@cartel-securite.fr> writes:

> States a completly different concept than TCP connection, for it must
> also apply to UDP, or other layer 4 protocols, which can be
> connectionless.
> 
> A NEW packet is a packet for which Netfilter cannot find an existing
> state in conntrack table. This packet, if TCP, can be SYN, as it should,
> but also ACK, or any flag combination you want. This packet, if allowed,
> create a state that will match following packets.
> 
> An INVALID packet is a packet for which Netfilter cannot guess its
> state. Most of the time, it is ICMP errors that cannot be associated
> (i.e. RELATED) to an existing connection. You can also have ressources
> lack or bugs.

Thank you very much for this explanation!

> [...]
> 
> To be strict, your iptables command should be :
> 
> 	iptables -A INPUT  -m state --state NEW -p TCP --dport 22 --syn -j LOG --log-level 5 --log-prefix "IPTABLES: Legal NEW TCP: "
> 

In fact, I had a similar command, but this again allows
SYN+FIN-packets.

What I am doing now is
 
 "--state NEW --tcp-flags SYN,ACK,FIN,RST SYN"...

I was just wondering about the meaning of INVALID, which you
explained above.

Thanks again,

Jens

Re: NEW vs INVALID

[Cedric Blancher]

Le lun 30/09/2002 à 16:39, Anders Fugmann a écrit :
> Anyhow, AFAIK, the INVALID target only matches  ackets which are 
> malformed. a SYN-FIN packets is not malformed as such. (But yes, SYN-FIN 
> is an illegal combination, and should be dropped, though this is not the 
> purpose of the INVALID match (IMHO, this can easily be done using 
> standard netfilter rules).

By the way, I was wondering why --syn was "only" equivalent to :
	--tcp-flags SYN,ACK,RST SYN

And not to :
	--tcp-flags SYN,ACK,RST,FIN SYN

I know it is definitly easy to filter according to such criterias, but I
was just wondering if there were a good reason why --syn should match
such packets (maybe should have asked netfilter-devel).

-- 
Cédric Blancher
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: NEW vs INVALID

[Anders Fugmann]

Cedric Blancher wrote:
> By the way, I was wondering why --syn was "only" equivalent to :
> 	--tcp-flags SYN,ACK,RST SYN
> 
> And not to :
> 	--tcp-flags SYN,ACK,RST,FIN SYN
> 
The tcp-flags would then not match packets with the SYN & FIN bits set, 
which is actually connection request, with should be closed immdiatly 
after opening. The syn-fin is widly used to scan hosts, and should be 
dropped. But still - it is a connection request and should therfore be 
caught by --syn.

Regards
Anders Fugmann

-- 
Neo: 'Can you fly that thing?'
Trinity: 'Not yet'.
$ apt-get install pilot-prg-v212helicopter.

Re: NEW vs INVALID

[Martijn Klingens]

On Monday 30 September 2002 17:50, Jens Lechtenbörger wrote:
> In fact, I had a similar command, but this again allows
> SYN+FIN-packets.
>
> What I am doing now is
>
>  "--state NEW --tcp-flags SYN,ACK,FIN,RST SYN"...

This makes quite some sense, but it makes me wonder what the use is of the 
'--syn' option. Also, does that mean I have to update my firewall script if I 
want to achieve tighter security? I guess so :(
-- 
Martijn

Re: NEW vs INVALID

[Cedric Blancher]

Le mar 01/10/2002 à 11:05, Anders Fugmann a écrit :
> Cedric Blancher wrote:
> > By the way, I was wondering why --syn was "only" equivalent to :
> > 	--tcp-flags SYN,ACK,RST SYN
> > And not to :
> > 	--tcp-flags SYN,ACK,RST,FIN SYN
> The tcp-flags would then not match packets with the SYN & FIN bits set, 
> which is actually connection request, with should be closed immdiatly 
> after opening.

Well, as SYN,FIN packet is quite nonsense, for a FIN is destined to
close an established connection (both parts) or spot a connection
establishment (client) and thus should not be received on CLOSED, LISTEN
or SYN-SENT, for while connection is not established, server sends RST.

But RFC does not cover the SYN,FIN case. Well, in fact, if we're in
LISTEN state, we are likeley to stop processing flags when we see SYN
set (and RST,ACK not set), and so do not check FIN bit value. But it
tells that a FIN should be discarded if received on CLOSED, LISTEN or
SYN-SENT state.

| eighth, check the FIN bit,
|
|      Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT
|      since the SEG.SEQ cannot be validated; drop the segment and
|      return.

> The syn-fin is widly used to scan hosts, and should be 
> dropped.

Yeah it surely should ;) By the way, this harmless, for there's no valid
application for SYN,FIN packets.

> But still - it is a connection request and should therfore be 
> caught by --syn.

I do not agree on the meaning of such a packet, but it is true that RFC
does not explicitly forbid this kind of flags setting, although it is
clear that a --syn packet must have RST and ACK set to 0 (for RST and
ACK value are checked _before_ SYN one). So, it can be understood this
way, and this should close the debate.

Ahhhh, the art of understanding RFCs :))))

-- 
Cédric Blancher
Consultant en sécurité des systèmes et réseaux  - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE