Date: Sun, 19 Dec 2010 17:07:45 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Alexander Verbod <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com> Cc: freebsd-ipfw@freebsd.org, Eugene Grosbein <eugen@grosbein.pp.ru> Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Message-ID: <20101219154609.Y81993@sola.nimnet.asn.au> In-Reply-To: <201012182000.oBIK0N6Q022100@freefall.freebsd.org> References: <201012182000.oBIK0N6Q022100@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-812309917-1292738864=:81993 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Sat, 18 Dec 2010, Alexander Verbod wrote: > Eugene Grosbein <eugen@grosbein.pp.ru> wrote: > > > One should not unconditionally disable ability of reloading ipfw rules > > using "/etc/rc.d/ipfw start" command. > > Patch doesn't "unconditionally disable ability of reloading ipfw rules"! > Patch disables the ability to run start up script "/etc/rc.d/ipfw" > with "start" command twice that causes lockdown even if type of firewall > is "OPEN". Please treat this as a general discussion of issues, as well as your PR. There may be a easier solution to this problem than having start fail if the firewall is already enabled .. that is, simply disable the firewall in ipfw_prestart(); it's enabled again in ipfw_poststart() and as you see there, it'd be necessary to test for and disable both IPv4 and IPv6 firewalls anyway. > By the term "reloading" I guess you meant the "restart" command > that's doing stop/start sequence, but not start/start. ;) Yes, stop then start also accomplishes this, but so could _prestart, which should solve the whole 'running it over the network' problem? > > For example, it's used extensively > > in my systems and does not lead to "lock-down". > > Eugene, you could do with your systems whatever you want, but here was > described the bug that appears when used standard, non modified OS. One of the reasons that people might want to run 'start' again when it's already running is described in (at least) both of: conf/148137: [ipfw] call order of natd and ipfw startup scripts http://www.freebsd.org/cgi/query-pr.cgi?pr=148137 and conf/153155: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 both to do with issues re the order of running firewall_coscripts and the loading of needed modules; a patch addressing these issues properly would be good in conjunction with the particular issue you describe. > Did you try all steps described in the "How-To-Repeat" section before replying? > > > > One should learn ipfw(8) manual page including CHECKLIST paragraph > > :) > > Could you check please /etc/rc.firewall for presence of this line > "${fwcmd} add 65000 pass all from any to any" > It's the only one line for "OPEN" firewall's profile. > > One who claim to know ipfw(8) manual page should understand this > firewall's rule that unconditionally allow all traffic in both direction for any > type of protocols. But after running "/etc/rc.d/ipfw start" twice all rules are > flashed and only default rule: > 65535 deny ip from any to any > to take affect. Yes, because you're running /etc/rc.d/ipfw start over the network, which I think disabling the firewall in ipfw_prestart() should fix. Comments? > > and make oneself familiar with proper ways of reloading ipfw over > > network. > > Did I say somewhere that I don't know "proper ways of reloading ipfw > over network"? > If one like to show of, bug report board isn't a good place to do that. > > > 2. Nice catch. > It isn't a catch, it's a report about bugs. Try not taking critique too defensively. Perhaps a language problem; 'nice catch' is a compliment; you caught a bug, it should be ${SYSCTL_W} > > However, that's only one of reasons why it is > > very bad habit to have "./" in PATH. > > It is a perfectly legal operation that shouldn't cause an error on the OS level. > If one can't use a hummer and broke his finger because of that - it isn't mean > that hummer is a bad tool. Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good idea when discussing security, which is what a firewall is all about. > > 3. Please use "diff -u" to make unified diffs, > > they are much easier to read. > > I'm agree with you on that but I used official advice > http://www.freebsd.org/doc/en/articles/contributing/contrib-how.html [..] There's another part of your patch that Eugene didn't comment on that caught my eye: -firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}" + +if checkyesno firewall_nat_enable; then + firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}" +elif checkyesno natd_enable; then + firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}" +fi Firstly, there's no problem with running /etc/rc.d/natd in any case, as it won't do anything (ie is a NOP) unless natd_enable is set in rc.conf. Secondly, having firewall_nat_enable set has no need or use for loading natd, they're quite separate methods of performing NAT. Currently ipfw_prestart() only loads ipfw_nat if firewall_nat_enable is set AND natd_enable is NOT set, but there's no complimentary test for whether to load natd if firewall_nat_enable is set. All in all, we need to define desired behaviour if both are enabled and implement that; this also applies to rc.firewall, which will currently add rules for both firewall_nat AND natd if both are enabled, except for the 'simple' firewall where firewall_nat has not yet been implemented .. see http://www.freebsd.org/cgi/query-pr.cgi?pr=148144 for patch(es). cheers, Ian --0-812309917-1292738864=:81993--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101219154609.Y81993>