Query: Stateful parameters Explicitly and Implicitly defined, which is it?

Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[William Fitzgerald]

Dear experts,

If a rule has a state of NEW does it implicitly imply ESTABLISHED also?

Looking at examples on the web I see references to both.

For example to permit access to an internal Web server, which of the 
straw-man rules are correct?

Implicit Established Example:
iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT

Explicit Established Example:
iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW,ESTABLISHED 
-j ACCEPT


Similarly, I see reference to setting TCP flags as a control measure. 
Particularly for port scanning etc. However sticking with the  Web 
server example, an internal Web Server should expect a client to 
initiate a connection (SYN flag) but the server itself should not do this.

example strawman-rules of the stateless kind:
iptables -a FORWARD -i eth0 --dport 80 --tcp-flags SYN -j ACCEPT

iptables -a FORWARD -o eth1 --sport 80 --tcp-flags ACK -j ACCEPT

The thing is, what happens after the 3-way handshake? Incoming http 
requests will no longer have a SYN flag set! So is there some implicit 
knowledge that netfilter or other packet filters operate over?

regards,
Will.

Re: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[John Lister]

William Fitzgerald wrote:
> Dear experts,
>
> If a rule has a state of NEW does it implicitly imply ESTABLISHED also?
>
> Looking at examples on the web I see references to both.
>
> For example to permit access to an internal Web server, which of the 
> straw-man rules are correct?
>
> Implicit Established Example:
> iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
>
> Explicit Established Example:
> iptables -a FORWARD -i eth0 --dport 80 -m state --state 
> NEW,ESTABLISHED -j ACCEPT
>
I'm no expert, but i would usually have a rule that accepts any 
established connections first, followed by ones where the state is new 
and has the conditions you require. I've also added RELATED below as 
you'd often want those to be accepted by default as well.

iptables -a FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT
iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
...

John

Re: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[Mart Frauenlob]

netfilter-owner@vger.kernel.org wrote:
> Dear experts,
>
> If a rule has a state of NEW does it implicitly imply ESTABLISHED also?
>
> Looking at examples on the web I see references to both.
>
> For example to permit access to an internal Web server, which of the 
> straw-man rules are correct?
>
> Implicit Established Example:
> iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
>
> Explicit Established Example:
> iptables -a FORWARD -i eth0 --dport 80 -m state --state 
> NEW,ESTABLISHED -j ACCEPT

both are, but both miss: '-p tcp'; and its '-A' not '-a'.
It depends what your other rules in the ruleset do.
if you have some like:
iptables -A FORWARD -m state --ESTABLISHED -j ACCEPT
the first of the 2 rules above will work out, though the second will 
also work, just has this redundant state descriptor (which does not 
matter all).

To allow http traffic, without other rules:
iptables -A FORWARD -i eth0 -m tcp --dport 80 -m state --state 
NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -o eth0 -m tcp --sport 80 -m state --state 
ESTABLISHED -j ACCEPT

>
> Similarly, I see reference to setting TCP flags as a control measure. 
> Particularly for port scanning etc. However sticking with the  Web 
> server example, an internal Web Server should expect a client to 
> initiate a connection (SYN flag) but the server itself should not do 
> this.
>
> example strawman-rules of the stateless kind:
> iptables -a FORWARD -i eth0 --dport 80 --tcp-flags SYN -j ACCEPT
>
> iptables -a FORWARD -o eth1 --sport 80 --tcp-flags ACK -j ACCEPT
>
> The thing is, what happens after the 3-way handshake? Incoming http 
> requests will no longer have a SYN flag set! So is there some implicit 
> knowledge that netfilter or other packet filters operate over?
>
Same as before, you need other rules to handle that. Usually I normalize 
TCP traffic, even before it hits the rules for the servers, but if i 
wouldn't do it globally, I'd rather write the rule like this:
iptables -A FORWARD -i eth0 -m tcp --dport 80 --tcp-flags SYN -m state 
--state NEW -j ACCEPT

> regards,
> Will.
>
hope it helps

regards

Mart

Re: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[William Fitzgerald]

Hi Mart,


