Loading
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.
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.
______________________
Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Tech Tip: Really Simple HTTP Server with Python
- Kernel Problem
1 hour 21 min ago - BASH script to log IPs on public web server
5 hours 48 min ago - DynDNS
9 hours 24 min ago - Reply to comment | Linux Journal
9 hours 56 min ago - All the articles you talked
12 hours 20 min ago - All the articles you talked
12 hours 23 min ago - All the articles you talked
12 hours 24 min ago - myip
16 hours 49 min ago - Keeping track of IP address
18 hours 40 min ago - Roll your own dynamic dns
23 hours 53 min ago
Poll
Comments
"you can ssh safely across a
"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
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
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.