[Next]  [Previous] [Contents]

----------------------------------------------------------------------------

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,
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 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, 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 telnet outside (which is a requisite 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.

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 you have shell accounts on both sides of the
firewall; that you can somehow telnet (or ssh, or equivalent) 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 IP connection emulated on
their side. 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

Most described software should be available from your standard distribution,
possibly among contrib's; at least all but the two small last ones are
available in as rpm packages. In case you want to fetch the latest sources
or binaries (after all, one of the ends of the connection 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 and cotty can be found at
     http://www.tunes.org/~fare/files/fwprc/.

----------------------------------------------------------------------------
[Next]  [Previous] [Contents]
