2. Introduction

2.1 Foreword

This is document with 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 be completely cut from the outside world, with no ssh, no telnet, no web browsing, no email, 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. You can and you shall protect them from the outside world, but you can't protect them from themselves.

Because there exists such things as system administrators who are either unresponsive, absent, overworked, plain incompetent, 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 tiny small bit trickle 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 remote 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 setting up 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 remote site (or benefit from and existing daemon, sshd, telnetd, or sendmail/procmail).

It is assumed that you'll know 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.

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 and cotty 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/.
• icmptunnel can be found at http://www.detached.net/icmptunnel/.