From owner-freebsd-hackers Fri Dec 15 08:37:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA02509 for hackers-outgoing; Fri, 15 Dec 1995 08:37:14 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA02502 for ; Fri, 15 Dec 1995 08:37:07 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA16535; Fri, 15 Dec 1995 09:39:28 -0700 Date: Fri, 15 Dec 1995 09:39:28 -0700 From: Nate Williams Message-Id: <199512151639.JAA16535@rocky.sri.MT.net> To: "Frank ten Wolde" Cc: Nate Williams , hackers@freebsd.org Subject: Re: Order of rules in ip_fw chain In-Reply-To: <9512151720.ZM309@pwood1.pinewood.nl> References: <9512151302.ZM27077@pwood1.pinewood.nl> <199512151611.JAA16380@rocky.sri.MT.net> <9512151720.ZM309@pwood1.pinewood.nl> Sender: owner-hackers@freebsd.org Precedence: bulk > > > 2) I noticed that the order in which the fw checks incoming packets is > > > *not* the same as the order in which the packet rules were added. > > > IMHO this should be fixed. I have not had the time (yet) to have > > > a look at the source myself, but will do so in the next few weeks. > > > > 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. > > But, you'd need a way to modify the list in non-secure mode, so I think > > the priority based approach is probably more flexible. > > 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 priority simply because it's easier to deal with a fixed upper limit than a fixed lower limit in these schemes) So, if a rule is added that has priority 4, it will be placed *after* any other rules with priorities 0-3. This allow you to set global filters which filter our *all* traffic of a certain kind no matter what the content is, and also allow you to add a new filter rule at a later date on the fly (assuming the security level is ok) to lock out traffic from a hacker site, knowing that it will be placed above any other filter rules which may allow certain types of traffic. This is great for stopping mail spamming and such. Normally, I allow *any* incoming traffic to the smtp port, but if I start getting mail bombed (by accident or otherwise), with priority rules I can add a new rule-set on the fly to block smtp traffic from a particular host which has a higher priority than my previous version. 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, but there are occasions when I need to open up the firewall to 'trusted' hosts, and I'd rather not bring down my Internet connection to do it. Nate