  Firewall Piercing mini-HOWTO
  Franois-Ren Rideau, rideau@ens.fr
  v0.1, 25 April 1998

  Directions for using ppp over telnet to do network stuff transparently
  through an Internet firewall.
  ______________________________________________________________________

  Table of Contents


  1. Stuff

     1.1 DISCLAIMER
     1.2 Legal Blurp
     1.3 Credits

  2. Introduction

     2.1 Foreword
     2.2 Security problems
     2.3 Other requirements
     2.4 Downloading software

  3. Understanding the problem

     3.1 Giving names to things
     3.2 The problem
     3.3 Additional difficulty

  4. Understanding the solution

     4.1 Opening two connections
     4.2 Synchronization

  5. Detailed instructions

     5.1 fwprc
     5.2 .fwprcrc

  6. Reverse piercing

     6.1 Rationale
     6.2 Getting the triggering mail

  7. Final note

     7.1 HOWTO maintenance
     7.2 Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!


  ______________________________________________________________________

  1.  Stuff



  1.1.  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 hackers 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.

  1.2.  Legal Blurp

  Copyright  1998 by Franois-Ren Rideau.  This document may be
  distributed only subject to the terms and conditions set forth in the
  LDP license at <http://sunsite.unc.edu/LDP/LICENSE.html>.



  1.3.  Credits

  Even though I rewrote most everything but the disclaimers, I'm
  indebted to Barak Pearlmutter  <mailto:bap@cs.unm.edu> for his Term-
  Firewall mini-HOWTO: I think there was a necessity for a mini-HOWTO
  about piercing firewalls, and despite its shortcomings, his HOWTO was
  a model and an encouragement.



  2.  Introduction



  2.1.  Foreword

  Because system administrators and users have different constraints and
  proficiencies, it so happens that a user may find himself behind a
  firewall.  This mini-HOWTO explains a generic and portable way to
  circumvent such firewalls by the use of an IP emulator over a telnet
  session.

  It is freely inspired by the Term-Firewall mini-HOWTO by Barak
  Pearlmutter  <mailto:bap@cs.unm.edu>, which relies on an ancient and
  no-more-supported program named Term (yet a great program at its
  time), as well as on peculiarities of a not-so-standard telnet
  implementation, that is, many obsolete and non-portable facts.



  2.2.  Security problems


  Of course, if your sysadm has setup a firewall, 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 telnet outside (which is a
  requisite for the presented hacks to work) means that you are allowed
  to access external systems, whereas the use of a user-level IP
  emulator such as SLiRP should still prevent external systems 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).

  Hence, this 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.  Moreover, 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.

  All in all, 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 you have shell accounts on both
  sides of the firewall; that you can somehow telnet from one account to
  the other; that you can run an IP emulator on both shell accounts;
  that you have programs able to use the emulated IP connection.  Note
  that any program can use the connection, in case the local emulator is
  pppd talking to the linux kernel; other emulators, like term, need
  recompilation and linking to a special library.

  Talking about IP emulators, pppd can be found in any good linux
  distribution or ftp site; so can slirp.  If your remote shell account
  is user-level only, you can use SLiRP to connect.



  2.4.  Downloading software


  All described software should be available from your standard
  distribution, possibly among contrib's; at least they're all available
  in as rpm packages.  In case you want to fetch the latest sources or
  binaries (after all, one of the ends may not be running 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.peak.org/zsh/>.

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

    FWPRC can be found at <http://www.tunes.org/~fare/files/>.



  3.  Understanding the problem



  3.1.  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.



  3.2.  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 the "current tty" is also the
  channel from which the emulators are initially launched at the command
  prompt, so that we can't "directly" connect I/Os until both emulators
  are launched or ready to be launched, least we're going to execute one
  session's garbage output as commands on the other one, which would
  recursively produce more garbage.


  3.3.  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 thru the current tty; it must
  be a tty, not a pair of pipe.  This is fine for the remote pppd if
  any, as it can use the telnet session's tty; but for the local pppd,
  it sucks, as it can't launch the telnet session to connect to; hence,
  there must some kind of wrapper around it.  [Note: if I find the
  sucker 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!]



  4.  Understanding the solution


  4.1.  Opening two connections

  The most obvious way of building a wrapper is to launch a telnet
  session in the ``background'', to which the pppd would connect.  But
  how can you do it so the telnet session be controlled by a tty in
  which the pppd also runs, with crossed output and input?  The solution
  is to use the zsh coproc feature, with which you can have a concurrent
  processe whose input and output you can control with a pair of pipes.
  However, because pppd insists on having a tty, not a pair of pipes, we
  need a tty emulator for pppd, too.

  The very same solution applies again, which is also the only portable
  one, that is, is telnet as a tty emulator.  So we'll open a local
  telnet connection as a zsh coproc, in which we'll run the pppd.p We
  then launch a remote telnet connection as the "normal" zsh
  computation, with I/O crossed with the local connection, so that they
  talk to each other.  But before we can connect the crossed I/O pipes,
  we must make sure both sessions are synchronized to the same PPP
  emulation state, rather than waiting for shell commands.


  4.2.  Synchronization

  First, the mother process launches the local connection, starts a
  fwprc with local options, and waits for the local fwprca to send
  cookie.  Then it launches the remote connection, starts a fwprc with
  remote options, and connects I/O.  The local connection will wait for
  the remote connection to send its cookie.  When both cookies are
  received, the handshake is achieved, and IP emulators are run on both
  sides.

  Synchronization is achieved by exchanging obfuscated cookies whose
  probability of appearing unexpectedly are close to nothing.  During a
  synchronization step, the waiting side flushes the output of the other
  side until it finds the expected cookie.






  5.  Detailed instructions


  5.1.  fwprc

  I wrote a very well self-documented script to pierce firewalls, fwprc
  0.1, available from my site  <http://www.tunes.org/~fare/files/>.  I
  tested it in several settings, by configuring it through resource
  files.  But of course, by Murphy's law, it will break for you.

  The name 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).  If you must read it aloud, choose the worst way you
  can imagine.

  CONTEST! CONTEST! Send me an audio file with a digital audio recording
  of how you pronounce "fwprc".  Worst entry will win a free upgrade and
  his name on the fwprc 0.2 page!



  5.2.  .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 }




  6.  Reverse piercing



  6.1.  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 mail; all you need is add fwprc as a procmail filter to
  messages using the protocol.  Note however, that if you are to launch
  pppd with appropriate priviledges, you might need create your own suid
  wrapper to become root.  Instructions enclosed.


  6.2.  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 external telnet.  No
  problem! You can use fetchmail to get mail to your client linux
  system, and add a cron-job to automatically poll for mail every 1-5
  minutes, which will forward mail to a local address through sendmail,
  which itself will have been configured to use procmail for delivery.
  Too frequent a poll won't be nice to either the server or your host.
  Too unfrequent 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.


  7.  Final note


  7.1.  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.  So will it stay, until I
  get enough feedback so as to know what sections to enhance.  Feedback
  welcome. Help welcome. mini-HOWTO maintenance take-over welcome.

  Most notably among things TODO, explain how to use SLIP instead of PPP
  on 7-bit lines, if needed (I never tried, because lines are more or
  less 8-bit clean these days).


  7.2.  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 hackers 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.































