PF firewall rules and documentation

[Da Rock]

On 02/01/11 00:40, Kevin Wilcox wrote:
> 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.
>
>    
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>