Date: Sun, 19 Dec 2010 20:25:52 +0600 From: Eugene Grosbein <egrosbein@rdtc.ru> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, Alexander Verbod <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>, bug-followup@freebsd.org, Alexander Verbod <AlexJ@freebsd.forum> Subject: Re: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Message-ID: <4D0E15F0.1000406@rdtc.ru> In-Reply-To: <20101219154609.Y81993@sola.nimnet.asn.au> References: <201012182000.oBIK0N6Q022100@freefall.freebsd.org> <20101219154609.Y81993@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On -9.01.-28163 02:59, Ian Smith wrote:
> 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"!
"unconditionally disable ability of reloading ipfw rules using
'/etc/rc.d/ipfw start' command" - will this way of reloading ipfw rules
work with your patch applied? It seems, no.
> > 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".
It does not cause lockdown if used in right way, I do this all the time.
> > By the term "reloading" I guess you meant the "restart" command
> > that's doing stop/start sequence, but not start/start. ;)
Disabling firewall is not an option.
There must be a way to reload rules without passing packets by meantime.
This way now is "/etc/rc.d/ipfw start" command.
> > > 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.
Of course, with standard OS.
> > Did you try all steps described in the "How-To-Repeat" section before replying?
Yes. No problems here.
> > > 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.
Yes.
> > 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, that's intentional. Then 'allow' rule is loaded again,
if you use the command right way.
> 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?
I don't think we should disable firewall (creating 'open' window).
> > > 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"?
Proper way is the way when your system does not lock down.
> > > 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}
Exactly, thanks for clarification.
> 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.
Nice catch ;-) I've overlooked this.
Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D0E15F0.1000406>