Date: Mon, 26 Feb 1996 14:55:26 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: nate@sri.MT.net (Nate Williams) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <199602262055.OAA15921@brasil.moneng.mei.com> In-Reply-To: <199602261920.MAA00322@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 12:20:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Why not? Stick a few rules with a variable in a script that is called when
the interface is started. This can be driven from sysconfig, OR manually by
startslip/ppp/etc. I do this all the time for routing purposes.
> Now, I can explicitly force the old behavior by adding a rule to open up
> the world, but I haven't gained anything.
YOU haven't, but you haven't lost anything either. On the other hand, it's
fixed a loophole in ipfw, and OTHERS have gained something.
> 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:
Why not just put in the sample ipfw.conf I gave at the end of the last
message...
> # 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.
And that is plain and simple bull. The problem is circumventable at that
level. Just use our heads and stick in a wide-open ipfw.conf. I *agree* we
can't ship something out the door that is network-dumb!!!! But if we can do
a simple wide-open configuration and SOLVE your support problem AND not
punch a needless hole in IPFW, LET'S DO IT.
> > 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?
% cat /etc/ppp/ip-up
ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address}
would work for me.
> > I'm not clear on what the problem that you perceive is.
>
> The old behavior was more flexible and made for less confusion. :)
Less confusion, maybe. More confusion when it didn't work as expected.
More flexible? We'll see where this is all taken in the end. I suspect the
new stuff will be most flexible.
Either way I think it needs to be documented.
> > 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?
I wasn't aware that that's how other firewalls work.
Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun
it, not having to worry about even small holes opening when "ipfw f" runs.
This is all about making IPFW act like a REAL firewall. Real firewalls
DON'T open holes. We have no reason to argue with this change.
The sample ipfw.conf I gave in my last message addresses your concerns,
provides a system that performs as you expect, yet does not have any of the
holes that the rest of us are worried about. If we can agree that this is a
MOST optimal solution, let's put this to bed.
Thanks,
... Joe
-------------------------------------------------------------------------------
Joe Greco - Systems Administrator jgreco@ns.sol.net
Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602262055.OAA15921>