INVALID state

INVALID state

[Nemeth Denes]

Dear all

Could someone help me to identify the difference between
the following 3 rules.

1. iptables -t mangle -A PREROUTING -p tcp ! --syn -m state --state 
INVALID -j DROP
2. iptables -A INPUT -p tcp ! --syn -m state --state INVALID -j DROP
3. iptables -A INPUP -p tcp ! --syn -m conntrack --cstate INVALID -j DROP

Many thanks

Re: INVALID state

[Mart Frauenlob]

On 28.02.2010 10:31, netfilter-owner@vger.kernel.org wrote:
> Dear all
> 
> Could someone help me to identify the difference between
> the following 3 rules.
> 
> 1. iptables -t mangle -A PREROUTING -p tcp ! --syn -m state --state
> INVALID -j DROP
> 2. iptables -A INPUT -p tcp ! --syn -m state --state INVALID -j DROP
> 3. iptables -A INPUP -p tcp ! --syn -m conntrack --cstate INVALID -j DROP


take a look at this picture, to see, that mangle/PREROUTING may catch
different things than filter/INPUT:
http://jengelh.medozas.de/images/nf-packet-flow.png

Generally filtering (ACCEPT/DROP/REJECT) should be done in the filter
table, unless there is a good reason (and understanding) to do it
otherwise (i.e. the nat table does not allow DROP).
The mangle table is generally meant for packet manipulation. i.e.
marking, changing ip settings, etc...

conntrack supports all states that the state match does, plus some more.


More in general:
imho the '! --syn' is quite unnecessary, correct me if I'm wrong.

Best regards

Mart

Re: INVALID state

[Nemeth Denes]

Thanks for the help.

Assuming that the a packet reach the 1,2,3 rules is there a
difference regards matching between "-m state --state INVALID"
applied in 1 and 2 rules or the "-m conntrack --cstate INVALID"
statements?

I am not sure about ! --syn, I read it in the chaostables doc
http://jengelh.medozas.de/documents/Chaostables.pdf

Best wishes,
Denes


What I do not really understand is that is there a difference
between the behavior of the

Mart Frauenlob wrote:
> On 28.02.2010 10:31, netfilter-owner@vger.kernel.org wrote:
>   
>> Dear all
>>
>> Could someone help me to identify the difference between
>> the following 3 rules.
>>
>> 1. iptables -t mangle -A PREROUTING -p tcp ! --syn -m state --state
>> INVALID -j DROP
>> 2. iptables -A INPUT -p tcp ! --syn -m state --state INVALID -j DROP
>> 3. iptables -A INPUP -p tcp ! --syn -m conntrack --cstate INVALID -j DROP
>>     
>
>
> take a look at this picture, to see, that mangle/PREROUTING may catch
> different things than filter/INPUT:
> http://jengelh.medozas.de/images/nf-packet-flow.png
>
> Generally filtering (ACCEPT/DROP/REJECT) should be done in the filter
> table, unless there is a good reason (and understanding) to do it
> otherwise (i.e. the nat table does not allow DROP).
> The mangle table is generally meant for packet manipulation. i.e.
> marking, changing ip settings, etc...
>
> conntrack supports all states that the state match does, plus some more.
>
>
> More in general:
> imho the '! --syn' is quite unnecessary, correct me if I'm wrong.
>
> Best regards
>
> Mart
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: INVALID state

[Mart Frauenlob]

On 28.02.2010 11:52, netfilter-owner@vger.kernel.org wrote:
> Mart Frauenlob wrote:
>> On 28.02.2010 10:31, netfilter-owner@vger.kernel.org wrote:
>>
>>> Dear all
>>>
>>> Could someone help me to identify the difference between
>>> the following 3 rules.
>>>
>>> 1. iptables -t mangle -A PREROUTING -p tcp ! --syn -m state --state
>>> INVALID -j DROP
>>> 2. iptables -A INPUT -p tcp ! --syn -m state --state INVALID -j DROP
>>> 3. iptables -A INPUP -p tcp ! --syn -m conntrack --cstate INVALID -j
>>> DROP
>>>
>>
>>
>> take a look at this picture, to see, that mangle/PREROUTING may catch
>> different things than filter/INPUT:
>> http://jengelh.medozas.de/images/nf-packet-flow.png
>>
>> Generally filtering (ACCEPT/DROP/REJECT) should be done in the filter
>> table, unless there is a good reason (and understanding) to do it
>> otherwise (i.e. the nat table does not allow DROP).
>> The mangle table is generally meant for packet manipulation. i.e.
>> marking, changing ip settings, etc...
>>
>> conntrack supports all states that the state match does, plus some more.
>>
>>
>> More in general:
>> imho the '! --syn' is quite unnecessary, correct me if I'm wrong.
>>

> Thanks for the help.
> 

np, but please switch to bottom posting...

> Assuming that the a packet reach the 1,2,3 rules is there a
> difference regards matching between "-m state --state INVALID"
> applied in 1 and 2 rules or the "-m conntrack --cstate INVALID"
> statements?
> 

requoting myself:
> conntrack supports all states that the state match does, plus some more

