[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: IPFilter: Shouldn't this be let in [WITH PATCH]
From:       Darren Reed <avalon () caligula ! anu ! edu ! au>
Date:       2003-11-26 23:01:12
[Download RAW message or body]

In some mail from Guido van Rooij, sie said:
> 
> On Wed, Nov 26, 2003 at 11:05:05AM +1100, Darren Reed wrote:
> > In some mail from Guido van Rooij, sie said:
> > > 
> > > > Where I'm going with this is that it might be nice to have a choice of 
> > > > using keep state with limitations on specific classes of "related" packets 
> > > > passed implicitly. You've sort of got that in this case without the patch, 
> > > > since you can always let in the ICMP explicitly as part of your ruleset. 
> > > > Once it becomes implicit with state, there's no method for controlling it 
> > > > in the current semantics.
> > > 
> > > I do agree with that. The question is how to do this. Should this be a
> > > per-rule directive or a general one (e.g. block all icmp error
> > > towards an old SunOS box but let unreachable(couldnt fragment) in
> > > for all other hosts).
> > 
> > In IP Filter 4.0 you can do:
> > 
> > pass in proto tcp ... keep state (no-icmp-err)
> 
> This is too simple. You want to specify e.g. that ICMP_UNREACH_NEEDFRAG is
> allowed through but not ICMP_UNREACH_PORT.

Granted this is "too simple" but the decision is more complex than it
first appears because the matrix of `request' vs `response' is not fixed
and nor is it simply aligned by the icmp type.

With respect to SunOS 4, the dangerous set includes network, host, port
and protocol unreachable messages, as well as all "parameter problem" ones.

So how do you distinguish between them ?

Decide upon a set of known "good" vs "bad" ones with maybe
"no-{bad,good}-icmp-err" ?

Does the user manage this set at all given that's what is good for
one is not necessarily good for another ?

Do you move state checking from being an implicit one to being activated
by a rule such that you can put filtering before state checking ?

Or perhaps do something like "icmp-group 101" and allow users to define
a set of filter rules to check off icmp packets against before allowing
them ?

Darren

[prev in list] [next in list] [prev in thread] [next in thread]