3 ms·
I too am curious to know what the consensus is. People seem to fall into one of two camps: 1. it's unnecessary if you disable password login or 2. it's an easy
by mwpmaybe 10y ago
I too am curious to know what the consensus is. People seem to fall into one of two camps: 1. it's unnecessary if you disable password login or 2. it's an easy thing to add as yet another safety net on top of sane service configuration and firewall rules.
I've taken some flak here for being in the #2 camp so I'm loathe to expose myself once again, but my thinking is that even with password authentication disabled, sshd is still vulnerable to DoS attacks. From the public internet or from other machines in my VPS provider's datacenter. The ssh and recidive fail2ban filters add some minimal defense against that.
- mordechai9000 10y agoIf all you're worried about is keeping the low-level noise out of your logs and discouraging waste of resources on brute-force attacks (which won't work because of course password auth is disabled), I think it's sufficient to use the built-in iptables rate-limit feature on SYN packets. UFW has a feature that will implement this with a limit of 6 SYN packets in 30 seconds from individual IPs. ufw limit ssh/tcp This may not be ideal for some services like http without persistent connections, and if fail2ban provides extra exploit protection it could be worthwhile.
- mwpmaybe 10y agoThis is a much better answer than, "If you're using fail2ban for that reason, you don't know what you're doing," as someone said to me recently, so thank you. :-) I'll explore replacing fail2ban with this mechanism.
- aalbertson 10y agoI don't think he means replacing fail2ban, but augmenting it with this.
- lez 10y agoUseful or not, it opens an extra attack vector on the server. Parsing logs is always a dangerous area from security perspective.