Reverse Remote Access

by st4r_runner

Most businesses have some form of remote access for their employees.

Well, what if your company doesn't want to support your Linux/*BSD operating system?  Or what if remote access is down and you can't connect to finish that important project?  What do you do then?  What if there were a way to have reverse remote access, or, in other words, have your company's network connect to you instead of the other way around?

There are several ways this can be done.  This article will describe one way to do this.  The basic outline of this scenario will go like this:

Send an email to your work address.

Your email client at your workstation at work will receive that email and launch a command.

Your workstation at work will then connect to your workstation at home.

Got it?

Pretty simple concept.  And just as easy to do to.

These instructions are based on the following assumptions:

At work you have a Windows OS workstation with Outlook installed.

At work you have the ability to connect to the Internet either directly or through an HTTP proxy that supports the HTTP CONNECT method.

At home you have a Linux workstation and a Linux firewall (or some firewall that can do port forwarding).

The abstract would look something like this:
WorkXPWorkstation <--> CorporateFW/Proxy <--> Internet <--> HomeLinuxFW  <--> HomeLinuxWorkstation
Those are the pieces. To put them together, we'll focus on one piece at a time.

//BEGIN Configuration

WorkXPWorkstation

Need:

Cygwin (sources.redhat.com/cygwin/setup.exe) base installation with OpenSSH.

Outlook (or some mail user agent that can process rules and run commands). You must be able to keep your workstation powered on and logged in with Outlook running.

Corkscrew (www.agroman.net/corkscrew) to proxy SSH through if you need to.

Config:
1.)  Outlook.

      A.)  Create a client-side rule that says: Any email from myaddress@homeisp.net -] with subject of phone-home -] run command C:\ssh-home.bat

      B.)  Create C:\ssh-home.bat containing:
cd C:\cygwin\bin
cmd /k bash ~/run-ssh.sh
2.) Cygwin.

A.) Create a ~/.ssh directory (if one does not exist already).
$ mkdir ~/.ssh
B.) Create a ~/.ssh/config file containing:
Host home
    HostName myhomefw.dyndns.org
    User myusername
    ProxyCommand /usr/local/bin/corkscrew proxy.work.com 8000 %h %p
    IdentityFile ~/.ssh/mykey
    RemoteForward 3389 localhost:3389
C.) Create a password-less SSH key. The key must not have a password or this won't work.
$ cd ~/.ssh; ssh-keygen -f mykey -t dsa
(Hit Enter at the password prompts.  This creates: mykey and mykey.pub)

      D.  Compile Corkscrew in the Cygwin environment.

      E.)  Create ~/run-ssh.sh containing:
#!/bin/bash
/ust/bin/ssh -N -F ~/.ssh/contig -f home &
HomeLinuxWorkstation

Need:

1.) SSH server (I'd be surprised if it's not on your system already).

2.) rdesktop client (www.rdesktop.org)

Config:
1.) SSH.

A.) Edit /etc/ssh/sshd_config (location will differ depending on distribution/installation).
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
B.) Copy the mykey.pub created earlier on your windows workstation into your authorized_keys file.
$ cat mykey.pub >> ~/.ssh/authorized_keys
HomeLinuxFW

Config:
1.) iptables port forwarding (replace XXX.XXX.XXX with your corporate public IP range and 10.0.0.2 with the IP address of your Linux workstation).
# iptables -t nat -I PREROUTING -p tcp -s XXX.XXX.XXX.0/24 --dport 22 -j DNAT --to 10.0.0.2:22
If you do not have a Linux firewall then just create your own rule to forward port 22 into your internal machine.

The beauty of the iptables rule on the Linux firewall is that the firewall can still run its own SSH server while forwarding connections from your corporate network to your internal machine.
//END Configuration

Now let's test some things out.

From your WorkXPWorkstation open up a Cygwin Bash shell and try running this command:
$ ssh home
If this is your first time connecting you will be prompted to accept the host key, so type yes.

You should have been logged in without being prompted for a password.  If not, then check the proxy settings.

Final Run

1.)  Send an email from your home email account to your work email account with a subject line of phone-home.

2.)  Watch the output of netstat -ltnp to see when port 3389 opens up on your HomeLinuxWorkstation.  You can alternatively do:
$ while true; do netstat -ltnp|grep 3389; sleep 5; done
3.) Once port 3389 is listening on HomeLinuxWorkstation, you can run rdesktop to your WorkXPWorkstation:
$ rdesktop -a 16 -g 1280x968 localhost &
Voilà.  You should now have an RDP connection to your WorkXPWorkstation desktop.

Warnings

This is not the most secure setup.

Yes, you will have an encrypted tunnel going to your corporate network.  That's not the problem.

First, keep in mind that you have a password-less SSH key.  If someone gets a hold of this key they can log into your machine without a password.  Please do not try setting this up as the root user on your home machine.  So do not put your mykey.pub into /root/.ssh/authorized_keys - that's bad.

Second, weakest link scenario: If your home firewall is insecure and someone was able to get in and steal your SSH host key and intercept your connections in a "man-in-the-middle" attack.  If they didn't have your SSH host key, then a "man-in-the-middle" attack would be a little more difficult since the SSH client would fail complaining that the host key that it has stored is different.  (Verify your SSH host key.)

Third, remember that your corporate policy may frown upon this type of outbound connection.  Ask your manager/supervisor about it.  You don't want to get fired over this.  If you actually support your company's remote access environment then you can probably sell it as a way to get in to fix things when remote access is down (wink, wink).

In conclusion, this is a quick and easy way to get an encrypted tunnel into your corporate network for work you need to get done.

Shouts: imreut, King AdRock, frodo.

Return to $2600 Index