Date: Wed, 30 Jan 2002 21:09:40 -0000 From: Matthew Whelan <muttley@gotadsl.co.uk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Thomas T. Veldhouse" <veldy@veldy.net>, andrew.cowan@hsd.com.au, "Nate Williams" <nate@yogotech.com>, "Freebsd-Stable" <freebsd-stable@FreeBSD.ORG> Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <JI75GAYSTRA5PJZYUKGON75TOB88.3c586114@VicNBob> In-Reply-To: <200201292106.g0TL6T748013@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
29/01/2002 21:06:29, Matthew Dillon <dillon@apollo.backplane.com> wrote: > Anyone who intends to use a compiled-in IPFW is going to have firweall > rules. If you forget to add your firewall rules you might as well not > have a network at all (i.e. the machine will be completely useless). > So there's no 'safety' issue in opening up the default closed firewall > in /etc/rc* if the person didn't specify a firewall ruleset. It's possible that the nature of the rules precludes loading them via rc.conf's firewall_* variables - Warner, for example, has a real-life example of this in his network. The meaning in the rest of rc.conf of *_enable=NO is not 'I do not want this feature at all' but 'I do not want rc.* to set this feature up for me; either I want to leave the default state or I want to do something cleverer/ more customised than rc.* is capable of'. Thus firewall_enable=NO doesn't necessarily mean that the admin has 'forgotten' something, it could well be a deliberate choice > The only safety issue we have is simply that we do not want to temporarily > open up the machine while it is in the booting problem. If the booting > process ends with firewall_enable="NO", then at that point we can safely > open up the machine (add the 'allow everything' rule). Well, no, see above. Nate dismisses the install stage (have compiled custom kernel but not yet configured firewall rules) as a 'straw-man' but that's rubbish IMO. Say your gateway has an unfortunate accident and needs replacing with a new machine. First up you'll compile a kernel with gateway and firewalling enabled. You'll also need to pull your firewall rules off tape/the old disk/networked backup/whatever. Your way, if the admin gets the order wrong, the network behind the gateway could be compromised. And don't give me the 'don't rely on firewalls for security' line either, this is the real world. Also, if you reboot and have no network connectivity, you know immedeately there's a problem. Maybe it's a while before someone's physically close enough to the machine to fix it; odds are though that the more people who're inconvenienced by this, the quicker there'll be someone to fix it. But that's the point - the *worst* that can happen is lost time, maybe resulting in a business losing a *small* amount of money. If you reboot and have no filtering, you could run like that for days before you notice, in which time severe damage could have been done to an entire network's worth of real and intellectual assets. There's no way for rc.* to distinguish between saying 'NO' or saying nothing in /etc/rc.conf, and admin error of deleting a line you didn't mean to without noticing is all too plausible. > I've been hit by this piece of nonsense before as well. I would like > to see the rules fixed so it doesn't matter what you compile into the > kernel -- if your firewall_enable is NO, then it should be as if you > don't have a file. So fix the docs (and possibly the variable name) so that the behaviour is obvious to everyone. The ambiguity is the real problem, *not* the behaviour. Quite frankly, though, people remotely rebooting a machine which has been actively configured to have a compiled-in strict firewall don't have any right to complain if they get locked out. > Simple, obvious, straightforward. All this other crap about having to > specify firewall_ options one way if you have the firewall compiled in > and another way if you don't is, well, crap. /etc/rc.conf should work > the same no matter how the kernel is compiled. Exactly. Currently rc.network does just that. If firewall_enable=NO, it does nothing. It does exactly the same nothing if ipfw is compiled in as if it is totally absent. You are proposing that the behaviour should differ. You are propsing that if and only if ipfw is present it should *actively* add a pass-all rule. You are proposing that it should take the view of 'I know better than you, stupid human' - a view which regularly leads me to screaming obscenities at Microsoft products. In fact, what is different here, is not how rc.conf works. It's how the system works. I am sure you'll agree that how the system works *is* something which should depend on how the kernel is compiled. (I quote SMP and SYSV IPC as off-the-top-of-my-head examples). In order to have ipfw present at rc time, someone *must* have *asked* for it to be. They can do this either by compiling it in, or by adding a line to loader.conf (so it's not purely a matter of kernel compilation). FreeBSD should respect that. Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?JI75GAYSTRA5PJZYUKGON75TOB88.3c586114>