Howto: Remote Desktop At Work, Evading A Firewall

A lot of organizations intentionally block remote desktop capabilities. With that in mind, please be aware that following the instructions in this post may lead to consequences depending on policies outlined within your organization. This guide will demonstrate ways to evade firewalls, which could result in enough justification for termination, so be careful!

I’m going to provide several methods, so read the entire post and decide which method might work best for you. If you’re unsure, just try ‘em all until one works. The first method in this guide assumes the following:

• Your Remote Desktop server is Microsoft’s Windows XP Professional
• You’ve successfully used Remote Desktop before
• Remote Desktop server is to listen on port 3389
• You’re able to leave the protected network somehow: http, ftp, ssh, whatever

Change Remote Desktop’s Listening Port

This is the easiest method, but requires modifying the registry, which can result in a very negative outcome if modified incorrectly. There are several tools available that prevent the need to go into the registry, but have faith, you’ll do ok.

• First, login on the server as an administrator - the computer you’re trying to connect to (most likely your home PC).
• Click Start, then Run, and type: “regedit” (without quotes), then click OK.
• Click the plus (+) signs next to the key values below until you reach the last one.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
• Click the key on the left labeled RDP-Tcp to reveal a list of entries - find the entry labeled: PortNumber
• Double click the entry and toggle the radio button from Hexadecimal to Decimal

At this point, the choice is yours. I personally recommend port 443 (secure HTTP) since most organizations will allow traffic to leave your computer to that port. To test this, try logging into any secure site at your client workstation (work/school PC). Gmail, your bank, any site that utilizes a certificate and https://. If you’re able to successfully login to a secure site, chances are outgoing TCP traffic on port 443 is allowed. In this case, changing the listening port from 3389 to 443 is advised. If that doesn’t work, try port 80, or 21, even 22.

You can test whether or not the change was successful by visiting this web site. The first text input box should populate your remote desktop server IP address (your home IP in most cases) and have an empty text input box for the port you’d like to test. Supply the port number provided above (443, 80, whatever you changed 3389 to), and click the Go command button. If you see something similar to the following:

192.168.100.100 is responding on port 443 ().

You’re good to go! If not, make sure port forwarding in your router has been updated, and a software firewall isn’t restricting access. Once you’ve verified port 443 is responsive, goto work or school and open the Remote Desktop client. Instead of just providing the IP address, you’ll now need to specify the new listening port like so:

192.168.100.100:443

If you successfully connected, congratulations! If not, you either did something wrong, or your IT staff is clever. In that case, you should try the next method.

Tunneling Remote Desktop For Evasion and Security

This method will require a little more effort, but the probability of working is in your favor, and the enhanced security (encryption) is an added bonus. A number of variables come into play with this method, so depending on your situation, you may need administrator rights on the client (work/school) PC. If that’s not an option, you at least have to have the ability to get putty on your computer somehow - either from a CD, thumb drive, whatever. Here’s what’s needed:

• If administrator rights exist, a Linux Virtual OS on the client (the work/school PC)
• If that’s not an option, a Linux shell account from a shell provider is needed
• Web masters: check with your web space provider for shell/ssh access!
• PuTTY.exe, the best free SSH client available

If you are an administrator on the client workstation but don’t have access to a Linux shell account, or simply don’t want to pay for one, a virtual operating system is for you. First, download Microsoft’s free Virtual PC 2007. Once downloaded and installed, head over to my favorite Linux distribution’s web site and download the business card installation. You’ll find an installation guide on their web site - perhaps I’ll go over that in more detail another time.

Fire up Virtual PC 2007 and create a New virtual machine. This is pretty easy, and the defaults should work fine. Just click next, next, next. For the virtual hard disk space, a single gigabyte (1024 megabytes) or even less will work fine. The business card download is 36 megabytes, which is ultra small for an OS. Just choose not to install anything during the installation (of the virtual Linux session).

With the new Debian virtual machine template created, start the session by clicking Start in the Virtual PC Console. Before the session has an opportunity to fully initialize (boot), click CD at the top of the new window, then click Capture ISO Image… and select the Debian business card installation ISO previously downloaded. This will begin the Debian installation. If you’ve never installed Linux before, now’s a good time to learn. Don’t get intimidated, it’s pretty straight forward, and rewarding. Perform the most minimal installation possible, but make sure SSHD is installed and enabled. If you’re unsure whether or not SSHD was installed, here’s how to check. Login as root (you did remember your root password, didn’t you?), and type:

