Inspired by a thread on the Hak5 Forums...
Sometimes, you might find yourself wishing you could poke arbitrary holes through a NAT or firewall. The potential uses (both good and evil) are nearly limitless. Perhaps you want to be able to log in to the computer in your dorm room while you're a thousand miles away on vacation with family.
You will need a few things before we start:
- Physical access to a computer on the "inside" of the network
- Access and permission to install software on that computer
- A system on the "outside" that can accept SSH connections from the Internet
I'll be using NetBSD on my SparcStation 20 on the inside of the HiR Lab, and one of my web servers with a public IP address on the outside.
SSH Tunneling is the process of encapsulating some other protocol within an SSH session. There are many advantages to this. Essentially, if you can get out of a network with SSH, you can get to almost any TCP service on the outside world, even if it's blocked.
Reverse SSH Tunneling is a similar process. If you can get out of the network with SSH, you can use that SSH tunnel to spawn a listening process on the outside of the network, from which you can get to anything internal.
Step One: Deploy SSH keys without a password
This has to be done from the "inside" computer. You can use your personal desktop system or a server where you have an account. It must be able to SSH out to the Internet.
I don't like to use public keys without passwords, but they do come in handy, particularly for tunneling. The un-protected public key should only be placed into the authorized keys list for UN-TRUSTED accounts that aren't in the wheel group or sudoers file.
I wrote about using passwordless SSH keys before. If you're using a UNIX variant, just follow the first few steps on generating and distributing the ssh keys. If you're using Windows, install PuTTy and follow the steps that Steve Friedl put together.
Step Two: Create and test your tunnel
I wrote a little about tunneling (forward and reverse) back in February. In this case, I'm going to tunnel SSH over a reverse SSH connection -- that is, I'm going to SSH from my inside box (NetBSD) to the web server (betaweb.h-i-r.net), and tell SSH to open a reverse tunnel port (2222) on the web server that connects to the SSH port on the NetBSD box (localhost:22). The -g option allows any remote host to use the tunnel. Otherwise, it will bind only to the localhost interface.
[axon@NetBSD]$ ssh axon@betaweb.h-i-r.net -g -R 2222:localhost:22Now, from anywhere in the world that can access port 2222 on betaweb.h-i-r.net, I can SSH through my home NAT to get to the internal NetBSD box:
Last login: Sun Nov 30 14:13:08 2008 from netbsd.labs.h-i-r.net
[axon@betaweb.h-i-r.net]$
Chimera:~ axon$ ssh -oPort=2222 axon@betaweb.h-i-r.netYou don't need to reverse tunnel to localhost, and you could just as easily use this trick to reverse-tunnel your e-mail (POP/IMAP), VNC to a Windows/Mac desktop or even to an internal web proxy server.
Password: [my password]
Last login: Tue Oct 14 19:01:57 2008 from localhost
NetBSD 4.0.1 (GENERIC) #0: Wed Oct 8 01:06:02 PDT 2008
Welcome to NetBSD!
[axon@NetBSD]$
Step 3: Automate!
If you just leave the SSH tunnel up and running, it won't likely last too long because of session timeouts. You'll need some process to start the tunnel. Here's where you can get creative. Obviously, a process involving the use of cron or at would be one way of going about it. A script running in the background (with nohup) or in a screen session could also take care of things nicely. One idea I had was to set up fetchmail to check a dummy e-mail account every 5 minutes or so. If there's new mail, it initiates the tunnel. Send mail. Wait. Tunnel. Another way would be to upload a file to a web or ftp site to trigger it. You could even make it read information from that file to create the tunnel for different protocols. I opted to create a configuration file on the web server that would be downloaded and used.
On the "inside" box, I created this script and called it tunnel.sh:
#!/bin/shThen, I added this to my crontab:
ssh betaweb.h-i-r.net rm .tunnel
args=`cat .tunnel`
rm .tunnel
ssh $args
*/5 * * * * scp axon@betaweb.h-i-r.net:.tunnel ~/.tunnel && ~/scripts/tunnel.shEvery five minutes, it will try to scp a file called ".tunnel" from the "outside" box. If it was successful, it runs the tunnel.sh script.
The tunnel.sh script removes the .tunnel file from the remote box (so that it doesn't try to spawn multiple tunnels every 5 minutes) and then uses the contents of .tunnel as the arguments for ssh.
I create a file on my laptop named ".tunnel" and add the following:
axon@betaweb.h-i-r.net -g -R 2222:localhost:22 sleep 600Then, I upload it to the location and wait about 5 minutes. Then, I ssh to port 2222 of betaweb.h-i-r.net. The "sleep 600" is executed on the remote end, which means it will only stay connected for 10 minutes (600 seconds).
Tada!
chimaera:~ axon$ scp .tunnel axon@betaweb.h-i-r.net:
axon@betaweb.h-i-r.net's password:
stdin: is not a tty
.tunnel 100% 58 0.1KB/s 00:00
[ wait 5 minutes ... cue Jeopardy theme song ]
chimaera:~ axon$ ssh -oPort=2222 axon@betaweb.h-i-r.net
Password: [my password]
Last login: Tue Oct 14 23:24:10 2008 from localhost
NetBSD 4.0.1 (GENERIC) #0: Wed Oct 8 01:06:02 PDT 2008
Welcome to NetBSD!
[axon@NetBSD]$
Considerations and Risks:
I've already stated that using public keys without a password is risky business.
The other shady business is directly executing anything using arguments pulled from some file on a remote server. All it would take is "; [insert evil command here]" added to the .tunnel file and havoc can potentially be wreaked on that internal box.
If you can get away with it, BY ALL MEANS use separate accounts that are not used for anything other than this tunneling process. Lock them down as best you can and be mindful of local privilege escalation attacks.
See? This is why admins put firewalls up in the first place. And don't go pointing your finger at me if you get in trouble for unauthorized tunneling.
Posts
