pf rules

[Erik Norgaard]

Doug Hardie wrote:

>> 1. pf allows short cuts, but these also makes it more difficult to debug. I'd separate NAT from filtering,
> 
> Ok.  I guess you want some white space between them?  Here it is with the white space and comments:
> 
> ext_if="dc0"    
> table <blackhole> persist file "/etc/blackhole"
> table <spamd> persist
> table <spamd-white> persist
> table <spamd-white-local> persist file "/etc/mail/whitelist"
> MAILHOSTS = "{zool.lafn.org}"
> 
> # NAT/RDR Rules
> no rdr on { lo0, lo1 } from any to any
> no rdr inet proto tcp from <spamd-white-local> to any port smtp
> no rdr inet proto tcp from <spamd-white> to any port smtp
> rdr pass log inet proto tcp from any to any port smtp -> 127.0.0.1 port spamd
> 
> # Filter Rules
> pass in log inet proto tcp to $MAILHOSTS port smtp keep state
> pass in log on sis0 reply-to (sis0 192.168.25.1) proto tcp from any to any port 75 keep state
> block in quick log on $ext_if from <blackhole> to any
> 
> Other than the comments I don't see the difference.

you didn't separate nat from filtering, and you didn't add interfaces on 
your rdr rules. When you make these shortcuts, maybe your ruleset 
becomes more compact, maybe it works, but it becomes more difficult to 
debug.

>> that is never use "rdr pass" even though pf allows it. You also need to understand when rdr takes place to write your filtering rules.
> 
> That would be really helpful if that information were available somewhere it could be found.  I have not been able to find that anywhere.  

Basically, for rdr, the address translation takes place before the 
packet is parsed by the filter rules. For nat, it takes place after the 
filtering. For binat, you can think of it as nat in one direction rdr in 
the other.

This is for the first packet, keep state and you don't have to worry 
about the rest.

se also,

http://www.openbsd.org/faq/pf/rdr.html
http://www.openbsd.org/faq/pf/nat.html

>> 2. you can deploy one of two policies: Default block with a whitelist or default pass with a black list. Mixing these is a bad idea.

This is one thing you should see to clarify in your ruleset above. When 
you have both whitelist and blacklist what happens to those that are in 
neither? what happens to those that are in both.

Which default policy makes sense depends on the service. You may want to 
use black lists for smtp but whitelist for ssh for example.

>> anyway, to interpret the output of pflog, you need the output from pfctl -sr and pfctl -sn rather than your config file.
> 
> zool# pfctl -sr
> No ALTQ support in kernel
> ALTQ related functions disabled
> pass in log inet proto tcp from any to 206.117.18.7 port = smtp flags S/SA keep state
> pass in log on sis0 reply-to (sis0 192.168.25.1) inet proto tcp from any to any port = 75 flags S/SA keep state
> block drop in log quick on dc0 from <blackhole> to any

so your filter rules are numbered 0, 1, 2

> zool# pfctl -sn
> No ALTQ support in kernel
> ALTQ related functions disabled
> no rdr on lo0 all
> no rdr on lo1 all
> no rdr inet proto tcp from <spamd-white-local> to any port = smtp
> no rdr inet proto tcp from <spamd-white> to any port = smtp
> rdr pass log inet proto tcp from any to any port = smtp -> 127.0.0.1 port 8025

your rdr rules are numbered 0, .. 4, but you only have log in rule 4.

So, when you see matches in your pflog, rule 0 .. 2 are filter rules and 
rule 4 is rdr rule, which you can also see from the action logged, pass, 
block or rdr. That seems to explain why you have no matches for rule 3.

>> So, to solve your problem, separate first NAT and filtering. Things becomes so much more clear.

Repeated: Get rid of that "rdr pass" make an rdr rule and a pass rule. 
Yes, it's the rule recommended by the spamd man page, but if you want to 
see and understand what's going on, that kind of rules can really make 
things obscure.

BR, Erik

-- 
Erik Nørgaard
Ph: +34.666334818/+34.915211157                  http://www.locolomo.org