3

The idea is the following:

I have a port open (P) on a remote machine (R) with a service application running which is listening on (P). I would like to connect from a client machine to the service application on the remote machine.

Possibility 1:

I leave the port open so I can connect directly from my client via the ip and the port to the service application on the remote machine.

Possibility 2:

I restrict the service application via firewall to localhost and forward (P) with an ssh tunnel to my client machine.

My own conclusion:

If I open the port of the service application across the internet, then I have to trust that it cannot be exploited for remote code execution on (R).

If I use an ssh tunnel, then I only have to trust that the listening ssh port cannot be exploited. The number of open ports is reduced and hence the attack surface (from my point of view). I would still be vulnerable if my client machine was compromised, but I'm accepting that risk anyway when using ssh.

Question:

So my question is, is my conclusion correct? Is it more secure to use an ssh tunnel and forward a port instead of exposing that port directly?

4
  • What you're doing here is using SSH for authentication, and for encrypting traffic. If your application handles both these things properly, you are only adding layers that an attacker would need to bypass, which is good. In addition, you're hiding what you're running, which would be useful to prevent automated scanners and such from flagging you as a target if that service has a well known vulnerability. I'd hide behind ssh.
    – Pheric
    Dec 18, 2019 at 9:55
  • If you care to write this as an answer, I‘d see this as an acceptable answer.
    – Max1
    Dec 18, 2019 at 12:25
  • Which-ever choice you make, the publicly facing service will need hardening. Provided your Service Application is using TLS, you'll not be gaining much on that front. Leaving the choice of authentication methods. Cert Authentication via SSH is relatively secure if you're careful w/ your key, but WebAuthn w/ a hardware token is arguably better. Also you have to weigh the costs of a successful attack. If someone gets on to your SSH server, are they getting a full shell free of charge? I'd probably just harden the Service App.
    – tjd
    Jan 10, 2023 at 16:56
  • You might also consider a less flexible tunneling service. IPSEC gives you all the tunnel with none of the shell. Just something to think about.
    – tjd
    Jan 10, 2023 at 17:09

2 Answers 2

1

Is it more secure to use an ssh tunnel and forward a port instead of exposing that port directly?

Yes, for several reasons.

  1. As you noted, it reduces attack surface.
  2. SSH provides authentication. Not only is your app server hidden from malicious internet probes in general, nobody can even try to authenticate to it unless they can also authenticate to your SSH server. SSH authentication can use strong methods like public keys (technically possible on other servers, but SSH makes it pretty easy).
  3. SSH provides encryption. A network eavesdropper won't be able to tell what traffic is sent in each direction, not even that you're communicating with your app server on port P. Without the SSH tunnel, the attacker would at the very least be able to see the destination port, and - unless your app has its own encryption such as TLS - the attacker would be able to read the traffic too.
  4. SSH provides integrity. Without SSH (or similar protection such as TLS or custom message authentication codes), a man-in-the-middle network attacker could modify the messages sent to, or from, the server. Such an attacker wouldn't necessarily need to be able to read the messages, even - that is, encryption wouldn't necessarily save you - as many forms of encryption offer a vector for an attacker to flip bits in the plaintext at a chosen location. If the attacker knows even a little bit about the message, bit-flipping can be sufficient for massive security compromise.
  5. SSH provides order and replay protection. Alternatively to flipping bits, an MitM attacker could alter the message sequence by rearranging traffic in each direction, or capturing traffic in one direction and replaying it later. The attacker again doesn't need to know exactly what the message says; it may be sufficient to just know what the effect of sending the message is. Anyhow, SSH protects against all of that.
  6. SSH provides logging. Even if your app server doesn't have a mechanism to record when sessions start and end, or where they come from, SSH absolutely does. The SSH logs won't reveal what was done on the app server - to the SSH server, that's just opaque traffic, and you don't want to log potentially-sensitive data like full traffic anyhow - but they will absolutely record when the session starts and stops, and who logged in and from where. If you use SSH port forwarding you can even tell which SSH sessions were specifically for that purpose.

Do note that this won't fully protect your app server. Any software running as any user on R (unless in a separate network namespace that blocks access) will be able to reach port P and interact with the app server, unless you get very tricky with the firewall indeed (it's probably possible to do this - limit the requests to P to coming specifically from the sshd process - on Linux, but I don't even know how). Additionally, if you use SSH port forwarding, then any software running on your SSH client machine will be able to use the forwarded port to reach the app server at P on R as well. This includes even scripts running in web pages or similar.

Most of the time, people don't bother with this kind of forwarding except for very highly sensitive systems; it adds overhead and inconvenience, and many app servers are running TLS these days so the security benefits of tunneling through SSH are substantially fewer. However, it's a perfectly good way to reach a server that you don't want to directly expose to the Internet.

0

Many service applications can be configured to bind only on localhost, i.e. they then listen on a port on the 127.0.0.1 loopback address. That port is simply not accessible from other networks (whether you run a firewall or not).

An ssh tunnel allows a connection provided several conditions are met, and you can configure these to your liking:

  • firewall rules, for example allowed source addresses.
  • Authentication, key exchange, and other crypto algorithms
  • PKI security (authorized_keys, signed keys, host keys)
  • allowed ssh users or groups

You must log in to answer this question.

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