From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 29 17:26:02 2005 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 464FE16A41F for ; Thu, 29 Sep 2005 17:26:02 +0000 (GMT) (envelope-from ap@bnc.net) Received: from mailomat.net (mailomat.net [217.110.117.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74DB43D49 for ; Thu, 29 Sep 2005 17:26:00 +0000 (GMT) (envelope-from ap@bnc.net) X-SpamCatcher-Score: 2 [X] Received: from [194.39.192.125] (account bnc-mail@mailrelay.mailomat.net HELO bnc.net) by mailomat.net (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 5591691 for freebsd-ipfw@freebsd.org; Thu, 29 Sep 2005 19:25:57 +0200 X-BNC-SpamCatcher-Score: 2 [X] Received: from [194.39.192.247] (account ap HELO [194.39.192.247]) by bnc.net (CommuniGate Pro SMTP 4.3.5) with ESMTPSA id 1260233 for freebsd-ipfw@FreeBSD.ORG; Thu, 29 Sep 2005 19:26:00 +0200 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <200509281224.j8SCOJUv047047@lurza.secnetix.de> References: <200509281224.j8SCOJUv047047@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Achim Patzner Date: Thu, 29 Sep 2005 19:25:54 +0200 To: freebsd-ipfw@FreeBSD.ORG X-Mailer: Apple Mail (2.734) Cc: Subject: Re: Enable ipfw without rebooting 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, 29 Sep 2005 17:26:02 -0000 >>> No. Performing a reboot is a rather bad idea. >> >> Actually _loading kernel modules you haven't been using before_ > > Lots of people have been using it before. *You* actually means: You have to have don it yourself, on the machine you want to use it before anyone is putting it to serious tasks. Been there, watched it being done, got a cellar full of t- shirts... > (Personally I prefer to compile it statically in the kernel, though.) Agreed 8-). > Apropos ideas: Not having remote console access to a > machine which is located at 800 km distance is (not only > in my opinion) a stupid idea. ;-) That was not my attempt at being funny ("Oh - yes, I needed that connection on the KVM switch. Didn't I tell you?"). >>> A much better way would be a small "at" job that inserts >>> an appropriate "allow" rule: >>> >> >> Where's the advantage? > > A solution that doesn't require a reboot is always better, > especially on production machines. I prefer doing the reboot thing from time to time, having had quite a history of customers neither testing nor documenting changes in system configuration... It's reducing the number of surprises per boot considerably. > This isn't Windows, after all. Windows' "firewall" couldn't keep me outside either... The problem isn't FreeBSD, it's the idiots in front of it fumbling around with the pitchfork. > For changing (and testing) rules, there's an even more > elegant (and non-[qddisruptive) solution, see: > /usr/share/examples/ipfw/change_rules.sh As I said: It's not about changing the rules, it's about loading kernel modules that could aid you in serious in-the-knee-shooting. > and you must change them very often. "If people were permitted to change their underwear only after changing their password you could even smell the idiots from afar." Achim