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

DISCUSSION William Fitzgerald 3 participants 7 messages Oct 20, 2009 – Oct 21, 2009

lore

Share & tools

lore

William Fitzgerald

author

2009-10-20 21:07 UTC #0 lore raw

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.

John Lister

2009-10-21 07:21 UTC #1 lore raw

Quoted 6 lines · 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.

Quoted 8 lines

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

Mart Frauenlob

2009-10-21 07:59 UTC #2 lore raw

In reply to William Fitzgerald

Quoted 6 lines · [email protected] 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.

Quoted 7 lines

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

Quoted 10 lines

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

Quoted 3 lines

regards,
Will.

hope it helps

regards

Mart

William Fitzgerald

author

2009-10-21 08:46 UTC #3 lore raw

Hi Mart,

Quoted 9 lines · Mart Frauenlob

Quoted 8 lines · [email protected] 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?

Quoted 7 lines

Quoted 5 lines
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 ;-)

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 11 lines

Quoted 10 lines
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.

Quoted 4 lines

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.

Quoted 14 lines

Quoted 3 lines

regards,
Will.

hope it helps

regards

Mart

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mart Frauenlob

2009-10-21 09:33 UTC #4 lore raw

Quoted 31 lines · [email protected] wrote:

Hi Mart,
Quoted 9 lines · Mart Frauenlob
Quoted 8 lines · [email protected] 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?
Quoted 7 lines
Quoted 5 lines
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 ;-)
Quoted 6 lines
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.
Quoted 3 lines
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

Quoted 7 lines

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.

Quoted 11 lines

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.
Quoted 8 lines
Quoted 8 lines
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

Quoted 9 lines

Quoted 3 lines
Quoted 2 lines
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.
Quoted 3 lines
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

Quoted 5 lines

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

William Fitzgerald

author

2009-10-21 09:46 UTC #5 lore raw

Quoted 61 lines · Mart Frauenlob

Quoted 31 lines · [email protected] wrote:
Hi Mart,
Quoted 9 lines · Mart Frauenlob
Quoted 8 lines · [email protected] 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?
Quoted 7 lines
Quoted 5 lines
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 ;-)
Quoted 6 lines
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.
Quoted 3 lines
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
Quoted 7 lines
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.
Quoted 18 lines
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.
Quoted 11 lines
Quoted 10 lines
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.
Quoted 3 lines
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

Quoted 6 lines

Quoted 2 lines
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.

Quoted 8 lines

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

Quoted 6 lines

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.

Quoted 14 lines

Quoted 5 lines
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
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mart Frauenlob

2009-10-21 10:08 UTC #6 lore raw

Quoted 8 lines · [email protected] wrote:

Quoted 7 lines · Mart Frauenlob
Quoted 6 lines
Quoted 4 lines
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?

Quoted 17 lines

Quoted 3 lines
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.
Quoted 8 lines
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 ;-)

Quoted 7 lines

Quoted 6 lines
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