Date: Mon, 31 Jan 2011 09:40:54 -0500 From: Kevin Wilcox <kevin.wilcox@gmail.com> To: Da Rock <freebsd-questions@herveybayaustralia.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: PF firewall rules and documentation Message-ID: <AANLkTim_nsAvRPAnsNDOTZzDaQVYri6jmk=ubie9sUTu@mail.gmail.com> In-Reply-To: <4D4695D0.1040604@herveybayaustralia.com.au> References: <4D437DD6.4030202@herveybayaustralia.com.au> <20110131113058.71d4e4e8@mr129041.univ-rennes1.fr> <4D4695D0.1040604@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >> 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim_nsAvRPAnsNDOTZzDaQVYri6jmk=ubie9sUTu>