4

I have setup a remote CentOS VM (through a host) for our websites. I read an online recommendation to change the default SFTP port from 22 to a higher port such as 22000. I understand it is security through obscurity for the most part but is that the only advantage? Otherwise, it seems better to just leave it as port 22, setup DOS mitigation, and use a strong password.

Additional background: I must have the Root account active on the server to manage multiple accounts and domains. SSH access is only allowed through specific IP/Mac combinations. Even if a user mimics the specific IP/Mac, they only have 5 chances to get the password before it blocks them with escalating penalties: with 5mins, 60min, 24hrs, and permanent block. Finally, I have multi factor authentication enabled for the Root account.

Related posts:
Joshua Thijssen. (2012). Why putting SSH on another port than 22 is bad idea

Should I change the default SSH port on linux servers?

https://www.reddit.com/r/synology/comments/31ov2g/root_ssh_from_china/

https://serverfault.com/questions/74176/what-port-does-sftp-use

Secure FTP access; best practices

What security measures should be taken when running a Linux web server out of our office?

Closed Port security

https://serverfault.com/questions/189282/why-change-default-ssh-port

https://unix.stackexchange.com/questions/2942/why-change-default-ssh-port

4
  • 3
    It looks like you already have answers. What are you looking for?
    – schroeder
    Commented Oct 26, 2015 at 22:31
  • Don't forget that ports numbered less than 1024 require special access on the Linux side of things. Depending on your situation, this may or may not matter. Commented Oct 26, 2015 at 23:58
  • You will get rid of automated scans on port 22 possibly trying to explote new discovered vulnerabilities which seems an advantage to me. Other than that you won't get any more security.
    – YoMismo
    Commented Oct 27, 2015 at 7:49
  • In my experience moving SSH from 22 to another high-numbered port has the useful effect of reducing the size of your log files. The effect on security may be small but you'll have an easier time reviewing and rotating the log files. Normal config is to list a small & controlled number of permitted users (not root, that's what su and sudo are for) and disallow password-based logins, etc. Commented Oct 27, 2015 at 15:27

4 Answers 4

4

As you've speculated, changing the SSH port from 22 to another port is basically "security by obscurity" and only carries with it minimal advantages.

The main advantage is less botnet/automated traffic will come in on port 22 looking to run SSH attacks. However, it is fairly trivial for a real attacker, or a botnet with a more astute programmer running it; to run a port scan against all the ports. Port 20,000 (or whatever number) will clearly respond with an SSH handshake, and thus they'll try attacks on that port. End of security advantages.

Generally, what these bots try to do is:

  • Brute force 'root' or 'admin' password by using common passwords and/or dictionaries/and or random characters.
  • Try SSH vulnerabilities or exploits to get to a shell, or use common users like nginx/nginx in order to get a beachhead shell into the system.

Of course, using fail2ban or similar software to blacklist IPs after so many failed attempts will mitigate the chances of a successful brute force attack. You can also restrict your SSH daemon to only use SSH-key based authentication and disallow password authentication; thus making brute force attacks unfeasible.

To respond to some of the further information you provided, please note that it is a best practice to disable remote SSH logins from your root account. Simply enabling multifactor authentication is sub optimal, you should have all sudoers users having to login with multifactor; and then needing to use sudo to issue commands from there.

So, in short, you might receive less scan activity on an odd port. However, it's no replacement for using best practices for securing your SSH daemon, such as fail2ban, hardened sshd configuration (e.g. disallow SSH1, etc), two factor authentication, restricting SSH users/groups, not logging in as root directly, properly configured sudoers, and regular security patches/updates.

1
  • Thank you for confirming what I thought and I will take your advice to make additional improvements!
    – LJones
    Commented Oct 26, 2015 at 23:35
3

Edit:

After looking at the page where this question has previously been addressed I would definitely recommend a read of the green-checked answer there. It outlines well most of both the positives and the negatives of changing the port, and suggests that whether or not doing so is a good idea depends on the circumstances. For the types of clients I most often have--small(ish) businesses with small networks, for the most part-- I will usually recommend or implement moving the SSH port away from the default on at least some machines (Net-facing, DMZ-facing, etc.). But other people in other IT circumstances might not even consider it as a serious option. Vive la difference.

I will say, though, that I like @Steffen Ullrich I get irritated by the "But it's Security by Obscurity!! It must be terrible!" point. Yes, it's Security by Obscurity. So what? If you're really using a defense-in-depth strategy Security by Obscurity can be a positive contributor, another layer that adds to the strength of an already robust defense. Should you use a measure that falls under Security by Obscurity as your sole or even a main line of defense? Barring some extreme, hypothetical circumstance, of course not. (For example, moving your SSH port is obviously no substitute at all for requiring strong authentication of anybody who does manage to connect to it.) But being able to deceive, slow down, frustrate, and confuse an attacker is a good thing too in InfoSec. Just as it's a good thing in war, poker, sports, or ... well, in pretty much any adversarial situation that ever occurs in human experience.

And finally, you know who uses Security by Obscurity? Everybody, everyday. Every security pro or admin who doesn't publish to the Internet a comprehensive, exact listing of every device, every physical connection, every OS, every application, every authorized user, every administrator, every piece of security software, and every other security-relevant detail for every network they work on relies on Security by Obscurity to slow down & hinder prospective attackers to some degree. It's just relying on Security by Obscurity alone that's profoundly stupid.

Anyway :) , original answer starts here:


