Date: Wed, 21 Mar 2001 21:50:51 +0000 From: Paul Richards <paul@freebsd-services.co.uk> To: Bill Fumerola <billf@mu.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Paul Richards <paul@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw.c Message-ID: <3AB9223B.218966FC@freebsd-services.co.uk> References: <89202.985209871@critter> <3AB91CC0.9F52628A@freebsd-services.co.uk> <20010321153442.H2567@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fumerola wrote: > > On Wed, Mar 21, 2001 at 09:27:28PM +0000, Paul Richards wrote: > > > Configuring any *firewall* without a default deny rule is foolhardy then > > :-) > > locking yourself out of a machine miles away from where you are is probably > just as foolhardy. Absolutely, but it's a simple fact of life today that clients are scattered all over the country and when a client wants a small change made it's not practical to spend two days travelling. What I did was provide a safety net so that most of the time you can provide this sort of support remotely. > if your machine could be compromised/attacked within the span of however > long it takes to reload all your rules, thats some seriously large holes you > have. That's not really the way to look at security. If there's a hole there's a hole. Hoping no-one sees it because it's only there for a short time is trusting to probabilities and that will eventually bite you. Having no firewall rules is about as "seriously large a hole" as you can have. There's also a really nice window of opportunity when the machine is booting up if the default rule isn't deny. > in any event, when I'm done with the ipfw lists support (aka ipfw rulesets, > I can never decide on what to name things...) you'll be able to setup a > list and then atomically switch to it, avoiding the need for hacks like > flush-resistant rules. I'm still not opposed to flushproof rules, done right, > however. That's not really what I was trying to achieve though. The flushproof rules is an implementation detail, I considered others. The point is to be able to set some built-in default that can be fallen back to when you reset everything. Having the ability to mark rules as persistent isn't the same. When you reconfigure a firewall it's good practice to clear the rules and reload them to be sure your startup configuration is the same as your current one, otherwise who knows what might happen after a power loss etc. To do that you have to wipe your whole configuration and reload it, regardless of whether it's made up of groups, immutable rules or whatever. Of course, if you're connected across SSH when you wipe your configuration then you're screwed. What I wanted to do was have a minimal rule set that was protected, only a few rules that suffice keep your SSH connection alive, so that you can do that "wipe the slate clean and make sure it reloads properly" sort of testing remotely with some assurance that you're not going to screw yourself. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB9223B.218966FC>