Hacker News Reader

Comment by dotBen | Hacker News Reader

The reason he's right is most attacks on SSH are one-dimensional.

In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running.

The other dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common.

Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.

View on HN

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Attacks on port 22 end up consuming CPU.

and attack on other ports don't?

The assumption is that bots don't usually scan other ports: way too inefficient for them to scan all ports for every potential target host.

fail2ban

And now you have another exploitable venue, the log parser of fail2ban ;).

Personally, I trust netfilter/iptables' rate limiting more.

Even better yet is pam_abl. If any IP or user fails authentication faster than a configured rate pam_abl will block logging into that user or any authentication attempts coming from the same IP address and it's all nicely tied into PAM so you don't have to worry about yet another fail2ban vulnerability or someone spoofing some important IP address and tricking your server into blocking it.

Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.

Bots frequently exploit changes that were recently fixed upstream. Not perhaps 0-days, but maybe a couple days after the original fix. How up-to-date do you really keep your SSH server? On the off chance the attacker gets to an exploit faster than you get around to updating your machine, then keys won't keep you safe. Using a non-standard port in that scenario might very well save you from the botnets, if the GP's argument about the dimensionality of attacks is correct.

> Frankly I'd much rather do that then have my server on a non-standard port.

Frankly, the problems with key security and management are much worse than are being discussed. Using only keys is fine as long as your keys are secure and you know which is which and control all access and immediately remove any key which needs to be. In a complex environment, this is extremely difficult and more prone to security breaches than password access.

I don't know. In complex environments that try to use passwords, I've observed that the password spreads until everyone knows it and then nobody can change it because "everyone already knows it and it would be a pain". Keys allow fine grained access and can theoretically be way more secure.

On the other hand, the last place I consulted for had their private key for production checked in to the main git repo, unencrypted. :-/

> Keys allow fine grained access and can theoretically be way more secure.

This is true but as often is theory and "life" don't agree about the practice. This is exactly my point. If you could enforce a non-blank password on keys then I would change my tune at least a bit.

Security is as strong as your weakest link. If you can't protect your port 22, any other ports are probably easy to take over too. Are you saying you get extra time since attacker has to find this new port? I am not totally sure what you mean. Please educate me.

It's more of an annoyance. If you require password based login, port 22 will lead to constant attempts that fill the logs. Move to any other port,and you'll see none.

Curiously, that was my primary motive for moving SSH on a couple of servers off 22. It had nothing to do with any notion of security and everything to do with the annoyance of filling up my auth logs with mindless login attempts by dozens of bots.

Maybe that's the wrong reason, but irritation can be a decent motivator. :)

Your premise is wrong – while the security of encryption, for example, is as weak as the weakest out of algorithm, key, random numbers used etc., the security of a system solely attacked via the SSH daemon is the sum of each layer of defence (or at least the strongest of these layers); that is, an attacker has to pierce each layer individually and successfully attacking one of them (e.g. finding the SSH port or the correct port knocking sequence) is not enough to render the whole defence void.

Reply on news.ycombinator.com