8

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.

Improve this question
7
  • 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.
    – schroeder ♦
    Mar 17, 2015 at 23:12
  • If you've properly secured your SSH, it's more akin to letting attackers beat their heads against a brick wall.
    – Mark
    Mar 18, 2015 at 8:03
  • 1
    @Mark A brick wall that may or may not have a hole in it somewhere
    – Radvylf Programs
    Dec 14, 2018 at 16:03
  • 1
    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.
    – TZubiri
    Mar 21, 2020 at 15:08
  • 1
    I think it's fair to have a separate question for each port, there's a finite number of them. But of course this depends on the size of all of the site and whether there can be an answer for each port.
    – TZubiri
    Apr 15, 2022 at 20:55

2 Answers 2

Reset to default
6

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.

Improve this answer
3
  • For this reason also, the firewall operates as a separate physical component from the application server.
    – munchkin
    Mar 18, 2015 at 13:35
  • 1
    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.
    – TZubiri
    Mar 21, 2020 at 15:09
  • 1
    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.
    – Karol Babioch
    Mar 22, 2020 at 17:56
2

Ultimately you need remote access to your servers but there are some things you can do to keep the bad guys out.

Don't run the internet facing SSH on an IP used by the application. Ideally use a dedicated host acting as a jump box. Use port knocking. Use key pairs. Use fail2ban. Don't allow root logins. Restrict access to a named group. Don't use shared logins. Don't allow direct access below the presentation tier.

Improve this answer
3
  • 4
    What I don't understand about the bastion architecture is that it just adds an indirection layer, it looks like security by complexity. Why not apply the same restrictions you would use to connect to the bastion host to connect to the specific port directly?
    – TZubiri
    Mar 21, 2020 at 15:14
  • Then post a question asking for some elaboration (there's too much to cover in a comment)
    – symcbean
    Apr 11, 2022 at 17:11
  • 2
    The idea would be to cover it in the answer. The question asks what the risks of opening port 22, by elaborating on how the bastion architecture would reduce risks, you would undoubtedly shed light on a specific risk that is supposedly mitigated, answering the question. An expansion to this question or a new answer are both sensible, and can answer the question in a more concrete way than in a generic question about the bastion pattern.
    – TZubiri
    Apr 15, 2022 at 21:02

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