From e21abb8ae64f2535ff11414c85a157035c0bccfc Mon Sep 17 00:00:00 2001 From: gferg <> Date: Fri, 3 Nov 2000 14:59:28 +0000 Subject: [PATCH] new --- LDP/howto/linuxdoc/Firewall-Piercing.sgml | 626 ++++++++++++++++++++++ 1 file changed, 626 insertions(+) create mode 100644 LDP/howto/linuxdoc/Firewall-Piercing.sgml diff --git a/LDP/howto/linuxdoc/Firewall-Piercing.sgml b/LDP/howto/linuxdoc/Firewall-Piercing.sgml new file mode 100644 index 00000000..fd9ef756 --- /dev/null +++ b/LDP/howto/linuxdoc/Firewall-Piercing.sgml @@ -0,0 +1,626 @@ + + + +
+ +Firewall Piercing mini-HOWTO +François-René Rideau, fare@tunes.org +v0.6, 3 November 2000 + + +Directions for using ppp over ssh or telnet +so as to do network stuff transparently +through an Internet firewall. +Also applies to VPN construction. + + + + + +Stuff +

+ +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 term of connectivity +and to your access rights, with your recompiling some software if needed. + + + +Downloading software +

+Most named software should be available +from your standard Linux distribution, possibly among contrib's. +At least, the four first below are available in as rpm 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(1) 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(1) 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(8), +which itself will have been configured +to use procmail(1) for delivery. +Note that if you run fetchmail(1) 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, +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(1), suck(1), +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 Term-Firewall mini-HOWTO. + +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 a complex 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. + + + + + +