so, no difference.

Re: INVALID state

[Gilad Benjamini]

Here is my partial analysis of the code (2.6.24) , trying to understand what
INVALID state means.
Feedbacks are appreciated.

- init_conntrack calls l4proto->new. If a zero value is returned,
nf_conntrack_free is called and the packet's connection is considered
INVALID
- l4proto->new can be one of
	- tcp_new
		- Determines the new state according to tcp_conntracks
		- Returns 0 in these cases:
			- The new state is invalid
			- The new state is not SYN_SENT, and loose TCP is
turned off
	- icmp_new
		- Return 1 only for ICMP: ECHO,
TIMESTAMP,INFO_REQUEST,ADDRESS
	- icmpv6_new
		- Return 1 only for ECHO, NI_QUERY
	- sctp_new
		- (not sure of the details) 
	- A list of functions which always return 1; i.e. never produce an
INVALID state
		- udp_new
		- new (@nf_conntrack_proto_generic.c)
		- gre_new
		- udplite_new

Re: INVALID state

[Christoph Paasch]

Hi,

On Thu November 13 2008, Gilad Benjamini wrote:
> - init_conntrack calls l4proto->new. If a zero value is returned,
> nf_conntrack_free is called and the packet's connection is considered
> INVALID
In fact, the packet isn't marked "INVALID", there is just xt_state.c, who 
detects an invalid packet, if nf_ct_get(...) returns 0 or null. Which means, 
that skb->nfct == NULL. Which in turn means, that nf_conntrack_in doesn't 
assigned a connection to the packet.