Mart Frauenlob wrote:
> netfilter-owner@vger.kernel.org wrote:
>> Dear experts,
>>
>> If a rule has a state of NEW does it implicitly imply ESTABLISHED also?
>>
>> Looking at examples on the web I see references to both.
>>
>> For example to permit access to an internal Web server, which of the 
>> straw-man rules are correct?
>>
>> Implicit Established Example:
>> iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
>>
>> Explicit Established Example:
>> iptables -a FORWARD -i eth0 --dport 80 -m state --state 
>> NEW,ESTABLISHED -j ACCEPT
>
> both are, but both miss: '-p tcp'; and its '-A' not '-a'.
Your right a typo and a little too much of a straw-man rule here ;-)
> It depends what your other rules in the ruleset do.
> if you have some like:
> iptables -A FORWARD -m state --ESTABLISHED -j ACCEPT
> the first of the 2 rules above will work out, though the second will 
> also work, just has this redundant state descriptor (which does not 
> matter all).
>
> To allow http traffic, without other rules:
yep, just for the example to fully understand the semantics.
> iptables -A FORWARD -i eth0 -m tcp --dport 80 -m state --state 
> NEW,ESTABLISHED -j ACCEPT
> iptables -A FORWARD -o eth0 -m tcp --sport 80 -m state --state 
> ESTABLISHED -j ACCEPT
>
As I suspected, one must explicitly defined both NEW and ESTABLISHED in 
the inbound rule. Of course, it can be separated into 2 rules. But the 
important point is that both are required.

Just specifying NEW is not good enough.

I got a little mixed up looking at various examples on the web, some of 
which are probably snippets of a full configuration that probably also 
included a rule as John Lister stated previously:
iptables -A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

I guess what also got me  thinking was,  the  Netfilter connection 
track. I was thinking perhaps if a certain kind of traffic was permitted 
to request a new connection with the NEW state then the connect track 
engine does some magic to implicitly imply it must also be allowed to 
continue a connection with the ESTABLISED. However, as i can see from 
your example, one must explicitly define the "states" within the rules. 
Thus, NEW to the conection track engine means only NEW and does not also 
imply ESTABLISHED behind the scenes.


>>
>> Similarly, I see reference to setting TCP flags as a control measure. 
>> Particularly for port scanning etc. However sticking with the  Web 
>> server example, an internal Web Server should expect a client to 
>> initiate a connection (SYN flag) but the server itself should not do 
>> this.
>>
>> example strawman-rules of the stateless kind:
>> iptables -a FORWARD -i eth0 --dport 80 --tcp-flags SYN -j ACCEPT
>>
>> iptables -a FORWARD -o eth1 --sport 80 --tcp-flags ACK -j ACCEPT
>>
>> The thing is, what happens after the 3-way handshake? Incoming http 
>> requests will no longer have a SYN flag set! So is there some 
>> implicit knowledge that netfilter or other packet filters operate over?
>>
> Same as before, you need other rules to handle that. 
Ok.
> Usually I normalize TCP traffic, even before it hits the rules for the 
> servers, but if i wouldn't do it globally, I'd rather write the rule 
> like this:
> iptables -A FORWARD -i eth0 -m tcp --dport 80 --tcp-flags SYN -m state 
> --state NEW -j ACCEPT
>
I see your using stateful operators also in the above rule. Why would 
there be a need to use the stateless SYN flag operator given the NEW 
operaror implicitly handles this?


I have some interesting questions about flags, so what I will do is 
start a thread for them as the discussion about them may get lost with 
the heading of this particular thread.

Thanks so much for the comments,
Will.
>> regards,
>> Will.
>>
> hope it helps
>
> 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: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[Mart Frauenlob]

