Date: Wed, 22 Dec 2010 17:10:12 GMT From: Eugene Grosbein <egrosbein@rdtc.ru> To: freebsd-ipfw@FreeBSD.org Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Message-ID: <201012221710.oBMHACCD082155@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/153252; it has been noted by GNATS.
From: Eugene Grosbein <egrosbein@rdtc.ru>
To: Alexander Verbod <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
Cc: bug-followup@freebsd.org, freebsd-ipfw@freebsd.org,
Ian Smith <smithi@nimnet.asn.au>
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent
call of "/etc/rc.d/ipfw start"
Date: Wed, 22 Dec 2010 23:07:18 +0600
On 22.12.2010 21:03, Alexander Verbod wrote:
> Ian Smith <smithi@nimnet.asn.au> wrote:
>
>> Please treat this as a general discussion of issues, as well as your PR.
>> Try not taking critique too defensively. Perhaps a language problem;
>
> I'd always like to learn from people, but if someone can't see
> difference between /sbin/ipfw and /etc/rc.d/ipfw and point wrongly to manual
> page of /sbin/ipfw(8) while talking many times about some special secret
> 'right way' how to run _START UP_ script - I just simply trying to explain
> that is wrong in my opinion, so no any defense or aggression :)
No secrets here. You was pointed to section that has second paragraph
leading to /usr/share/examples/ipfw/change_rules.sh.
Examples directory, right? This script shows proper way.
> IMHO reloading firewall's rules should be handled by additional command such
> as "reload" or similar but not in the "start" action because "start" must mean
> "start" only.
> Does anybody can start running again for example without prior stopping?
Yes. Why not? :-)
> Start must be start. Official documentation doesn't provide any
> explanation how to handle in a special way some particular _start up_ scripts.
> Right way to applying firewall's rules over network explained very well for
> /sbin/ipfw but not for /etc/rc.d/ipfw and I believe it is right.
/etc/rc.d/ipfw is basically wrapper for /sbin/ipfw, so all rules apply.
> I think it should be kept simple - start up script load initial firewall's
> rule and after that one should handle reloading of firewall's rules with
> own scripts by calling /sbin/ipfw that is intended exactly to do this kind
> of actions.
That's POLA issue. One should not break commands worked for years.
Instead, fix bugs :-) And no, "/sbin/ipfw flush" does NOT break connections.
Really, it does not deal with TCP connections at all.
At application layer, sendto()/send() failure is NOT
a legitimate reason to break session/connection, terminate user session
and cause SIGHUP to be sent to users' processes.
You may use one particular sshd(8) implementation having this misfeature
to maintain the system over network, but it does not mean it's flaws
should bring changes to firewall. You may also use other implementation
possibly not having this bug. This one is in base system - well, that's
another reason to fix bug where it is - inside sshd, but not touch
perfectly working firewall.
> Running command "start" twice is meaningless. If one want to reload
> firewall's rules with
> /etc/rc.d/ipfw then there should be implemented safe command "reload"
> or something else, but I don't think it is a good idea.
> /etc/rc.d/ipfw is a mechanism that generally
> control service - enable it or not.
> If one need just reload firewall's rules it could be done by running
> /etc/rc.firewall script enclosed in guarding script instead of
> "/etc/rc.d/ipfw start", something like this:
>
> /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
>
> or simply
>
> /usr/bin/nohup /bin/sh /etc/rc.firewall
>
> in case if /usr already mounted.
That would work for pre-8 versions of FreeBSD but not anymore
because of coscripts. So, running just /etc/rc.firewall
to reload rules is not an option anymore.
Only /etc/rc.d/ipfw start is right way for now.
> Ian Smith <smithi@nimnet.asn.au> wrote:
>> One of the reasons that people might want to run 'start' again when it's
>> already running is described in (at least) both of:
> I'm sorry, but running twice '/etc/rc.d/ipfw start' isn't solution in that case.
> I think the right solution is to fix logical bug and run natd first before
> loading firewall rules instead of running "start" command twice.
> (BTW, it's impossible to run '/etc/rc.d/ipfw start' on boot twice,
> so it could be a solution)
Here we may have a security issue. Firewall should be loaded
before interfaces brought up. natd may depend on interfaces up and running
to initialize itself properly. For example, it may need to know right MTU
of interface (I can describe why it may need it in detail, if you wish).
Basically, it means that firewall should support its own DIVERT rules
configuration before natd is started (and it supports) and it means
that natd should be started later than firewall, not before.
The system behaves this way now and there are reasons for it.
> Ian Smith <smithi@nimnet.asn.au> wrote:
>> Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good
>> idea when discussing security, which is what a firewall is all about.
> Well, I completely agree with you and Eugene on that if it come to a
> general security. This is kind of topic, but you forget that some
> projects don't need to be opened to the wild internet, it could be an
> automatic stations in closed environment where using ./ in the PATH can
> simplify things a lot without any security issues.
Just use telnet then :-) it won't break sessions AFAIR.
> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> "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.
> Eugene, don't take my words as offense please, lets talk about technical
> aspects only.
> Do you reload MySql with '/usr/local/etc/rc.d/mysql-server start'?
> I guess - no. The same with other services because meaning of word "start"
> is to born new instance of something.
> "/etc/rc.d/ipfw start" isn't exclusion, it should follow human's logic.
> If one want to reload firewall's rules he/she need to implement command "reload".
I'm not against implementing "reload". I'm strongly against breaking POLA
and breaking working setups by prohibition of multiple "/sbin/ipfw start" calls
for sake of someone's logic favour. Instead, one could fix real problem with sshd.
> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> It does not cause lockdown if used in right way, I do this all the time.
> Instead of repeating many times about magic "right way" could you point me
> to documentation where is this "right way" explained?
See above.
> Don't point me to ipfw(8) manual page again please because it describe
> "/sbin/ipfw" but isn't "/etc/rc.d/ipfw".
> There is a big difference between them.
But same rules apply and lead to success :-)
> I didn't saw in the documentation a special 'right way' of using rc.d start up
> scripts. May be I miss something, may be you.
Well, you may consider documentation insufficient (I do not :)
Then, feel free to submit patches for documentation but please,
don't fix what ain't broken.
> You can execute anyone scripts without any parameters in rc.d directory and it
> will show all available arguments that can be passed to scripts.
> I didn't found anyone rc scripts that says it need to be used in a special
> "right way".
> There no and shouldn't be any special tricks to run start up scripts.
There may be any kind of tricks depending on real task
(all "tricks" should be documented, though), for example:
- one should not blindly call rc.d script for natd with "restart" argument
over NAT'ed connection, because THAT may really break TCP connection;
- one should not blindly call rc.d script for routed with "restart" argument
when it may destroy route it's using for pretty long time (RIP diverges slowly);
- one should not blindly call rc.d script for amd/nfsd with "restart" argument
when it's current directory resides on network-mounted file system;
- et cetera, et cetera, et cetera (ipsec, netif, ...)
> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> 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.
> Absolutely agree with you on that - "Disabling firewall is not an option"
> but reloading firewall's rules by employ "/etc/rc.d/ipfw start" isn't
> an option too.
Why not? It works when used right way, and worked for long time.
> Eugene Grosbein <egrosbein@rdtc.ru> wrote:
>> > Did you try all steps described in the "How-To-Repeat" section before replying?
>> Yes. No problems here.
> I bet you did it from system console or by enclosing "/etc/rc.d/ipfw start"
> to surrounding guarding script, otherwise if you don't protect
> '/etc/rc.d/ipfw start' from interruption then first
> "ipfw -f flash" command will broke connection to the box and script
> "/etc/rc.d/ipfw" will stop execution in a middle by leaving box inaccessible
> over network.
My first letter was written in reply to your PR having no words
about running command over network. Or about what your "lock-down" means,
kernel panic? kernel hang? shell process deadlock? I've seen so many
weird effects with FreeBSD over time, so avoid attempts to use telepathy.
Now you know how important it is to be exact in problem reports.
And yes, I generally use screen(1) for remote sessions,
so my connections do not break. And I always use output redirection
for "/etc/rc.d/ipfw start" even for screen-based sessions.
That's the safe and working way.
Eugene Grosbein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012221710.oBMHACCD082155>