From: "Michael Frank" <mhf@linuxmail.org>
To: Rob Sterenborg <rob@sterenborg.info>, netfilter@lists.netfilter.org
Subject: Re: Qustion wrt state RELATED,ESTABLISHED
Date: Wed, 07 Jul 2004 14:13:25 +0800 [thread overview]
Message-ID: <opsaq7knqf4evsfm@smtp.pacific.net.th> (raw)
In-Reply-To: <20040707051150.381201787@sterenborg.info>
On Wed, 7 Jul 2004 07:11:50 +0200, Rob Sterenborg <rob@sterenborg.info> wrote:
>> Is my assumtion correct that state RELATED,ESTABLISHED
>> checks all flags
>> for match and thus this state can (and should be for
>> performance reasons)
>> be the first in each table ?
>
> No, it checks the *state*.
>
> The first packet that is seen in a connection has state NEW, the rest
> have state ESTABLISHED or RELATED (as with e.g. ftp). Since these
> packets are let's say 99% in a connection, the ESTABLISHED and RELATED
> match will match the most packets. Also see the byte/packet counters for
> this (first 2 columns in the list below).
> That's why you probably want that rule somewhere on top for performance
> reasons because the rules are traversed in the order they are entered,
> and therefore matched in the order they are entered.
>
>> Chain INPUT (policy DROP 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source
>> destination
>
>> 15172 2029K ACCEPT all -- any any anywhere
>> anywhere state RELATED,ESTABLISHED
>
> Rule 1 (state checking)
>
>> 0 0 BADTCP tcp -- any . any
>> anywhere anywhere tcp
>> flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
>
> Rule 2 (flag checking)
>
> So you have 2 separate rules ; 1 for state and 1 for flag checking.
>
>
Thank you for your reply.
I apprectiate that first packet is NEW and others are EST/REL.
My point is, does EST/REL _match_ state and packets exactly and ignore
packets with _mismatching_ flags so I do _not_ have to check them
_before_ EST/REL and check them _only_ for NEW ??
Ok here is bigger example:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
437K 100M ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
488 107K EXTIF all -- ppp0 any anywhere anywhere
9 588 ACCEPT all -- lo any anywhere anywhere < ---lo and eth0 local is still too easy and under development :)
450 42411 ACCEPT all -- eth0 any anywhere anywhere
0 0 LOG all -- any any anywhere anywhere limit: avg 3/min burst 3 LOG level alert prefix `ipt - INPUT dropped: '
Chain EXTIF (1 references)
pkts bytes target prot opt in out source destination
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN,RST
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN/FIN,SYN
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
0 0 BADTCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
1 28 PINGFLOOD icmp -- any any anywhere anywhere icmp echo-request
52 2564 SYNFLOOD tcp -- any any anywhere anywhere tcp flags:SYN,RST,ACK/SYN
..... additional NEW enties eg for http
Logging here would be optional - great way to spam the logs.
69 3422 DROP all -- any any anywhere anywhere
Chain BADTCP (6 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- any any anywhere anywhere limit: avg 3/min burst 3 LOG level alert prefix `ipt - Blocked Bad TCP flag: '
0 0 DROP all -- any any anywhere anywhere
Chain PINGFLOOD (1 references)
pkts bytes target prot opt in out source destination
1 28 RETURN all -- any any anywhere anywhere limit: avg 10/sec burst 3
0 0 LOG all -- any any anywhere anywhere limit: avg 3/min burst 3 LOG level alert prefix `ipt - Blocked PING Flood: '
0 0 DROP all -- any any anywhere anywhere
Chain SYNFLOOD (1 references)
pkts bytes target prot opt in out source destination
52 2564 RETURN all -- any any anywhere anywhere limit: avg 10/sec burst 3
0 0 LOG all -- any any anywhere anywhere limit: avg 3/min burst 3 LOG level alert prefix `ipt - Blocked SYN Flood: '
0 0 DROP all -- any any anywhere anywhere
Regards
Michael
prev parent reply other threads:[~2004-07-07 6:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-07 3:48 Qustion wrt state RELATED,ESTABLISHED Michael Frank
2004-07-07 5:11 ` Rob Sterenborg
2004-07-07 6:13 ` Michael Frank [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=opsaq7knqf4evsfm@smtp.pacific.net.th \
--to=mhf@linuxmail.org \
--cc=netfilter@lists.netfilter.org \
--cc=rob@sterenborg.info \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox