dimitar.me

Dynamic Port Forwarding with SOCKS over SSH

Dynamic Port Forwarding with SOCKS over SSH is probably the easiest and cheapest secure method to connect a client application to a remote host over a preferred port.

This method allows an application on a client computer to make request to a local port, then the requests are forwarded to a remote host, which processes the requests and returns the data back to the client. This is very similar to a simple proxy, with the exception that in a proxy set up the application sends data directly to the remote host, while in this configuration we have an emulated local SOCKS server that handles the requests first and then directs them to the remote computer… oh yeah… and the network traffic is encrypted.

Dynamic Port Forwarding over SSH is in a way a simple alternative to VPN.

Why would anyone need this? Two main reasons immediately come to mind. First, if you are on a public, non secure, non trusted, unencrypted network (for example at the local coffee shop) you can use this method to securely connect to a remote host and have your network traffic encrypted and thus protect your data and privacy. Second, if you need to bypass local network restrictions and monitoring services. A good example here is circumventing surf control restrictions. In most cases, surf control is implemented by monitoring the traffic and examining the tcp/ip packets over port 80. By using Dynamic Port Forwarding over SSH, we channel http traffic through a different port and furthermore all http requests/responses are encrypted via ssh and thus cannot be examined or filtered.

Now let’s see how it is done.

Remote Host Setup.

A remote host is needed that will receive and process the requests from the client. Any computer or device can be the remote host as long as it runs ssh. In this respect any Linux box is ideal for that purpose.
From a practical standpoint, your home router is probably one of the best candidates for being your remote host. You need to run open source software on it, like OpenWRT, DD-WRT, Tomato, etc. and have ssh enabled on it. If you are still running the original firmware that you router came with, you are only using a fraction of the hardware’s capabilities and you are missing out on a lot of great features.

If you plan on using a computer on your home network as the remote ssh host, do not forget to set up the port forwarding on your router accordingly.

Client Setup.

If your client is a Linux box, you hardly have to set up anything. All you have to do is connect to the remote host with the following command:

ssh –D port_number user_name@remote_host (for example: ssh –D 8080 dimitar@72.134.54.23)

And then the only thing that is left is to configure your application to use SOCKS. Look at the Firefox setup below as an example (Step 7).

If your client is a Windows box, you have to install an ssh client. PuTTY is a good ssh client for Windows and it is free:

Step 1. Download PuTTY.
Step 2. Open up PuTTY and put in the host IP address or domain name. Leave the port as the default 22 and give the connection a name under “Saved Sessions” and click “Save”:

Step 3. Click the “SSH” on the left hand side under “Connections” and make sure that the “Preferred SSH protocol version” is set to 2.

Step 4. Click on “Auth” and select “Allow agent forwarding”:

Step 5. Go to “Tunnels” and enter the port in the “Source Port” field, select the “Dynamic” radio button and click the “Add” button. Here optionally you can check “Enable X11 forwarding”, which will come in handy if you want to run graphical applications from the remote host. For this piece to work though, you will need an X11 client running on your Windows client, like Cygwin, Reflections X, Humming Bird, etc., but this is beyond this discussion.

Step 6. Click “Session” on the top left to go back to the first screen and save your setting.

Step 7. Now you are ready to configure your application to use the Dynamic Port Forwarding with SOCKS. For this exercise we will configure Firefox. Open Firebox’s “Options” dialog (called “Preferences” if running on Linux) and go to “Advanced” and then “Network”, hit the “Settings” button under “Connection”. In the window that pops up select “Manual proxy configuration”, enter localhost for “SOCKS host” and the port number (8080 for this exercise). Select the “SOCKS v5” radio button and enter localhost, 127.0.0.1 in the “No Proxy for” box:

Now when you browse the internet with Firefox, all the traffic will be directed to the local SOCKS proxy server on port 8080, then the packest will be encrypted and forwarded over ssh on port 22  to the remote host (you can alwasy change the default ssh port to any other port). It is important to notice, that the remote host will decrypt the packets from the client and then make the requests on port 80 without encryption.

Basics of Networking

I have to admit that the majority of the IT professionals I have met have a little or no idea of basic networking. And sadly some of those are sys admins, site admins, programmers and in the extreme cases even WAN and Network admins and Security “experts”. In the above mentioned group, only the programmers can actually be “excused” . Being a programmer myself, I know that you do not have to be aware of what a Level 4 device is in order to write good code. But it helps… especially in troubleshooting scenarios- for example when your program cannot connect to the database due to network or firewall misconfiguration.

I am a visual person and most of the time a picture speaks a lot more to me than a bunch of words, so here is a simple diagram that explains the basics of a TCP/IP network packet:

A little more detailed version of this diagram I drew up in my notebook when I was taking a networking class in college. I still find myself drawing it on a white board when someone asks me a network question.

The “Level” labels above refer to the different layers of the OSI model. It is helpful to think about a network packet as a present, wrapped in multiple boxes. The outermost box corresponds to level 2 in the OSI model (Data Link layer) and it is the one containing the physical addresses of the source and the destination machines. A typical level 2 device is a network switch.

Inside this big box is the level 3 (Network layer) box that contains the IP address of the computer sending the packet and the one that it is directed to. An example of a level 3 device is a router.

The next box is the one that identifies what port the packet originated from and the number of the port that the destination computer should receive the data on. The port number ultimately determines what application is responsible for processing the data. For example, a packet coming on port 21 means that it is an ftp request and that the ftp daemon on the machine should process it. This box corresponds to level 4 on the OSI model – the Transport layer. A PIX firewall is a typical level 4 network device.

And the innermost box of the packet is the “present” itself – the data. This is what was needed to be delivered from one computer to another on the first place and the rest of the boxes were just the means to accomplish this.

The different network devices and computers open the different boxes and read the information they carry as needed. For example, it is helpful to remember that routers strip the Data Link layer to find out the destination (the IP) address of the packet. Then they reconstruct that layer with a new destination physical address – the MAC address of the next hop on the network and with their own MAC address as the source address. This process repeats until the packet reaches its destination.

I have been asked many times by web programmers how to find out the MAC address of the machine that made the original request . As you can see now- this is impossible. The TCP/IP packet that reaches the web server will only contain the MAC address of the last router that processed the frame.

Of course there is a lot more to network packets and protocols than this. But the simple diagram above is good enough to give you a basic idea and to get someone started in the field of networking.