Date: Fri, 15 Dec 1995 14:17:40 -0700 From: Nate Williams <nate@rocky.sri.MT.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: nate@rocky.sri.MT.net (Nate Williams), hackers@freebsd.org Subject: Re: Order of rules in ip_fw chain Message-ID: <199512152117.OAA17558@rocky.sri.MT.net> In-Reply-To: <199512151950.UAA00783@labinfo.iet.unipi.it> References: <199512151639.JAA16535@rocky.sri.MT.net> <199512151950.UAA00783@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo writes: > > > > Ugen was supposed to be working on this a while back. I agree that > > > > something should be done. His work was going to allow 'priority' based > > > > rules, which I agree would be a good thing. Either that or allow the > > > > rules to be listed in the same order in the kernel as they are added. > > > > > > Tell me more about 'priority' based rules, I don't grasp the basic idea > > > behind it (could be because it's Friday late-afternoon :-). > > > > Basically, with priority based rules, you attach a 'priority' on the > > rule which causes this ruls to be placed above all other rules with > > a higher priority number. (I'm assuming that priority 0 is the highest > > Priorities are nice, but kind of hard to implement. Huh? Using a simple priority queue they are cake, and priority queus are *very* simple to write. > Moreover, an ordering between rules with the same priority is still > required to achieve a deterministic *and* easili predictable > behaviour. This would be based on the order of the file. > What I do to set the firewall is to have a script like this > > ipfw -n flush > ipfw -n policy deny > ... filtering rules > > Whenever I need, I modify the script and re-run it. Sure, there > is a hole in between the two commands where unwanted connections > might get in, but the probability is quite low *and* a simple change > to the 'flush' command can allow the firewall to set the default > policy as well. This is what I do as well because I *can't* do any priority based ordering now, but with priority based ordering I test things easier. > All in all, I would just try to make additions to the firewall chain be > stored in the same order as they are made. I still think adding priorities would make things easier, and would allow less mistakes with users if they can know that rules are placed in an order in the tree, IMHO. > > Finally, while I agree that not allowing the filtering rules is a good > > thing, I'm of the opinion that it's much better to allow changing it > > without having to reboot the system. I have a pretty good set of rules, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > it is non-trivial to determine if the rules work, and expecially > to fix unwanted behaviours, given the unknown addition order. > Hopefully it is deterministic. The current system is not the optimal solution. My comment above was in regards to the desire for the addition to the code to not allow firewall updates if the system was in securelevel > 0. I like to run my firewall system fairly secure, but if I couldn't do firewall updates it would be a hinderance more than a help to me. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512152117.OAA17558>