Date: Mon, 26 Feb 1996 15:53:55 -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: <199602262153.PAA16062@brasil.moneng.mei.com> In-Reply-To: <199602262112.OAA00842@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 02:12:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Joe Greco writes:
> > > 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.
>
> When I start, I don't know that it will succeed? When my link goes
> down, it usually means my ISP is having problem and will continue to
> have problems for a couple hours. During that time, a home user will
> dial in to the system. This user may take the ppp0 slot since the
> outside connection isn't used.
So.... I must be missing something. You don't (or shouldn't) CARE if
someone takes the ppp0 slot. You have the flexibility to do it by address,
and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I
recall.
> > This can be driven from sysconfig, OR manually by
> > startslip/ppp/etc. I do this all the time for routing purposes.
>
> I won't know until the PPP link is successful which interface to use.
> Now, the first thing that happens (/etc/ppp/ip-up) is that the ipfw
> entries are added, but there is still that window of opportunity (which
> is acceptable to me) between the time the link goes up but before ip-up
> is run where packets can get into my machine. I consider this
> acceptable for me.
And if it's not, you should still be able to write some rules that solve
your problem. I guess I'm not seeing why you think this is such a problem.
> > > 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.
>
> See my comment. Since we have the ability to close the loophole, my
> concern is to minimize support headaches now. Make the default behavior
> less likely to bit the casual user, and make them shoot themselves in
> the foot by enabling it so they don't ask me questions. :)
I think we agree, but you are "solving" the problem by breaking the tool.
> > > 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...
>
> Support. If we're going to disable it by default, then why have it
> enabled in the first place?
Because!!!! It DOESN'T break the tool to do so. You simply "change your
mind" and allow everything to be routed. You introduce a HOLE in the
wall if you do it the other way around!
> > > # 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.
>
> What's the point of having it then if it's open by default?
Because you're bitching about support issues and how confused people will
be. If we provide a default that is wide open, and samples that are not,
people have the flexibility to choose what they want to do. This is what
you have been arguing FOR!!! Doing it in this manner allows us to ship a
perfect brick wall IPFW that doesn't suffer from "minor instances of
forgetfulness" while rules are being reloaded, but also doesn't break all
the networking services and cause users to scratch their heads.
> > 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.
>
> 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.
But what's the objection to a simple reversal of logic? IF what you say is
true, why can't we build a BETTER firewall than the next guy by reversing
the logic, dealing with the immediate "learning curve" problem that network
administrators may have by putting in a default rule that makes it
"magically work"? Then, when they understand the deal, they can stick in
whatever rules they want. AND those of us who want real firewalling don't
have to contend with a hole in the wall.
> > > > 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}
>
> Ok, now all of my PPP machine are no longer able to speak to my local
> net, which have valid IP address in nates.net. :(
Maybe I don't get what you're trying to accomplish.
> Now I have to go re-write all of my rules and scripts and I've gained
> *NOTHING* because I have to explicitly disable the default rule anyway.
> You're making it *ALOT* more work for me than it needs to be. It
> *doesn't have to be* this hard.
No, you can go to CVS and extract ipfw1.0 and install it and keep your head
in the sand. That seems silly. IPFW needs some changes in order to be
taken seriously. With some changes comes some pain. That is unfortunate.
I agree.
> > > The old behavior was more flexible and made for less confusion. :)
> >
> > Less confusion, maybe. More confusion when it didn't work as
> > expected.
>
> I consider the 'didn't work as expected' to be bugs that are now fixed.
> I have problems with changing the default behavior, not with fixing
> bugs.
So let me stick my "default reversing" line in your ipfw.conf, and you are
once again happy. The rest of us are happy because we have a SOLID
firewall. Life is good.
> > > 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.
>
> I like the way MorningStar's product works in this regard. It shuts
> down the link, when new entries are added, and depending on how
> extensive they are (I don't know what measure they use) it shuts down
> the link completely and re-connects. It reads a file which contains the
> IPFW entries, so if you modify the file you send the firewall program a
> HUP signal to re-read it. Unfortunately, this won't work in our case
> since we are using kernel code, but the general idea is sound. I'm not
> sure how this could be done in FreBSD though.
... 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?199602262153.PAA16062>