Hacker News Reader

Comment by nblr | Hacker News Reader

Fail2ban? sshguard? unnecessary. Just disable ssh passwd auth (which generally is a good idea) -> done/done

If you don't like lognoise from ssh scanners (even if you disable passwd auth), move your sshd port to some random high port and make note of it in your ~/.ssh/config

Generally: if in doubt, take the more simple and elegant solution to a problem.

View on HN

I agree that fail2ban for ssh seems unnecessary. But, it also provides monitoring for other services like http and common exploits.

I'd be interested in learning from the community if fail2ban adds much value. As I've looked into the service, it seems like simply running the latest security patches obviates the need for fail2ban.

I run a web server with some 50+ Wordpress installs on it. You better believe Fail2Ban is necessary. Without it all resources would be consumed by brute force attacks. If someone knows of a better way I would like to hear about it.

We use the WordFence module to block brute force attacks, seems to work fine.

I cannot believe that Wordpress still ships without basic rate limiting on its login form.

In my experience, better to let a webserver handle stopping bad traffic by whitelisting WordPress endpoints.

Parsing a url and returning 404 from nginx is cheap and scalable, and allows through legitimate traffic that may be sharing an IP (such as TOR).

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.

If 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.

This 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.

I don't think he means replacing fail2ban, but augmenting it with this.

Useful or not, it opens an extra attack vector on the server. Parsing logs is always a dangerous area from security perspective.

> move your sshd port

Sick of seeing this idiotic advice. Standard ports are standard for a reason. Perhaps one should also change their web and mail ports for "security".

But those ports are more or less supposed to be available to the general public. You keep those where they're expected to be. Any other port that "does not concern you, move along" is fair game IMHO.

Standards exist so you know where to find the things you're supposed to find, and how to talk to them.

He said:

> If you don't like lognoise from ssh scanners [...], move your sshd port [...]

It’s not about security as you claim.

Reply on news.ycombinator.com