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).
It's a reasonable enough way of protecting hosted websites, especially if you're running more than one server. You can monitor multiple logs for abuse from different sources, and then update all servers to drop traffic from those sources. So, if someone runs a WordPress vulnerability scan on a hosted website, you can detect that and immediately refuse any mail/ssh/dns/www/ftp/other service from that IP.
It requires a little bit of kludging to do this though. :-( As packaged, it's not much more useful than a hacky shell script.
Comments
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).
I see another benefit of using fail to ban. That is, it helps a little to keep the log files (a little) shorter.
It's a reasonable enough way of protecting hosted websites, especially if you're running more than one server. You can monitor multiple logs for abuse from different sources, and then update all servers to drop traffic from those sources. So, if someone runs a WordPress vulnerability scan on a hosted website, you can detect that and immediately refuse any mail/ssh/dns/www/ftp/other service from that IP.
It requires a little bit of kludging to do this though. :-( As packaged, it's not much more useful than a hacky shell script.