Date: Mon, 26 Feb 1996 14:12:45 -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: <199602262112.OAA00842@rocky.sri.MT.net> In-Reply-To: <199602262055.OAA15921@brasil.moneng.mei.com> References: <199602261920.MAA00322@rocky.sri.MT.net> <199602262055.OAA15921@brasil.moneng.mei.com>
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.
> 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.
> > 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. :)
> > 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?
> > # 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?
> 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'?
> > > 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. :(
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.
> > 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.
> > 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.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602262112.OAA00842>