Port 22 - should we really be using port 22 for SSH?
Port 22 for SSH - Is it a good or bad idea to use port 22 for SSH?

Awhile ago I read an article explaining why using port 22 for SSH is a bad idea. The article basically explained that people like to use a different port than the standard port 22 for SSH for the sake of security through obscurity. Humans and scripts alike automatically guess that the SSH port is listening on, as the default typically is, port 22. This makes sense; however, there are some pros and cons to all of this, as suggested by a response article that explained using a port besides port 22 for SSH is, in fact, a good idea. I found these two articles intriguing enough to share with the community, so here they are with some added commentary from myself. 

People often set their listening port(s) to non-privileged ports since people like to throw their SSH port somewhere totally random, often above port 1024, a non-privileged port (anything that is 1024 or lower is privileged). The article claiming that ports besides port 22 is a bad idea explains that "when we start SSH on port 22, we know for a fact that this is done by root or a root-process since no other user could possibly open that port. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE. You have no way of knowing if you are talking to the real SSH server or not. This reason, and this reason alone makes it that you should NEVER EVER use a non-privileged port for running your SSH server."

Besides this, other things are brought up; for example, if a 0 day is suddenly released and exploited in the wild, people could attack servers at random with an automated script. These scripts probably won't take the time to scan absolutely every single random IP, so they may just assume that the SSH port is listening on port 22. If we choose to not use port 22 just for this reason, even though it is security through obscurity, it is still very effective. The writer that was defending other ports besides 22 went on to explain an examination of his own, he explains that "just to see what would happen, [he] tried to gather some actual data on this and ran two SSH ports for a few days. The result was something like 5 connections on the non-standard port, compared to tens of thousands on 22. Now imagine there’s a new SSH zero-day out, and ask yourself which config is more likely to get popped."

Besides this, both the articles bring up some other interesting points like port knocking (another interesting infosec-related thing that is worth looking into if you own a server of your own). 

An easy solution for pretty much all issues on both sides is to just use a privileged port like 789 to listen for SSH connections on; this port is a privileged port since it is less than 1024, and it is not port 22 - the best of both worlds. 

Overall, I found both articles very interesting. I encourage everyone to read them in the order that they are presented in below!

This brings up some very good ideas, but I think running on nonstandard ports is better if you just want to be lazy Just use a .ssh/config file to set up an alias and make sure you set up your ssh accounts to always use SSH keys, passwords/passphrases have a tendency to suck when humans are involved.

If you are also concerned still it is VERY easy to write a script that looks for password based login attempts and uses IP Tables to ban until the next reboot. Or put the server behind a VPN and you have to be on the VPN to have port 22 open to you, or an IP white list. The list goes on on how to actually protect your server from people without using STO.

Security through obscurity is never a means to an end, just a lazy attempt.
Security through obscurity is totally underrated in the infosec world, particularly when it comes to interconnected systems

Security through obscurity should NEVER be the only mechanism in play, and it should never be the primary mechanism in play... but that doesn't mean it shouldn't be used as a mechanism at all.

And it all comes down to the fact that while it will not slow down a seasoned professional for long, it will often completely eliminate automated/scripted attacks, of which most compromises consist of.
An SSH alias, NO-OP? That's new to me. A lot of this is new to me. I will have to read into that, would you suggest any particular resources?

I also agree that security through obscurity is definitely treated as the underdog in the security scene. As much as people talk down on it, it is not a bad thing to include in your threat model. Security through obscurity really is not that bad as long as it is applied safely with real security in mind as well.
If you only allow key based login does it really matter? Log clutter is the only thing I can think of.
(10-10-2016, 12:22 AM)StickFigure Wrote: If you only allow key based login does it really matter? Log clutter is the only thing I can think of.

Scenario - A buffer overflow vuln is discovered that allows you to provide a key, whether valid or not, that allows an attacker to compromise the ssh service.

An exploit/worm is then written to scan every port 22 on the internet and attempts to take advantage of the vulnerability. The worm compromises 50 million machines.

Conclusion: Doesn't really matter if you only allow key-based login, if a vulnerability is discovered in the key authentication/management process. Your approach assumes that 1 vector is vulnerable, and another is not. Should never assume that any vector is 100% invulnerable.

Again, Security through Obscurity shouldn't be your primary or only defence - but if a vulnerability does crop it, the difference between scanning 4 billion hosts, and scanning 4b*1025 or even 4b*65535 is astronomical. The attacker is going to stick to looking for services on the known port simply because the average success rate will be higher.
I think changing the default port 22 to another one (less than 1024) is a good idea because a lot of scripts just scanning port 22, if nothing is there they go.

as said changing the port is not enough but it can be pretty save with a strong password or even private key setup.

If you compare a server with port 22 and a server with lets say 789 you will see a big difference.

If you're still paranoid you can setup fail2ban for blocking brute force attacks.
non-standard, but privileged port. Key with passphrase to connect. No remote root login (just do sudo su - when you're in your user account).

If you wanna be fancy add a module to do things like google authenticator to your SSH, do it.

Please don't be like a friend of mine and store SSH keys to root user without passphrase on your laptop.
Then have their laptop get popped and pwned my email server.

I learned my lesson there...
As with many things, a happy medium may be seen as a good approach here - use a non-standard but privileged port. Even though the second article correctly points out that even if your SSH service was still running on 22 or any other privileged port, there is still nothing stopping malicious scripts or servers from pretending to be SSH and scraping credentials on a non-standard, non-privileged port.
(12-29-2016, 08:04 PM)VenAAX Wrote: If you wanna be fancy add a module to do things like google authenticator to your SSH, do it.

Please don't be like a friend of mine and store SSH keys to root user without passphrase on your laptop.
Then have their laptop get popped and pwned my email server.

The SSH key implementation definitely encourages bad behavior as is. There is an OpenSSH-like implementation that has been reworked to use CA certs. Forcing them to expire would be smart (and a major pain in the ass).

I was reading that Facebook does something like x509 / CA certs for authenticating but goes straight to the root user. I forget the details, they probably used 2FA too. The logic being it's easier to audit who is logging in where this way instead of with user accounts and for some reason worked mostly in root anyway (that part I don't get).

Possibly Related Threads…
Thread Author Replies Views Last Post
  primitive creature blindly using nmap, scapy, and wireshark neftis 0 1,313 04-14-2022, 04:30 PM
Last Post: neftis
  Using Wget for Maintaining Access to a System misfit 4 24,013 12-09-2020, 07:36 AM
Last Post: Vector
  want to do this kind of MITM attack without using wireshark QMark 2 14,803 02-06-2019, 07:17 PM
Last Post: Insider
  New attack on WPA/WPA2 using PMKID (Hashcat) Insider 1 14,611 08-14-2018, 10:54 PM
Last Post: overfl0wN