And that will be the case, if any of these calls return a negative value (take 
a look at nf_conntrack_in and the functions it's calling):
l3proto->get_l4proto
l3proto->pkt_to_tuple
l3proto->invert_tuple
l4proto->error
l4proto->pkt_to_tuple
l4proto->invert_tuple
l4proto->new
l4proto->packet
nf_conntrack_alloc

So, there can be A LOT of cases, where conntrack detects an invalid packet...

--
Christoph Paasch

www.rollerbulls.be
--

RE: INVALID state

[Gilad Benjamini]

Back to my original question then: what is the rule of thumb ?
In other words, for a non-programmer reading proper documentation, how would
the documentation describe INVALID ?

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-
> owner@vger.kernel.org] On Behalf Of Christoph Paasch
> Sent: Thursday, November 13, 2008 2:31 PM
> To: Gilad Benjamini
> Cc: netfilter@vger.kernel.org
> Subject: Re: INVALID state
> 
> Hi,
> 
> On Thu November 13 2008, Gilad Benjamini wrote:
> > - init_conntrack calls l4proto->new. If a zero value is returned,
> > nf_conntrack_free is called and the packet's connection is considered
> > INVALID
> In fact, the packet isn't marked "INVALID", there is just xt_state.c,
> who
> detects an invalid packet, if nf_ct_get(...) returns 0 or null. Which
> means,
> that skb->nfct == NULL. Which in turn means, that nf_conntrack_in
> doesn't
> assigned a connection to the packet.
> 
> And that will be the case, if any of these calls return a negative
> value (take
> a look at nf_conntrack_in and the functions it's calling):
> l3proto->get_l4proto
> l3proto->pkt_to_tuple
> l3proto->invert_tuple
> l4proto->error
> l4proto->pkt_to_tuple
> l4proto->invert_tuple
> l4proto->new
> l4proto->packet
> nf_conntrack_alloc
> 
> So, there can be A LOT of cases, where conntrack detects an invalid
> packet...
> 
> --
> Christoph Paasch
> 
> www.rollerbulls.be
> --
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INVALID state

[Christoph Paasch]

On Thu November 13 2008, Gilad Benjamini wrote:
> Back to my original question then: what is the rule of thumb ?
> In other words, for a non-programmer reading proper documentation, how
> would the documentation describe INVALID ?

In the "Packet Filtering HOWTO" of netfilter.org, they say:

A packet which could not be identified for some reason: this includes running 
out of memoory and ICMP errors which don't correspond to any known connection.

By looking to the code, I would say, that a packet is invalid, if the 
connection tracker doesn't manages to create a proper connection-state for 
that packet (memory-errors while treating the packet, ...), or the tests 
defined by the specific protocol-handlers fail.

But I'm also asking me this question, because I have to implement shim6-
support in netfilter in the case of my Master Thesis. So does somebody can give 
me a reference which will explain me, what a firewall should check, and what 
not...? Should it check, if the packet respects the whole protocol (in case of 
shim6: nonces, cga/hba, ...)?

Thanks for your help, and sorry, if i'm running out of the topic of that 
thread.

--
Christoph Paasch

www.rollerbulls.be
--

INVALID state

[Gilad Benjamini]

iptables allows querying for 4 states: NEW, ESTABLISHED, RELATED, INVALID
The first three are pretty obvious.
What exactly are the semantics of the INVALID state ?

My setup involves a firewall on a bridge and a dual-NIC protected machine

Network A -- Protected machine -- Network B -- Firewall

The protected machine has asymmetric routing. A ping arriving via network A
is replied via network B. The reply packet is seen as part of an INVALID
connection.
Same thing happens for a SYN packet from network A, which leads to a SYN-ACK
on network B.

I read somewhere that an ACK packet belonging to a non-existing connection,
for example, will be in NEW state. I was assuming that SYN-ACK will behave
the same.

So when is a connection considered INVALID ?

P.S: By now this is a theoretical question, as the asymmetric routing was a
misconfiguration. Nevertheless, I am trying to understand what happened.

Re: INVALID state

[Thomas Jacob]

I don't really understand your setup description, but asymmetric routing
often leads to problems with stateful inspection firewalls, as both
directions of a conversation need to go through the same firewall for
connection tracking to work. 

For instance, if your ICMP echo request doesn't go through your
firewall, how can the stateful inspection know
about the echo reply to be expected? Also, if the firewall
doesn't see the initial TCP SYN packet, but the SYN-ACK goes
through the firewall, it clearly shouldn't allow that through.

The iptables connection pickup feature is, depending on your point
of view, a bad hack to make up for iptables' (now historic) lack of
a state synching mechanism like OpenBSD's pfsync.

Or a rather nice feature that keeps the scalability of independent
netfilter boxen running in parallel, while allowing some kind of
fail over capability that works in many to most cases while
incurring only small security drawbacks.

It's definitely not a mechanism to deal with asymmetric routing though,
AFAIK a pickup only happens when you see traffic in both directions,
which doesn't happen when one part of your conversation doesn't
go through your filtering box.


On Wed, 2008-11-12 at 14:08 -0800, Gilad Benjamini wrote:
> iptables allows querying for 4 states: NEW, ESTABLISHED, RELATED, INVALID
> The first three are pretty obvious.
> What exactly are the semantics of the INVALID state ?
> 
> My setup involves a firewall on a bridge and a dual-NIC protected machine
> 
> Network A -- Protected machine -- Network B -- Firewall
> 
> The protected machine has asymmetric routing. A ping arriving via network A
> is replied via network B. The reply packet is seen as part of an INVALID
> connection.
> Same thing happens for a SYN packet from network A, which leads to a SYN-ACK
> on network B.
> 
> I read somewhere that an ACK packet belonging to a non-existing connection,
> for example, will be in NEW state. I was assuming that SYN-ACK will behave
> the same.
> 
> So when is a connection considered INVALID ?
> 
> P.S: By now this is a theoretical question, as the asymmetric routing was a
> misconfiguration. Nevertheless, I am trying to understand what happened.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INVALID state

[Christoph Paasch]

Hi,

On Thu November 13 2008, Thomas Jacob wrote:
> For instance, if your ICMP echo request doesn't go through your
> firewall, how can the stateful inspection know
> about the echo reply to be expected? Also, if the firewall
> doesn't see the initial TCP SYN packet, but the SYN-ACK goes
> through the firewall, it clearly shouldn't allow that through.

as I'm currently trying to understand the netfilter implementation, I tried to 
find the point, where the ICMP-Echo-Reply gets filtered.

In xt_state.c->match(...) I saw, that it detects the state XT_STATE_INVALID if 
there is no connection associated to the packet (skb->nfct). But in the ICMP 
connection tracker I don't find the point, that it doesn't tracks the echo-
reply packets if no echo-request packet passed. I have the impression, that it 
will track the echo-reply as a NEW connection.

Could someone please point me to the code?

Thanks in advance,

--
Christoph Paasch

www.rollerbulls.be
--

Re: INVALID state

[Thomas Jacob]

> In xt_state.c->match(...) I saw, that it detects the state XT_STATE_INVALID if 
> there is no connection associated to the packet (skb->nfct). But in the ICMP 

To clarify, I wasn't making any specific claims related to Gilad's
problem on how exactly ICMP connections fail with an asymmetric routing
setup, just that asymmetric routing causes problems like this in
general.
  
However, an initial SYN-ACK packet in a TCP connection for instance,
definitely is considered invalid (see the tcp_conntracks array
in netfilter/nf_conntrack_proto_tcp.c).

For ICMP packets, I think icmp_new in nf_conntrack_proto_icmp.c doesn't
allow an echo request for the creation of a new conntrack, but I'm not
so sure.

But I was also having something like this in mind:

-P FORWARD DROP
-A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT
-A FORWARD --state NEW -p icmp --icmp-type echo-request

If your initial packet echo-request doesn't pass through the
firewall, the echo reply will be blocked, even if the conntrack
code wouldn't classify a sole echo reply as INVALID.

Re: INVALID state

[Christoph Paasch]

Hi,

thanks for the fast answer...

On Thu November 13 2008, Thomas Jacob wrote:
> For ICMP packets, I think icmp_new in nf_conntrack_proto_icmp.c doesn't
> allow an echo request for the creation of a new conntrack, but I'm not
> so sure.
That's true, it checks, if the type of the ICMP is one of valid_new 
(containing ECHO, TIMESTAMP, INFO_REQUEST and ADDRESS)

--
Christoph Paasch

www.rollerbulls.be
--