netfilter-owner@vger.kernel.org wrote:
> Hi Mart,
>
>
> Mart Frauenlob wrote:
>> netfilter-owner@vger.kernel.org wrote:
>>> Dear experts,
>>>
>>> If a rule has a state of NEW does it implicitly imply ESTABLISHED also?
>>>
>>> Looking at examples on the web I see references to both.
>>>
>>> For example to permit access to an internal Web server, which of the 
>>> straw-man rules are correct?
>>>
>>> Implicit Established Example:
>>> iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
>>>
>>> Explicit Established Example:
>>> iptables -a FORWARD -i eth0 --dport 80 -m state --state 
>>> NEW,ESTABLISHED -j ACCEPT
>>
>> both are, but both miss: '-p tcp'; and its '-A' not '-a'.
> Your right a typo and a little too much of a straw-man rule here ;-)
>> It depends what your other rules in the ruleset do.
>> if you have some like:
>> iptables -A FORWARD -m state --ESTABLISHED -j ACCEPT
>> the first of the 2 rules above will work out, though the second will 
>> also work, just has this redundant state descriptor (which does not 
>> matter all).
>>
>> To allow http traffic, without other rules:
> yep, just for the example to fully understand the semantics.
>> iptables -A FORWARD -i eth0 -m tcp --dport 80 -m state --state 
>> NEW,ESTABLISHED -j ACCEPT
>> iptables -A FORWARD -o eth0 -m tcp --sport 80 -m state --state 
>> ESTABLISHED -j ACCEPT
>>
> As I suspected, one must explicitly defined both NEW and ESTABLISHED 
> in the inbound rule. Of course, it can be separated into 2 rules. But 
> the important point is that both are required.
>
> Just specifying NEW is not good enough.
>
> I got a little mixed up looking at various examples on the web, some 
> of which are probably snippets of a full configuration that probably 
> also included a rule as John Lister stated previously:
> iptables -A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT
>
such a rule is often placed as first rule in chains, because it matches 
a lot of packets, thus speeding up processing.
There might be scenarios where it's appropriate to distinguish the 
states into more rules, but that might be quite complex setups.
For the average ruleset these are perfect.

> I guess what also got me  thinking was,  the  Netfilter connection 
> track. I was thinking perhaps if a certain kind of traffic was 
> permitted to request a new connection with the NEW state then the 
> connect track engine does some magic to implicitly imply it must also 
> be allowed to continue a connection with the ESTABLISED. However, as i 
> can see from your example, one must explicitly define the "states" 
> within the rules. Thus, NEW to the conection track engine means only 
> NEW and does not also imply ESTABLISHED behind the scenes.
>
>
>>>
>>> Similarly, I see reference to setting TCP flags as a control 
>>> measure. Particularly for port scanning etc. However sticking with 
>>> the  Web server example, an internal Web Server should expect a 
>>> client to initiate a connection (SYN flag) but the server itself 
>>> should not do this.
>>>
>>> example strawman-rules of the stateless kind:
>>> iptables -a FORWARD -i eth0 --dport 80 --tcp-flags SYN -j ACCEPT
>>>
>>> iptables -a FORWARD -o eth1 --sport 80 --tcp-flags ACK -j ACCEPT
>>>
>>> The thing is, what happens after the 3-way handshake? Incoming http 
>>> requests will no longer have a SYN flag set! So is there some 
>>> implicit knowledge that netfilter or other packet filters operate over?
>>>
>> Same as before, you need other rules to handle that. 
> Ok.
>> Usually I normalize TCP traffic, even before it hits the rules for 
>> the servers, but if i wouldn't do it globally, I'd rather write the 
>> rule like this:
>> iptables -A FORWARD -i eth0 -m tcp --dport 80 --tcp-flags SYN -m 
>> state --state NEW -j ACCEPT
>>
> I see your using stateful operators also in the above rule. Why would 
> there be a need to use the stateless SYN flag operator given the NEW 
> operaror implicitly handles this?
>

Because NEW to the connection tracker means any new packet, which is not 
ESTABLISHED,RELATED, or INVALID.
So it's not necessarily a tcp syn packet. Explicitly defining  -m tcp 
--syn makes sure it's a valid tcp connection attempt.
That's why I talked about normalizing  the tcp traffic. Many rulesets 
place a rule like this (quite on top) to remove bad tcp packets:
iptables -N bad_tcp
iptables -A bad_tcp -p tcp ! --syn -m state --state NEW -j DROP

for c in INPUT FORWARD; do
    iptables -A $c -p tcp -j bad_tcp
done

