From owner-freebsd-stable Mon Feb 26 13:11:36 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16531 for stable-outgoing; Mon, 26 Feb 1996 13:11:36 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16526 Mon, 26 Feb 1996 13:11:31 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA00842; Mon, 26 Feb 1996 14:12:45 -0700 Date: Mon, 26 Feb 1996 14:12:45 -0700 From: Nate Williams Message-Id: <199602262112.OAA00842@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262055.OAA15921@brasil.moneng.mei.com> References: <199602261920.MAA00322@rocky.sri.MT.net> <199602262055.OAA15921@brasil.moneng.mei.com> Sender: owner-stable@freebsd.org Precedence: bulk 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