DISCLAIMER

READ THIS IMPORTANT SECTION !!!

I hereby disclaim all responsibility for this hack. If it backfires on you in any way whatsoever, that's the breaks. Not my fault. If you don't understand the risks inherent in doing this, don't do it. If you use this hack and it allows vicious vandals to break into your company's computers and costs you your job and your company millions of dollars, well that's just tough nuggies. Don't come crying to me. Legal Blurp

Copyright © 1998-2000 by François-René Rideau. This document is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Looking for a maintainer

I haven't been actively developing this mini-HOWTO recently; in particular, the french version is lagging behind. I'm looking for a maintainer to take over this document, and maybe develop software to make it easier to pierce firewalls. It has been considered to merge this document into the NASG, but that wasn't done. I also have a lot of ideas for active maintainers to expand this HOWTO, if anyone is interested. Credits

Even though I rewrote most everything but the disclaimers, I'm indebted to for his Term-Firewall mini-HOWTO: I think there was a necessity for a mini-HOWTO about piercing firewalls, and despite its shortcomings, his mini-HOWTO was a model and an encouragement. I'd also like to thank and for their fine http, mail and icmp tunnels. Introduction

Foreword

Because system administrators and users have different constraints and proficiencies, 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 use standard Internet tools seamlessly across such firewalls, by the use of an IP emulator through a tunnel achieved by a telnet, http, or mail connection. It is freely inspired by the Term-Firewall mini-HOWTO by , which relies on an ancient and no-more-supported program named Term (a great program at its time, and still useful in some unhappy circumstances), as well as on peculiarities of a not-so-standard telnet implementation, that is, many obsolete and non-portable facts. Security problems

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. 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. 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 and/or . zsh can be found at . ppp can be found at . ssh can be found at . fwprc and cotty can be found at . httptunnel can be found at . mailtunnel can be found at . icmptunnel can be found at . Understanding the problem

Understanding a problem is the first half of the path to solving it. Giving names to things

If you want this hack to work for you, you'll have to get an idea of how it works, so that in case anything breaks, you know where to look for. The first step toward understanding the problem is to give a name to relevant concepts. So we'll herein call "local" the machine that initiates the connection, as well as programs and files on that machine; conversely, we'll call "remote" what's on the other side of the connection. The problem

The goal is to connect the input and output of a local IP emulator to the output and input respectively of a remote IP emulator. Only the communication channels with which IP emulators interact are either direct devices (in the usual case of pppd), or the "current tty". The previous case obviously does not happen with telnet sessions. The latter is tricky, because when you launch the local emulator from the command line, the "current tty" is linked to the command-line user, not to a remote session; also, should we open a new session (local or remote) on a new terminal, we must synchronize the launching and connection of IP emulators on both sides, least one session's garbage output is going to be executed as commands on the other session, which would recursively produce more garbage. Additional difficulty

To get the best ease of use, the local IP emulator has to provide IP to kernel networking, hence be pppd. However, pppd is dumb enough to only accept having data through /dev or through the current tty; it must be a tty, not a pair of pipe (which would be the obvious design). This is fine for the remote pppd if any, as it can use the telnet session's tty; but for the local pppd, this sucks, as it can't launch the telnet session to connect to; hence, there must some kind of wrapper around it. Telnet behaves almost correctly with a pair of pipe, except that it will still insist on doing ioctl's to the current tty, with which it will interfere; using telnet without a tty also causes race conditions, so that the whole connection will fail on "slow" computers (fwprc 0.1 worked perfectly on a P/MMX 233, one time out of 6 on a 6x86-P200+, and never on a 486dx2/66). [Note: if I find the sucker (probably a MULTICS guy, though there must have been UNIX people stupid enough to copy the idea) who invented the principle of "tty" devices by which you read and write from a "same" pseudo-file, instead of having clean pairs of pipes, I strangle him!] Secure solution: piercing using ssh

Principle

Let's assume that your site administrator allows transparent TCP connections to some port, (be it the standard SSH port 22, or an alternate destination port, like the HTTP port 80 or whatever), or that you somehow managed to get some port in one side of the firewall to get redirected to a port on the other side (using httptunnel or mailtunnel or whatever). Then, you can run an sshd on the remote port, and connect to it with an ssh on the local port. On both sides of the ssh connection, you run IP emulators (pppd), and there you have your VPN, Virtual Public Network, that circumvents the stupid firewall limitations.