You might check out the iptables tutorial on frozentux, which may answer 
many of your questions:
http://www.frozentux.net/documents/iptables-tutorial/

and also read this:
http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf

>
> I have some interesting questions about flags, so what I will do is 
> start a thread for them as the discussion about them may get lost with 
> the heading of this particular thread.
>
> Thanks so much for the comments,
> Will.

Regards

Mart

Re: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[William Fitzgerald]

Mart Frauenlob wrote:
> netfilter-owner@vger.kernel.org wrote:
>> Hi Mart,
>>
>>
>> Mart Frauenlob wrote:
>>> netfilter-owner@vger.kernel.org wrote:
>>>> Dear experts,
>>>>
>>>> If a rule has a state of NEW does it implicitly imply ESTABLISHED 
>>>> also?
>>>>
>>>> Looking at examples on the web I see references to both.
>>>>
>>>> For example to permit access to an internal Web server, which of 
>>>> the straw-man rules are correct?
>>>>
>>>> Implicit Established Example:
>>>> iptables -a FORWARD -i eth0 --dport 80 -m state --state NEW -j ACCEPT
>>>>
>>>> Explicit Established Example:
>>>> iptables -a FORWARD -i eth0 --dport 80 -m state --state 
>>>> NEW,ESTABLISHED -j ACCEPT
>>>
>>> both are, but both miss: '-p tcp'; and its '-A' not '-a'.
>> Your right a typo and a little too much of a straw-man rule here ;-)
>>> It depends what your other rules in the ruleset do.
>>> if you have some like:
>>> iptables -A FORWARD -m state --ESTABLISHED -j ACCEPT
>>> the first of the 2 rules above will work out, though the second will 
>>> also work, just has this redundant state descriptor (which does not 
>>> matter all).
>>>
>>> To allow http traffic, without other rules:
>> yep, just for the example to fully understand the semantics.
>>> iptables -A FORWARD -i eth0 -m tcp --dport 80 -m state --state 
>>> NEW,ESTABLISHED -j ACCEPT
>>> iptables -A FORWARD -o eth0 -m tcp --sport 80 -m state --state 
>>> ESTABLISHED -j ACCEPT
>>>
>> As I suspected, one must explicitly defined both NEW and ESTABLISHED 
>> in the inbound rule. Of course, it can be separated into 2 rules. But 
>> the important point is that both are required.
>>
>> Just specifying NEW is not good enough.
>>
>> I got a little mixed up looking at various examples on the web, some 
>> of which are probably snippets of a full configuration that probably 
>> also included a rule as John Lister stated previously:
>> iptables -A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT
>>
> such a rule is often placed as first rule in chains, because it 
> matches a lot of packets, thus speeding up processing.
> There might be scenarios where it's appropriate to distinguish the 
> states into more rules, but that might be quite complex setups.
> For the average ruleset these are perfect.
>
>> I guess what also got me  thinking was,  the  Netfilter connection 
>> track. I was thinking perhaps if a certain kind of traffic was 
>> permitted to request a new connection with the NEW state then the 
>> connect track engine does some magic to implicitly imply it must also 
>> be allowed to continue a connection with the ESTABLISED. However, as 
>> i can see from your example, one must explicitly define the "states" 
>> within the rules. Thus, NEW to the conection track engine means only 
>> NEW and does not also imply ESTABLISHED behind the scenes.
>>
>>
>>>>
>>>> Similarly, I see reference to setting TCP flags as a control 
>>>> measure. Particularly for port scanning etc. However sticking with 
>>>> the  Web server example, an internal Web Server should expect a 
>>>> client to initiate a connection (SYN flag) but the server itself 
>>>> should not do this.
>>>>
>>>> example strawman-rules of the stateless kind:
>>>> iptables -a FORWARD -i eth0 --dport 80 --tcp-flags SYN -j ACCEPT
>>>>
>>>> iptables -a FORWARD -o eth1 --sport 80 --tcp-flags ACK -j ACCEPT
>>>>
>>>> The thing is, what happens after the 3-way handshake? Incoming http 
>>>> requests will no longer have a SYN flag set! So is there some 
>>>> implicit knowledge that netfilter or other packet filters operate 
>>>> over?
>>>>
>>> Same as before, you need other rules to handle that. 
>> Ok.
>>> Usually I normalize TCP traffic, even before it hits the rules for 
>>> the servers, but if i wouldn't do it globally, I'd rather write the 
>>> rule like this:
>>> iptables -A FORWARD -i eth0 -m tcp --dport 80 --tcp-flags SYN -m 
>>> state --state NEW -j ACCEPT
>>>
>> I see your using stateful operators also in the above rule. Why would 
>> there be a need to use the stateless SYN flag operator given the NEW 
>> operaror implicitly handles this?
>>
>
> Because NEW to the connection tracker means any new packet, which is 
> not ESTABLISHED,RELATED, or INVALID.
> So it's not necessarily a tcp syn packet. Explicitly defining  -m tcp 
> --syn makes sure it's a valid tcp connection attempt.
I understand you now, I hope!

