Nonrouting Networks

Our journey does not end here. Oh, no. There are networks still more fanatically isolated. There are, out there, networks that do not allow any directly routed IP datagrams in or out. Yes, indeed.

I have encountered networks where the only outbound communications permitted are through HTTP proxy servers and e-mail servers (where only the mail machine is allowed to send traffic ”all mail users first forward their mail to the master server).

Personally, I consider such draconian networks to be severely misguided, as I suspect the rest of this chapter will make clear. Why? Because if you have a hole, any hole, in your network balloon, then it is always possible to pass the air that is network traffic through it. In other words, phhhfffftthhhhhh! Your security balloon has deflated.

Let's posit a network far more restrictive than that described earlier in this chapter. This network does not allow any packet originating from the internal network to leave the building. The exceptions to this are proxied HTTP requests and e-mail routed through the corporate mail server.

What Is an HTTP Proxy?

An HTTP proxy is a special box that "mediates" outbound HTTP requests. It may be fairly transparent, or it may aggressively deny or modify HTTP requests and replies. Generally, a Web client is configured to go to a proxy instead of attempting direct network connections to servers. (More than likely if you are using a proxy you will find that no outbound traffic is allowed to traditional HTTP ports on addresses outside the local network.) This is done for the following reasons (of variable soundness).

Obscures Internal Network Details

Since all Web accesses will appear to originate from the proxy machine, no one on the outside can discover anything about the network behind the proxy by merely observing HTTP activity (mostly ”some information may still be gleaned from data within the HTTP request itself, unless the proxy filters or modifies it, and, yes, some do so).

Deflects Some Browser-Based Attacks

Some evil HTTP or HTML can trick some browsers into sending information or writing files and so forth. Some of these techniques are fooled merely by proxying. Still others may be blocked by filtering or header modification at the proxy.

Site Blocking

Most HTTP proxies allow the blocking of access to particular sites. If there are inappropriate sites being accessed from inside, the proxy administrator may block them.

Employee Watching

The proxy knows what sites were accessed, when, and by whom. This is a great way to pat your employees down without their knowledge. This is also perceived as a way to limit corporate liability should an employee attempt to access illegal or obscene sites that may result in an employee civil action. (Consult your attorney! I have been told that putting in a filter may increase liability. It establishes a pattern of company responsibility for Web access. If someone then brings up an unblocked obscene site and a suit results, it becomes reasonable to ask why the proxy administrator failed to block the site in question. These same people tell me that it is better to establish a "no tolerance" policy, to inform employees that their Internet use may be monitored , and then to leave the employees free to access any site. Then it is undoubtedly the one employee's fault when they access the inappropriate site. Remember, I am not a lawyer!)

Tunneling

Tunneling is carrying one protocol in another protocol. Modems are actually an example of this. Think about it. The phone network is a system designed to carry sound from one point to another point. A modem is a device that "tunnels" data in sound. In our case, we will be talking about carrying a standard application protocol (Telnet) "tunneled" through a completely different application protocol (HTTP).

The httptunnel Package

Introduction

The httptunnel package is, like SSH is in part, a port forwarding system. It lets you set up a "server" that looks to the Internet like an HTTP server. It lets you set up a client that to the Internet looks like a Web browser.

Server-Side Setup (HTS)

First, you must set up a server. This server looks like a Web server to anything that connects to it. It is, however, a server that expects data for some totally different protocol carried in HTTP requests.

Server setup is quite simple. Here's one I use to pierce an http-proxy-only firewall:

 # hts -F localhost:22

The HTS program listens on port 8888 by default. This is why I did not have to specify a listen port. The "-F" option lets me specify what I really want to contact when an httptunnel client connects to this server. In this case, I am connecting it to SSH. An httptunnel server can create a tunnel to exactly one port. That's why SSH is a very good choice. Even though you have only one port tunneled through the firewall, by using SSH you can pass any number of ports in or out that one port, as we've already described exhaustively. That's it for the server side.

The HTS program has many more options. Run hts ”help to see the complete list. Remember, we are introducing here. We want to leave you with some things to discover!

Client-Side Setup (HTC)

The client side can be quite a bit more complex. Here's what I use right now:

 $ htc -A schwarzm:d0ntsf0 -B 4k -c 2k -F 20022 -P 211.100.233.100:8080 alienmystery.planetmercury.net:8888

Now that looks complicated! Don't worry. It's not as bad as it seems. It would help if there were a configuration file you could specify. Instead you have to tell HTC everything on the command line every time.

So what's going on here? The "-A" argument specifies a user name and password for the proxy. If, when you open your browser, you are prompted for a username and password no matter what Web site you first try to visit, you probably need this. If you are not prompted, you probably don't need it. I did.

The "-B" option lets you specify a buffer size for the proxy. Some proxies require a minimum request size. I had to play around to find a value that would always work. Try your connection without this at first. If it doesn't work, set this to very large value (say 32k) and try again. If it works, great! If not, try the "-c" argument.

The "-c" argument specifies the " chunk size" of your HTTP requests. This is slightly different from the "-B" argument. This fixes the actual size of each request packet no matter how much data they carry. If you are doing a lot of typing through the tunnel, you probably want this fairly small. If you are doing a lot of file transfers, you prob ably want this fairly large! (Small is 1k to 5k. Large is probably anything 16k or greater.) The truth is, I have not dug in to figure out what precisely the -B and -c arguments do in the code. I tried values until I got something that works. You may have to do the same (or dig even deeper than I did! Remember, it is your source code!)

The "-F" argument specifies what port on the client side will be listened to for traffic to tunnel. I chose 20022. That means my .ssh/config contains an entry that looks like this:

  Host localhost

  Port 20022

The "-P" argument specifies the address and port of the HTTP proxy. I made this IP address up. It is not the real address of the proxy I pierced. You would substitute the address of your proxy.

Finally, you name the server side (the HTS HTTP tunnel server). When you hit Enter, the tunnel begins running in the background. You can now do this:

  mschwarz@mars:~ ssh localhost

  Enter passphrase for RSA key 'mschwarz@mars':

  You have new mail in /var/spool/mail/mschwarz.

  Last login: Fri Oct 13 01:47:39 2000 from localhost

  Have a lot of fun...

  alienmystery:~$

Now, you will probably find this to be a bit erratic and slow. Remember that each time you type a character, you perform the equivalent of a Web query and result! That's a lot of overhead. This is certainly not the optimal way to communicate, but it exists and it does work.

Tunnels within Tunnels: SSH over httptunnel

Remember, just as with any other situation where you use SSH, you can now add LocalForward and RemoteForward entries to your .ssh/config file to use the one HTTP tunnel to open any number of tunnels to any number of services. And because you chose to use SSH to do it, all of the traffic is cryptographically secure. Remember, httptunnel doesn't do any authentication or encryption itself. I highly recommend that if you must use it, you use it only to tunnel SSH.