Solved Is my pf configuration crazy?

GregTheHun

Member

Reaction score: 1
Messages: 39

OK, after reading the handbook several times, my brain is just not getting what is wrong with my pf.conf:

Code:
set block-policy return
block in all
pass out all keep state
pass in on wlan0 inet6 proto tcp from port 50000 keep state
pass in on wlan0 inet proto tcp from port 50000 keep state

As far as I remember reading the rules should be read from top to bottom, last rule match winning. What I want is some rules saying, "Block everything coming in except for TCP port 50000, and allow everything going out to pass."

Seems pretty basic, but this always block me out.
 
Last edited by a moderator:

Maxnix

Well-Known Member

Reaction score: 218
Messages: 337

OK, after reading the handbook several times, my brain is just not getting what is wrong with my pf.conf:

set block-policy return
block in all
pass out all keep state
pass in on wlan0 inet6 proto tcp from port 50000 keep state
pass in on wlan0 inet proto tcp from port 50000 keep state


As far as I remember reading the rules should be read from top to bottom, last rule match winning. What I want is some rules saying, "Block everything coming in except for TCP port 50000, and allow everything going out to pass."

Seems pretty basic, but this always block me out.
By default PF uses a last matching approach, but using the quick keyword on a rule will tell it to stop evaluation at that rule (if matches).
Moreover you don't need "keep state", it's the default.
This is an example of configuration that should meet your needs:
Code:
# Set default behaviour for blocked packets.
set block-policy return

# Permit all outgoing connections.
pass out quick all

# Permit incoming IPv4 and IPv6 TCP connections on wlan0 from anyone on 
# port 50000.
pass in quick on wlan0 inet proto tcp from any port 50000
pass in quick on wlan0 inet6 proto tcp from any port 50000

# Block all connections that don't match any of the previous rules.
block all
 
OP
GregTheHun

GregTheHun

Member

Reaction score: 1
Messages: 39

Well, locked myself out again (not a system I don't have physical access to, not production either). Now, granted, I still made one edit from your suggestion:

set block-policy return
pass out quick all
pass in quick on wlan0 inet proto tcp from any port 50000
pass in quick on wlan0 inet6 proto tcp from any port 50000
block in all (the only thing I changed)

However, if it does help I'm using port 50000 for ssh, and I know security through obscurity is moot. But better than having scan bots brute forcing, oh well.

Any suggestions?
 

Eric A. Borisch

Aspiring Daemon

Reaction score: 362
Messages: 590

Well, locked myself out again (not a system I don't have physical access to, not production either). Now, granted, I still made one edit from your suggestion:

set block-policy return
pass out quick all
pass in quick on wlan0 inet proto tcp from any port 50000
pass in quick on wlan0 inet6 proto tcp from any port 50000
block in all (the only thing I changed)

However, if it does help I'm using port 50000 for ssh, and I know security through obscurity is moot. But better than having scan bots brute forcing, oh well.

Any suggestions?

from any to port 50000 perhaps?
 

ucc

New Member

Reaction score: 1
Messages: 14

Hi, here is the relevant bit from my default config (using your suggested port) you can leave the block all above:

Code:
### Ports ###
 SshPort = "50000"

### Queues, States and Types ###
 SshState = "flags S/SA keep state"

### default block ###
 block in  log on $ExtIf

### enable ssh ###
 pass in quick on $ExtIf proto tcp from any to $MyHost port $SshPort $SshState

I also use Stateful Tracking Options to block brute forcing (a little nicer than just sec by obscurity) but it work's fine without. Also, it should work fine without the state options.

Are you sure about your interface being correct?

How do you test your set up? Because using
Code:
pfctl -f /etc/pf.conf
should not terminate your ssh session and you can just try to build up a new one, if that fails, clear the rules with the still open ssh.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,691
Messages: 39,288

Test with something like pfctl -f /etc/pf.rules.new && sleep 60 && pfctl -f /etc/pf.rules.

That way if you botch up the rules and lock yourself out, you have to wait 60 seconds and the 'old' rule set will be loaded again. The 60 seconds should be enough to test a few basic things but you can obviously increase the time-out.
 
Top