PF firewall rules

[Michael VInce]

Greg Hennessy wrote:
>  
>
>   
>> So ultimately what your saying is PF is too clever now and 
>> can never be simplified like UDP state modes for single line 
>>     
>
> The notion of UDP keeping state is overstated. 
>
> Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer
> tracking how long it was since the last packet for the reverse flow arrived.
>
>   
>> firewall rules using rough careless flags options on a 
>> firewall rules where everything is just going out keep state 
>>     
>
> One  cannot 'keep state' for TCP in any meaningful fashion without tracking
> the flags + sequencing. 
>
> If you want a primitive packet filtered ACL from point a to b for TCP. 
>
> 	pass out on int inet proto tcp from a to b 
> 	pass in  on int inet proto tcp from b to a
>
> will match all packets and allow that flow. 
>   
While a lot of people are telling me things I already know, its nice to 
be refreshed, on the other side I have seen a few ideas for PF now to 
make maybe slightly cleaner firewall rule set, thanks for this.

I did mention it a few times but I suppose I wasn't clear about it, but 
I really do want to use "single line firewall rules", and the only way 
to do this is to keep state, if there are other ways/rules to have 
really flexible firewall but still with stateful inspection with a small 
amount of rules I would like to see them.
Using double line firewall rules (stateless) is going way past even my 
goal of testing out a less strict (easy going) firewall setup.

My goal has been to have a really simple firewall rule set, strictly 
single line rules per access rule (for the basic stuff), I aimed to have 
all out going connections have only firewall rules that had the keyword 
"out"  for any out going connections or blocks with no "in" rules for 
what I would normally see the other way around, and every thing else 
blocked.
Also to have the TCP keep state rules lean to the point their behavior 
was similar to UDP as in to really pay no attention to flags so I could 
continue with my "testing" and reset the state table as much as I like 
even if I can use the /etc/rc.d/pf resync or the other methods to reload 
rules but still keep the state table.
If you follow these rules very strictly enough they can not be done with 
PF but are a fair bit easier to do with IPFilter.

I thought PF being a new firewall technology that it could do everything 
IPFilter could do in the exact same fashion and more, but it can't and I 
am glad I asked.
Realistically everyone is right to point out that there are plenty of 
compromises such as block "in" on the internal interface etc, I just 
wasn't sure these were the only options and I just once again had to ask.
Some other people might be wondering the same things as me, you never know.

I really was hoping that I could create the rules exactly as how I would 
imagine them to be, but I am ready to make some compromises and I am 
actually have a good feeling I will be more happy with my new rules 
setup then before simply because I know more about my options and 
limitations.

Just like most people I don't see it any other way then the fact that 
single line firewall rules are great, and I never have and never will be 
making any compromises on this. I just don't know if I agree on what 
appears to be overly strict behavior on TCP in regards to its state 
activity and how it could be done for some firewall scenarios like a 
home firewall, but again people can just point out I can just keep my 
state table and reload my rules while using stick keep state methods, I 
just want to test the alternative limits for situations I don't want to 
have to go into, isn't what flexible firewalling technology is about?

As for UDP being stateless I still do see the big benefit of using the 
stateful rules for what they are worth as a more sure way of tracking 
those packets of "who" is initiating those connections, if I go back to 
the true old school ways and have 2 firewall rules for every rule over 
what could be done with a single stateful rule I would still taking a 
step back as I can't be sure some ones loading up some of the old 
classic back door UDP trojans into my network by 'initiating' 
connections into my network.

Mike