Solved Is my pf configuration crazy?

[GregTheHun]

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.

 

[Maxnix]

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:

# 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

 

[GregTheHun]

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?

 

[GregTheHun]

Yeah, changed it in sshd_config myself.

 

[Eric A. Borisch]

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]

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

### 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

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]

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.