netstat -tap |grep sshd

If you see something similar to:

tcp 0 0 *:22  *:* LISTEN 10000/sshd

You’re good to go! If not, don’t worry. Still logged in as root, type:

apt-get install ssh-server

Once completed and back at the root prompt, type the netstat command mentioned above to ensure the service is running. If not, type:

/etc/init.d/ssh force-reload

If that doesn’t start the service, or you get an error, or whatever, ask your question(s) in the comment section below.

Now that SSH is up and running in the Linux virtual session, fire up PuTTY. The first screen that appears is titled PuTTY Configuration. In the Host Name (or IP address) text input box, type in the IP address of your Linux shell server. For virtual user’s, this is the IP address of your Linux OS, for those who pay for a shell account, use the IP or hostname your shell provider gave you.

To find your IP in Linux, type the following while logged in as root:

ifconfig

Output similar to the following will appear:

eth0 Link encap:Ethernet HWaddr 00:22:EE:29:01:19

inet addr:192.168.100.200  Bcast:192.168.100.255  Mask:255.255.255.0

inet6 addr: ef70::101:ffff:ef42:114/64 Scope:Link

You’re after the inet addr portion, which in this example is 192.168.100.200. Back to PuTTY, for the port, just provide 22, unless you’ve changed the SSHD listening port. Now, on the left side of the PuTTY Configuration screen, navigate to Connection, then SSH. Check the box labeled Enable compression and select the radio button labeled 2. Drill further down on the left to the Tunnels area (it’s a sub menu of the SSH area). In the Source port text input box supply: 443. This is telling PuTTY to listen for communicate with your remote desktop server on port 443 (commonly known as secure http). For the text input box labeled Destination, type in your remote desktop server IP (target machine, usually your home network IP) along with remote desktop’s listening port (typically 3389). I’d suggest following the steps mentioned above on how to change the listening port because chances are, if you can’t remote desktop to port 3389 from your Windows XP machine at work or school, your Linux virtual machine won’t be able to, either. Here’s an example entry:

Once again, just to make things clear, the Source port is the port PuTTY will listen on to intercept remote desktop connections leaving the client (the computer your remoting from), and the Destination is the IP address and port of the computer you’re remoting to. So, to wrap this up. Your PuTTY session IP address is your Linux shell server’s IP or hostname with the port set to 22 (assuming you haven’t changed it). SSH compression is enabled, and you’ve setup the Tunnels portion to route traffic leaving your client workstation on port 443 to your home computer.

Here’s a diagram to illustrate what’s going on with a virtual machine setup:

Here’s a diagram to illustrate what’s going on with a remote Linux shell:

I’m aware the diagrams suck, I’m not artist; however, they should basically illustrate how this entire setup is intended to operate. Now, save the newly configured putty configuration settings with a name of your choice and connect. If you’re unable to connect via port 22, you may need to reconfigure SSH to listen on port 443 as well. Login with your normal user account (not root) and keep that session open. The putty window must remain open to continue tunneling the traffic as configured. Open the remote desktop client and instead of using your regular home IP, use the following:

127.0.0.1:443

The remote desktop client will now connect to the local workstation on port 443, which is the port we configured putty to listen on. Putty then uses the active SSH connection established with the Linux server on port 22 to forward activity on 127.0.0.1:443 to your home IP that’s also listening on port 443. If you’re using a VM, network monitors will only show your workstation as having an active SSH session with some rogue Linux box while the rogue Linux box looks as though it’s just surfing the web with secure http (https, or port 443).

If you’re using an external shell account, network monitors will reveal just an SSH connection established with an outside IP, unless you configured your Linux box to listen on port 443. In that case, network monitors will only reveal that you’re surfing the web securely. Ok, so I’m not the best at explaining how all this works, but the point is, it does, and you can always ask questions, provide comments, or offer suggestions in the comment submission box below.

To conclude, there’s an obvious advantage to having an external shell - the traffic remains highly encrypted until the Linux shell communicates with the RDP server. This ensures your RDP traffic within the network (your work/school) is secure and unreadable. Unless I’m mistaken, RDP has a built in level of encryption, but no where near as strong as what SSH offers. This is also a great way to secure communications when using an open WIFI access point. Tunneling your communications through an external Linux server will make all of your internal network transmission unreadable.

Good luck! And if this is confusing, or you just need some help getting everything setup, please don’t hesitate to ask.