The exact same technology can be used to build a VPN, Virtual Private Network, whereby you securely join physical sites into a one logical network without sacrificing security with respect to the transport network between the sites.

A sample session

REMOTE_ACCOUNT=root@remote.fqdn.tld REMOTE_PPPD="pppd ipcp-accept-local ipcp-accept-remote" LOCAL_PPPD="pppd silent 192.168.0.1:192.168.0.2" cotty -d -- $LOCAL_PPPD -- ssh -t $REMOTE_ACCOUNT $REMOTE_PPPD This command requires cotty 0.4 or later. Be sure to edit this into a script with the right values. Use option -p for ssh to try another port than port 22 (but then, be sure to run sshd on same port). You can use slirp on the remote end, if you are not root there, or simply want to screen your local network from outbound connections. Automatic reconnection is left as an exercise to the reader. Unsecure solution: piercing using telnet

Principle

If all you can do is telnet (because of a telnet proxy), then this solution might be fit for you. The firewall-piercing program, fwprc, will use a "tty proxy", cotty, that opens two pseudo-tty devices, launches some command on each of those devices' slaves, and stubbornly copies every character that one outputs to the tty that serves as input of the other command. One command will be telnet connection to remote site, and the other will be the local pppd. pppd can then open and control the telnet session with a chat script as usual. Actually, if your telnet proxy allows connection to an arbitrary port, and you can reliably run a daemon on the remote host (with a cron job to relaunch it in case of breakage), then you'd better write some program that will just connect a local port to the remote one through the proxy, so you can use the above secure solution, possibly using some variant of ssh -t -o "ProxyCommand ..." (if you submit it to me, I'll integrate it to the fwprc distribution). fwprc

I wrote a very well self-documented script to pierce firewalls, fwprc, available from , together with cotty (which is required by fwprc 0.2 and later). At the time of my writing these lines, latest versions are fwprc 0.3e and cotty 0.4. The name "fwprc" is voluntarily made unreadable and unpronounceable, so that it will confuse the incompetent paranoid sysadm who might be the cause of the firewall that annoys you (of course, there can be legitimate firewalls, too, and even indispensable ones; security is all a matter of correct configuration). If you must read it aloud, choose the worst way you can imagine. CONTEST! CONTEST! Send me a .au audio file with a digital audio recording of how you pronounce "fwprc". The worst entry will win a free upgrade and his name on the fwprc 1.0 page! I tested the program in several settings, by configuring it through resource files. But of course, by Murphy's law, it will break for you. Feel free to contribute enhancements that will make life easier to other people who'll configure it after you. .fwprcrc

fwprc can be customized through a file .fwprcrc meant to be the same on both sides of the firewall. Having several alternate configurations to choose from is sure possible (for instance, I do it), and is left as an exercise to the reader.

To begin with, copy the appropriate section of fwprc (the previous to last) into a file named .fwprcrc in your home directory. Then replace variable values with stuff that fits your configuration. Finally, copy to the other host, and test.

Default behavior is to use pppd locally, and slirp remotely. To modify that, you can redefine the appropriate function in your .fwprcrc with such a line as: remote_IP_emu () { remote_pppd }

Note that SLiRP is safer than pppd, and easier to have access to, since it does not require being root on the remote machine. Another safe feature is that it will drop packets not directly coming from the connected machine (which feature becomes a misfeature if you attempt to route a subnetwork onto it with masquerading). The basic functionality in SLiRP works quite well, but I've found advertised pluses (like run-time controllability) to be deficient; of course, since it is free software, feel free to hack the source so as to actually implement whichever feature you need. Reverse piercing

Rationale

Sometimes, only one side of the firewall can launch telnet sessions into the other side; however, some means of communication is possible (typically, through e-mail). Piercing the firewall is still possible, by triggering with whatever messaging capability is available a telnet connection from the ``right'' side of the firewall to the other. fwprc includes code to trigger such connections from a PGP-authentified e-mail message; all you need is add fwprc as a procmail filter to messages using the protocol, (instructions included in fwprc itself). Note however, that if you are to launch pppd with appropriate privileges, you might need create your own suid wrapper to become root. Instructions enclosed in fwprc. Also, authentified trigger does not remotely mean secure connection. You should really use ssh (perhaps over telnet) for secure connections. And then, beware of what happens between the triggering of a telnet connection, and ssh taking over that connection. Contribution in that direction welcome. Getting the triggering mail

If you are firewalled, your mail may as well be in a central server that doesn't do procmail filtering or allow telnet sessions. No problem! You can use fetchmail to run in daemon mode to poll and get mail to your client linux system, and/or add a cron job to automatically poll for mail every 1-5 minutes. fetchmail will forward mail to a local address through sendmail, which itself will have been configured to use procmail for delivery. Note that if you run fetchmail as a background daemon, it will lock away any other fetchmail that you'd like to run only at other times, like when you open a fwprc; of course, if you can also run a fetchmail daemon as a fake user. Too frequent a poll won't be nice to either the server or your host. Too infrequent a poll means you'll have to wait before the message gets read and the reverse connection gets established. I use two-minute poll frequency. Final notes

Other settings

There are other kinds of firewalls than those that allow for direct ssh or telnet connections. As long as a continuous flow of packets may transmit information through a firewall in both directions, it is possible to pierce it; only the price of writing the piercer may be higher or lower. In a very easy case, we saw that you can just launch ssh over a pty master and do some pppd in the slave tty. You may even want to do it without an adverse firewall, just so as to build a secure ``VPN'' (Virtual Private Network). The gives all the details you need about this. We invite you, as an exercise, to modify fwprc so as to use this technique, or perhaps even so as to use it inside a previous non-secure fwprc session. Now, if the only way through the firewall is a WWW proxy (usually, a minimum for an Internet-connected network), you might want to use 's , a http daemon and client combination that achieves a TCP/IP tunnel connection through the proxy-friendly HTTP protocol. You should then be able to run fwprc (preferably over ssh) over that connection, although I haven't tried it yet. Could anyone test and report? Note that httptunnel is still under development, so you may help implement the features it currently lacks, like, having multiple connections, and/or serving fake pages so as to mislead suspicious adverse firewall administrators. Whatever goes through your firewall, be it telnet, HTTP or other TCP/IP connections, or something real weird like DNS queries, ICMP packets, e-mail (see , ), or whatelse, you can always write a tunnel client/daemon combination, and run a ssh and/or PPP connection through it. The performance mightn't be high, depending on the effective information communication rate after paying the overhead for coding around filters and proxies; but such a tunnel is still interesting as long as it's good enough to use fetchmail, suck, and other non-interactive programs. If you need cross a 7-bit line, you'll want to use SLIP instead of PPP. I never tried, because lines are more or less 8-bit clean these days, but it shouldn't be difficult. If necessary, fall back to using the . If you have an 8-bit clean connection and you're root on linux both sides of the firewall, you might want to use ethertap for better performance, encapsulating raw ethernet communications on top of your connection. David Madore has written ethertap-over-TCP and ethertap-over-UDP tunneling . There remains to write some ethertap-over-tty to combine with fwprc-like tools. If you really need more performance than you can get while paying for a user-space sequential communication tunnel through which to run PPP, then you're in the very hard case where you might have to re-hack a weird IP stack, using (for instance) the Fox project's packet-protocol functors. You'll then achieve some direct IP-over-HTTP, IP-over-DNS, IP-over-ICMP, or such, which requires not only an elaborate protocol, but also an interface to an OS kernel, both of which are costly to implement. HOWTO maintenance

I felt it was necessary to write it, but I don't have that much time for that, so this mini-HOWTO is very rough. Thus will it stay, until I get enough feedback so as to know what sections to enhance, or better, until someone comes and takes over maintenance for the mini-HOWTO. Feedback welcome. Help welcome. mini-HOWTO maintenance take-over welcome. In any case, the above sections have shown many problems whose solution is just a matter of someone (you?) spending some time (or money, by hiring someone else) to sit down and write it: nothing conceptually complicated, though the details might be burdensome or tricky. Do not hesitate to contribute more problems, and hopefully more solutions, to this mini-HOWTO. For instance, there is some need for a section on setting up routes correctly with fwprc, including example use of getroute.pl from /etc/ppp/ip-up. Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!

I hereby disclaim all responsibility for this hack. If it backfires on you in any way whatsoever, that's the breaks. Not my fault. If you don't understand the risks inherent in doing this, don't do it. If you use this hack and it allows vicious vandals to break into your company's computers and costs you your job and your company millions of dollars, well that's just tough nuggies. Don't come crying to me.