iptables jump to userdefined chain and ESTABLISHED,RELATED rules

iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[richard lucassen]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Hello,

I want all traffic on port 80 be handled by a userdefined chain
"CH_WWW". Now my question: What is better, this way (I let the port
80 packets jump first, then I have _two_ ESTABLISHED,RELATED rules, as
well in the INPUT as in the CH_WWW chain):

********************************************************************
${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[..]

And an extra ESTABLISHED,RELATED in the CH_WWW:
${IPT} -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPT} -A CH_WWW (first rule)
[..]
********************************************************************

or this (I have _one_ ESTABLISHED,RELATED rule, and then let port 80 
jump):

********************************************************************
${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
[..]

And an extra ESTABLISHED,RELATED in the CH_WWW:
${IPT} -A CH_WWW (first rule)
[..]
********************************************************************

Both ways work, but I'd say the second way is the best. Am I right?

Richard.

-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[richard lucassen]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Hello,

I want all traffic on port 80 be handled by a userdefined chain
"CH_WWW". Now my question: What is better, this way (I let the port
80 packets jump first, then I have _two_ ESTABLISHED,RELATED rules, as
well in the INPUT as in the CH_WWW chain):

********************************************************************
${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[..]

And an extra ESTABLISHED,RELATED in the CH_WWW:
${IPT} -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPT} -A CH_WWW (first rule)
[..]
********************************************************************

or this (I have _one_ ESTABLISHED,RELATED rule, and then let port 80 
jump):

********************************************************************
${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
[..]

And an extra ESTABLISHED,RELATED in the CH_WWW:
${IPT} -A CH_WWW (first rule)
[..]
********************************************************************

Both ways work, but I'd say the second way is the best. Am I right?

Richard.

-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+


[-- Attachment #2: 00000000.mimetmp --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Cedric Blancher]

Le ven 10/10/2003 à 13:26, richard lucassen a écrit :
> I want all traffic on port 80 be handled by a userdefined chain
> "CH_WWW". Now my question: What is better, this way (I let the port
> 80 packets jump first, then I have _two_ ESTABLISHED,RELATED rules, as
> well in the INPUT as in the CH_WWW chain):
> 
> ********************************************************************
> ${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
> ${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> [..]
> 
> And an extra ESTABLISHED,RELATED in the CH_WWW:
> ${IPT} -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT
> ${IPT} -A CH_WWW (first rule)
> [..]
> ********************************************************************
> 
> or this (I have _one_ ESTABLISHED,RELATED rule, and then let port 80 
> jump):
> 
> ********************************************************************
> ${IPT} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> ${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
> [..]
> 
> And an extra ESTABLISHED,RELATED in the CH_WWW:
> ${IPT} -A CH_WWW (first rule)
> [..]
> ********************************************************************
> 
> Both ways work, but I'd say the second way is the best. Am I right?

I agree.
To me, theses two rulesets are equivalent for HTTP packets, but first
one implies one more rule evaluation than the second one for ESTABLISHED
packets that are destined to TCP/80.

PS : there's no RELATED packets in HTTP ;)

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[CAM IT Solutions]

On Sat, 11 Oct 2003 18:26:04 +0200
Cedric Blancher <blancher@cartel-securite.fr> wrote:

[snip rules]

> > Both ways work, but I'd say the second way is the best. Am I right?
> 
> I agree.
> To me, theses two rulesets are equivalent for HTTP packets, but first
> one implies one more rule evaluation than the second one for
> ESTABLISHED packets that are destined to TCP/80.

I don't know too much about netfilter internals, but I suppose that
there must be a separate connection table for each chain. I think this
is because you can't enter:

/sbin/iptables -m state --state ESTABLISHED,RELATED -j ACCEPT

without mentioning the chain. I *have* to enter:

/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

I just wonder if these ESTABLISHED,RELATED packets are handled by 1
overall connection table, or handled by 2 connection tables, 1 for
INPUT and 1 for FORWARD.

And what happens if a jump is made from the FORWARD chain to a
userdefined chain, is the connection table the one of the FORWARD chain?
And if the answer is "yes", why does iptables accepts the 

/sbin/iptables -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT

rule then? I haven't found any answer to that question on the net yet :(

> PS : there's no RELATED packets in HTTP ;)

Ok, the CH_WWW was just an example, but you certainly have got a point
there ;-)

R.

___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+
 

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Willy TARREAU]

On Sat, Oct 11, 2003 at 07:45:27PM +0200, CAM IT Solutions wrote:
 
> without mentioning the chain. I *have* to enter:
> 
> /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> I just wonder if these ESTABLISHED,RELATED packets are handled by 1
> overall connection table, or handled by 2 connection tables, 1 for
> INPUT and 1 for FORWARD.
> 
> And what happens if a jump is made from the FORWARD chain to a
> userdefined chain, is the connection table the one of the FORWARD chain?
> And if the answer is "yes", why does iptables accepts the 
> 
> /sbin/iptables -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> rule then? I haven't found any answer to that question on the net yet :(

You can share the user defined chains between several chains as long as
they are in the same table and support the same arguments. Since the
'state' match is valid from INPUT and FORWARD, it will work in a shared
user chain.

However, if you use some illegal information, you'll either get error
messages each time the rule is evaluated or get a never-matching rule.

eg:

  # iptables -A INPUT -j mychain
  # iptables -A FORWARD -j mychain
  # iptables -A mychain -o eth1 -j LOG --log-prefix "out_eth1"

  => Since the output interface (-o) is not defined when starting
     from the INPUT chain, the rule will never match, and possibly
     make the kernel complain.

But in a more general way, user chains are very useful to dissect rules
by addresses, using only DROP, ACCEPT and RETURN. And in this case, it's
easy to share them between different chains without risk.

Willy

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Joel Newkirk]

On Sat, 2003-10-11 at 12:26, Cedric Blancher wrote:

> I agree.
> To me, theses two rulesets are equivalent for HTTP packets, but first
> one implies one more rule evaluation than the second one for ESTABLISHED
> packets that are destined to TCP/80.
> 
> PS : there's no RELATED packets in HTTP ;)

Not precisely true - there are ICMP messages that may arrive in response
to HTTP requests that are RELATED.

j

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Cedric Blancher]

Le dim 12/10/2003 à 17:10, Joel Newkirk a écrit :
> > PS : there's no RELATED packets in HTTP ;)
> Not precisely true - there are ICMP messages that may arrive in response
> to HTTP requests that are RELATED.

Absolutely true. Should have been more precise.

I was meaning no RELATED on TCP/80 using HTTP, so first case WWW_CH
chain would never see a RELATED packet :

${IPT} -A INPUT -p tcp --dport 80 -j CH_WWW
${IPT} -A CH_WWW -m state --state ESTABLISHED,RELATED -j ACCEPT

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[richard lucassen]

On Sun, 12 Oct 2003 13:16:20 +0200
Willy TARREAU <willy@w.ods.org> wrote:

> You can share the user defined chains between several chains as long
> as they are in the same table and support the same arguments. Since
> the'state' match is valid from INPUT and FORWARD, it will work in a
> shared user chain.
> 
> However, if you use some illegal information, you'll either get error
> messages each time the rule is evaluated or get a never-matching rule.
> 
> eg:
> 
>   # iptables -A INPUT -j mychain
>   # iptables -A FORWARD -j mychain
>   # iptables -A mychain -o eth1 -j LOG --log-prefix "out_eth1"
> 
>   => Since the output interface (-o) is not defined when starting
>      from the INPUT chain, the rule will never match, and possibly
>      make the kernel complain.
> 
> But in a more general way, user chains are very useful to dissect
> rules by addresses, using only DROP, ACCEPT and RETURN. And in this
> case, it's easy to share them between different chains without risk.

Ok, but that does not answer my question ;-) Maybe I'm not so clear
in saying what I mean. Let me put it this way: Does the
ESTABLISHED,RELATED rule of the FORWARD chain handles all
ESTABLISHED,RELATED packets of a connection which was accepted as NEW in
a "child" chain? I think the answer is finally "yes". I did this simple
test:

case 1
**************************************************************
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
[..]
$IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
**************************************************************


case 2 (I swapped rule 1 and 2)
**************************************************************
$IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
[..]
$IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
**************************************************************


case 3 (I swapped rule 1 and 2 AND used an extra ESTABLISHED,RELATED
rule)
**************************************************************
$IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
$IPT -A FORWARD -m state--state ESTABLISHED,RELATED -j ACCEPT
[..]
$IPT -A CH_SSH -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
**************************************************************


Case 1 works, the new connection was accepted by the CH_SSH and all
ESTABLISHED,RELATED packets are handled by the ESTABLISHED,RELATED rule
in the FORWARD chain. AFAIUI this is proven by the fact that case 2 does
not work. Case 3 works as well.

case 1. This works:
$ telnet 1.2.3.4 22
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.7.1p2
^]
telnet> q
Connection closed.