Changing the SSH port is a practice I try to follow whenever I can and advise clients to follow where reasonably possible (ie. whenever that can be done without breaking access scenarios for elaborate, labyrinthine administration setups that evolved resting on the assumption that SSH would be on the default port). Why? Well:

  • As others have said, it means that a typical, quick & dirty port scan run against large numbers of ip addresses by an attacker who's just looking for potentially-vulnerable common services on any machine he or she can find will usually miss detecting your SSH service. Couldn't a determined attacker who was specifically targeting your box and trying to find your SSH service just check every port? Sure. But for most bad guys doing something like that is only practical if you've already found & selected your target machine in the first place. In other words, a bad guy using a broad scan against many ip addresses to discover interesting targets, whether from outside your network perimeter or inside it, is (usually) not going able to (or want to) check hundreds or thousands, let alone tens of thousands, of ports per ip address. It simply isn't practical to do that--usually, for most attackers--across more than a few potential targets. Thus, changing the SSH port can sometimes meaningfully reduce the visibility of your machine against non-targeted attacks.

(Although, if you are indeed doing IP and/or MAC-based filtering properly non-targeted attacks should fail anyways. But for the sake of defense-in-depth it's still a desirable trait to have.)

  • But okay, what about targeted attacks? What about the attacker who is willing to scan all 65000+ ports for your listening SSH service? Well, obviously an attacker like that will find what he or she is looking for, your SSH port. But here changing the port can still be helpful if you have an IDS/IDPS in place & configured skillfully. Why? Well, simply put scanning tens of thousands of ports on a machine is a much "higher profile" event than scanning a relative handful. The reason is obvious: very, very infrequently is a device receiving scans across tens of thousands of ports a sign of anything but a concerted attack. Even if the scans come from a number of different ips, stretched across hours or days, there's just no way to really hide it when an attacker needs to check thousands upon thousands of ports on a machine, especially that are rarely if ever used by common services. With any kind of thoughtful configuration/setup of an IDS (host-based or network-based) and appropriate monitoring of alerts you can create a nasty tripwire for an attacker who just says "Well, I know how to find SSH. I'll just scan everything on the box...".

Of course, if your attacker is a little more patient and has internal network-side access to your box he/she may be able to just sniff for SSH traffic and see what port it's directed at. But this gives your opponent one more opportunity to be impatient and screw up...

At the end of the day, changing the port should definitely be just an additional, supplementary factor of protection that an attacker has to deal with. It is not a substitute for doing the SSH basics right (strong factors of authentication, proper configuration of auth-try throttling/ lockouts, etc.) But it can still be a useful measure.

5
  • I actually think that changing the SSH port to non-default is a poor approach and NOT in line with best practices. Because non-root users on *NIX systems can open up port 2222, it opens up a whole new level of vulnerability to privilege escalation attacks. If you wanted to really seal it off, firewalls, port knocking, or VPN should be used. Commented Oct 27, 2015 at 18:17
  • @Herringbone_Cat Maybe I'm a little daft at the moment, but I'm not immediately seeing the connection between non-root user being able to open an arbitrary port, privilege escalation, and having SSH listen on a port other than the default. (That's not snarky criticism; my brain isn't seeing the connection.) If you elaborate about how the whole new level of vulnerability to privilege escalation happens I'd be obliged. Commented Oct 27, 2015 at 22:18
  • The first reference from the original post: adayinthelifeof.nl/2012/03/12/… explains this I think. Commented Oct 27, 2015 at 22:21
  • Oh, duh. Just figured it out, the privileged ports vs. user-accessible ports thing. If your SSH listener exits for some reason a user can bind to the port (as it's not in the privileged ports range) and take the place of what should be listening there. Thanks anyways for the reply Commented Oct 27, 2015 at 22:31
  • 1
    If you will change your SSH default port is recommended to change to a low port. When was the last time you needed to run a service on port 863? 1020? Changing above that and you actually decrease security. Combine that with firewall rules to blacklist IPs scanning your box and restricting logins to keys only and etc.
    – Freedo
    Commented Nov 1, 2015 at 6:10
2

I understand it is security through obscurity for the most part but is that the only advantage?

Moving to a different port effectively means that the attacker now has less information about how to best attack your system and must figure out first where to look for SSH before attempting to crack it. So this security through obscurity increases the cost of the attacker and might already deter some lazy attackers because there are cheaper targets. Thus obscurity can be part of a defense in depth.

You could also setup some SSH server at port 22 with a different configuration and no password authentication at all. This will keep the attackers busy trying to brute-force passwords while you can happily login at the real SSH server.

1
  • Creating a honeypot at port 22 is a nice, clever idea. Just note that depending on how you set it up, it would defeat the "minimizing logs noise" advantage of changing the default port.
    – MestreLion
    Commented Oct 6, 2023 at 10:57
2

The main advantage is that you'll be reducing the number of SSH brute force attempts on you VM. But changing the default port doesn't make the service more secure.

If someone wants to discover if there is port serving a SSH/SFTP service, nmap will do it easily.

But as you said it's security by obscurity is a bad approach to secure your system.

The main disadvantage resides on the usage. If you change the default SSH port, you'll have to specify your custom port every time you'll try to establish a connection to SSH/SFTP (not already defined in a config file)

ssh mysuperhost.com -p 22222

Other solution regarding what's have been already suggested:

  • Permit Root Login: Do not permit the root login directly on the SSH server PermitRootLogin no. You can then do privilege escalation by using su/sudo command but first login over ssh with a standard user.
  • Beyond strong password usage: enforce the usage of SSH keys for authentication which is much secure than password usage (in them of complexity)
  • Port Knocking: You can establish a port sequence you have to knock on before your SSH/SFTP default port will be acception new connections. Nice to know about but pretty cumbersome for usage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .