Date: Tue, 01 Feb 2011 23:45:47 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: PF firewall rules and documentation Message-ID: <4D480E8B.8050207@herveybayaustralia.com.au> In-Reply-To: <AANLkTim_nsAvRPAnsNDOTZzDaQVYri6jmk=ubie9sUTu@mail.gmail.com> References: <4D437DD6.4030202@herveybayaustralia.com.au> <20110131113058.71d4e4e8@mr129041.univ-rennes1.fr> <4D4695D0.1040604@herveybayaustralia.com.au> <AANLkTim_nsAvRPAnsNDOTZzDaQVYri6jmk=ubie9sUTu@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/01/11 00:40, Kevin Wilcox wrote: > On Mon, Jan 31, 2011 at 05:58, Da Rock > <freebsd-questions@herveybayaustralia.com.au> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D480E8B.8050207>