case 2. There is a connection started, but ESTABLISHED,RELATED packets
apparently are dropped:
$ telnet 1.2.3.4 22
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
....(wait 1 minute)....
^]
telnet> q
Connection closed.

To speak "man iptables" language: in both cases the FORWARD chain has
"seen" the start of the connection, so the ESTABLISHED,RELATED rule of
the FORWARD chain will accept the rest of the packets of this
connection. So, no need for an extra ESTABLISHED,RELATED rule in each
user defined chain.

Please correct me if I'm wrong.

R.

-- 

___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+
-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Cedric Blancher]

Le dim 12/10/2003 à 19:53, richard lucassen a écrit :
> case 1
> **************************************************************
> $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
> [..]
> $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
> **************************************************************

Working...

> case 2 (I swapped rule 1 and 2)
> **************************************************************
> $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
> $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> [..]
> $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
> **************************************************************

Not working for SSH.

In fact, it should work. A TCP SYN flaged as NEW will be sent to CH_SSH
chain, then be accepted by CH_SSH rule that allows NEW packets. Then
further packets are going by. They are ESTABLISHED.

They match first rule so they are sent to CH_SSH chain. They do not
match the rule, for thieses packets are not NEW. So they hit end of user
chain and are returned to FORWARD chain, rule 2. They match rule 2 and
then get accepted.

