[tuzakey]

Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem.

So why not solve the problem with something a little more proactive like turning off password auth and go for sshkeys only. Maybe toss in something like fail2ban if you want to interrupt kiddies scanning your boxen.

That said high port ssh can be nice if you're frequently on restrictive networks and getting out on port 22 is impossible.

edit(spelling)

[brooksgarrett]

I think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.

[justinwr]

I completely agree, moving the port is a must just to change up the configuration from everyone else's. Configuration items like port numbers are meant to be tweaked, especially when you can just stick a unique SSH port in your ssh_config.

However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.

[tszming]

Yes, you have pointed out - a targeted attack.

What if non-targeted attack like a robot scanning all port 22 in your datacenter?

[tuzakey]

Thats where fail2ban is useful, pick a number of failed auth attempts on any service you care to integrate, lets say 8 PAM failures, and trigger a rule that inserts an iptables rule to drop/reject the attackers IP for 5minutes. That will time out the ssh scan for all but the most patient scanners. If you shared the fail2ban database across hosts you could inject null routes for the offender into your router or block them at your firewall.

[tszming]

I think you have missed the point - you should tell why using non-standard port is less secure, not provide me an alternative, because I would also argue VPN is better fail2ban.

You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is bad and therefore we should do nothing.

[lotyrin]

Because moving your port has an opportunity cost.

Documenting and configuring it has a non-zero cost which could be spent doing something else more impactful.

I've never seen an infrastructure where there was a sufficiently advanced state of security such that obscuring the port numbers of services was the at top of the todo list.

Unless people recommending these things work for shadow organizations I've never heard of, I'm pretty sure it's something done without any kind of cost-benefit analysis.

What are the odds of a SSHd zero-day? Or, more specifically, what are the odds that someone with zero-day knowledge would be so stupid as to decide to risk the vulnerability being discovered by others by using it in a horizontal search of all running SSHds?

Because it has to both be more likely than any other attack that could be mitigated (and port obscurity would have to be the most effective solution) with the same effort.

Pretty sure that for virtually all infrastructures, auditing that your systems are properly isolated, users and services have the least privilege possible prevent massively more probable attacks, and that firewalling services or port knocking or really anything are more effective solutions for this attack.

[stephen_g]

Well, apparently with Zmap [1] you can do internet-wide scans in less than an hour from a single host, so I can't imagine they'd have that much trouble finding any open SSH ports on a smaller IP range.

So just changing the SSH port will do little, but enabling port knocking would help it stay hidden.

1. https://zmap.io/zmap-talk-sec13.pdf

[socillion]

"Less than an hour" is with gigabit internet, which is rare for an attacker to have.

[Zr40]

With a 100 Mbit/sec connection, that would become "Less than 10 hours". That's still quite fast.