From owner-freebsd-current Tue Feb 27 05:02:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA16880 for current-outgoing; Tue, 27 Feb 1996 05:02:06 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA16875 Tue, 27 Feb 1996 05:02:04 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0trP1J-0003wXC; Tue, 27 Feb 96 05:00 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA13804; Tue, 27 Feb 1996 14:00:40 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Rodney W. Grimes" cc: nate@sri.MT.net (Nate Williams), jgreco@brasil.moneng.mei.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 15:55:33 PST." <199602262355.PAA15114@GndRsh.aac.dev.com> Date: Tue, 27 Feb 1996 14:00:40 +0100 Message-ID: <13802.825426040@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > > > > It's not punching any hole in the code. *ALL* of the firewall products > > > > I've used (not extensive by any means) are open by default and require > > > > the user to explicitly close them. If a user mis-configures the > > > > firewall it's their problem in all of the other products, why is it now > > > > FreeBSD's problem to make the users 'smarter'? > > > > > > I've never seen a firewall product that is open by default. That is an > > > oxymoron. > > > > A firewall is *always* open by default. You determine what it is to > > firewall against. All of them haven't told me how to make policy, or > > force me to 'revert' behavior. Firewalls don't make policy, they > > enforce policy. > > It is not a firewall if it is always open, it is just a plain old router :-) > And per the RFC's FreeBSD can not, and does not, ship with even IP forwarding > turned on. Amen. By doing it so the default is "deny all", we solve a couple of nasty corner cases: 1. You can "ipfw flush" and then add your rules, without leaving the door open in the meantime. 2. If you get your rules wrong you wont by accident leave some crap through. 3. It is clearly visible for the user what will happen if nothing is explicitly defined before. 4. Statistics are gathered on this policy rule, just like for the rest of the rules, so you can see if they do what you want. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.