[ Saturday, 19 August 2006, pazkooda ]
The goal of this article is to present a few effective methods to revamp the way you work in a restricted corporation-like network. In order to achieve it we’re going to use SSH tunneling to bypass the firewall rules applied by your system administrator. We’ll start with breaking through simple restrictions and gradually pass to more and more elaborate firewalls while we move on.
Author: Lukasz Usowicz
Translation: Lukasz Usowicz, Borys Musielak
Important note: It’s not our goal to encourage you to illegally bypass any restrictions set by the administrators of your network. We present a technology which is often helpful when working on a machine behind a firewall. If you are willing to use some tricks presented here to break through your company’s firewall, you have to understand that it may not be allowed in your corporation and you risk getting sacked. We take no responsibility for your actions. You’ve been warned.
This article is a continuation of a previous text: SSH tricks published in our vortal last month. The spirit of this article is a little bit different, though. It targets more experienced users, especially those who have to work in computer networks with harsh security rules. To make it clear – using SSH to tunnel insecure protocols like FTP or CVS is not in the scope. Perhaps another SSH article will cover this.
Here are a few things that you need to know or prepare in order to benefit from this article.
- Basic SSH and Linux knowledge (which can be obtained from the article mentioned above).
- A local workstation (in a restricted network) with GNU/Linux installed.
- A remote Linux machine, with a public IP address (let’s assume it’s static to simplify the situation).
- Patience and no fear to use the command line.
For simplicity reasons, throughout this text we’re going to use some default names. The workstation which is located in a restricted network eg. on our desk at work (the one we are going to revamp) will be called
LOCAL_HOST. The second one should be outside the restricted network eg. at our house and will be called
REMOTE_HOST. Let’s assume that on the home workstation there is a user named
user and on the work machine there is a user
worker. On the
REMOTE_HOST with a public, static IP an SSH server is installed. Although all the solutions presented in this article can be applied in any GNU/Linux distribution or even in MS Windows to make it simpler, we will consider a Debian-like system only.
If you don’t have the SSH server installed and running, open up a terminal and type (as root or using
sudo) the following command:
REMOTE_HOST:~# aptitude install openssh-server
The server should start automatically after being installed (as well as on system start-up). We should also check whether we’re not blocking the port 22 on our firewall (and open it if we do). We should also note down our IP address (we’ll call it
IP_NUMBER in text; try
/sbin/ifconfig command to figure it out).
All right, let’s leave our home computer (
REMOTE_HOST) now on and go visit our office. First, we need to analyze our network restrictions. Sounds serious but don’t worry – I’m not going to mess with network sniffers and other types of hacker tools. We are going to simply try to connect to some outside networks and depending on the level of restrictions we’ll see whether we fail or not. Looks good? Let’s start then.
Creating a simple tunnel
At the beginning let’s assume that SSH connections are not blocked, but we can receive e-mails only from our local office account. This means that ports 25 and 110 (SMTP and POP) are open only for our local network. But what if we want to be able to receive mail from external servers (
EXT_POP_SVR) and send it using external accounts as well (
EXT_SMTP_SVR)? Here is where the tunnels enter the stage. We just need to add a parameter while connecting to the
REMOTE_HOST via SSH. So, we’re digging the tunnel from our work machine to home with the following command:
worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\ -L 10025:EXT_SMTP_SVR:25 -L 10110:EXT_POP_SVR:110
Let’s try to decode this. The option
-L can be read as “listen on local host”. After a space bar we put the port on which SSH has to listen (in our case respectively
10110, but it’s just an example; we can choose different ones but in order to tunnel ports with numbers lower than 1024 we need root privileges). After first colon we point where our
REMOTE_HOST should forward the connection. After second colon we state on which port the final server/computer awaits our connection. I emphasize that just after the first colon we give an address relative to REMOTE_HOST. If we want to connect via tunnel with
REMOTE_HOST on port 25 (and not further than there) we should use something like:
worker@LOCAL_HOST:~$ ssh user@IP_NUMBER -L 10025:localhost:25
The relation between
REMOTE_HOST is the following: this is the very same host , so it’s
localhost for itself.
Let’s get back to our tunnels. We can now configure an e-mail client to connect to an external server. As we’ve mentioned earlier, our
LOCAL_HOST listening on port
10025 is now “
EXT_SMTP_SVR server listening on port 25”. By analogy, we can say that
localhost:10110 is an
EXT_POP_SVR:110. In our e-mail client we shall set an incoming server to
localhost and port to
10110 – SSH will carry on further communication. Naturally,
localhost set on
LOCAL_HOST will point to itself. And again by analogy outgoing server should be set to
localhost and port to
In this quite simple (I hope!) way we can bypass not very complex restrictions only. But our network administrator is not sleeping so…
Note that you don’t have to use your
IP_NUMBER all the time. If you want to use
REMOTE_HOST by its name you need to put a line like this
/etc/hosts file (on the machine at work), so that your work machine translates the
IP_NUMBER on the fly. You don’t need to do this only if the
REMOTE_HOST is a domain name (or if you’re fine with using your
IP_NUMBER all the time). In this text we use
Let’s swing into a higher gear
Our present situation has changed. It seems that somebody in our work abuses usage of WWW. Access via HTTP has been cut to the minimum allowed by the boss. Right now we are not interested in how it has been done. Port 22 is still open, but we can’t say the same about port 80 (responsible for HTTP communication). Now when we know how the tunnels work, this is not a big problem for us.
It seems impossible but even the Google search has been blocked. So, to solve this unfortunate situation, we sit down and log onto our
REMOTE_HOST like that:
worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\ -L 10080:www.google.com:80
Just a few clicks in Firefox:
Edit -> Preferences -> Connection Settings -> Manual proxy configuration. Here we can put in the
HTTP proxy server field:
port. If there has been some other values in those fields, we shall write them down. We may need to use them later on. I’ll call those extra settings
Now, we can type
http://www.google.com in the address bar and… hip hip hooray – the WWW is wide open again. Don’t be so happy though. Try
http://www.altavista.com. And what you’ve got – Google search again. Well, what else can we expect if we’re forwarding all traffic to
www.google.com via SSH! To visit AltaVista we should reconnect again with:
worker@LOCAL_HOST:~$ ssh user@IP_NUMBER \\ -L 10080:www.altavista.com:80
This is rather a pretty non-effective way to work with the Internet, don’t you think?
SSH as a proxy
In this situation let’s look into the SSH manual and find a parameter
-D. As we can read there, SSH can act as a (specific) proxy server. This is a SOCKS-type (pseudo)server. We won’t be concerned how it works, just remember the name. Type the following in your text terminal:
worker@LOCAL_HOST:~$ ssh user@IP_NUMBER -D 8080
From now on, SSH listens on port
8080. Looking back into Firefox’s proxy settings we can find a
SOCKS Host field. There we put
localhost and port
8080 (server type should be set to 5). Don’t forget to remove the previous entries in
HTTP Proxy that we’ve set earlier. And what we’ve got? Well, now SSH will intercept everything on this port and dynamically open a tunnel (via
REMOTE_HOST) to the final target typed in the Firefox address bar. From now on we can surf over the whole Internet! Vualla!
Putting on transparent socks
There is one little issue. And you know what? I think that Opera users will rise it first. That’s because currently Opera does NOT support SOCKS. I’m an Opera user too and I can’t understand that, just like you . This is the right time and place to introduce one of the SSH friends: tsock (abbr. transparent SOCKS). Yet again we won’t look deeper in how SOCKS server works but with tsocks we’re going to use some of its features instead. We’ll need root account privilege on
LOCAL_HOST to do this. This is not always available but here it’s required. Let’s install tsocks (again on Debian):
LOCAL_HOST:~# aptitude install tsocks
Assuming that SSH still listens on port 8080 as a proxy, we should perform the following steps:
- edit tsocks configuration file
- find an option called
localand put there our local network(s) address(es) eg.
local = 192.168.0.* local = 10.0.0.0/255.255.255.0
- if we want to create a custom path, we can do this with the option
path, I’ll omit this part for now,
- here is the most important thing: options
server_port. We’ve got to set them to our proxy server. In our example it will look like this:
server = localhost server_port = 8080
- we should also set SOCKS server type; set it to
server_type = 5and don’t ask me why
It’s time to put those socks on. We can do this as a normal user. Again in a terminal:
worker@LOCAL_HOST:~$ tsocks opera
Here tsocks are used to run Opera. But it will also intercept all network queries generated by the browser and forward them directly to the SOCKS server (except for the local network queries). Our proxy server (ie. SSH) will then forward those queries further on to
REMOTE_HOST. All in all, Opera will act as if it has been run in the
REMOTE_HOST environment. This way, the browser won’t be vulnerable on any network restrictions. If
REMOTE_HOST is connected directly to the Internet, Opera should also be configured as
Directly connected. The whole “dirty job” is done by the tsocks+SSH tandem. In fact we can run practically any net application with
That’s how we’ve met first good SSH friend, but…
We’re in trouble now…
… just because our admin closed port 22. Loser! Well, we need to adjust to the new environment now. First, we should find a port which is usually open. Let’s try the one responsible for secure web pages (SSL connections) which is usually left open in all networks. Its number is 443. As there is no possibility to change anything remotely for now, we need to go back home. Sitting in front of our
REMOTE_HOST as root we need to edit
/etc/ssh/sshd_config file. Find the place with entry
Port 22 and put
Port 443 just below. All we have to do now is to restart SSH server with:
REMOTE_HOST:~# /etc/init.d/ssh restart
Sample command to connect to
LOCAL_HOST in the present situation may look like that:
worker@LOCAL_HOST:~$ ssh -p 443 user@REMOTE_HOST -D 8080 \\ -L 10025:smtp.gmail.com:25 -L 10110:pop.gmail.com:110
As you can see, option
-p 443 is a proper switch to force SSH to use a non-default port for a connection. And again we are “free as a bird”.
Battle continues with a corkscrew
Oh, no! Our network administrator got really furious now. “It’s time to finish these abuses” – he said. But he was not allowed to block all HTTPS traffic (fortunately!). So he figured out that the best thing in this situation is to control all traffic with an HTTP proxy server. He has set it up to listen on port 3128 and opened this port to connect only to a proxy server (naturally port 443 has been blocked). Outside connections on port 3128 are blocked too. Is there any way to bypass this? Well, try to remind some settings you’ve written down earlier:
PROXY_SVR, PROXY_PORT. We’ll assume now that these values point to admins’ proxy server (here
PROXY_PORT = 3128). We need to find a proper tool to use these values. Let’s look into our repositories:
worker@REMOTE_HOST:~$ apt-cache search proxy ssh tunnel
Among the results we should probably see a corkscrew app. Quick installation:
REMOTE_HOST:~# aptitude install corkscrew
Corkscrew manual reveals an easy way to “teleport” SSH to the other side of the HTTP proxy. To generate such a “hoop” we need to know which types of connections are passed directly through the proxy. All encrypted connections usually fulfill this condition. That’s why we again concentrate on HTTPS (port 443). To force SSH skip the proxy we should edit
~/.ssh/config and add the entry shown below:
Host IP_NUMBER ProtocolKeepAlives 30 ProxyCommand /usr/bin/corkscrew PROXY_SRV \ PROXY_PORT IP_NUMBER 443
Having such settings we should be able to connect to
REMOTE_HOST again with:
worker@LOCAL_HOST:~# ssh -p 443 user@IP_NUMBER
All those switches like -L and -D still work, so we can use them in a suitable way for us. So please welcome another good friend of SSH – corkscrew.
Once again we can feel the breath of freedom, but …
And so on, and so on
We could continue our speculations further and further. A well-prepared administrator will find a way to block all methods shown above. But one truth is uncontested: if there is any hole in a restricted network, it automatically becomes a wide open window to the whole world. Here we talked only about the HTTPS protocol abuse and a HTTP proxy. But there are other environments and protocols we could possibly use.
- There is another useful option for SSH. It’s
-Cwhich compresses all traffic on-the-fly. It’s especially useful while using corkscrew.
- I haven’t mentioned the reverse tunnels (option
-R), but they are very useful as well.
- Another method to efficiently bypass restrictions when we don’t have root access on
LOCAL_HOSTis (our) proxy server installed on
- As I’ve mentioned in the beginning, SSH is widely used to secure “plain text” protocols, too.
- If you have the knowledge and would like to describe the above issues precisely for this vortal, feel free to contact michuk, I’m sure he’ll be very pleased with that
Appendix (for the tenacious ones): using httptunnel
The above text is an almost-direct translation from the original. But I’ve got something special for those who are not bored (or confused) with all those tunnels, yet. So, let’s met the…
Absolutely extreme conditions
Here I need to be more precise. Imagine that the traffic in our network is allowed only via port 3128 and only to one specific IP number which points to a proxy server. What’s more, the proxy doesn’t allow for http_connect (i.e. forwarding encrypted protocols). This excludes the usage of corkscrew. And to make it even harder, the firewall blocks all packages that don’t have an HTTP header. Conditions described above mean no more than that we are only allowed to view “classical” web pages and only with a proxy. What shall we do to bypass such restrictions? To effectively overcome this “not so fortunate” situation, we’ll still need SSH. But this time SSH is going to have a special carrier to bypass the proxy. This carrier needs to have an HTTP header to do its job. You can probably figure out the name of this third SSH friend – yes, it’s an httptunnel. Installation is needed on both hosts (
REMOTE_HOST) and as you’ve noticed earlier, in Debian this is as simple as:
REMOTE/LOCAL_HOST:~# aptitude install httptunnel
The application contains both an httptunnel server (
hts) and an httptunnel client (
htc). I encourage you to take a look at the manual to see how it works in detail, but the usage is very similar to SSH tunneling. On the
REMOTE_HOST we need to run the server side of the application. The server is responsible for deciding where the connections should be forwarded. If we want to tunnel the connection to
REMOTE_HOST we simply point it by using
In our example we only want to forward all connections to an SSH server running on
REMOTE_HOST. To accomplish this task, the httptunnel server should be started as follows:
REMOTE_HOST:~# hts -F localhost:22 80
A word of explanation:
-F localhost:22 means that each connection is going to be forwarded to
REMOTE_HOST‘s port 22 (i.e to an SSH server on
80 is the port on which hts should await our connections from the outside (just remember to open it on the firewall and/or stop any other services that may be running and listening on this port).
The appropriate command to connect to
LOCAL_HOST using the proxy is:
worker@LOCAL_HOST:~$ htc -P PROXY_SVR:PROXY_PORT \\ -F 10022 IP_NUMBER:80
From now on,
LOCAL_HOST listening on port
10022 should forward all connections to port 22 on
REMOTE_HOST. To establish a desired SSH connection we can type:
worker@LOCAL_HOST:~$ ssh -p 10022 user@localhost -C -D 8080 \\ -L 13389:somewhere.else.com:3389 -L \\ 13306:here.or.there.net:3306
Although this is a double-tunneled connection and may be a little bit slower than a direct one, it allows us to navigate all over the net, not only to the addresses set by the administrator. And you know what? We are free again!
I just hope that each of you won’t need to apply all of those tricks in real conditions. But… some day, somewhere… it may even save your life