1

Suppose you have a semi-trusted machine (e.g. one where your business partner's IT department has root access to) sitting behind a firewall and you want to connect to this machine from one of your trusted machines.

The basic idea is to circumvent the firewall by establishing an SSH tunnel from the untrusted machine, so that the trusted machine can connect locally. This tunnel should be persistent, so I use the autossh program.

In order to make this somewhat secure, I currently create a user autossh on both machines and authorize its public passphrass-less key, so that the autossh user can establish the connection without having to enter a passphrase. Furthermore, I set this users' shell to /bin/false, as this prohibits normal logins by still allowing to setup the tunnel.

This basically works, but I have the gut feeling that more must be done to make this reasonably secure.

Although an attacker with access to the semi-trusted machine cannot login to the trusted server using this key, she could e.g. perform a Denial-of-Service attack by creating an SSH tunnel-loop and flood the open files table (see e.g. 1) like so

ssh -vN -L4141:localhost:4141 trustedhost
ssh -vN -R4141:localhost:4141 trustedhost
telnet localhost 4141

And there are probably other possible attacks as well. So how can I further protect this mechanism of creating this semi-trusted tunnel? I only need to establish one persistent connection between these servers, no other commands/tunnels need to be executed/established by the autossh user.

0

First, ascertain that whoever set up the firewall really wants you to work around it. He may not have been made aware of your request to directly access that machine & may want to offer a different solution (such as changing firewall or network topology).


Resource exhaustion attempts as in your example should not cause huge concern, as you likely already have enforced nproc as well as nofile limits.

$ ulimit -n
1024
$ ulimit -u
2048

Memory or inode exhaustion is going to be difficult, as long as you are chrooting such user to a limited-size, empty tmpfs.

If you wish to reduce attack surface, stop using autossh (a program designed to work around historical deficiencies that were resolved in openssh a decade ago) and disallow using TCP ports on your side (unix sockets are entirely sufficient to maintain a tunnel).

Match Group untrusted
  ChrootDirectory /run/empty/%u
  AllowTcpForwarding no
  AllowStreamLocalForwarding remote
  PermitTunnel no

Risks that you may not be able to mitigate:

  • someone saturating your network link (which might be shared with services you care about)
  • privilege escalation vulnerabilities in your ssh server

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.