From owner-freebsd-ipfw@FreeBSD.ORG Sun Dec 19 06:22:26 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1491E106564A for ; Sun, 19 Dec 2010 06:22:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id BA1E18FC1B for ; Sun, 19 Dec 2010 06:22:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id oBJ67jxb022480; Sun, 19 Dec 2010 17:07:46 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 19 Dec 2010 17:07:45 +1100 (EST) From: Ian Smith To: Alexander Verbod In-Reply-To: <201012182000.oBIK0N6Q022100@freefall.freebsd.org> Message-ID: <20101219154609.Y81993@sola.nimnet.asn.au> References: <201012182000.oBIK0N6Q022100@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-812309917-1292738864=:81993" Cc: freebsd-ipfw@freebsd.org, Eugene Grosbein Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 06:22:26 -0000 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 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-- From owner-freebsd-ipfw@FreeBSD.ORG Sun Dec 19 15:02:52 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16193106566C; Sun, 19 Dec 2010 15:02:52 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id A89D18FC1C; Sun, 19 Dec 2010 15:02:50 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id oBJEPqE9002774; Sun, 19 Dec 2010 20:25:52 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D0E15F0.1000406@rdtc.ru> Date: Sun, 19 Dec 2010 20:25:52 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 MIME-Version: 1.0 To: Ian Smith References: <201012182000.oBIK0N6Q022100@freefall.freebsd.org> <20101219154609.Y81993@sola.nimnet.asn.au> In-Reply-To: <20101219154609.Y81993@sola.nimnet.asn.au> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, Alexander Verbod , bug-followup@freebsd.org, Alexander Verbod Subject: Re: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 15:02:52 -0000 On -9.01.-28163 02:59, Ian Smith wrote: > On Sat, 18 Dec 2010, Alexander Verbod wrote: > > Eugene Grosbein 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 From owner-freebsd-ipfw@FreeBSD.ORG Sun Dec 19 15:10:11 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3127C1065672 for ; Sun, 19 Dec 2010 15:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 04E518FC0A for ; Sun, 19 Dec 2010 15:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBJFAAUe003217 for ; Sun, 19 Dec 2010 15:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJFAAYk003216; Sun, 19 Dec 2010 15:10:10 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 15:10:10 GMT Message-Id: <201012191510.oBJFAAYk003216@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Eugene Grosbein Cc: Subject: Re: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Grosbein List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 15:10:11 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: Eugene Grosbein To: Ian Smith Cc: Alexander Verbod , freebsd-ipfw@freebsd.org, Alexander Verbod , bug-followup@freebsd.org Subject: Re: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Sun, 19 Dec 2010 20:25:52 +0600 On -9.01.-28163 02:59, Ian Smith wrote: > On Sat, 18 Dec 2010, Alexander Verbod wrote: > > Eugene Grosbein 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 From owner-freebsd-ipfw@FreeBSD.ORG Mon Dec 20 11:06:59 2010 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1344F10656C9 for ; Mon, 20 Dec 2010 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E9C2C8FC17 for ; Mon, 20 Dec 2010 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKB6wZJ024564 for ; Mon, 20 Dec 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKB6waG024562 for freebsd-ipfw@FreeBSD.org; Mon, 20 Dec 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Dec 2010 11:06:58 GMT Message-Id: <201012201106.oBKB6waG024562@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o conf/153155 ipfw [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on o kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148928 ipfw [ipfw] Problem with loading of ipfw NAT rules during s o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o conf/148144 ipfw [patch] add ipfw_nat support for rc.firewall simple ty o conf/148137 ipfw [ipfw] call order of natd and ipfw startup scripts o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o kern/122109 ipfw [ipfw] ipfw nat traceroute problem s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet] 6.3-RELEASE-p1 page fault in dummynet (corr o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 81 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Dec 20 18:10:11 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DA0F10656A5 for ; Mon, 20 Dec 2010 18:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3616D8FC2D for ; Mon, 20 Dec 2010 18:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBKIAAvh080781 for ; Mon, 20 Dec 2010 18:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKIAA3F080778; Mon, 20 Dec 2010 18:10:10 GMT (envelope-from gnats) Date: Mon, 20 Dec 2010 18:10:10 GMT Message-Id: <201012201810.oBKIAA3F080778@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Chris St Denis Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris St Denis List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 18:10:11 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: Chris St Denis To: bug-followup@FreeBSD.org, AlexJ@freebsd.forum Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Mon, 20 Dec 2010 09:45:04 -0800 If I understand this problem correctly, the lockdown is caused by the ssh session getting killed off between the "${fwcmd} -f flush" and the subsequent add rules in rc.firewall (or other user-defined custom script). If this is the case, couldn't the issue be resolved with a simple patch along the lines of this? --- ipfw.old 2010-12-20 09:41:02.000000000 -0800 +++ ipfw 2010-12-20 09:42:02.000000000 -0800 @@ -43,7 +43,7 @@ [ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall if [ -r "${firewall_script}" ]; then - /bin/sh "${firewall_script}" "${_firewall_type}" + /usr/bin/nohup /bin/sh "${firewall_script}" "${_firewall_type}" echo 'Firewall rules loaded.' elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then echo 'Warning: kernel has firewall functionality, but' \ -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 15:04:01 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD74D106564A for ; Wed, 22 Dec 2010 15:04:01 +0000 (UTC) (envelope-from UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id AD8068FC1A for ; Wed, 22 Dec 2010 15:04:01 +0000 (UTC) Received: (qmail 4591 invoked by uid 0); 22 Dec 2010 15:04:00 -0000 Received: from 76.122.146.81 by rms-us012.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 22 Dec 2010 10:03:26 -0500 From: "Alexander Verbod" Message-ID: <20101222150358.20060@gmx.com> MIME-Version: 1.0 To: bug-followup@FreeBSD.org X-Authenticated: #110092761 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: OHd6AO1mymCuLavZtjI0BKAiJihyahBL Cc: freebsd-ipfw@freebsd.org, Ian Smith , Eugene Grosbein Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:04:01 -0000 Ian Smith 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 :) Ian Smith wrote: > 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. I don't think that using ipfw_prestart()/ipfw_poststart() mechanism is a good way to resolve this issue. As Eugene already point it out - it will disable firewall for a while that will create window when there will be no firewall protection at all. The simplest way to satisfy everybody is to add on the top of "/etc/rc.d/ipfw" and "/etc/rc.firewall" this string: trap ':' 1 2 5 15; It will guaranty that script doesn't stop in a middle when ${fwcmd} -f flush command will be executed that broke connection anyway but at least it will allow to finish apply firewall rules and then will be possible to relogin again, but I don't think it is a nice solution. 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? 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. 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. 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. Ian Smith 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) Ian Smith wrote: > 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? Well, actually it wasn't me who "running '/etc/rc.d/ipfw start' over the network", it was my students who learning to manage FreeBSD. They wrote some script that accidentally called twice "/etc/rc.d/ipfw start" and I explained them that they couldn't be born twice, so the ipfw service couldn't be logically started twice too. Add code below to /etc/rc.d/ipfw #-------------- extra_commands='reload' reload_cmd='ipfw_reload' ipfw_reload() { /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;" } #-------------- add #-------------- trap ':' 1 2 #-------------- on top of /etc/rc.d/ipfw and /etc/rc.firewall and you'll have safe way to reload firewall's rules if you want. Disabling the firewall in ipfw_prestart() IMHO isn't right. Ian Smith 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. The point is that OS should protected itself from tricks that could be done with ./ in the PATH. Providing full path to the programs on an OS level is always a good idea. Ian Smith wrote: > 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. If it won't to do anything then why OS need to execute additional useless operations? /etc/rc.d/ipfw is already checked in ipfw_prestart() function - is nat needed or not, so no any reason to complicate it. I prefer in source code clear logic - if it isn't needed then it shouldn't be run and this logic IMHO should be handled in one place to guaranty simplicity and independence. It just a couple of strings that wouldn't bloat OS but increase speed of boot process by excluding useless operations. Anyway all this code block could be excluded if nat will be loaded in ipfw_prestart() function that will fix issue shown in PR's: http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 http://www.freebsd.org/cgi/query-pr.cgi?pr=148137 and exclude useless operation such as firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}" in the end of /etc/rc.d/ipfw Eugene Grosbein 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". Eugene Grosbein 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? 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. 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. 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. Eugene Grosbein 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. I guess all our disagreement is because there no command "reload" for ipfw service. Eugene Grosbein 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. Eugene Grosbein wrote: > Ian Smith wrote: > > 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. I don't agree with you guys here. There no any reason to execute /etc/rc.d/natd if it will not be used. Pointless operation. You create multiple dependency that is hard to track it down. Each script should be independent as much as possible and don't relay on assumption that /etc/rc.d/natd wouldn't start never. Why not to handle all logic in one place instead of creating possible holes. It just three additional lines that whouldn't bloat OS to the hell but ensure clear logic of operations and exclude useless running of /etc/rc.d/natd if it disabled. There already exist condition statements in the ipfw_prestart() function that tried to figure out if nat will be used or not, so IMHO better to handle it exactly in that place where test condition was done instead of cheese it up across multiple scripts. From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 15:10:12 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B8F106564A for ; Wed, 22 Dec 2010 15:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9E78FC18 for ; Wed, 22 Dec 2010 15:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMFACQ1043001 for ; Wed, 22 Dec 2010 15:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMFACs1042998; Wed, 22 Dec 2010 15:10:12 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 15:10:12 GMT Message-Id: <201012221510.oBMFACs1042998@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Alexander Verbod" Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Verbod List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:10:12 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: "Alexander Verbod" To: bug-followup@FreeBSD.org Cc: freebsd-ipfw@freebsd.org,"Ian Smith" ,"Eugene Grosbein" Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Wed, 22 Dec 2010 10:03:26 -0500 Ian Smith 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 :) Ian Smith wrote: > 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. I don't think that using ipfw_prestart()/ipfw_poststart() mechanism is a good way to resolve this issue. As Eugene already point it out - it will disable firewall for a while that will create window when there will be no firewall protection at all. The simplest way to satisfy everybody is to add on the top of "/etc/rc.d/ipfw" and "/etc/rc.firewall" this string: trap ':' 1 2 5 15; It will guaranty that script doesn't stop in a middle when ${fwcmd} -f flush command will be executed that broke connection anyway but at least it will allow to finish apply firewall rules and then will be possible to relogin again, but I don't think it is a nice solution. 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? 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. 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. 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. Ian Smith 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) Ian Smith wrote: > 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? Well, actually it wasn't me who "running '/etc/rc.d/ipfw start' over the network", it was my students who learning to manage FreeBSD. They wrote some script that accidentally called twice "/etc/rc.d/ipfw start" and I explained them that they couldn't be born twice, so the ipfw service couldn't be logically started twice too. Add code below to /etc/rc.d/ipfw #-------------- extra_commands='reload' reload_cmd='ipfw_reload' ipfw_reload() { /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;" } #-------------- add #-------------- trap ':' 1 2 #-------------- on top of /etc/rc.d/ipfw and /etc/rc.firewall and you'll have safe way to reload firewall's rules if you want. Disabling the firewall in ipfw_prestart() IMHO isn't right. Ian Smith 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. The point is that OS should protected itself from tricks that could be done with ./ in the PATH. Providing full path to the programs on an OS level is always a good idea. Ian Smith wrote: > 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. If it won't to do anything then why OS need to execute additional useless operations? /etc/rc.d/ipfw is already checked in ipfw_prestart() function - is nat needed or not, so no any reason to complicate it. I prefer in source code clear logic - if it isn't needed then it shouldn't be run and this logic IMHO should be handled in one place to guaranty simplicity and independence. It just a couple of strings that wouldn't bloat OS but increase speed of boot process by excluding useless operations. Anyway all this code block could be excluded if nat will be loaded in ipfw_prestart() function that will fix issue shown in PR's: http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 http://www.freebsd.org/cgi/query-pr.cgi?pr=148137 and exclude useless operation such as firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}" in the end of /etc/rc.d/ipfw Eugene Grosbein 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". Eugene Grosbein 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? 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. 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. 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. Eugene Grosbein 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. I guess all our disagreement is because there no command "reload" for ipfw service. Eugene Grosbein 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. Eugene Grosbein wrote: > Ian Smith wrote: > > 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. I don't agree with you guys here. There no any reason to execute /etc/rc.d/natd if it will not be used. Pointless operation. You create multiple dependency that is hard to track it down. Each script should be independent as much as possible and don't relay on assumption that /etc/rc.d/natd wouldn't start never. Why not to handle all logic in one place instead of creating possible holes. It just three additional lines that whouldn't bloat OS to the hell but ensure clear logic of operations and exclude useless running of /etc/rc.d/natd if it disabled. There already exist condition statements in the ipfw_prestart() function that tried to figure out if nat will be used or not, so IMHO better to handle it exactly in that place where test condition was done instead of cheese it up across multiple scripts. From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 15:17:13 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C61E10656C1 for ; Wed, 22 Dec 2010 15:17:13 +0000 (UTC) (envelope-from UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id E7E858FC17 for ; Wed, 22 Dec 2010 15:17:12 +0000 (UTC) Received: (qmail 27426 invoked by uid 0); 22 Dec 2010 15:17:12 -0000 Received: from 76.122.146.81 by rms-us012.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Wed, 22 Dec 2010 10:08:01 -0500 From: "Alexander Verbod" Message-ID: <20101222151709.20070@gmx.com> MIME-Version: 1.0 To: bug-followup@FreeBSD.org X-Authenticated: #110092761 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: QSQrdeEyx3+iJr2S7mBpF+d8amthc5vU Cc: freebsd-ipfw@freebsd.org, Chris St Denis Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:17:13 -0000 Chris St Denis wrote: > If I understand this problem correctly, the lockdown is caused by the > ssh session getting killed off between the "${fwcmd} -f flush" and the > subsequent add rules in rc.firewall (or other user-defined custom script). You right, "${fwcmd} -f flush" will broke connection to remote machine and start up script stop its execution, so no any firewall's rules applied and only default 65536 deny rule is in charge. > > If this is the case, couldn't the issue be resolved with a simple patch > along the lines of this? > > + /usr/bin/nohup /bin/sh "${firewall_script}" /usr couldn't be available on start up time, so IMHO it will be better to use /bin/sh -T .... as I already show it in the previous post. From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 15:20:08 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357AD1065670 for ; Wed, 22 Dec 2010 15:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD2B8FC18 for ; Wed, 22 Dec 2010 15:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMFK70j054078 for ; Wed, 22 Dec 2010 15:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMFK7PP054077; Wed, 22 Dec 2010 15:20:07 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 15:20:07 GMT Message-Id: <201012221520.oBMFK7PP054077@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Alexander Verbod" Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Verbod List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 15:20:08 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: "Alexander Verbod" To: bug-followup@FreeBSD.org Cc: freebsd-ipfw@freebsd.org,"Chris St Denis" Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" Date: Wed, 22 Dec 2010 10:08:01 -0500 Chris St Denis wrote: > If I understand this problem correctly, the lockdown is caused by the > ssh session getting killed off between the "${fwcmd} -f flush" and the > subsequent add rules in rc.firewall (or other user-defined custom script). You right, "${fwcmd} -f flush" will broke connection to remote machine and start up script stop its execution, so no any firewall's rules applied and only default 65536 deny rule is in charge. > > If this is the case, couldn't the issue be resolved with a simple patch > along the lines of this? > > + /usr/bin/nohup /bin/sh "${firewall_script}" /usr couldn't be available on start up time, so IMHO it will be better to use /bin/sh -T .... as I already show it in the previous post. From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 17:10:13 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C0E11065693 for ; Wed, 22 Dec 2010 17:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D36658FC1B for ; Wed, 22 Dec 2010 17:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMHACEf082156 for ; Wed, 22 Dec 2010 17:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMHACCD082155; Wed, 22 Dec 2010 17:10:12 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 17:10:12 GMT Message-Id: <201012221710.oBMHACCD082155@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Eugene Grosbein Cc: Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Grosbein List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:10:13 -0000 The following reply was made to PR bin/153252; it has been noted by GNATS. From: Eugene Grosbein To: Alexander Verbod Cc: bug-followup@freebsd.org, freebsd-ipfw@freebsd.org, Ian Smith 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 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 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 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 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 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 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 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 From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 17:45:16 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCC7D1065673 for ; Wed, 22 Dec 2010 17:45:16 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id F143A8FC0C for ; Wed, 22 Dec 2010 17:45:15 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id oBMH7NGe040088; Wed, 22 Dec 2010 23:07:23 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D123046.3030501@rdtc.ru> Date: Wed, 22 Dec 2010 23:07:18 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100712 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexander Verbod References: <20101222150358.20060@gmx.com> In-Reply-To: <20101222150358.20060@gmx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Ian Smith , bug-followup@freebsd.org Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:45:16 -0000 On 22.12.2010 21:03, Alexander Verbod wrote: > Ian Smith 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 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 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 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 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 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 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 From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 22 23:10:12 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E48C11065679 for ; Wed, 22 Dec 2010 23:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D41838FC13 for ; Wed, 22 Dec 2010 23:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBMNACm8065830 for ; Wed, 22 Dec 2010 23:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBMNAC3K065828; Wed, 22 Dec 2010 23:10:12 GMT (envelope-from gnats) Date: Wed, 22 Dec 2010 23:10:12 GMT Message-Id: <201012222310.oBMNAC3K065828@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Ceri Davies Cc: Subject: conf/148137 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ceri Davies List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 23:10:13 -0000 The following reply was made to PR conf/148137; it has been noted by GNATS. From: Ceri Davies To: FreeBSD Gnats Submit Cc: Subject: conf/148137 Date: Wed, 22 Dec 2010 22:48:39 +0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This still seems to be a problem in 7.4-PRERELEASE too; the attached patch seems to fix it here. Ceri --6c2NcOVqGQ03X4Wi Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="148137.diff" --- src/etc/rc.d/ipfw 2010-12-04 12:27:32.000000000 +0000 +++ /etc/rc.d/ipfw 2010-12-22 19:38:14.000000000 +0000 @@ -34,10 +34,19 @@ ipfw_start() { + local _coscript local _firewall_type _firewall_type=$1 + # Start firewall coscripts + # + for _coscript in ${firewall_coscripts} ; do + if [ -f "${_coscript}" ]; then + ${_coscript} quietstart + fi + done + # set the firewall rules script if none was specified [ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall @@ -60,16 +69,6 @@ ipfw_poststart() { - local _coscript - - # Start firewall coscripts - # - for _coscript in ${firewall_coscripts} ; do - if [ -f "${_coscript}" ]; then - ${_coscript} quietstart - fi - done - # Enable the firewall # ${SYSCTL_W} net.inet.ip.fw.enable=1 --6c2NcOVqGQ03X4Wi-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 23 13:07:34 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454F01065672 for ; Thu, 23 Dec 2010 13:07:34 +0000 (UTC) (envelope-from zimplex@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6348FC18 for ; Thu, 23 Dec 2010 13:07:33 +0000 (UTC) Received: by iyb26 with SMTP id 26so5181915iyb.13 for ; Thu, 23 Dec 2010 05:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=1tFZypc1+V76wI/LBu+EL9WgKtZ/O7YRNfrb++WrZkc=; b=B3hqW+VmCFP7pZ3yjiwt6gBcCrxsektLld5nJwthhIo8XJL/bskGnkv+1DhApwW/iI IaSm6uECDx/+9fkdg9ug1GOt7j85MP55xoxbGmur+botqeDRZ6w5JYVYEnxhU6Jf0DkF e7W2z3C1Dgl2FhEruPd2hAT4plrpWklWPS4ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ke0FzOZ5hpIv1k7+YDs/hGx1aW5Li+a1lL00a6ELBNOlnNLX73uJ9nIgxc0bexcqJF tP0C0dq9flWJ9DsOUSA1IZET01zmJLL0KbF6bOMJp7iANGB14T7XG3VqEaGtKOss5Fl9 /oEQF6J1H9vUBEJ7xjYqAdtlsNvmlGFIF/IDw= MIME-Version: 1.0 Received: by 10.231.11.72 with SMTP id s8mr8118867ibs.40.1293108207697; Thu, 23 Dec 2010 04:43:27 -0800 (PST) Received: by 10.231.49.1 with HTTP; Thu, 23 Dec 2010 04:43:27 -0800 (PST) Date: Thu, 23 Dec 2010 07:43:27 -0500 Message-ID: From: Ramon Amable Gonzalez Peguero To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: please i need information about shipping of parameters to ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 13:07:34 -0000 I need documentation, like I can send the real-time rule to ipfw from a program created in ansi c From owner-freebsd-ipfw@FreeBSD.ORG Thu Dec 23 14:58:59 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F869106566B for ; Thu, 23 Dec 2010 14:58:59 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE818FC16 for ; Thu, 23 Dec 2010 14:58:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id oBNEwus4056588 for ; Fri, 24 Dec 2010 01:58:56 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 24 Dec 2010 01:58:55 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Message-ID: <20101223233437.Q27345@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Request for policy decision: kernel nat vs/and/or natd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 14:58:59 -0000 Folks, [ If someone implements an /etc/rc.d/ipfw reload command that reliably works over a remote session without any open firewall window, great, but I'd rather not discuss the related issues below in reponses to any PR ] In order to address issues (and PRs) introduced by and since adding kernel nat and more recently firewall_coscripts, before offering any code it's clearly necessary to determine policy for what we should do when both natd_enable and firewall_nat_enable are set in rc.conf. "Don't do that" is not a policy, people will and already are bumping into this, affecting startup scripts and nat[d] rules in rc.firewall. We could: 1) Preference kernel nat over natd when both are enabled. 2) Preference natd over kernel nat when both are enabled. 3) Load both, including both modules, and include both nat and divert rules in the firewall constructed by rc.firewall types and/or another script configured as firewall_type - as happens now with rc.firewall, except kernel nat rules may crash if ipfw_nat isn't loaded, as below. My vote, so it's out of the way, is for (1). We've already seen people enabling firewall_nat while still having natd enabled, and to me it seems clear that adding firewall_nat will be intended to supercede natd. I think this would require a new test in /etc/rc.d/natd as well, or perhaps just making the prefixing of natd to _coscripts conditional. Relatively recent ipfw_prestart (paste, tabs lost) has chosen (2): 1.17 mtm 23: ipfw_prestart() 24: { 25: if checkyesno dummynet_enable; then 26: required_modules="$required_modules dummynet" 27: fi 1.19 emax 28: 29: if checkyesno firewall_nat_enable; then 30: if ! checkyesno natd_enable; then 31: required_modules="$required_modules ipfw_nat" 32: fi 1.24 ! dougb 33: fi ie ipfw_nat module is only required when natd is NOT also enabled - but this won't affect anything with ipfw_nat in kernel, or loaded at boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=153155 doesn't address the above quandary, but does provide what seems to be the necessary and correct fix for that and 2 other 2010 PRs, namely, again de-tabbed: --- rc.d/ipfw (revision 216439) +++ rc.d/ipfw (working copy) @@ -31,6 +31,10 @@ required_modules="$required_modules ipfw_nat" fi fi + + if checkyesno natd_enable; then + required_modules="$required_modules ipdivert" + fi } ipfw_start() which removes any temptation to suggest running /etc/rc.d/natd first. Then there's rc.firewall .. currently the NAT section (except for firewall_type="simple") will load both nat and divert rules, perhaps fortunately having the same rule number (again, pasted): case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} fi ;; esac case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_interface} ${firewall_nat_flags}" else firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac Garrett Cooper ran into this a while ago. We later figured that as the divert rule reenters the firewall at the next higher-numbered rule, not the next rule, then only natd would actually be invoked - but still it's not an ideal situation in the face of a possibly not uncommon config. Suggested patches (David Naylor's or mine) to add kernel nat support to 'simple' ruleset in http://www.freebsd.org/cgi/query-pr.cgi?pr=148144 would generate two different-numbered rules now if both were enabled, so this is another place where a clear decision on policy 1,2 or 3 above (or 4 if you've got a better idea :) would be really helpful. cheers, Ian PS I've got both 7.4-PRE and 8.2-PRE installed here, and apart from the IPv6 stuff, /etc/rc.d/{ipfw,natd} are in synch between both versions, and also with HEAD if I'm not mistaken. It's a bit harder to tell when http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ipfw is out of date at least re what's in 7.4-PRE, ie rev 1.15.2.6 2010/08/17 21:28:40 jhb From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 24 00:40:37 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD26106566C for ; Fri, 24 Dec 2010 00:40:37 +0000 (UTC) (envelope-from szander@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id CCDCC8FC13 for ; Fri, 24 Dec 2010 00:40:36 +0000 (UTC) Received: from [136.186.229.101] (szander-laptop.caia.swin.edu.au [136.186.229.101]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id oBO0IHVV024273 for ; Fri, 24 Dec 2010 11:18:17 +1100 Message-ID: <4D13E6CA.7080005@swin.edu.au> Date: Fri, 24 Dec 2010 11:18:18 +1100 From: Sebastian Zander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IPFW extension for traffic classification based on statistical properties X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 00:40:37 -0000 Hi all, We believe this may be of some interest to list members, and apologise in advance for any duplicates you may receive. We are pleased to announce DIFFUSE v0.1, our first release of a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE v0.1, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) techniques to assign flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify classes of applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. DIFFUSE v0.1 contains an example classifier model for identifying real-time first person shooter game traffic. In the next release we will include a classifier model to detect Skype traffic. The project site (http://caia.swin.edu.au/urp/diffuse) contains a more comprehensive introduction, including application examples, links to related work and documentation describing the design of our software. DIFFUSE v0.1 is a set of patches for FreeBSD-CURRENT, and can be obtained directly from http://caia.swin.edu.au/urp/diffuse/downloads.html The software was developed as part of the DIFFUSE research project at Swinburne University's Centre for Advanced Internet Architectures. The project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. We welcome your feedback and hope you enjoy playing with the code and tools. Cheers, Sebastian Zander and Grenville Armitage http://caia.swin.edu.au From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 24 02:41:33 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DD1106566B; Fri, 24 Dec 2010 02:41:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D442F8FC16; Fri, 24 Dec 2010 02:41:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBO2fWwO079295; Fri, 24 Dec 2010 02:41:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBO2fW7v079291; Fri, 24 Dec 2010 02:41:32 GMT (envelope-from linimon) Date: Fri, 24 Dec 2010 02:41:32 GMT Message-Id: <201012240241.oBO2fW7v079291@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153415: [ipfw] [patch] Port numbers always zero in dynamic IPFW rules for SCTP over IPv4 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 02:41:33 -0000 Old Synopsis: Port numbers always zero in dynamic IPFW rules for SCTP over IPv4 New Synopsis: [ipfw] [patch] Port numbers always zero in dynamic IPFW rules for SCTP over IPv4 Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Fri Dec 24 02:41:08 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153415