Date: Mon, 26 Feb 1996 12:20:04 -0700 From: Nate Williams <nate@sri.MT.net> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <199602261920.MAA00322@rocky.sri.MT.net> In-Reply-To: <199602261903.NAA15710@brasil.moneng.mei.com> References: <199602261540.IAA29287@rocky.sri.MT.net> <199602261903.NAA15710@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Greco writes:
> > Poul-Henning Kamp writes:
> > > > If you ^C your way to a shell prompt, there's a single rule that's in the
> > > > firewall list saying "deny all from any to any". Courtesy of the same recent
> > > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt
> > > > failed").
> > >
> > > If you call this "brain-damage" then you quite clearly don't need IPFW.
> >
> > I understand that it's there to stop a race condition where folks can
> > 'get into' the system before the FW rules are brought in. However, ...
>
> THIS can be generally solved by installing the rules before configuring the
> interfaces (at least that's how I do it).
I can't do this on my box, since I don't know which interface is going
to be used for my outgoing PPP connections until after the interface is
completely up. That's the disadvantage of keeping the system running
all the time no matter what the network affair is. The current system
won't allow me to do this now.
Now, I can explicitly force the old behavior by adding a rule to open up
the world, but I haven't gained anything.
The reason I think it should be open is because of support. Making the
system unable to talk to *anything* at bootup is going to cause more
support headaches than it's worth. If we add a line to /etc/sysconfig
similar to:
# Set this to yes if you want to avoid *any* possibiity of un-authorized
# packets from getting into your system.
# Note:
# By setting this to YES, *NO* network data will be allowed into your
# system, which may cause mis-configured firewalls to take a *very*
# long # time to boot if they rely on external networking services.
SECURE_IPFW=NO
> The disadvantage is that if you re-install the rules, you probably
> flush the old ones first, and you leave a small opening. That is not
> terrible but the ideal solution would address it. Argument FOR
> keeping this "default" rule, IMHO.
I disagree for support reasons. See above.
> > > QED: Setup your filters before anything gets passed.
> >
> > I can't do this on my box at all. It's a PPP connection, and *all* of
> > the filtering is done on my PPP interface, which can vary depending on
> > incoming calls. So, by having a default 'global' firewall entry I have
> > a couple problems.
>
> That's true.
>
> > 1) There is no established way to have it be on a per-process. This is
> > *bad* news for me since my PPP box is also my DNS/router. I can't wait
> > for my PPP connection to come up before I add entries, and I want all of
> > my local machines to have access to *everything* on my router box.
>
> But your local machines are well known:
>
> ipfw addf pass all from nates.net/24 to nates.router
>
> You can run a script when your PPP link {goes up, comes down} that installs
> further firewall entries to deal with your Internet connection, including
> correct dynamic addresses, etc.
Which I do. However, how do I filter out packets from machines that
*appear* to be mine from external now that I've setup the above default
rule?
> I'm not clear on what the problem that you perceive is.
The old behavior was more flexible and made for less confusion. :)
> In my opinion having the default drop rule is a good idea. It closes some
> small windows of opportunity. But it will confuse the hell out of
> people.
Yep. I think we should make it really easy to add a default 'close'
rule, but leave the stock behavior, because of the confusion. Make the
user explicitly firewall everything rather than forcing him to open up
things. This is the behavior all other firewalls take, so why should we
be different?
> > > Wrt to the rule #65535 "deny all from any to any", then you are correct,
> > > you cannot delete it. It represents the default policy of "anything not
> > > specifically allowed, is banned.
> >
> > While I understand why (see above), I still don't think this should be
> > the 'global' default behavior. It should be applied on a specific
> > interface since every gateway must have 2 interfaces, and only one will
> > need the 'block everything' rule.
>
> Yes, but which one? The current setup doesn't worry about it, it assumes
> you will open up the interface you want opened. And paranoids like me do
> actually firewall both interfaces :-)
There have been two people on the list that disagree with the 'policy'
decision, and two that agree. I think we should go with the behavior
other firewall vendors use and let the user choose his own default
policy, which you and Poul are free to do.
> > Yes, I understand that I can add a
> > 'open up everything' rule on my ethernet, but it'll also be necessary
> > for all of my incoming PPP/SLIP connections. Also, how does this affect
> > the PPP/SLIP startup code? Can a connection be established with the new
> > IPFW code in place?
>
> Sure. I already run the firewall rule config script before starting any
> interfaces. That works. (I don't see how it would interfere with a
> connection being established anyways, we are firewalling at the protocol
> level, not the byte level).
I wasn't sure if some of the 'startup' code required some IP traffic
late in the game.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602261920.MAA00322>