ipfw: ouch!, skip past end of rules, denying packet

Oleg Bulyzhin oleg at rinet.ru
Fri May 7 04:19:09 PDT 2004


On Fri, 7 May 2004, Luigi Rizzo wrote:

> On Fri, May 07, 2004 at 01:17:22PM +0400, Oleg Bulyzhin wrote:
> ...
> > > Your patch replaces the matching rule with the next one,
> > > which however might still end up being the default rule;
> > > so it does not fix the proble, plus, it might completely
> > > subvert the packet's flow.
> >
> > I've used dn_pkt.rule cause dn_pkt structure has no separate pointer for
> > 'next rule', perhaps we should add it?
>
> the problem is that there is a race here -- you start processing
> the packet, suspend, change the ruleset, then if one_pass=0 restart.
> When you restart,
> the ruleset might have little or nothing in common with the previous
> one, so there isn't really any assumption you can make that doesn't
> open holes in your firewall.
> So i really believe the only sensible choice in the above case
> is either drop the packet, or restart its processing from the
> beginning (but that might have annoying side effects).
>
> Dropping a packet (or a few) during a reconfiguration is not dramatic,
> it might have got lost anyways -- and note, this case is very
> different from reconfiguring a pipe's bandwidth, where you _know_
> what to do with the packet (and still you cannot guarantee
> if it will come out at the desired rate).

You have almost convinced me. Perhaps it would be better to apply default
policy to such packets. Thanks for explanation!

>
> 	cheers
> 	luigii
>

P.S. about your suggestion how to fix it: maybe instead of special check in
     ipfw_chk() would be better to change lookup_next_rule() behaviour in order
     to lookup_next_rule(default_rule) == default_rule?
     (anyway this function is not used for traversing list of rules);

-- 
Oleg.

================================================================
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at rinet.ru ===
================================================================



More information about the freebsd-ipfw mailing list