A n00b's adventure in the wonderful realm of BSD.

More fun with PF: blocking unwanted guests

Every once in a while, I check my /var/logs/auth to see people knocking on my port 22 door. While I do have a strong password for my user and “PermitRootLogin no” on my /etc/ssh/sshd_config, I’m still not very comfortable with people wanted to get in. Once again, PF came to rescue, delivering an elegant solution. Actually, two.

First, I tried the manual method. Looking in /var/logs/auth and putting the incriminated IPs into a text files. Them I would tell pf to look into that file and block all access for those IPs, like this:

table <blockedips> persist file “/etc/pf.blocked.ip.conf”
block in on bnx0 from <blockedips> to any

The first line defines a table with values in the specified file, then pf will block all connection from the matching IP (bnx0 being my network interface). Simple, but requires some daily maintenance. My next thought was: could I make this process automatic? It appears that I do, and this will be the second method of keeping your lawn clean.

The second solution was found on the web.

table <bruteforce> persist
block quick from <bruteforce>
pass inet proto tcp from any to any port \
ssh flags S/SA keep state (max-src-conn 5, \
max-src-conn-rate 5/30, overload <bruteforce> flush global)

We create another table and block all the IPs from it. Then we populate the table with IPs from users that try connecting to the server and fails to often. If they connect with more then 5 clients to the SSH server and try reconnect 5 times within 30 secs they get added to the table.

Don’t forget to reload pf rules by running, as root:

# pfctl -f /etc/pf.conf

If you want to check the content of any table, just run the following, as root:

# pfctl -t bruteforce -T show

To remove an IP from the table, run:

# pfctl -t bruteforce -T delete <IP>

I think the second option is the most elegant way to keep unwanted guests away. Although I’m pretty sure that the content of the bruteforce table will empty on reboot, but that’s ok since it will be repopulated next time someone fails to properly login.

  1. zerobsd posted this
blog comments powered by Disqus