I always install fail2ban or something like it on servers I want to have SSH on. Really cuts down on the log volume, even if I have locked myself out occasionally. The thing about port scanning is that it's cheap as hell. There's less than 4 billion IP4 addresses and zmap can hit them all within an hour on a decent network connection.
I used to set up Fail2Ban on any new server, but in the classic case of using it to protect SSH, I haven't allowed password logins for a long time, and so all it really does is cut down on log noise.
The advantage of port knocking to me is just reducing the amount of garbage script-kiddie scans. IMHO the design of `sshd` needs to just assume it will be slammed by garbage attempts and minimize the logging. I've heard of `fail2ban`, but banning does nothing as the bots have an unlimited number of IPs.
A few years ago I started installing fail2ban on all my server instances, which comes with sane defaults and the SSH filter enabled out of the box (on Debian/Ubuntu, at least).
fail2ban is another layer which is susceptible to abuse and vulnerabilities. It might keep noise out of your logs but at a huge cost. I'd rather just change the SSH port to something non-standard and write it down.
Do you ever examine logs? Fail2ban (or even better, using a nonstandard port or both) keep the noise out of lots to the point that you can still examine them manually.
Without it, 99.99% of the average ssh log is failed back attempts.
Fail2Ban can do more than SSH. Any log that can be parsed and has a useful remote IP can work.
I have it scanning my Ubiquiti NVR logs, I modified Tomcat to log the remote IP from my reverse proxy. If anyone tries to log into my NVR three times then Fail2Ban adds the IP to a permanent blocklist on my OpnSense firewall and then HAProxy kills the TCP connection. They can't even ping after that.
Yeah, they also miss (IMO) one of the biggest advantages of using something like fail2ban which is the reduction in logging noise. I've seen multiple VMs effectively DoS-ed because their disk filled up with SSH log entries. I've been paged by security monitoring tools that registered all the failed login attempts as attacks, and I've had to filter out or just wade through all those logs when investigating other issues.
fail2ban also works with services other than SSH, and one of my favorite tricks is to point it at nginx logs, add a `robots.txt` with a honeypot entry and have fail2ban block any IP that hits that or any of a dozen common vulnerability endpoints that I know aren't on the server (like `wp-admin.php`). Keeps the web logs cleaner and more useful.
fail2ban installed = less logspam, and never having to adjust default port with whatever tool is ssh'ing
moving ssh port = less logspam, but now you have to specify your ssh port in every tool that uses it, and it's one more thing that other staff have to remember
Changing the default port - yeah, works wonders for reducing noise. But I don't understand why people run fail2ban. Nobody is going to be brute forcing a ssh login, all it does is add another moving part very close to a security boundary for very little gain.
I agree with you -- port knocking and even changing ssh's listening port look a lot like security theatre. They're cool, they're hackish ... and they're completely unnecessary, assuming that you don't allow root ssh logins and have a relatively small subset of ssh users, along with a reasonable password policy.
At worst, the internet will just keep filling your logs with access attempts, none of which will actually accomplish anything.
I did recently decide to start using fail2ban though, not because I'm worried about someone hacking ssh, but because I wanted a centralized system that would monitor various forms of abuse (including obvious spammers).
Simply changing the default SSH port cuts it down even more, and I'm not convinced that fail2ban actually adds much security. It may even increase your surface of exposure, if it happens to have a security bug in it.
fail2ban basically just cleans log files for you - and gives someone else control over your iptables. And in the days of botnet attacks, it doesn’t do as much as someone might think.
Moving the ssh port (even without port knocking) does a lot more to cut out log messages.
Fail2ban monitors more than just ssh. I uses it against http auth, suspicious http bots, and all sorts (I even have fail2ban watching irc connections on one box)
What has helped me more than fail2ban with reducing login attempts by many orders of magnitude is changing default SSH port from 22 to something in 10000-30000 range.
reply