From owner-freebsd-questions@FreeBSD.ORG Tue Feb 1 13:49:17 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 158231065672 for ; Tue, 1 Feb 2011 13:49:17 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8298FC0A for ; Tue, 1 Feb 2011 13:49:16 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.186]) by mail.unitedinsong.com.au (Postfix) with ESMTP id 2AF755C44 for ; Tue, 1 Feb 2011 23:56:22 +1000 (EST) Message-ID: <4D480E8B.8050207@herveybayaustralia.com.au> Date: Tue, 01 Feb 2011 23:45:47 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101227 Thunderbird/3.0.11 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <4D437DD6.4030202@herveybayaustralia.com.au> <20110131113058.71d4e4e8@mr129041.univ-rennes1.fr> <4D4695D0.1040604@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PF firewall rules and documentation X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:49:17 -0000 On 02/01/11 00:40, Kevin Wilcox wrote: > On Mon, Jan 31, 2011 at 05:58, Da Rock > wrote: > > >> Yes. Me unfortunately, but I did manage to pick it up quite quickly though. >> I had a little thief attack one of my ports and attempt login on the >> firewall. I had to change it to 'block in $log on $ext_if all >> block out $log on $ext_if all' to actually block the traffic. Bit of a doozy >> really, I'm still monitoring the traffic very closely with tcpdump on the >> interface and not the log. >> > Unless you have an explicit need to block in/out, it's easier to > maintain a ruleset that uses > > block log on $ext_if > > For example, I use the following as a "starting point" for some of my > routing firewalls: > > ============================= > > int_if=bge1 > ext_if=bge0 > > set skip on lo > > # block everything > block > > # NAT rule > pass out log(all) on $ext_if from ($int_if:network) to any nat-to ($ext_if) > # allow traffic in on the internal interface > pass in on $int_if from ($int_if:network) to any keep state > > ============================= > > There are at least three things in that basic config that some people > would jump on me for. > > 1) why block all if I'm then allowing every in on the internal interface? > 2) why block all if I'm allowing everything out on the external interface? > 3) why not pass everything on the internal interface and then filter > on the external? > > The shortest answer is because I happen to like that starting point > and it serves as a syntactical reminder if I deploy without a pf > reference handy. > > Regarding 1) and 2), the longer answer is that I like to control > traffic flow. I don't want to allow inbound connections on the > external interface and I don't have a need for the firewall to connect > to machines inside the NAT. On my bridges I'll set skip on the > internal interface and filter on the other but I don't like doing that > for a router. > > No jumping here- just a big fat ditto! But that was the point of this whole thread- that block statement doesn't cut it. I started there and noticed a little sneak getting through anyway. Set it to the block explicitly and bam! No problem. Just a little heads up anyway... >>> There are some plans to update PF to a more recent version. So may >>> be it will be better. >>> >>> >> Actually, that sounds like a better idea than mine ;) Kills 2 birds with one >> stone then... >> > I am truly excited about this as the NAT and RDR stuff was > significantly cleaned up (and the OpenBSD pf FAQ is a great resource). > I'm even more excited about the patch to tcpdump that Daniel just sent > to freebsd-pf@ that allows you to tcpdump a pfsync device and pull the > state creation/updates - in my opinion, that's the weakest area for a > BSD firewall (we'll ignore span ports on routers since you can bridge > two addressed interfaces and create a span of that bridge) and being > able to easily pull those NAT translations fulfills some serious > accountability issues. > You think?! Man I was scratching a bit trying to translate between versions there- not too long, but long enough to a PITA. It would be nice to have it all nice and tidy... > If you need a reliable printed reference, you should really consider > picking up Hansteen's _The Book of PF_, available from No Starch > Press: > > http://nostarch.com/pf2.htm > > I have the first edition and it's incredible but somewhat dated. The > author suggests the second edition for FreeBSD 8.x+. > > kmw > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >