PF Blacklisting and/or whitelisting in (BSD) pf

J

jordanch

I am considering a pf rule like this:

Code: 
pass in on $ext_if inet proto tcp
from <ssh_clients>
to ($ext_if) port $myssh keep state
(max-src-conn 9, max-src-conn-rate 2/5,
overload <blocked_guests> flush global)

But I am not sure if allowing ssh connections only from a whitelist (ssh_clients) will still allow for the brute forcers table (unwelcome_guests) to be populated. My vague suspicion is that since the rule will ignore those requests anyway, it might not get so far as overloading them into the table. Or will it? I guess it boils down to how pf actually executes rules...
And if it won't, how can I do both - accept connections "from" only a predetermined table, and also add bruteforcers into the corresponding table? Does it make sense to do both?
Lastly: which is more efficient - blacklisting or whitelisting? Or a combination of both?
 
The blocked_guests would only be filled by brute-forcers originating from ssh_clients because the rule is specific to those source addresses. Connections from other IP addresses (not listed in ssh_guests) would never hit this rule.

Instead of trying to re-invent the wheel you should take a look at blacklistd(8), security/sshguard and security/py-fail2ban.
 
SirDice Many thanks for confirming my suspicion. I was indeed looking at fail2ban, but only for the app server, I'll now also add the ssh jail based on your advice. So I will have the whitelist (ssh_clients) as mentioned above and remove the redundant overloading of blocked_guests.

Followup question: the default regex for fail2ban's ssh (as shown below) should just work, since connection attempts from non-whitelisted hosts will hit the last rule (illegal/invalid user). Is this correct?
Code: 
failregex = Authentication failure for .* from <HOST>
            Failed [-/\w]+ for .* from <HOST>
            ROOT LOGIN REFUSED .* FROM <HOST>
            [iI](?:llegal|nvalid) user .* from <HOST>
 
They could trigger any of those, you'll get authentication failures for example if the brute-force happens to guess a correct username but uses the wrong password for it.
 
SirDice said:
They could trigger any of those, you'll get authentication failures for example if the brute-force happens to guess a correct username but uses the wrong password for it.
Click to expand...

Ah yes, of course. My apologies, I omitted to mention that I had configured the sshd to be key-only, as well as no-root login.

Hartelijke dank! Many thanks for your help :)
 
jordanch said:
Ah yes, of course. My apologies, I omitted to mention that I had configured the sshd to be key-only, as well as no-root login.
Click to expand...
If they guess a correct username you'd still get authentication failures. Regardless of how you authenticate valid users it would still be an authentication failure if they used the wrong authentication (wrong key or wrong password). It just makes it a bit more challenging (understatement) to guess a key instead of a password.
 
You must log in or register to reply here.
Back
Top