Re: Firewall config non-intuitiveness
On Mon, Jan 28, 2002 at 12:17 -0800, David Raistrick wrote: > > It IS confusing though. > > Especially when man rc.conf says: > >firewall_enable (bool) Set to ``NO'' if you do not want have firewall > rules loaded at startup, or ``YES'' if you do. > > that sort of implies that it would disable it...but only an > implication. Huh? `uname -sr` please! :) You must have been in front of a different system. Consulting a running "FreeBSD 4.4-STABLE" as well as the -CURRENT source for "$FreeBSD: src/share/man/man5/rc.conf.5,v 1.149 2002/01/21 10:28:18 mpp Exp $" I haven't seen anything different from firewall_enable (bool) Set to ``YES'' to load firewall rules at startup. If the kernel was not built with IPFIREWALL, the ipfw ker- nel module will be loaded. See also ipfilter_enable. I didn't feel too much like replying again in the thread since all the points seem to have been made. The thread mostly seems to continue for the purpose of counting votes. So I try to put my view here while inviting those who search for a solution, too, to followup to the PR I filed (http://www.freebsd.org/cgi/query-pr.cgi?pr=34355). I'm still not convinced that reinterpreting a "leave it alone, I know better" as "magically disable things for me, since I might want you to do so" is a good idea. This kind of sounds like the Windows approach to me where assistants try to guess what the user meant. This change in meaning is especially bad when the things to be disabled explicitely have been introduced into the system, have security impact and should guard a machine (i.e. disabling them weakens the machine). What would we do next? Automatically enable routing as soon as more than one NIF becomes available? Go the SuSE route and automatically start X just because it gets installed on disk? Oops, I'm side stepping ... Sorry, but I (strongly) feel that disabling a packet filter should have to be done in a more explicit way than just leaving a variable at its default setting (remember: there's no way of knowing if the admin said "NO" or if this is left from the /etc/defaults/rc.conf script). Especially when the filter was compiled into the kernel upon the admin's explicit request. We are not talking about GENERIC kernels as they are shipped with the distro here where firewall_enable=NO has and always had the effect everybody around expects. So the variable might be renamed to "firewall_load_ruleset" (of course with a HEADS UP) and could get a third setting of DISABLE_IPFW next to the YES and NO which remain in their "load the ruleset" and "don't load a ruleset" meaning. Until then the comment next to the firewall_enable variable should make clear that not the whole filter is enabled / disabled but a ruleset might get loaded or not depending on the switch. That's why I started PR conf/34355 where those with the tristate patch might want to follow up. Maybe the rc.conf manpage should explicitely state that nothing happens in the NO case (but then it should for *any* _enable variable ...) -- this is missing in the PR. I still consider the current situation an education/documentation issue, not wrong behaviour. And I don't consider the _enable variable for the firewall any different from the other _enable variables. None of them does any disabling for me while all of them allow me to not enable/activate a certain aspect (with the option for me to do these things not at all or in a different way or in a different location). And since none of these variables have the word "disable" in them I don't expect any of them to disable something for me. They just allow me to start things in a regular, suggested location. There's still a difference between not acting and actively preventing something (strictly speaking disabling something is an action -- and in the case we discuss here there are already means for this like sysctl.conf and firewall_type). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Nate Williams <[EMAIL PROTECTED]> types: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > Maybe we're having an English language question. I'd say you are. > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. No. Failing to enable something doesn't mean that you disable it. Those are both actions. It's also possible that to take no action whatsoever. Tanya Harding disabled Nancy Kerrigan. Nobody else in the world disabled her. By your logic, they all must therefore have enabled her, which clearly isn't the case. Most of them did nothing. A small number of people did the things necessary to enable her to skate again. That said, I don't really have an objection to changing the variable name, or making it tristated, or some such to avoid this confusion. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Mon, Jan 28, 2002 at 12:53:42PM -0700, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. > > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. > > If I enable the clutch in my car, my car moves (assuming it's in gear). > If I disable it, the power is no longer going to the drive wheels. True, but the real question is what does firewall_enable actually enable and disable? In its current state it enables and disables the adding of rules as defined by firewall_type (rc.conf(5)). The docs could be a little better about what will happen if you set firewall_enable="NO", and have it compiled into your kernel. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> : If I enable the clutch in my car, my car moves (assuming it's in gear). > : If I disable it, the power is no longer going to the drive wheels. > > That's not quite right, but it is a good analogy. If you disable your > clutch, then you are going to have to shift without it and deal with > putting it into gear at stops. Unfortunately, you can't do it w/out a clutch. (At least, not without tearing your clutch/transmission to bits). > If you enable your clutch, then you > can use it to help in shifting. This isn't quite the same as what you > said, and an analogous condition exists with the firewall rules. "help in shifting"? I'd call a clutch the most critical part of a transmission. W/out a clutch, you don't have a transmission. > Also, when you enable apm, you aren't enabling power management. Sure you are. > That's done in the BIOS. You are enabling the OS using the power > management. If you don't enable apm in the OS, power management won't be done. It (the BIOS) sends the commands to the OS, which ignores them, and the BIOS does nothing. (It means that you can't shutdown the box automatically when the power gets low, etc...) > If you set apm_enable to NO, then the OS doesn't enable power > management, but at the same time it doesn't go down to the BIOS to > turn off the power management settings in the BIOS. Because that wouldn't do much. > The effects in this case are almost identical, but some BIOSes will > still spin down the hard disk, etc even when APM isn't engaged. Not w/out OS participation on any of the dozen or so laptops I've owned, or any of the desktops. > When you say sendmail_enable=no, it doesn't prevent another mailer > from binding to port 25. No, but it disables 'sendmail' from binding to port 25. Note the item is 'sendmail_enable', not 'mail_enable'. > It just fails to start sendmail, which is the default behavior for the > system. If you have sendmail_enable=NO, it doesn't go through and > delete the mail queue, or make it impossible to run sendmail from a > cron job. Who said anything about making anything impossible? Saying 'firewall_enable'=NO doesn't disable the system from using the firewall in the future. It doesn't recompile the kernel and remove the FIREWALL capability from the kernel, and/or delete ipfw.ko from the system. Now you're being silly. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Mon, 28 Jan 2002, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. > > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. It would so appear...but there is this alternative: The firewall is already on. If there is not an explicit disable, it is still on. firewall_enable="NO" wouldnt be a "disable" just a "do nothing. if on, leave on, if off, leave off." It IS confusing though. Especially when man rc.conf says: firewall_enable (bool) Set to ``NO'' if you do not want have firewall rules loaded at startup, or ``YES'' if you do. that sort of implies that it would disable it...but only an implication. I guess that it leaves to the obvious that if it is enabled through a method other then the rc.conf, it is up to the user..er..admin...to know that. anyway. i probably should have read how this all started...:p ...david --- david raistrick (no longer deep in the south georgia woods) [EMAIL PROTECTED] http://www.expita.com/nomime.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
In message: <[EMAIL PROTECTED]> Nate Williams <[EMAIL PROTECTED]> writes: : If I enable the clutch in my car, my car moves (assuming it's in gear). : If I disable it, the power is no longer going to the drive wheels. That's not quite right, but it is a good analogy. If you disable your clutch, then you are going to have to shift without it and deal with putting it into gear at stops. If you enable your clutch, then you can use it to help in shifting. This isn't quite the same as what you said, and an analogous condition exists with the firewall rules. If you engage your clutch, then you can shift. If you disengage your clutch then your car will go if it is gear (and won't if it isn't). Also, when you enable apm, you aren't enabling power management. That's done in the BIOS. You are enabling the OS using the power management. If you set apm_enable to NO, then the OS doesn't enable power management, but at the same time it doesn't go down to the BIOS to turn off the power management settings in the BIOS. The effects in this case are almost identical, but some BIOSes will still spin down the hard disk, etc even when APM isn't engaged. When you say sendmail_enable=no, it doesn't prevent another mailer from binding to port 25. It just fails to start sendmail, which is the default behavior for the system. If you have sendmail_enable=NO, it doesn't go through and delete the mail queue, or make it impossible to run sendmail from a cron job. I'd argue that the firewall_enable is poorly named, but does the same thing. At most we should rename it to ipfw_maybe_load_ipfw_and_then_load_rules to be 100% correct. firewall_enable=YES means, right now: 1) If ipfw isn't in the kernel, load it. 2) load the rules firewall_enable=NO means do nothing. Same as when sendmail_enable=NO. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> Note that "do not enable firewall" (which is implied by firewall_enable="NO") > is *not* equivalent to "disable firewall". Maybe we're having an English language question. If something isn't enabled, doesn't that imply that it's disabled? Last I checked, enabled/disabled were binary operations. If I enable the clutch in my car, my car moves (assuming it's in gear). If I disable it, the power is no longer going to the drive wheels. It's either enabled or disabled. There is no 'in-between' state. (Well, unless you're riding the clutch, but that's not considered a valid state, since the behavior is undefined, as well as bad for your clutch. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Michael Sierchio wrote: > > Nate Williams wrote: > > > > > > See above. It can easily be done in a more standard way. (One can > > > > argue that the '-z' should be the default flag, but so far I've failed > > > > to convince Warner of this fact. :) :) > > > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > > looked at it) seems to assume exactly one network interface, and > > > I was never able to get the "standard" way to work properly with > > > two. > > > > You don't have to use pccard_ifconfig. You can use the normal > > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > > as easily. > > Right, I discovered this after updating my pccard_ether... With the -z > flag the cards get configured in order -- that is, the card in slot0 > gets configured first, and everything seems to work right. Thanks again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> > > > See above. It can easily be done in a more standard way. (One can > > > > argue that the '-z' should be the default flag, but so far I've failed > > > > to convince Warner of this fact. :) :) > > > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > > looked at it) seems to assume exactly one network interface, and > > > I was never able to get the "standard" way to work properly with > > > two. > > > > You don't have to use pccard_ifconfig. You can use the normal > > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > > as easily. > > Right, I discovered this after updating my pccard_ether... With the -z > flag the cards get configured in order -- that is, the card in slot0 > gets configured first, and everything seems to work right. Thanks again. Glad it helped! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Nate Williams wrote: > > > > See above. It can easily be done in a more standard way. (One can > > > argue that the '-z' should be the default flag, but so far I've failed > > > to convince Warner of this fact. :) :) > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > looked at it) seems to assume exactly one network interface, and > > I was never able to get the "standard" way to work properly with > > two. > > You don't have to use pccard_ifconfig. You can use the normal > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > as easily. Right, I discovered this after updating my pccard_ether... With the -z flag the cards get configured in order -- that is, the card in slot0 gets configured first, and everything seems to work right. Thanks again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> > See above. It can easily be done in a more standard way. (One can > > argue that the '-z' should be the default flag, but so far I've failed > > to convince Warner of this fact. :) :) > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > looked at it) seems to assume exactly one network interface, and > I was never able to get the "standard" way to work properly with > two. You don't have to use pccard_ifconfig. You can use the normal ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just as easily. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
I have to go along with common sense and logic with this one. I was once burnt by it about 2 years ago. I compiled it in and set it to NO in .rc and nothing going thru. Strange, NO means no right?, it is a control knob to the kernel so NO must disable it right?. And disabled means the same as not in there right? If it means something else then say so clearly. I read this as allow "# firewall_type=open in /etc/rc.conf when first enabling this feature" similarly "firewall_enable="NO" means allow also. This problem cost me several hours of work, I was thinking that the compile was wrong because it did not make any sense. I say NO and it is dead so I boot GENERIC w/o firewall it works therefore the compile must have borked it. Recompile, tweak etc... LINT was/is Not comprehensive nor clear on that point! Just one of those things I guess, forget it for now. This thread brings up that damn problem of days past and that it was Not me. Everyone is new to Freebsd at some time but this goes beyond that, It should make common sense and not be an illogical nightmare. Say what you mean and be coherent about it. John R. Long sstec.com At 03:50 PM 1/27/2002, Patrick Greenwell wrote: >On Sun, 27 Jan 2002, Gerhard Sittig wrote: > > > I filed a PR which does adjust the rc.conf comment (I understand > > that LINT resp. NOTES as well as "man 5 rc.conf" both told the > > originator of the thread what would happen while rc.conf was too > > short and not authoritative enough a source to stop him from > > shooting into his foot). > >I didn't address this issue earlier because I was more concerned with >having something called "firewall_enable" do something that made sense >when it was set to no. However, since you along with a couple of others >have made the claim that this mislabled behavior is well-documented, I'd >like to point out why I believe you are mistaken. > >Here's the relevent "documentation" that has been mentioned: > > >From LINT: > ># WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" ># and if you do not add other rules during startup to allow access, ># YOU WILL LOCK YOURSELF OUT. It is suggested that you set ># firewall_type=open in /etc/rc.conf when first enabling this feature, ># then refining the firewall rules in /etc/rc.firewall after you've tested ># that the new kernel feature works properly. > >See anything in there about the firewall_enable variable? Anything that >says something along the lines of "the firewall_enable variable has no >effect if set to no?" > >While we're on the subject, the above documentation is incomplete as it fails >to mention that you need to set firewall_enable to yes in order for the >rc.firewall script to be executed(if I'm reading /etc/rc.network correctly.) > >The results of following the documentation outlined in LINT as written is >that you'd still be locked out of your box. > >and here's the info from the rc.conf man page > >firewall_enable >(bool) Set to ``YES'' to load firewall rules at startup. >If the kernel was not built with IPFIREWALL, the ipfw >kernel module will be loaded. See also ipfilter_enable. > >See anything in there about setting firewall_enable to "no"? > >So much for well-documented behavior. > >Really, I'm just arguing for doing something that makes sense, and the >current behavior does not qualify, regardless of how long it's been >understood to be broken that way. Even if this behavior were adequately >documented, which it isn't, it's extremely user-unfriendly to have no mean >yes. > >At this point I'm rather reticent to even bother submitting anything to >the "security officer" role as Warner has indicated that he's part of that >role and will speak out against it in the name of security. I'm not a >member of the inner circle, just a long-time user who saw some confusing >behavior and thought that there was an opportunity to fix it. > >I'll go tilt at some other windmills now. :-) > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ >Patrick Greenwell > Stealthgeeks,LLC. Operations Consulting > http://www.stealthgeeks.net >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Sun, Jan 27, 2002 at 10:27:48AM -0700, M. Warner Losh wrote: [snip] > Right now what I have works. You are changing the semantics of a > security related feature of the system in such a way that after this > change what I have will not work. I agree that your work around will > allow me to easily correct things. However, if I fail to do so, I > open my firewall up completely. To me, that's an unacceptible change > in the API. I agree that changing this in -STABLE may be too much of a disruption in the API. It may be too late. That's why I think this discussion has been necessary. However, changing the behavior in -CURRENT... That's a whole different issue (but not really a topic for this list). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Gerhard Sittig <[EMAIL PROTECTED]> types: > On Sun, Jan 27, 2002 at 11:57 -0600, David Syphers wrote: > > [ ... surprise ... ] As others have pointed out this behavior is > > documented, but we must remember that a variable name itself is the most > > important and immediate documentation. And having a firewall load when > > firewall_enable is NO is complete nonsense. > So maybe the variables should be named a little longer to fully > describe their effect? Like > firewall_ruleset_script_run_enable_when_set_to_yes? If you're going to do it, do it right: firewall_load_ipfw_if_needed_then_run_ruleset_script_when_set_to_yes http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
In message: <[EMAIL PROTECTED]> "Crist J. Clark" <[EMAIL PROTECTED]> writes: : Warner, if the proposed change were to be made, you could get the same : effect by doing, : : firewall_enable="YES" : firewall_script="/dev/null" : : Which I think more accurately describes the behavior you want (if : someone were to browse the rc.conf and try to understand your : configuration, they'd be more likely to understand what you are trying : to do if they saw the above). You want to enable firewalling, but : don't want to load any rules. But I don't want it to fail unsafely. That's the part that I still do not like about the change and why I'm making a big deal out of it. This is a security feature that you are proposing that we depart from our long standing tradition and make fail unsafely. rc scipts shouldn't take things out of the kernel that people have specifically compiled into the kernel. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Warner, if the proposed change were to be made, you could get the same effect by doing, firewall_enable="YES" firewall_script="/dev/null" Which I think more accurately describes the behavior you want (if someone were to browse the rc.conf and try to understand your configuration, they'd be more likely to understand what you are trying to do if they saw the above). You want to enable firewalling, but don't want to load any rules. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
In message: <[EMAIL PROTECTED]> Nate Williams <[EMAIL PROTECTED]> writes: : > You still haven't responded to my comment that I have it setup like : > this on some of my boxes so that I can do things that don't fit in : > well with the current firewall paradigm. Nor to my comment that we : > shouldn't be changing a security feature in a fail*UN*safe way. : : Explain to me how disabling the firewall with 'FIREWALL_ENABLE=NO' can : be unsafe? Because I have the firewall compiled into my kernel with the setting to not pass any packets. Due to some strange network stuff on my end, I don't load the actual rules until way late in the boot process, later than the normal firewall rules. I go from having the system not passing any packets, to the system passing only those that the firewall rules allow. Most of the reason I do this is because I have to get data on usage patterns from another system, and can't do that early enough in the boot process. The rules I have are dynamic based on how much bandwidth the coop has used so far this month and other conditions that change from time to time. Right now we do default route AFTER we load the firewall rules. However, the usage data is on another machine, not on my local segment. We've also found that the wireless link we have does better when bandwidth limited during bad weather (again, the data isn't on the router, but on another machine not on its local segment). Another reason would be because we would be communicating with a host that accepts only ipsec connections. This too happens after the firewall rules are added. While we don't do this today, it won't be too long into the future before we do do this. : Can you show me *ANY* system that uses a closed down firewall that also : has FIREWALL_ENABLE=NO? That would be the only 'safe->unsafe' : transition, since otherwise the default firewall setup is wide-open. rover.village.org has such a setup today. : > I'll grant that I might be in the minority here, but I sure don't want : > my the ability to use my firewall going away after my "next" : > mergemaster change because you were helpful and unloaded/disabled : > stuff for me. : : Fixing something that's broken is still fixing something. If you don't : want a firewall, then why have it activated and enabled? (This is a : rhetorical question.) Because I don't want the automatic firewall rules to happen at the place in the boot sequence where they happen now. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> You still haven't responded to my comment that I have it setup like > this on some of my boxes so that I can do things that don't fit in > well with the current firewall paradigm. Nor to my comment that we > shouldn't be changing a security feature in a fail*UN*safe way. Explain to me how disabling the firewall with 'FIREWALL_ENABLE=NO' can be unsafe? Can you show me *ANY* system that uses a closed down firewall that also has FIREWALL_ENABLE=NO? That would be the only 'safe->unsafe' transition, since otherwise the default firewall setup is wide-open. > I'll grant that I might be in the minority here, but I sure don't want > my the ability to use my firewall going away after my "next" > mergemaster change because you were helpful and unloaded/disabled > stuff for me. Fixing something that's broken is still fixing something. If you don't want a firewall, then why have it activated and enabled? (This is a rhetorical question.) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, 25 Jan 2002, Bob K wrote: > > I could be mistaken, but it would seem to me that the number of > > individuals that really want to deny all traffic to and from their > > machine(which is the current result of setting firewall_enable to no) > > is relatively small. > > If the variable name gets changed to, say, LOAD_FIREWALL_RULES, with the > rc scripts spitting out a warning (and otherwise behaving as expected) > if ENABLE_FIREWALL is encountered, then the number of people that gets > surprised by the change would be zero. That number would be higher > than zero if the variable behaviour is changed. The variable behavior is non-sensical. Do you continue doing things that don't make sense simply due to inertia? (I feel a PHB story coming on...) Further, doesn't the act of adding variables "suprise" people? > As for people that want to deny all traffic, I can think of at least one > case where this might be desired: People who only want connectivity > enabled after a PPP or SL/IP or some scripted link with user > intervention comes up. It is always easy to find edge cases which is why I try to avoid speaking in absolutes. In any case, do you believe that there are thousands of people out there running systems in the particular fashion you describe above? /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, 25 Jan 2002, Mike Meyer wrote: > Patrick Greenwell <[EMAIL PROTECTED]> types: > > On Fri, 25 Jan 2002, Bob K wrote: > > > The problem is that you're not taking into account the installed base of > > > users who twiddle this knob. How many angry firewall admins will come > > > into being when the behaviour suddenly stops being, "don't load any > > > firewall rules" and starts being, "disable the firewall"? > > I could be mistaken, but it would seem to me that the number of > > individuals that really want to deny all traffic to and from their > > machine(which is the current result of setting firewall_enable to no) > > is relatively small. > > Actually, that's the base you want to start with when building a > firewall. You then go on to allow in traffic that you want to pass > through. That's right, but it that case you wouldn't be setting firewall_enable to "no" since you *want* a firewall. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
Patrick Greenwell <[EMAIL PROTECTED]> types: > On Fri, 25 Jan 2002, Bob K wrote: > > The problem is that you're not taking into account the installed base of > > users who twiddle this knob. How many angry firewall admins will come > > into being when the behaviour suddenly stops being, "don't load any > > firewall rules" and starts being, "disable the firewall"? > I could be mistaken, but it would seem to me that the number of > individuals that really want to deny all traffic to and from their > machine(which is the current result of setting firewall_enable to no) > is relatively small. Actually, that's the base you want to start with when building a firewall. You then go on to allow in traffic that you want to pass through. This is really a security issue. If you're tweaking the firewall for a machine, what do you want to happen if you screw so badly the rules aren't loaded: 1) nobody can get to the machine, or 2) the machine is wide open to the world. #1 is clearly the more secure behavior, and thus makes sense as the default. Yes, it means that in the case where you've built a custom kernel with a firewall and not set up any firewall rules, the rc.conf firewall_enable variable is a bit odd; after all, you've enabled the firewall already. If you want it to behave the other way when you build a custom kernel, you can. Personally, I think the current behavior of making things more secure is the better default. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, Jan 25, 2002 at 05:40:04PM -0800, Patrick Greenwell wrote: > > > The problem is that you're not taking into account the installed base of > > users who twiddle this knob. How many angry firewall admins will come > > into being when the behaviour suddenly stops being, "don't load any > > firewall rules" and starts being, "disable the firewall"? > > I could be mistaken, but it would seem to me that the number of > individuals that really want to deny all traffic to and from their > machine(which is the current result of setting firewall_enable to no) > is relatively small. If the variable name gets changed to, say, LOAD_FIREWALL_RULES, with the rc scripts spitting out a warning (and otherwise behaving as expected) if ENABLE_FIREWALL is encountered, then the number of people that gets surprised by the change would be zero. That number would be higher than zero if the variable behaviour is changed. As for people that want to deny all traffic, I can think of at least one case where this might be desired: People who only want connectivity enabled after a PPP or SL/IP or some scripted link with user intervention comes up. -- Bob <[EMAIL PROTECTED]> | Please don't feed the sock puppet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, 25 Jan 2002, Bob K wrote: > The problem is that you're not taking into account the installed base of > users who twiddle this knob. How many angry firewall admins will come > into being when the behaviour suddenly stops being, "don't load any > firewall rules" and starts being, "disable the firewall"? I could be mistaken, but it would seem to me that the number of individuals that really want to deny all traffic to and from their machine(which is the current result of setting firewall_enable to no) is relatively small. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, Jan 25, 2002 at 05:05:48PM -0800, Patrick Greenwell wrote: > > You know, I continue to be amazed at the attitude that says that things > should be kept counter-intuitive and anyone who doesn't like it that way > is ignorant. What possible benefit is there in perpetuating mislabeled > behavior? > > To me, it's very simple: there's this "firewall_enable" option in rc.conf, > and I think that reasonable people would infer that if you set it to "no" > it meant that you didn't want a firewall enabled(based on the name of the > variable), yet that is not what happens. > > All the documentation reading in the world isn't going to make me think it's a > good idea to have "no" mean "yes" and I certainly don't think it's useful or > helpful to cast aspersions on individuals who want "no" to actually mean "no." The problem is that you're not taking into account the installed base of users who twiddle this knob. How many angry firewall admins will come into being when the behaviour suddenly stops being, "don't load any firewall rules" and starts being, "disable the firewall"? Perhaps the variable could be renamed to something more specific. -- Bob <[EMAIL PROTECTED]> | Please don't feed the sock puppet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
On Fri, 25 Jan 2002, Thomas T. Veldhouse wrote: > > > It only works the way > > > complained about when you build your own custom kernel with IPFIREWALL > and > > > not with IPFIREWALL_DEFAULT_TO_ACCEPT. At that point, I think the admin > > > needs to educate one self. I prefer to leave it as is, as it errs on > the > > > side of safety. > > > > I am not sure that making the system pretty much unusable really errs > > on the side of safety. I guess brick, cut off from the world, is > > pretty secure. We always need to balance security versus other > > factors and usability is one of the big ones. > > No -- it implies that you should know what you are doing if you are going to > be building and installing new kernels and working on you firewall remotely. > There is NOTHING stopping you from getting onto the machine with a good old > fashioned keyboard. You know, I continue to be amazed at the attitude that says that things should be kept counter-intuitive and anyone who doesn't like it that way is ignorant. What possible benefit is there in perpetuating mislabeled behavior? To me, it's very simple: there's this "firewall_enable" option in rc.conf, and I think that reasonable people would infer that if you set it to "no" it meant that you didn't want a firewall enabled(based on the name of the variable), yet that is not what happens. All the documentation reading in the world isn't going to make me think it's a good idea to have "no" mean "yes" and I certainly don't think it's useful or helpful to cast aspersions on individuals who want "no" to actually mean "no." /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Firewall config non-intuitiveness
> On Fri, Jan 25, 2002 at 07:51:33AM -0600, Thomas T. Veldhouse wrote: > > It works as expected using the GENERIC kernel. > > Because when there is no firewall in the kernel and firewall_enable is > not set to "YES", there is no firewall loaded. This behavior would not > change. In fact this can be an argument for the suggested change, it > would make behavior more consistent between systems without built-in > firewalling and ones with firewalling. Behavior is very consistant. It loads the ipfw module if needed and runs the firewall script. > > > It only works the way > > complained about when you build your own custom kernel with IPFIREWALL and > > not with IPFIREWALL_DEFAULT_TO_ACCEPT. At that point, I think the admin > > needs to educate one self. I prefer to leave it as is, as it errs on the > > side of safety. > > I am not sure that making the system pretty much unusable really errs > on the side of safety. I guess brick, cut off from the world, is > pretty secure. We always need to balance security versus other > factors and usability is one of the big ones. No -- it implies that you should know what you are doing if you are going to be building and installing new kernels and working on you firewall remotely. There is NOTHING stopping you from getting onto the machine with a good old fashioned keyboard. > > > There is a message to this respect right in the LINT configuration file. > > > > # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" > > # and if you do not add other rules during startup to allow access, > > # YOU WILL LOCK YOURSELF OUT. It is suggested that you set > > firewall_type=open > > # in /etc/rc.conf when first enabling this feature, then refining the > > # firewall rules in /etc/rc.firewall after you've tested that the new kernel > > # feature works properly. > > It doesn't actually mention that you need to set firewall_enable="YES" > here, but I really do not think there is a problem with the current > documentation either. You don't actually have to if you don't want to. You can set the proper sysctl in /etc/sysctl.conf if you like. > > I _do_ think that having firewall_enable="NO" actually disable the > firewall would be more useful. Right now, there is no supported way to > boot up a system with firewalling built into the kernel and actually > disable the firewalling. I think that should be an option. That's > really what makes the change attractive to me. (I have wanted to do > this in the past, I had to enable firewalling, load an "open" rule > set, before I could flip 'net.inet.ip.fw.enable' off.) That tells me that you should either leave it as a module or add IPFIREWALL_DEFAULT_TO_ACCEPT to your kernel config. Both are something that is an educated administration choice. The only time that firewall_enable="NO" is a problem is when you consciously put IPFIREWALL into the kernel. It really is up to you to make sure you at least know a little about what you are doing when you begin messing with a new kernel and building a firewall. I still believe the current knobs in rc.conf work just fine and I don't believe they should be changed at all as they pertain to this discussion. Tom Veldhouse [EMAIL PROTECTED] > > > - Original Message - > > From: "Crist J. Clark" <[EMAIL PROTECTED]> > > To: "Patrick Greenwell" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Friday, January 25, 2002 12:03 AM > > Subject: Re: Firewall config non-intuitiveness > > > > > > > On Thu, Jan 24, 2002 at 08:21:50PM -0800, Patrick Greenwell wrote: > > > > > > > > I recently got bit by this: I have firewall options configured into my > > > > kernel, and made the mistake of thinking that in order to disable > > > > this functionality to allow all traffic that I merely needed to remove > > the > > > > firewall_enable paramater from my rc.conf since firewall_enable is set > > to NO in > > > > /etc/defaults/rc.conf. > > > > > > > > This did not have the intended result of disabling the firewall, rather > > a > > > > default deny was applied. If firewall_enable is set to NO, wouldn't it > > make > > > > more sense to have the init scripts set net.inet.ip.fw.enable to 0, or > > am I > > > > missing something? > > > > > > > > Opinions welcome. > > > > > > I think this is a valid point. When 'firewall_enable="NO"' the > > > firewalling should be disabled with the n
Re: Firewall config non-intuitiveness
On Fri, Jan 25, 2002 at 07:51:33AM -0600, Thomas T. Veldhouse wrote: > It works as expected using the GENERIC kernel. Because when there is no firewall in the kernel and firewall_enable is not set to "YES", there is no firewall loaded. This behavior would not change. In fact this can be an argument for the suggested change, it would make behavior more consistent between systems without built-in firewalling and ones with firewalling. > It only works the way > complained about when you build your own custom kernel with IPFIREWALL and > not with IPFIREWALL_DEFAULT_TO_ACCEPT. At that point, I think the admin > needs to educate one self. I prefer to leave it as is, as it errs on the > side of safety. I am not sure that making the system pretty much unusable really errs on the side of safety. I guess brick, cut off from the world, is pretty secure. We always need to balance security versus other factors and usability is one of the big ones. > There is a message to this respect right in the LINT configuration file. > > # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" > # and if you do not add other rules during startup to allow access, > # YOU WILL LOCK YOURSELF OUT. It is suggested that you set > firewall_type=open > # in /etc/rc.conf when first enabling this feature, then refining the > # firewall rules in /etc/rc.firewall after you've tested that the new kernel > # feature works properly. It doesn't actually mention that you need to set firewall_enable="YES" here, but I really do not think there is a problem with the current documentation either. I _do_ think that having firewall_enable="NO" actually disable the firewall would be more useful. Right now, there is no supported way to boot up a system with firewalling built into the kernel and actually disable the firewalling. I think that should be an option. That's really what makes the change attractive to me. (I have wanted to do this in the past, I had to enable firewalling, load an "open" rule set, before I could flip 'net.inet.ip.fw.enable' off.) > - Original Message - > From: "Crist J. Clark" <[EMAIL PROTECTED]> > To: "Patrick Greenwell" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, January 25, 2002 12:03 AM > Subject: Re: Firewall config non-intuitiveness > > > > On Thu, Jan 24, 2002 at 08:21:50PM -0800, Patrick Greenwell wrote: > > > > > > I recently got bit by this: I have firewall options configured into my > > > kernel, and made the mistake of thinking that in order to disable > > > this functionality to allow all traffic that I merely needed to remove > the > > > firewall_enable paramater from my rc.conf since firewall_enable is set > to NO in > > > /etc/defaults/rc.conf. > > > > > > This did not have the intended result of disabling the firewall, rather > a > > > default deny was applied. If firewall_enable is set to NO, wouldn't it > make > > > more sense to have the init scripts set net.inet.ip.fw.enable to 0, or > am I > > > missing something? > > > > > > Opinions welcome. > > > > I think this is a valid point. When 'firewall_enable="NO"' the > > firewalling should be disabled with the net.inet.ip.fw.enable > > sysctl(8). > > > > That said, it _may_ be a little late to make this change in > > -STABLE. Although the name may be misleading, I think the rest of the > > documentation is accurate. Besides all the stuff people have quoted > > about the 'options IPFIREWALL' in the kernel, I think rc.conf(5) is > > fairly clear, > > > > firewall_enable > >(bool) Set to ``YES'' to load firewall rules at > startup. > >If the kernel was not built with IPFIREWALL, the ipfw > ker- > >nel module will be loaded. See also ipfilter_enable. > > > > In that it only says special things happen when it is "YES" and > > doesn't say it is explicitly disabled when set to "NO." Since this is > > such a security critical option, I really hesitate when it comes to > > changing this in -STABLE. -CURRENT OTOH... -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
