pf.conf improvements

B

baot

Hi. I'm running pf on a public-facing server. It has a couple of services running and I'd like to protect it as much as I can with a firewall. So, I'm looking for any ideas or changes I could apply to my configuration file. "IP1" is the main IP for the server, "IP2" is a jail. Here is what I'm using:

Code: 
ext_if = "bge0"
set block-policy drop
scrub in all
block in all
block in quick on $ext_if from any to 255.255.255.255
pass out on $ext_if from any to any
pass out keep state
set skip on lo0
block in quick from urpf-failed
antispoof quick for $ext_if
block drop in log (all)  quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 255.255.255.255/32 } to any
block drop out log (all) quick on $ext_if from any to { 10.0.0.0/8, 172.16.0.0/12, 255.255.255.255/32 }
block in from no-route to any
# ssh on host
pass in on $ext_if proto tcp from any to IP1 port 22
# lighttpd on jail
pass in on $ext_if proto tcp from any to IP2 port 80
pass in on $ext_if proto tcp from any to IP2 port 443
# vlc streaming on jail
pass in on $ext_if proto tcp from any to IP2 port 8080
# mumble server on jail
pass in on $ext_if proto tcp from any to IP2 port 25565

I realize security revolves around many other things, I'm just asking about my pf.conf. Thanks.
 
Hello,

Does not look bad, only for TCP IN rules you can use synproxy state. For ssh bruteforce prevention use max-src-conn-rate option (pf.conf(5) - it's all there).
 
Thanks for your reply. I've added synproxy state to the TCP IN rules. I'll also add the ssh bruteforce line. I already monitor the ssh log very closely, but this will help, too.

Any other suggestions are welcome.
 
synproxy is really only used when the firewall itself is not the end-point of an incoming tcp connection, e.g. when the actual end-point is a server behind the firewall. When the firewall is multi-purpose (also a mail/web/ftp server, etc.), a regular keep state is enough (so you can omit it from the rules altogether, because keep state is implied in every rule).
 
...and since block in has been declared above, all block in (not the quick ones), could be also safely stripped, or you might better use block all instead, then remove also further block outs.

Also, pass in implicitly set pass out for that connection, thus global pass out is no longer necessary, unless you intended so.

block drop actually hangs the connection until time out, eating unnecessary resources. For internal network, using block return or set block-policy return is more robust (TCP only though); for external, it might expose a bit of security concern, for example, nmap could examine the reset-packet to identify your host.
 
You must log in or register to reply here.
Back
Top