If it does not work as your's, then you have a drop all rule at the end
of CH_SSH chain (I suppose) that prevents packet from returning from
user chain (CH_SSH here) to calling chain (FORWARD here).

To me, the best way to handle this is :

# ESTABLISHED and RELATED packets are accepted anyway
# We accept them first as they are most treated packets
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Then we care of each proto.
$IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
[...]
$IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT

Case 3 works because you enforce ESTABLISHED,RELATED accept in your use
chain.

I really do think that 1st case is the best way to handle, as it implies
less rules evaluation for each packet.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[Cedric Blancher]

Le dim 12/10/2003 à 19:53, richard lucassen a écrit :
> Ok, but that does not answer my question ;-) Maybe I'm not so clear
> in saying what I mean. Let me put it this way: Does the
> ESTABLISHED,RELATED rule of the FORWARD chain handles all
> ESTABLISHED,RELATED packets of a connection which was accepted as NEW in
> a "child" chain? I think the answer is finally "yes".

Well, because I di not really answer this very question, the answer is
yes, because packet state does not depend on rules. I mean a packet is
flaged with its state and carries this within all Netfilter framework,
regardless rules and chains.

So, if a packet is ESTABLISHED, then it is ESTABLISHED all the way,
regardless prior NEW packet as been matched (or not) in a builtin or
user chain. Rules have no effect on state.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: iptables jump to userdefined chain and ESTABLISHED,RELATED rules

[richard lucassen]

On Sun, 12 Oct 2003 20:54:00 +0200
Cedric Blancher <blancher@cartel-securite.fr> wrote:

> Not working for SSH.
> 
> In fact, it should work. A TCP SYN flaged as NEW will be sent to
> CH_SSH chain, then be accepted by CH_SSH rule that allows NEW packets.
> Then further packets are going by. They are ESTABLISHED.
> 
> They match first rule so they are sent to CH_SSH chain. They do not
> match the rule, for thieses packets are not NEW. So they hit end of
> user chain and are returned to FORWARD chain, rule 2. They match rule
> 2 and then get accepted.

Yes, sorry, you're right, but I forgot to mention that I have a cleanup
rule at the end of the CH_SSH:

$IPT -A CH_SSH -j DROP
 
> If it does not work as your's, then you have a drop all rule at the
> end of CH_SSH chain (I suppose) that prevents packet from returning
> from user chain (CH_SSH here) to calling chain (FORWARD here).

You got it right ;-)

> To me, the best way to handle this is :
> 
> # ESTABLISHED and RELATED packets are accepted anyway
> # We accept them first as they are most treated packets
> $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> # Then we care of each proto.
> $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH
> [...]
> $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT
> 
> Case 3 works because you enforce ESTABLISHED,RELATED accept in your
> use chain.
> 
> I really do think that 1st case is the best way to handle, as it
> implies less rules evaluation for each packet.

Ok, thanks a lot, it's much clearer now :)

R.

-- 
___________________________________________________________________
Recursion: see recursion

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+