On Sun, 2 Jan 2000 01:39:46 +0100 (MET),
Ketil Froyn <[EMAIL PROTECTED]> wrote:
>On Sat, 1 Jan 2000, Emmerich Eggler wrote:
>
>> I wouldn't care about the performance in the first place -
>> finally, you want to have a secure gateway to an insecure network.
>
>I agree, but I would like to know anyway. For example, if the rules can be
>rearranged so that the type of packets you are getting most often are the
>ones that are checked first, that might be a good thing. But if the time
>spent rearranging the rules is greater than the total time ever saved
>because of that, I'll agree it's pointless. We'd be a little wiser,
>though.
In most cases, you cannot rearrange rules in "most often received"
order. Rules to exclude rogue packets must come before the rules to
accept packets but you get far fewer rogue packets than normal ones.
In some cases it is worth defining a secondary chain and using a high
level filter to direct certain packets down that chain. For example, I
have 31 rules that control which privileged services (port < 1024) are
allowed in on PPP. Those 31 rules are stored in chain Ipriv and the
main ruleset has
ipchains -A input -p TCP -i ppp+ --destination-port 0:1024 -j Ipriv
ipchains -A input -p UDP -i ppp+ --destination-port 0:1024 -j Ipriv
which moves the 31 special cases out of the main line. Apart from
tricks like that, you have little flexibility in rule ordering,
specific exclusions must come before generic inclusions. Most network
servers need generic inclusion rules, especially when you are serving
ftp.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
