Use SSH to Cross a Suspect Host Securely

SSH tunnels can be used to connect securely to a server behind a firewall in such a way that the firewall can't observe the data. This is also true and useful if you know an attacker has gained control of the firewall.

If Netbook has a public IP, you also can set up a reverse tunnel from Server to Netbook. The reverse tunnel allows you to connect to Netbook from Server and then connect back to Server via the reverse tunnel. If the reverse tunnel doesn't need to go through Gateway, you then could take Gateway down for investigation and repair while still being connected to the internal network. See the Reverse SSH Tunnel sidebar for more information about reverse tunnels.

Review

Connect to your possibly compromised machine, Gateway, and create a tunnel to the machine you ultimately want to reach, Server. Once the tunnel is up, use it to connect to SSH on Server:

ssh -a -N -f -L 3333:Server:22 Gateway
ssh -P 3333 localhost

Reminders:

  • Don't forget to block authentication agent forwarding.

  • Don't forget to specify remote user names if you need them.

  • Use a port above 1023 if you're not connecting as root.

  • Make sure to have confirmed SSH host keys previously.

  • Add the host key to your known_hosts file as an entry for localhost, because SSH will see the connection as being to localhost.

  • Use -D to create a SOCKS proxy.

  • None of the commands in this article require root access. All would work from your own account.

  • The attacker can block the connection and can control the connection to Gateway, but the attacker can't compromise the connection to Server.

Any SSH connection across the Internet is crossing questionable hosts/routers. If those were safe, you wouldn't need a secured connection. The tunnel is the same scenario, because it's just enabling a normal SSH connection.

der.hans is Vice President of Engineering at a startup in stealth-mode, cofounder of TwoGeekTechs, founder of the Free Software Stammtisch, an adjunct instructor at a local community college, Chairman of the Phoenix Linux Users Group, strategic advisor to TEDxPhoenix and founding member of League of Professional System Administrators (LOPSA). In his free time, he likes to go camping, annually not set himself on fire and brag about his grandma's cheesecakes and Spätzle. He can be reached via Commerz+LJ@LuftHans.com.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"you can ssh safely across a

Anonymous's picture

"you can ssh safely across a compromised host"

You keep using that word. I do not think it means what you think it means.

Not so troubling

lufthans's picture

WARNING: Anything communicated to authenticate to a compromized host could potentially be captured by the attacker and used against other hosts.

As the author, I do not mean for my article to dismiss the importance of shutting down a compromised host. The article explains that you might need to temporarily hop through the compromized host and describes how to do so safely.

I agree in pulling a machine off the air and even specify doing so in the 3rd paragraph. As a sysadmin I realize there are often steps to take before doing so. This article describes a way to safely connect to the internal network if needed, even if it's not the best position to be in.

The authentication credentials for the bastion host and the chewy center of your network should be different :).

I warn against forwarding agent connections through the compromized host. I also cover safely verifying the internal server's host key.

I see that I did leave out specific warnings about authentication credential ( such as personal key and password ) reuse. You are correct, if they are the same on both Gateway and Server the attacker could gain the credentials when you connect with Gateway and then use them on Server. I should have covered that in the article.

WARNING: Anything communicated to authenticate to the Gateway could potentially be captured by the attacker and used against other hosts.

Better?

The article does not pretend there are no security risks at all and specifically warns against a couple.

I generally believe bastion hosts on the edge of the network should be treated as if they could be compromized any minute. The methods in this article allow access to network resources without giving the bastion host access to those resources even if it's the gateway to reach them.

Very Troubling Article

Anonymous's picture

This article does a fine job of explaining ssh tunneling. However, I am troubled by two issues with the technique suggested by the author.

First, that the author simply dismisses the importance of immediately removing a suspect host from the network. This is a red flag to be highly skeptical of any security advice to follow. Best practices are ignored at one's own peril.

Second, the omission of any discussion of the risks of establishing an ssh connection to the compromised host.

Yes, the tunneled ssh connection is not much different than an ssh session crossing unknown internet hosts. However in order to create that tunnel, one must first authenticate to the compromised host. This risks of this cannot be understated.

Well known are many rootkits which alter or replace sshd in very nasty ways. At a minimum, you are handing over your authentication credentials. By establishing a tunnel to an internal host you are potentially alerting your attacker to another target of interest which may accept those credentials.

The entire tone of the article presents the author's tunneling technique as if it involved no security risks at all. This is simply not true. The security best practice in this case is well established: Never open a network login to a compromised host.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState