4

Background is that I am learning some technical stuff with the Enki App. In this case about security. The App states that it is a misuse of a port if I change for example the ssh port from 22 to something different and that's a vulnerability. For a full background a screenshot:

enter image description here

For my own Server I changed the port to reduce the attack surface (at least a very tiny bit).

So my question is do I really introduce a vulnerability by changing the port?

migrated from softwareengineering.stackexchange.com Jan 28 at 11:11

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 1
    If your server is anywhere a hostile nmap might grace it, your change of ports improves your security less than 1%, but the confidence you get from thinking you've done something clever reduces your security by upwards of 10%. Security by obscurity is insecurity. Also, Blrfl is right, this goes on Information Security. – Ed Grimm Jan 28 at 3:53
  • 1
    If a security layer depends on people using the default ports for well-known services, then it is fundamentally broken and I wouldn't listen to anything its authors have to say. – Kilian Foth Jan 28 at 7:35
  • "I changed the port to reduce the attack surface"> This does not reduce your attack surface at all. Not even a tiny bit. – Sean Burton Jan 29 at 17:33
  • You could make an argument that this reduces confused-deputy attacks from web browsers, but those come around fairly rarely and are fixed quickly. – Riking Feb 4 at 3:10
6

Generally, no you're not introducing a new vulnerability by running a server on another port. The software will behave the same way regardless of what port it listens to (unless of course there is a vulnerability in the code that parses and sets custom ports).

Though you may find that your clients cannot connect to your server because a firewall or intrusion detection system notices "bad" traffic, since it expects the right protocol on well known ports. And if you're in an enterprise environment, those same firewalls and intrusion detection systems will likely be flooding you with false positives, making it harder to detect legitimate threats among the noise.

And the lesson may be hinting at naive security where an admin thinks they've protected themselves from ftp vulnerabilities by closing off ports 20-21 and you're opening ftp vulnerabilities by putting an ftp server on port 22 which is open to the world. The ftp software isn't more vulnerable here, but the system as a whole may be.

3

This isn't what your screenshot is referring to, but you can introduce a vulnerability if you use a port above 1024. Ports 1-1024 can only be bound by root. If you run ssh on port 2222 for example, anyone who is able to crash that process can then start their own ssh server on port 2222.

Say you have a website with a vulnerability that allows them to take control of your Apache/Nginx web user (all too common), and your ssh server has a vulnerability that can crash it (less common, but also much less severe). The web user can crash the ssh server and start their own, and because it's running on a port above 1024 nothing will prevent it. As soon as you send your password to that ssh server (either to log in, or using sudo to gain root privileges), the attacker can gain whatever privileges you have as well.

I wouldn't call it a high severity vulnerability, but if an attacker can gain access to a non-root user on your server, and your server is expected to run trusted services on ports above 1024, it can be an unnecessary weakness.

  • Any significant security benefit of "only root can bind to ports < 1k" disappeared the moment the first private individual ran a UNIX box. – mlp Jan 28 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy