Is there a risk in opening port 22 for ssh access with a network?

  • Background

    We have our own datacenter which houses platform specific environments and each environment is isolated. Eeach environment is also has 3 tiers (Web Servers, Application Servers & Datastore). We also plan on introducing an Automation framework(environment) which needs to communicate with the platform specific environments hosts.

    Network

    private datacenter [Automation environment host runs commands ----> <ssh> ---> platform hosts]
    

    Concern

    Some team members have raised this as a security concern. Specially ssh access into the DB servers in tier 3. Now I'm more of a dev than an ops guy so I'd like to get more of a thorough explanation on why this might be too much of a risk.

    Can someone clearly highlight why this is not recommended? or perhaps it is not a risk, and if so can you please highlight the considerations to implement it.

    Thanks.

    short answer: Having direct access to the server allows attackers to pound on the door and get in. There are ways to secure that access (for ssh), but in general, you want to seriously limit access to servers.

    If you've properly secured your SSH, it's more akin to letting attackers beat their heads against a brick wall.

    @Mark A brick wall that may or may not have a hole in it somewhere

    I understand that 5 years ago, when this stackexchange was burgeoning, having a general answer for why ports should be closed was a good idea. There were not enough resources to expound on the nuances on each services. However, there are different risks-benefit relationships to exposing different services to the internet. For example exposing port 80, port 22 and port 53 all carry different risk profiles. Marking every question as a duplicate is the equivalent of answering is ignoring these nuances and it's time to look at what ports are related to internet-safe services.

  • Can someone clearly highlight why this is not recommended?

    Because any running service is increasing your attack surface. Especially with network capable services, you're always exposed to danger. I don't think anyone can give you a more specific answer than that, since the SSH implementations tend to be quite OK from a security standpoint. Nevertheless there is always the possibility that an exploit is discovered, granting anyone sending the right packets to your server access or that you've greatly misconfigured your servers.

    But, even if you assume that the software itself is flawless, there are a couple of reasons why you might want to re-think your approach. Obviously, you haven't told us and details about your setup, but in the real world key management, audit trails and firewalling is always an issue. Aiming for another approach might therefore be a good idea.

    For this reason also, the firewall operates as a separate physical component from the application server.

    The generic answer of "every exposed port is an attack surface" misses important port 22 nuances like the authentication method, SSH has a wide array of auth options, password authentication is more dangerous than private key, I believe there's also federated authentication like ldap.

    This doesn't make the generic answer less true. Also all of your nuances are rendered invalid when some (unlikely) pre-authentication flaw is found in OpenSSH. At least we've seen such flaws in other protocols / implementations.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM

Tags used