PF firewall rules and documentation

[Kevin Wilcox]

On Mon, Jan 31, 2011 at 05:58, Da Rock
<freebsd-questions at 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