2. Introduction

2.1. Foreword

This document has a moral. And the moral is: a firewall cannot protect a network against its own internal users, and should not even try to.

When an internal user asks you system administrator to open an outbound port to an external machine, or an inbound port to an internal machine, then you should do it for him. Of course you should help the user to make sure that his transactions are secure, and that his software is robust. But a flat out denial of service is plain incompetence. For unless he is so firewalled as to be completely cut from the outside world, with no ssh, no telnet, no web browsing, no email, no dns, no ping, no phone line, no radio, no nothing, then the user can and will use firewall piercing techniques to access the machines he wants nonetheless, and the net result for security will be an unaudited connection with the outside world. So either you trust your users, after proper training and selection, or you shouldn't grant them access to the network at all - but then again, the role of a network administrator is usually to serve its users, so your goal should be the former rather than the latter. You can and you shall protect them from the outside world; you can and you shall protect your critical services from them; but you can't and you shall not protect them from themselves.

Because there exists such things as system administrators who are either unresponsive, absent, overworked, plain incompetent, irresponsible, or more generally managed by incompetent people, it so happens that a user may find himself behind a firewall that he may cross, but only in awkward ways. This mini-HOWTO explains a generic and portable way to pierce tunnels into firewalls, by turning any thin, tiny trickle of bits into a full-fledged information superhighway, so the user can seamlessly use standard tools to access computers on the other side of the firewall. The very same technique can be used by competent system administrators to build virtual private networks (VPN).

2.2. Security issues

Of course, if your sysadm has setup a firewall s/he might have a good reason, and you may have signed an agreement to not circumvent it. On the other hand, the fact that you can use telnet, the web, e-mail, or whatever other bidirectional information flux with the outside of the firewall (which is a prerequisite for the presented hacks to work) means that you are allowed to access external systems, and the fact that you can log into a particular external system somehow means you're allowed to do it, too.

So this is all a matter of conveniently using legal holes in a firewall, and allow generic programs to work from there with generic protocols, as opposed to requiring special or modified (and recompiled) programs going through lots of special-purpose proxies that be misconfigured by an uncaring or incompetent sysadm, or to installing lots of special-purpose converters to access each of your usual services (like e-mail) through ways supported by the firewall (like the web).

Moreover, the use of a user-level IP emulator such as SLiRP should still prevent external attackers from piercing the firewall back in the other way, unless explicitly permitted by you (or they are clever and wicked, and root or otherwise able to spy you on the server host).

All in all, the presented hack should be relatively safe. However, it all depends on the particular circumstances in which you set things up, and I can give no guarantee about this hack. Lots of things are intrinsically unsafe about any Internet connection, be it with this hack or not, so don't you assume anything is safe unless you have good reasons, and/or use some kind of encryption all the way.

Let's repeat the basics of networking security: you cannot trust anything about a connection more than you trust the hosts that can handle the unencrypted data, including hosts on both ends of the connection, and all hosts that can intercept the communication, unless the communication is properly encrypted with secret keys. If you misplace your trust, your passwords may be stolen and used against you, your credit card number may be stolen and used against you, and you may be fired from your work for endangering the whole company. Tough nuggies.

To sum it up, don't use this hack unless you know what you're doing. Re-read the disclaimer above.

2.3. Other requirements

It is assumed that you know what you're doing, that you know about configuring a network connection, that in case of doubt, you will have read all relevant documentation (HOWTOs, manual pages, web pages, mailing-list archives, RFCs, courses, tutorials).

It is assumed that you have shell accounts on both sides of the firewall, that you can somehow transmit packets of information both ways across the firewall (with telnet, ssh, e-mail, and the web being the ways currently known to work), and that you can let a daemon run as a background task on the server site (or benefit from and existing daemon, sshd, telnetd, or sendmail/procmail).

It is assumed that you know or are willing to learn how to configure an IP emulator (pppd, slirp) or an Internet access daemon and its associated library (SOCKS, Term) on each side, according to your needs in terms of connectivity and to your access rights, with your recompiling some software if needed.

Last but not least, so that you can use the hacks described in this document, it is assumed that you are root on the side of the firewall that needs full transparent IP access to the other side. Indeed, you'll want to run the PPP daemon on this side which allows for use the normal kernel packet routing facilities. In case you're not root on this side, your case is not desperate though: indeed, Barak Pearlmutter's Term-Firewall mini-HOWTO describes how to use Term, a purely userland program, to the end of piercing firewalls. Although there's no HOWTO, I suspect SOCKS could also be used as a way to pierce firewalls without have root privilege; I will gladly accept patches to this HOWTO that describe such a method of piercing firewalls.

2.4. Downloading software

Most software named in this HOWTO should be available from your standard Linux distribution, possibly among contrib's. At least, the four first below are available in as .rpm and .deb packages. In case you want to fetch the latest sources (after all, one of the ends of the connection may not be running under Linux), use the addresses below:

• SLiRP can be found at http://blitzen.canberra.edu.au/slirp and/or ftp://www.ibc.wustl.edu/pub/slirp_bin/.

• zsh can be found at http://www.zsh.org/.

• ppp can be found at ftp://cs.anu.edu.au/pub/software/ppp/.

• ssh can be found at http://www.openssh.com/.

• fwprc, cotty and getroute.pl can be found at http://fare.tunes.org/files/fwprc/.

• httptunnel can be found at http://www.nocrew.org/software/httptunnel/.

• mailtunnel can be found at http://www.detached.net/mailtunnel/.