Date: Wed, 21 Mar 2001 05:18:32 -0500 From: Daniel Hagan <dhagan@colltech.com> To: Paul Richards <paul@freebsd-services.co.uk> Cc: freebsd-audit@FreeBSD.ORG Subject: Re: ipfw permanent rules Message-ID: <3AB87FF8.C9442D09@colltech.com> References: <3AB857E7.D4CEBD40@freebsd-services.co.uk> <200103210738.f2L7cof42204@gratis.grondar.za> <3AB85B6F.32E9EE7C@freebsd-services.co.uk> <3AB87590.FA684AE7@colltech.com> <3AB8792A.19308025@freebsd-services.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[Reply-To: set for -ipfw & participants] [Summary for -ipfw folk: Paul has a patch which adds an integer sysctl & modifies ip_fw.c. Any ipfw rule numbered below that integer will not be deleted by a flush, effectively making it permanent. This is useful for rules like ssh access, making it safer to modify ipfw rule sets remotely.] Paul Richards wrote: > Daniel Hagan wrote: > > I'm a little concerned that this overrides the meaning of the rule > > numbers. Now they will define what order rules are processed and > > whether they can be flushed. [snip] > > The order of rules processing isn't affected unless you enable this > feature. If you set the rule number above 0 then after a flush all the > presistent rules will be at the front of the chain so in that situation > it's possible for the rule order to get changed when you add back > flushed rules but if you're using this feature then you're going to have > your persistent rules together at the bottom of the number range anyway > so the problem shouldn't arise. Allow me to use a pseudo-ipfw-syntax example: ... 10 deny all from hacker.ip ... 100 allow tcp to port 22 101 allow tcp to port 25 102 allow tcp to port 80 ... I want 100, 101, & 102 to be permanent, but I want to have 10 flushed because it's a temporary rule (generated by portsentry, just as an example). Since the numbers define the order of processing _and_ what is permanent, I can't have this setup. But I certainly don't want to loose the ability to place specific deny rules early on in the stack either. > I looked at making it a per-rule setting but the flags field looks full It looks like the high bit is available in my copy of the source* (once IP_FW_F_MASK is set to 0xffffffff). I could be wrong though. If it is full, we should move to an unsigned long anyway (what are the chances that we won't want to add another flag down the road...). > so it would require extending the struct and modifying the userland > parser. That was too much of a change for what I needed but I might take > a look at extending the functionality later. I think, for it to be added to the base system, the functionality should be as orthogonal as possible. Just my opinion, of course. Daniel * ip_fw.h,v 1.57; it hasn't be supped for a while though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB87FF8.C9442D09>