Although, given the protocol is TCP we know explicitly its not a UDP new 
connection attempt. But forcing the syn check ensures that the 
particular TCP packet is the kind we want.

So in all, its a further set of "checks and balances" that provide 
additional security, perhaps from various packet crafting situations 
where a packet may have both the syn and ack for example set.

> That's why I talked about normalizing  the tcp traffic. Many rulesets 
> place a rule like this (quite on top) to remove bad tcp packets:
> iptables -N bad_tcp
> iptables -A bad_tcp -p tcp ! --syn -m state --state NEW -j DROP
>
> for c in INPUT FORWARD; do
>    iptables -A $c -p tcp -j bad_tcp
> done
>
> You might check out the iptables tutorial on frozentux, which may 
> answer many of your questions:
> http://www.frozentux.net/documents/iptables-tutorial/
>
> and also read this:
> http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf
>
perfect, thanks.
>>
>> I have some interesting questions about flags, so what I will do is 
>> start a thread for them as the discussion about them may get lost 
>> with the heading of this particular thread.
>>
>> Thanks so much for the comments,
>> Will.
>
> 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: Query: Stateful parameters Explicitly and Implicitly defined, which is it?

[Mart Frauenlob]

netfilter-owner@vger.kernel.org wrote:
> Mart Frauenlob wrote:
>>>
>>>> Usually I normalize TCP traffic, even before it hits the rules for 
>>>> the servers, but if i wouldn't do it globally, I'd rather write the 
>>>> rule like this:
>>>> iptables -A FORWARD -i eth0 -m tcp --dport 80 --tcp-flags SYN -m 
>>>> state --state NEW -j ACCEPT
>>>>
>>> I see your using stateful operators also in the above rule. Why 
>>> would there be a need to use the stateless SYN flag operator given 
>>> the NEW operaror implicitly handles this?
>>>
>>
>> Because NEW to the connection tracker means any new packet, which is 
>> not ESTABLISHED,RELATED, or INVALID.
>> So it's not necessarily a tcp syn packet. Explicitly defining  -m tcp 
>> --syn makes sure it's a valid tcp connection attempt.
> I understand you now, I hope!
>
> Although, given the protocol is TCP we know explicitly its not a UDP 
> new connection attempt. But forcing the syn check ensures that the 
> particular TCP packet is the kind we want.
>
> So in all, its a further set of "checks and balances" that provide 
> additional security, perhaps from various packet crafting situations 
> where a packet may have both the syn and ack for example set.
>
>> That's why I talked about normalizing  the tcp traffic. Many rulesets 
>> place a rule like this (quite on top) to remove bad tcp packets:
>> iptables -N bad_tcp
>> iptables -A bad_tcp -p tcp ! --syn -m state --state NEW -j DROP
>>
>> for c in INPUT FORWARD; do
>>    iptables -A $c -p tcp -j bad_tcp
>> done
>>
Yes another common rule that's on top of the bad_tcp chain is:
 -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT 
--reject-with tcp-reset

but you can read that in the tutorials ;-)

>> You might check out the iptables tutorial on frozentux, which may 
>> answer many of your questions:
>> http://www.frozentux.net/documents/iptables-tutorial/
>>
>> and also read this:
>> http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf
>>
> perfect, thanks.

Regards

Mart