2000-11-03 14:59:28 +00:00
|
|
|
|
<!doctype linuxdoc system>
|
|
|
|
|
<!-- $Id$ -->
|
|
|
|
|
<!-- 1.3 corresponds loosely to Firewall-Piercing.fr.sgml 1.3 -->
|
|
|
|
|
<article>
|
|
|
|
|
|
|
|
|
|
<title>Firewall Piercing mini-HOWTO</title>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
<author>Fran<61>ois-Ren<65> Rideau, <tt>fare+fwprc@tunes.org</tt></author>
|
|
|
|
|
<date>v0.96, 23 November 2001</date>
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
|
|
|
|
<abstract>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Directions for using ppp over ssh, telnet or whatever,
|
|
|
|
|
so as to do achieve transparent network connection accross a firewall.
|
|
|
|
|
Applies to friendly VPN construction
|
|
|
|
|
as well as to piercing unfriendly firewalls.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</abstract>
|
|
|
|
|
|
|
|
|
|
<toc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect>Stuff
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
<sect1>DISCLAIMER
|
|
|
|
|
<p>
|
|
|
|
|
<bf>READ THIS IMPORTANT SECTION !!!</bf>
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
<bf>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
I hereby disclaim all responsibility for <em>your</em> use of this hack.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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.
|
|
|
|
|
</bf>
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>Legal Blurp
|
|
|
|
|
<p>
|
2001-07-13 13:53:25 +00:00
|
|
|
|
Copyright © 1998-2001 by Fran<61>ois-Ren<65> Rideau.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2001-07-13 13:53:25 +00:00
|
|
|
|
This document is free software published under the
|
|
|
|
|
<url url="http://www.geocities.com/SoHo/Cafe/5947/bugroff.html"
|
|
|
|
|
name="bugroff license">.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
To ease their task, it has also been released to the LDP maintainers
|
|
|
|
|
under the
|
|
|
|
|
<url url="http://www.gnu.org/copyleft/fdl.html"
|
|
|
|
|
name="GNU Free Documentation License">.
|
|
|
|
|
</p>
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>Looking for a maintainer
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
I also have a lot of ideas for active maintainers
|
2000-11-03 14:59:28 +00:00
|
|
|
|
to expand this HOWTO, if anyone is interested.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
<sect1>Remarks on the english version
|
|
|
|
|
<p>
|
|
|
|
|
The english version of this document is written by the author
|
|
|
|
|
together with the french version.
|
|
|
|
|
Neither version is truly the translation of the other,
|
|
|
|
|
though each is somehow partly translated from the other.
|
|
|
|
|
Both are the ``original version''.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
NOT TRUE ANYMORE. I'VE ABANDONNED MAINTENANCE OF THE FRENCH VERSION.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
<sect1>Credits
|
|
|
|
|
<p>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
Even though the only thing left is the disclaimers,
|
|
|
|
|
this document owes a lot to the
|
|
|
|
|
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html"
|
|
|
|
|
name="Term-Firewall mini-HOWTO">
|
|
|
|
|
by <URL URL="mailto:bap@cs.unm.edu" name="Barak Pearlmutter">.
|
|
|
|
|
Barak's mini-HOWTO relies on
|
|
|
|
|
an ancient and no-more-supported program named Term
|
|
|
|
|
(a great program in its time,
|
|
|
|
|
and maybe 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.
|
|
|
|
|
Nevertheless, there was a necessity for a mini-HOWTO about piercing firewalls,
|
2001-07-13 13:53:25 +00:00
|
|
|
|
and despite the limitations of its hacks,
|
|
|
|
|
this mini-HOWTO was a model and an encouragement.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
I'd also like to congratulate
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<URL URL="mailto:lars@nocrew.org" name="Lars Brinkhoff">
|
|
|
|
|
<!-- URL
|
|
|
|
|
URL="mailto:ajje@wombat.ludvika.se" name="Andreas 'Ajje' Pettersson"-->
|
|
|
|
|
and
|
|
|
|
|
<URL URL="mailto:logic@gore.nocrew.org" name="Magnus Lundstr<74>m">
|
|
|
|
|
for their fine http, mail and icmp tunnels.
|
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect>Introduction
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
<sect1>Foreword
|
|
|
|
|
<p>
|
2001-07-16 15:48:50 +00:00
|
|
|
|
This document has a moral. And the moral is:
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<bf>a firewall cannot protect a network against its own internal users,
|
|
|
|
|
and should not even try to.</bf>
|
|
|
|
|
|
|
|
|
|
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.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
For unless he is so firewalled as to be completely cut from the outside world,
|
|
|
|
|
with no ssh, no telnet, no web browsing, no email, no dns, no ping,
|
|
|
|
|
no phone line, no radio, no nothing,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
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,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
or you shouldn't grant them access to the network at all - but then again,
|
|
|
|
|
the role of a network administrator is usually to serve its users,
|
|
|
|
|
so your goal should be the former rather than the latter.
|
|
|
|
|
You can and you shall protect them from the outside world;
|
|
|
|
|
you can and you shall protect your critical services from them;
|
|
|
|
|
but you can't and you shall not protect them from themselves.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
|
|
|
|
|
Because there exists such things as system administrators
|
2001-07-13 13:53:25 +00:00
|
|
|
|
who are either unresponsive, absent, overworked, plain incompetent,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
irresponsible, or more generally managed by incompetent people,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
it so happens that a user may find himself behind a firewall
|
2000-11-03 14:59:28 +00:00
|
|
|
|
that he may cross, but only in awkward ways.
|
|
|
|
|
This mini-HOWTO explains a generic and portable way
|
2000-11-05 17:56:43 +00:00
|
|
|
|
to pierce tunnels into firewalls,
|
2001-07-13 13:53:25 +00:00
|
|
|
|
by turning any thin, tiny trickle of bits
|
|
|
|
|
into a full-fledged information superhighway,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
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).
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<sect1>Security issues
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<p>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
Of course, if your sysadm has setup a firewall
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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 <em>conveniently</em>
|
|
|
|
|
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 <em>relatively</em> 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:
|
|
|
|
|
<em>you cannot trust anything about a connection
|
|
|
|
|
more than you trust the hosts that can handle the unencrypted data</em>,
|
|
|
|
|
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.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>Other requirements
|
|
|
|
|
<p>
|
|
|
|
|
It is assumed that you know what you're doing,
|
2001-07-13 13:53:25 +00:00
|
|
|
|
that you know about configuring a network connection,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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).
|
|
|
|
|
|
2001-07-13 13:53:25 +00:00
|
|
|
|
It is assumed that you know or are willing to learn
|
|
|
|
|
how to configure an IP emulator (pppd, slirp)
|
2000-11-03 14:59:28 +00:00
|
|
|
|
or an Internet access daemon and its associated library (SOCKS, Term)
|
2000-11-03 18:43:18 +00:00
|
|
|
|
on each side, according to your needs in terms of connectivity
|
2000-11-03 14:59:28 +00:00
|
|
|
|
and to your access rights, with your recompiling some software if needed.
|
2001-07-13 13:53:25 +00:00
|
|
|
|
|
|
|
|
|
Last but not least, so that you can use the hacks described in this document,
|
|
|
|
|
it is assumed that you are root on the side of the firewall
|
|
|
|
|
that needs full transparent IP access to the other side.
|
|
|
|
|
Indeed, you'll want to run the PPP daemon on this side which
|
|
|
|
|
allows for use the normal kernel packet routing facilities.
|
|
|
|
|
In case you're not root on this side, your case is not desperate though:
|
|
|
|
|
indeed, Barak Pearlmutter's
|
|
|
|
|
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html"
|
|
|
|
|
name="Term-Firewall mini-HOWTO">
|
|
|
|
|
describes how to use <tt>Term</tt>, a purely userland program,
|
|
|
|
|
to the end of piercing firewalls.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
Although there's no HOWTO, I suspect SOCKS could also be used
|
2001-11-24 16:24:03 +00:00
|
|
|
|
as a way to pierce firewalls without have root privilege;
|
|
|
|
|
I will gladly accept patches to this HOWTO that describe
|
|
|
|
|
such a method of piercing firewalls.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
<sect1>Downloading software
|
|
|
|
|
<p>
|
2000-11-03 18:43:18 +00:00
|
|
|
|
Most software named in this HOWTO should be available
|
2000-11-03 14:59:28 +00:00
|
|
|
|
from your standard Linux distribution, possibly among contrib's.
|
2000-11-03 18:43:18 +00:00
|
|
|
|
At least, the four first below are available in
|
|
|
|
|
as <tt>.rpm</tt> and <tt>.deb</tt> packages.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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:
|
|
|
|
|
<itemize>
|
|
|
|
|
<item><tt>SLiRP</tt> can be found at
|
|
|
|
|
<URL URL="http://blitzen.canberra.edu.au/slirp"> and/or
|
|
|
|
|
<URL URL="ftp://www.ibc.wustl.edu/pub/slirp_bin/">.
|
|
|
|
|
<item><tt>zsh</tt> can be found at
|
2000-11-03 18:43:18 +00:00
|
|
|
|
<URL URL="http://www.zsh.org/">.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<item><tt>ppp</tt> can be found at
|
|
|
|
|
<URL URL="ftp://cs.anu.edu.au/pub/software/ppp/">.
|
|
|
|
|
<item><tt>ssh</tt> can be found at
|
|
|
|
|
<URL URL="http://www.openssh.com/">.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
<item><tt>fwprc</tt>, <tt>cotty</tt> and <tt>getroute.pl</tt>
|
|
|
|
|
can be found at
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<URL URL="http://fare.tunes.org/files/fwprc/">.
|
|
|
|
|
<item><tt>httptunnel</tt> can be found at
|
2000-11-03 18:43:18 +00:00
|
|
|
|
<URL URL="http://www.nocrew.org/software/httptunnel/">.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<item><tt>mailtunnel</tt> can be found at
|
|
|
|
|
<URL URL="http://www.detached.net/mailtunnel/">.
|
|
|
|
|
</itemize>
|
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect>Understanding the problem
|
|
|
|
|
<p>
|
|
|
|
|
Understanding a problem is the first half of the path to solving it.
|
|
|
|
|
|
|
|
|
|
<sect1>Giving names to things
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
As usual, we'll herein call "client" the machine
|
2000-11-05 17:56:43 +00:00
|
|
|
|
that decides to initiate the connection,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
as well as programs and files on that machine.
|
|
|
|
|
Conversely, we'll call "server" that waits for connections and accepts them,
|
|
|
|
|
as well as programs and files on that machine.
|
|
|
|
|
Firewall piercing is useful when the two machines are separated by a firewall,
|
|
|
|
|
such that it is possible for the server to accept some kind of connections,
|
|
|
|
|
whereas the client might or might not be able to accept any.
|
|
|
|
|
A tunnel will be created between the two machines
|
|
|
|
|
that allows full IP traffic despite the firewall.
|
|
|
|
|
|
|
|
|
|
Usually, when piercing firewalls, the client is the machine behind a firewall:
|
|
|
|
|
it has limited access to the internet,
|
|
|
|
|
but can somehow open some kind of connection to the server.
|
|
|
|
|
The server is a machine with full internet access,
|
|
|
|
|
that will serve as a proxy for the client to access all of the internet.
|
|
|
|
|
In a VPN, the firewall the roles might be reversed,
|
|
|
|
|
with the client being on the internet, and
|
|
|
|
|
the server serving as a proxy for the client to access some private network.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<sect1>The main problem
|
|
|
|
|
<p>
|
|
|
|
|
The main problem with firewall piercing is to create a tunnel:
|
2001-11-24 16:24:03 +00:00
|
|
|
|
a continuous connection from the client machine
|
|
|
|
|
to a server machine on the other side of the firewall,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
that allows for bidirectional exchange of information.
|
|
|
|
|
Optionally, this connection should be a secure one.
|
|
|
|
|
The secondary problem is to transform this connection
|
|
|
|
|
into a full IP access for normal programs to use transparently.
|
|
|
|
|
|
|
|
|
|
For the main problem, we'll assume that
|
|
|
|
|
either (1) you can establish normal TCP/IP connections
|
2001-11-24 16:24:03 +00:00
|
|
|
|
from the client side of the firewall to some port on a server machine
|
2000-11-05 17:56:43 +00:00
|
|
|
|
where a sshd runs or can be set to run, or
|
|
|
|
|
(2) you can somehow establish a telnet connection through a telnet proxy.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
In case you cannot, we will give you pointers
|
|
|
|
|
to other software that allows you
|
2000-11-05 17:56:43 +00:00
|
|
|
|
to pierce a tunnel accross a firewall.
|
|
|
|
|
Although we only give a secure solution in the first case,
|
|
|
|
|
you can hack your own secure solution in the other cases,
|
|
|
|
|
if you understand the principle
|
|
|
|
|
(if you don't, someone, e.g. I, can do it for you in exchange for money).
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<sect1>The secondary problem
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<p>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
For the secondary problem,
|
|
|
|
|
IP emulators (<tt>pppd</tt> or <tt>SLiRP</tt>)
|
|
|
|
|
are run on each side of the tunnel.
|
|
|
|
|
|
|
|
|
|
On the side that wants full IP access to the other side,
|
|
|
|
|
you'll want to run <tt>pppd</tt>.
|
|
|
|
|
On the other side, you want to run <tt>pppd</tt>
|
|
|
|
|
if you also want full IP access to the first side,
|
|
|
|
|
or <tt>SLiRP</tt> if you want to prevent any access.
|
|
|
|
|
Go to your usual pppd or SLiRP documentation for more information,
|
|
|
|
|
if you have specific needs not covered by the examples given below.
|
|
|
|
|
|
|
|
|
|
Although this is conceptually trivial,
|
|
|
|
|
it nonetheless requires a few silly tricks, so as to work, since
|
|
|
|
|
(a) in case you're using some kind of programmed interactive shell session
|
|
|
|
|
to start the remote IP emulator on either side, you need to correctly
|
|
|
|
|
synchronize the start of the IP emulator on the other side,
|
|
|
|
|
so as not to send garbage into the shell session,
|
|
|
|
|
and
|
|
|
|
|
(b) IP emulators are designed to be run on a "tty" interface
|
|
|
|
|
so you have to convert your tunnel's interface into a tty one.
|
|
|
|
|
|
|
|
|
|
Issue (a) is just your usual synchronization problem,
|
|
|
|
|
and doesn't even exist if you use <tt>ssh</tt>,
|
|
|
|
|
that transparently handles remote command launching.
|
|
|
|
|
|
|
|
|
|
Issue (b) requires the use of a simple external utility.
|
|
|
|
|
We wrote one, <tt>cotty</tt> just for that purpose.
|
|
|
|
|
|
|
|
|
|
<FLAME ON>
|
|
|
|
|
|
|
|
|
|
Among the silly problems caused by <tt>pppd</tt> maintainers' shortmindedness,
|
|
|
|
|
you can only run it through
|
|
|
|
|
either a device in <tt>/dev</tt> or the current tty.
|
|
|
|
|
You cannot run it through a pair of pipe
|
2000-11-03 14:59:28 +00:00
|
|
|
|
(which would be the obvious design).
|
2001-11-24 16:24:03 +00:00
|
|
|
|
This is fine for the server's <tt>pppd</tt> if any,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
as it can use the <tt>telnet</tt> or <tt>ssh</tt> session's tty;
|
2001-11-24 16:24:03 +00:00
|
|
|
|
but for the client's <tt>pppd</tt>, this conflicts with
|
2000-11-05 17:56:43 +00:00
|
|
|
|
the possible use of <tt>telnet</tt> as a way to establish a connection.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
Indeed, <tt>telnet</tt>, too wants to be on a tty;
|
|
|
|
|
it behaves <em>almost</em> correctly with a pair of pipe,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
except that it will still insist on doing ioctl's to the current tty,
|
|
|
|
|
with which it will interfere;
|
2000-11-05 17:56:43 +00:00
|
|
|
|
using <tt>telnet</tt> without a tty also causes race conditions,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
so that the whole connection will fail on "slow" computers
|
2000-11-05 17:56:43 +00:00
|
|
|
|
(<tt>fwprc</tt> 0.1 worked perfectly on a P/MMX 233,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
one time out of 6 on a 6x86-P200+, and never on a 486dx2/66).
|
2000-11-05 17:56:43 +00:00
|
|
|
|
All in all, when using <tt>telnet</tt>, you need <tt>cotty</tt>
|
|
|
|
|
to run as a daemon to copy output from one tty on which runs <tt>pppd</tt>
|
|
|
|
|
into another tty on which runs <tt>telnet</tt>, and conversely.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
If I find the sucker (probably a MULTICS guy,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
I strangle him!
|
|
|
|
|
|
|
|
|
|
</FLAME>
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect>Secure solution: piercing using ssh
|
|
|
|
|
<p>
|
|
|
|
|
<sect1>Principle
|
|
|
|
|
<p>
|
|
|
|
|
Let's assume that your site administrator allows
|
2000-11-05 17:56:43 +00:00
|
|
|
|
transparent TCP connections to some port on some remote machine,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
(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
|
2001-07-16 15:48:50 +00:00
|
|
|
|
(using <tt>httptunnel</tt>, <tt>mailtunnel</tt>,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
some tunnel over <tt>telnet</tt>, or whatelse).
|
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Then, you can run an <tt>sshd</tt> on the server side port,
|
|
|
|
|
and connect to it with an <tt>ssh</tt> on the client side port.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
On both sides of the <tt>ssh</tt> connection,
|
|
|
|
|
you run IP emulators (<tt>pppd</tt>),
|
2000-11-03 14:59:28 +00:00
|
|
|
|
and there you have your VPN, Virtual Public Network,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
that circumvents the stupid firewall limitations,
|
|
|
|
|
with the added bonus of being encrypted for privacy
|
|
|
|
|
(beware: the firewall administrator still knows the other end of the tunnel,
|
|
|
|
|
and whatever authentication information you might have sent before to run
|
|
|
|
|
<tt>ssh</tt>).
|
|
|
|
|
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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.
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>A sample session
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Below is a sample script for you to adapt to your needs.
|
|
|
|
|
It uses the array feature of <tt>zsh</tt>,
|
|
|
|
|
but you may easily adapt it to your favorite shell.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
Use option <tt>-p</tt> for <tt>ssh</tt> to try another port than port 22
|
|
|
|
|
(but then, be sure to run <tt>sshd</tt> on same port).
|
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Note that the script supposes that <tt>ssh</tt>
|
|
|
|
|
can login without your having to interactively type your password
|
|
|
|
|
(indeed, it's controlling tty will be connected to <tt>pppd</tt>,
|
|
|
|
|
so if it asks for a password, you lose).
|
|
|
|
|
This can be done either by ssh keys in your <tt>~/.ssh/authorized_keys</tt>
|
|
|
|
|
that either do not require a password,
|
|
|
|
|
or that you unlock using <tt>ssh-agent</tt> or <tt>ssh-askpass</tt>.
|
|
|
|
|
See your SSH documentation.
|
|
|
|
|
Actually, you might also use a <tt>chat</tt> script to enter your password,
|
|
|
|
|
but this is definitely <em>not</em> the Right Thing.
|
|
|
|
|
|
|
|
|
|
If you are not <tt>root</tt> on the server end,
|
|
|
|
|
or simply if want to screen your client's network from outbound connections,
|
|
|
|
|
you can use <tt>slirp</tt> instead of <tt>pppd</tt> as the remote PPP emulator.
|
|
|
|
|
Just uncomment the relevant line.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<verb>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
#!/bin/zsh -f
|
|
|
|
|
SERVER_ACCOUNT=root@server.fqdn.tld
|
|
|
|
|
SERVER_PPPD="pppd ipcp-accept-local ipcp-accept-remote"
|
|
|
|
|
#SERVER_PPPD="pppd" ### This usually suffices if it's in /usr/sbin/
|
|
|
|
|
#SERVER_PPPD="/home/joekluser/bin/slirp ppp"
|
|
|
|
|
CLIENT_PPPD=( pppd
|
|
|
|
|
silent
|
|
|
|
|
10.0.2.15:10.0.2.2
|
|
|
|
|
### For debugging purposes, you may uncomment the following:
|
|
|
|
|
# updetach debug
|
|
|
|
|
### Another potentially useful option (see section on Routing):
|
|
|
|
|
# defaultroute
|
|
|
|
|
)
|
|
|
|
|
$CLIENT_PPPD pty "ssh -t $SERVER_ACCOUNT $SERVER_PPPD"
|
2000-11-05 17:56:43 +00:00
|
|
|
|
</verb>
|
2001-07-13 13:47:43 +00:00
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Note that default options from your
|
|
|
|
|
<tt>/etc/ppp/options</tt> or <tt>~/.slirprc</tt>
|
2001-07-16 15:48:50 +00:00
|
|
|
|
may break this script, so remove any unwanted option from there.
|
|
|
|
|
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Also note that 10.0.2.2 is the default setting for <tt>slirp</tt>,
|
2001-07-16 15:48:50 +00:00
|
|
|
|
which might or not fit your specific setup.
|
|
|
|
|
In any case, you should most likely be using some address in one
|
|
|
|
|
of the ranges reserved by RFC 1918 for private networks:
|
|
|
|
|
10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.
|
|
|
|
|
The firewall-protected LAN might already be using some of them,
|
|
|
|
|
and avoiding clashes is your responsibility.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
For more customization, please read the appropriate documentation.
|
|
|
|
|
|
|
|
|
|
If your client's <tt>pppd</tt> is old or non-linux (e.g. BSD)
|
|
|
|
|
and hasn't got the <tt>pty</tt> option,
|
|
|
|
|
use <tt>cotty -d -- $CLIENT_PPPD -- ssh -t $SERVER_ACCOUNT $SERVER_PPPD</tt>.
|
|
|
|
|
Catches: don't put quotes around commands given to cotty,
|
|
|
|
|
as they are just <tt>exec()</tt>'d as is,
|
|
|
|
|
and don't forget to specify the full path for your the server's <tt>pppd</tt>
|
|
|
|
|
if it's not in the standard path setup by <tt>ssh</tt>.
|
|
|
|
|
|
|
|
|
|
Automatic reconnection is left as an exercise to the reader
|
|
|
|
|
(the <tt>nodetach</tt> option from <tt>pppd</tt> might help for that).
|
2000-11-05 17:56:43 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
|
|
|
|
<sect>Unsecure solution: piercing using telnet
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
<sect1>Principle
|
|
|
|
|
<p>
|
|
|
|
|
If all you can do is telnet (because of a telnet proxy),
|
|
|
|
|
then this solution might be fit for you.
|
|
|
|
|
|
|
|
|
|
The firewall-piercing program, <tt>fwprc</tt>,
|
|
|
|
|
will use a "tty proxy", <tt>cotty</tt>,
|
|
|
|
|
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.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
One command will be telnet connection to server site,
|
|
|
|
|
and the other will be the client's <tt>pppd</tt>.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<tt>pppd</tt> 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,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
and if you can reliably run a daemon on the server host
|
2000-11-03 14:59:28 +00:00
|
|
|
|
(with a cron job to relaunch it in case of breakage),
|
|
|
|
|
then you'd better write some program that will just connect
|
2001-11-24 16:24:03 +00:00
|
|
|
|
a client side port to the server side port through the proxy,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
so you can use the above secure solution,
|
|
|
|
|
possibly using some variant of <tt>ssh -t -o "ProxyCommand ..."</tt>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
(if you submit it to me, I'll gladly integrate such a solution
|
|
|
|
|
to the <tt>fwprc</tt> distribution).
|
|
|
|
|
|
|
|
|
|
Note: if you must use the unsecure telnet-based solution,
|
|
|
|
|
be sure that nothing lies in your target account
|
|
|
|
|
that you want to keep secret or untampered,
|
|
|
|
|
since the password will be sent in clear text accross the Internet.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
If you can control these things, a one-time-password system,
|
|
|
|
|
or an explicit cryptographic challenge system will enhance your security,
|
|
|
|
|
although it will make automated connection scripts much more complex.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
<sect1>fwprc
|
|
|
|
|
<p>
|
|
|
|
|
I wrote a very well self-documented script
|
|
|
|
|
to pierce firewalls, <tt>fwprc</tt>,
|
|
|
|
|
available from
|
2001-11-24 16:24:03 +00:00
|
|
|
|
<url url="http://fare.tunes.org/files/fwprc/"
|
2000-11-03 14:59:28 +00:00
|
|
|
|
name="my site">,
|
|
|
|
|
together with <tt>cotty</tt>
|
2001-07-16 15:48:50 +00:00
|
|
|
|
(which is required by <tt>fwprc.2</tt> 0 and later).
|
2000-11-03 14:59:28 +00:00
|
|
|
|
At the time of my writing these lines, latest versions are
|
2001-11-24 16:24:03 +00:00
|
|
|
|
<tt>fwprc</tt> 0.3e and <tt>cotty</tt> 0.4c.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
|
|
|
|
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 <em>correct</em> configuration).
|
|
|
|
|
If you must read it aloud, choose the worst way you can imagine.
|
|
|
|
|
|
2001-07-16 15:48:50 +00:00
|
|
|
|
CONTEST! CONTEST! Send me an audio file
|
2000-11-03 14:59:28 +00:00
|
|
|
|
with a digital audio recording of how you pronounce "fwprc".
|
2000-11-03 18:43:18 +00:00
|
|
|
|
The worst entry will win a free upgrade and his name
|
|
|
|
|
on the <tt>fwprc</tt> 1.0 page!
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>.fwprcrc
|
|
|
|
|
<p>
|
|
|
|
|
<tt>fwprc</tt> can be customized through a file <tt>.fwprcrc</tt>
|
|
|
|
|
meant to be the same on both sides of the firewall.
|
|
|
|
|
Having several alternate configurations to choose from is sure possible
|
|
|
|
|
(for instance, <em>I</em> do it),
|
|
|
|
|
and is left as an exercise to the reader.
|
|
|
|
|
<p>
|
|
|
|
|
To begin with, copy the appropriate section of <tt>fwprc</tt>
|
|
|
|
|
(the previous to last) into a file named <tt>.fwprcrc</tt>
|
|
|
|
|
in your home directory.
|
|
|
|
|
Then replace variable values with stuff that fits your configuration.
|
|
|
|
|
Finally, copy to the other host, and test.
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Default behavior is to use <tt>pppd</tt> on the client,
|
|
|
|
|
and <tt>slirp</tt> on the server.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
To modify that, you can redefine the appropriate function
|
|
|
|
|
in your <tt>.fwprcrc</tt> with such a line as:
|
|
|
|
|
<tscreen>
|
|
|
|
|
remote_IP_emu () { remote_pppd }
|
|
|
|
|
</tscreen>
|
|
|
|
|
<p>
|
2000-11-03 18:43:18 +00:00
|
|
|
|
Note that <tt>SLiRP</tt> is safer than <tt>pppd</tt>,
|
|
|
|
|
and easier to have access to,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
since it does not require being root on the server machine,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
and needn't additional firewall configuration to prevent
|
|
|
|
|
connections from the outside world into the firewalled network.
|
2000-11-03 18:43:18 +00:00
|
|
|
|
The basic functionality in <tt>SLiRP</tt> works quite well,
|
2000-11-05 17:56:43 +00:00
|
|
|
|
but I haven't managed to get some advertised pluses to work
|
|
|
|
|
(like run-time controllability).
|
|
|
|
|
Of course, since it is free software,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
feel free to hack the source
|
2000-11-05 17:56:43 +00:00
|
|
|
|
so as to actually implement or fix whichever feature you need.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
|
|
|
|
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<sect>Routing
|
|
|
|
|
<p>
|
|
|
|
|
Piercing the firewall is not everything.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
You must also route the packets
|
|
|
|
|
from the client side of the firewall to the server side.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
This section tackles the basic settings specific
|
|
|
|
|
about routing accross a tunnel.
|
|
|
|
|
For more detailed explanations of routing,
|
|
|
|
|
see the relevant HOWTOs and man pages
|
|
|
|
|
about networking, routing and masquerading.
|
|
|
|
|
</p>
|
|
|
|
|
<sect1>The catch
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
The catch is that although your network administration would tell you
|
|
|
|
|
to setup your some router on your client side's as the default route,
|
|
|
|
|
(this may be relevant if you want to have a specific route
|
|
|
|
|
to the networks on the client of the firewall),
|
|
|
|
|
you should setup PPP link as the route to the networks on the server side.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
In other words, your default route should point to a router
|
|
|
|
|
on whichever side of the tunnel that gives you access to the Internet.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Most importantly, packets sent to the server host as part of running the tunnel
|
|
|
|
|
should be routed through your usual network
|
|
|
|
|
(e.g. your default ethernet router);
|
|
|
|
|
otherwise, your kernel will have problems,
|
|
|
|
|
as it tries to route through the inside the tunnel
|
|
|
|
|
the very packets that ought to constitute the outside of the tunnel.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Thus, you'll have to setup correct routes
|
|
|
|
|
in your network startup configuration.
|
|
|
|
|
The precise location of your routing configuration data
|
|
|
|
|
depends on your distribution, but it is typically
|
|
|
|
|
under <tt>/etc/init.d/network</tt> or <tt>/etc/network/</tt>;
|
|
|
|
|
similarly, your PPP configuration is typically in <tt>/etc/ppp/</tt>,
|
|
|
|
|
and the proper place to configure its routes is usually
|
|
|
|
|
in <tt>ip-up</tt> or <tt>ip-up.d/</tt>.
|
|
|
|
|
(Tip: to identify your distribution-specific file locations,
|
|
|
|
|
you must read the documentation of your distribution and otherwise
|
|
|
|
|
<htmlurl url="http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?RTFM"
|
|
|
|
|
name="RTFM">;
|
|
|
|
|
alternatively use <tt>grep</tt> recursively on your <tt>/etc</tt>;
|
|
|
|
|
at worst, trace what happens at boot time,
|
|
|
|
|
as configured in your <tt>/etc/inittab</tt>.)
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
When piercing a tunnel from a roaming laptop on the Internet
|
|
|
|
|
into a protected network, the script <tt>getroute.pl</tt>
|
2001-07-16 15:48:50 +00:00
|
|
|
|
(available from the <tt>fwprc</tt> distribution)
|
2001-11-24 16:24:03 +00:00
|
|
|
|
gives the current route to the server host that is the other end of the tunnel.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</p>
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Once you can route packets to the server side of the tunnel,
|
2001-07-16 15:48:50 +00:00
|
|
|
|
you might want to setup your machine as a router for all your pals
|
2001-11-24 16:24:03 +00:00
|
|
|
|
on the client side of the firewall, achieving a full-fledged shared VPN.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
This is not specific to Firewall-Piercing, so just you read
|
|
|
|
|
the relevant HOWTOs about networking, routing and masquerading.
|
|
|
|
|
Also, for security reasons, be sure to also setup
|
|
|
|
|
a proper firewall on your machine,
|
|
|
|
|
especially if you're going to be a router for other people.
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Finally, be reminded that if you're using <tt>pppd</tt>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
on the server end of the tunnel (as opposed to user-mode <tt>slirp</tt>),
|
2001-07-16 15:48:50 +00:00
|
|
|
|
you will have to configure proper routes and firewall rules
|
2001-11-24 16:24:03 +00:00
|
|
|
|
on the server side of the tunnel, too.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</p>
|
|
|
|
|
</sect1>
|
|
|
|
|
<sect1>Example of routing
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
In this example, your client machine is connected to a firewalled LAN
|
|
|
|
|
through ethernet device <tt>eth0</tt>.
|
|
|
|
|
Its IP address is <tt>12.34.56.78</tt>;
|
|
|
|
|
its network is <tt>12.34.56.0/24</tt>;
|
|
|
|
|
its router is <tt>12.34.56.1</tt>.
|
|
|
|
|
|
|
|
|
|
Your network administrator may have told you to use <tt>12.34.56.1</tt>
|
|
|
|
|
as default router, but you shouldn't.
|
|
|
|
|
You should only use it as a route to the client side of the firewall.
|
|
|
|
|
|
|
|
|
|
Let's suppose the client side of your firewall is made of networks
|
|
|
|
|
<tt>12.34.0.0/16</tt> and <tt>12.13.0.0/16</tt>,
|
|
|
|
|
and of host <tt>11.22.33.44</tt>.
|
|
|
|
|
To make them accessible through your client router,
|
|
|
|
|
add these routes to your global network startup script:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route add -net 12.34.0.0 netmask 255.255.0.0 gw 12.34.56.1
|
|
|
|
|
route add -net 12.13.0.0 netmask 255.255.0.0 gw 12.34.56.1
|
|
|
|
|
route add -host 11.22.33.44 gw 12.34.56.1
|
|
|
|
|
</verb>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
You must also keep the route to the client's local network,
|
2001-07-16 15:48:50 +00:00
|
|
|
|
necessary for linux kernel 2.0 and earlier,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
but but unnecessary for linux kernel 2.2 and later
|
|
|
|
|
(that implicitly adds it during the <tt>ifconfig</tt>):
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route add -net 12.34.56.0 netmask 255.255.255.0 dev eth0
|
|
|
|
|
</verb>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
On the other hand, you <em>must</em> remove
|
|
|
|
|
any default route from your scripts.
|
|
|
|
|
Delete or comment away a line like:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route add default gw 12.34.56.1
|
|
|
|
|
</verb>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Note that it is also possible to remove the route from the running
|
|
|
|
|
kernel configuration without rebooting, by the following command:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route del default gw 12.34.56.1
|
|
|
|
|
</verb>
|
|
|
|
|
Then you can have <tt>pppd</tt> setup a default route automatically
|
|
|
|
|
when it starts by using its <tt>defaultroute</tt> option.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Alternatively, you can add it afterwards:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route add default gw 10.0.2.2
|
|
|
|
|
</verb>
|
|
|
|
|
If you don't want <tt>pppd</tt> as a default route,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
because the Internet access is available on your side of the firewall,
|
|
|
|
|
and if you instead want network <tt>98.76.48.0/20</tt>
|
|
|
|
|
to be routed through the tunnel,
|
|
|
|
|
except from host <tt>98.76.54.32</tt>
|
|
|
|
|
that serves as the other end of the tunnel,
|
|
|
|
|
then add the following lines to your <tt>/etc/ppp/ip-up</tt>:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
route add -host 98.76.54.32 gw 12.34.56.1
|
2001-11-24 16:24:03 +00:00
|
|
|
|
route add -net 98.76.48.0 netmask 255.255.240.0 gw 10.0.2.2
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</verb>
|
|
|
|
|
If you're a laptop and your current LAN moves,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
and yet you want to keep your current route to <tt>98.76.54.32</tt>,
|
|
|
|
|
whatever it be, then use <tt>getroute.pl</tt> as follows
|
|
|
|
|
to automatically find the right gateway
|
|
|
|
|
in the <tt>route add -host</tt> command:
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<verb>
|
|
|
|
|
$(getroute.pl 98.76.54.32)
|
|
|
|
|
</verb>
|
|
|
|
|
Note that if you have them in your <tt>/etc/hosts</tt>,
|
|
|
|
|
you might use symbolic names instead of numerical IP addresses
|
|
|
|
|
(and you might even use FQDN's, if you trust the DNS never to fail).
|
|
|
|
|
</p>
|
|
|
|
|
</sect>
|
|
|
|
|
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<sect>Reverse piercing
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
<sect1>Rationale
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
<tt>fwprc</tt> includes code to trigger such connections
|
2001-07-16 15:48:50 +00:00
|
|
|
|
from an OpenPGP-authentified email message;
|
2000-11-03 18:43:18 +00:00
|
|
|
|
all you need is add <tt>fwprc</tt> as a <tt>procmail</tt> filter
|
2000-11-03 14:59:28 +00:00
|
|
|
|
to messages using the protocol,
|
|
|
|
|
(instructions included in <tt>fwprc</tt> itself).
|
|
|
|
|
Note however, that if you are to launch <tt>pppd</tt>
|
|
|
|
|
with appropriate privileges,
|
|
|
|
|
you might need create your own suid wrapper to become root.
|
|
|
|
|
Instructions enclosed in <tt>fwprc</tt>.
|
|
|
|
|
|
|
|
|
|
Also, authentified trigger does not remotely mean secure connection.
|
|
|
|
|
You should really use <tt>ssh</tt> (perhaps over telnet)
|
|
|
|
|
for secure connections.
|
|
|
|
|
And then, beware of what happens between the triggering of a telnet
|
|
|
|
|
connection, and <tt>ssh</tt> taking over that connection.
|
|
|
|
|
Contribution in that direction welcome.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
2001-07-13 13:53:25 +00:00
|
|
|
|
<sect1>Getting the trigger message
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
If you are firewalled, your mail may as well be in a central mailserver
|
2000-11-03 14:59:28 +00:00
|
|
|
|
that doesn't do procmail filtering or allow telnet sessions.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
No problem! You can run <tt>fetchmail</tt>
|
|
|
|
|
in daemon mode (or within a cron job)
|
2001-11-24 16:24:03 +00:00
|
|
|
|
to poll your mailserver and deliver mail to your linux system
|
2001-07-16 15:48:50 +00:00
|
|
|
|
which itself will have been configured to use <tt>procmail</tt> at delivery.
|
2000-11-03 18:43:18 +00:00
|
|
|
|
Note that if you run <tt>fetchmail</tt> as a background daemon,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
it will lock away any other fetchmail that you'd like to run
|
|
|
|
|
only at other times, like when you open a <tt>fwprc</tt>;
|
|
|
|
|
of course, if you can also run a fetchmail daemon as a fake user.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
Too frequent a poll won't be nice to either the mailserver or your host.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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.
|
2001-07-13 13:53:25 +00:00
|
|
|
|
</p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
<sect1>Other automated tools for reverse piercing
|
2001-07-13 13:53:25 +00:00
|
|
|
|
<p>
|
|
|
|
|
Another way to poll for messages, when you don't have a mailbox,
|
|
|
|
|
but do have outbound FTP access, is to use
|
|
|
|
|
<url url="http://dhirajbhuyan.hypermart.net/ftp-tunnel.html"
|
|
|
|
|
name="FTP tunnel">.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
|
|
|
|
|
A tool to maintain a permanent connection between a firewalled host and
|
|
|
|
|
an external proxy, so as to export services from the host to the world, is
|
|
|
|
|
<url url="http://www.employees.org/~hek2000/projects/firewallTunnel/"
|
|
|
|
|
name="firewall tunnel">.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect>Final notes
|
|
|
|
|
<p>
|
|
|
|
|
|
|
|
|
|
<sect1>Other settings
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
I have no idea how to pierce firewalls with lesser operating systems,
|
|
|
|
|
but you can take one of these old disused computers
|
|
|
|
|
(about anything with 8MB of RAM and an ethernet card should do),
|
|
|
|
|
install Linux or BSD as on it, and pierce the firewall with it,
|
|
|
|
|
while serving as a router for other machines running lesser OSes.
|
|
|
|
|
See appropriate HOWTOs about routing, IP forwarding, NAT, etc.
|
|
|
|
|
|
|
|
|
|
I don't know the details, but a promising tool to pierce firewalls is
|
|
|
|
|
Chris Mason's <url url="http://www.r00t3d.org.uk/" name="Bouncer">,
|
|
|
|
|
which acts as a SOCKS-proxy-over-SSL.
|
|
|
|
|
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2000-11-03 18:43:18 +00:00
|
|
|
|
In a very easy case, we saw that you can just launch <tt>ssh</tt>
|
|
|
|
|
over a pty master and do some <tt>pppd</tt> in the slave tty.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
You may even want to do it without an adverse firewall,
|
|
|
|
|
just so as to build a secure ``VPN'' (Virtual Private Network).
|
|
|
|
|
The <htmlurl url="http://www.linuxdoc.org/HOWTO/mini/VPN.html"
|
|
|
|
|
name="VPN mini-HOWTO">
|
|
|
|
|
gives all the details you need about this.
|
|
|
|
|
We invite you, as an exercise,
|
|
|
|
|
to modify <tt>fwprc</tt>
|
|
|
|
|
so as to use this technique,
|
|
|
|
|
or perhaps even so as to use it
|
|
|
|
|
inside a previous non-secure <tt>fwprc</tt> 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
|
2001-07-13 13:53:25 +00:00
|
|
|
|
<url url="http://www.snurgle.org/~griffon/" name="Chris Chiappa">'s
|
|
|
|
|
script
|
|
|
|
|
<url url="http://www.snurgle.org/~griffon/ssh-https-tunnel"
|
|
|
|
|
name="ssh-https-tunnel">.
|
|
|
|
|
|
|
|
|
|
Another promising program for piercing through HTTP is
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<url url="http://lars.nocrew.org/" name="Lars Brinkoff">'s
|
|
|
|
|
<url url="http://www.nocrew.org/software/httptunnel/"
|
|
|
|
|
name="httptunnel">,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
a http server and client combination that achieves a TCP/IP tunnel connection
|
2000-11-03 14:59:28 +00:00
|
|
|
|
through the proxy-friendly HTTP protocol.
|
|
|
|
|
You should then be able to run <tt>fwprc</tt> (preferably over <tt>ssh</tt>)
|
|
|
|
|
over that connection, although I haven't tried it yet.
|
|
|
|
|
Could anyone test and report?
|
|
|
|
|
Note that <tt>httptunnel</tt> 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 <URL name="mailtunnel" URL="http://www.detached.net/mailtunnel/">,
|
|
|
|
|
<URL name="icmptunnel" URL="http://www.detached.net/icmptunnel/">),
|
|
|
|
|
or whatelse,
|
2001-11-24 16:24:03 +00:00
|
|
|
|
you can always write a tunnel client/server combination,
|
2000-11-03 18:43:18 +00:00
|
|
|
|
and run a <tt>ssh</tt> and/or PPP connection through it.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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
|
2000-11-03 18:43:18 +00:00
|
|
|
|
to use <tt>fetchmail</tt>, <tt>suck</tt>,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
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.
|
2000-11-03 18:43:18 +00:00
|
|
|
|
If necessary, fall back to using the
|
|
|
|
|
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Term-Firewall.html"
|
|
|
|
|
name="Term-Firewall mini-HOWTO">.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
<URL URL="ftp://quatramaran.ens.fr/pub/madore/misc/">.
|
|
|
|
|
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,
|
2000-11-03 18:43:18 +00:00
|
|
|
|
or such, which requires not only an elaborate protocol,
|
2000-11-03 14:59:28 +00:00
|
|
|
|
but also an interface to an OS kernel, both of which are costly to implement.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
|
|
|
|
|
Finally, if you're not fighting against an adverse firewall,
|
|
|
|
|
but just building your own VPN, there is a large offer of VPN tools,
|
|
|
|
|
and although the tricks I present are simple, work well,
|
|
|
|
|
and might be enough for your needs, it could be a good idea
|
|
|
|
|
to look at this evolving offer (that I do not know much about)
|
|
|
|
|
for a solution that fits your requirements of performance and maintainability.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect1>HOWTO maintenance
|
|
|
|
|
<p>
|
|
|
|
|
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.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2000-11-05 17:56:43 +00:00
|
|
|
|
<sect1>Related Documents
|
|
|
|
|
<p>
|
2001-11-24 16:24:03 +00:00
|
|
|
|
The <url url="http://www.linuxdoc.org/" name="LDP">
|
|
|
|
|
publishes many documents related to this
|
|
|
|
|
<htmlurl url="http://www.linuxdoc.org/HOWTO/HOWTO-INDEX/mini.html"
|
|
|
|
|
name="mini-HOWTO">.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
most notably
|
2001-11-24 16:24:03 +00:00
|
|
|
|
the <url url="http://www.securityportal.com/lskb/"
|
2000-11-05 17:56:43 +00:00
|
|
|
|
name="Linux Security Knowledge Base">,
|
|
|
|
|
the <htmlurl url="http://www.linuxdoc.org/HOWTO/VPN.html"
|
2001-07-16 15:48:50 +00:00
|
|
|
|
name="VPN HOWTO"> and
|
2000-11-05 17:56:43 +00:00
|
|
|
|
the <htmlurl url="http://www.linuxdoc.org/HOWTO/mini/VPN.html"
|
|
|
|
|
name="VPN mini-HOWTO">.
|
2001-07-16 15:48:50 +00:00
|
|
|
|
For more general questions about networking, routing and firewalling,
|
|
|
|
|
start from the
|
|
|
|
|
<htmlurl url="http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html"
|
|
|
|
|
name="Networking Overview HOWTO">.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
See also
|
|
|
|
|
the <url url="http://www.linux-firewall-tools.com/linux/"
|
|
|
|
|
name="Linux Firewall and Security site">.
|
2000-11-05 17:56:43 +00:00
|
|
|
|
|
|
|
|
|
Then again, when facing a problem with some program,
|
|
|
|
|
one reflex for any Linux user should be to RTFM:
|
|
|
|
|
Read The Fscking Manual pages for the considered programs.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2001-07-16 15:48:50 +00:00
|
|
|
|
<sect1>Final Word
|
|
|
|
|
<p>
|
|
|
|
|
If you think that all this mucking around with stupid scripts and silly HOWTOs
|
|
|
|
|
is overly complicated and that a decent computer system ought
|
|
|
|
|
to automate it all for you, then welcome with me among
|
|
|
|
|
<htmlurl url="http://www.research.microsoft.com/~daniel/preface.html"
|
|
|
|
|
name="UNIX haters">
|
|
|
|
|
and other people who hate current low-level operating systems,
|
|
|
|
|
and yearn for declarative computing systems
|
|
|
|
|
that take care of the silly details and let us focus on things that matter.
|
2001-11-24 16:24:03 +00:00
|
|
|
|
(Maybe have a peek at my own
|
|
|
|
|
<url url="http://tunes.org/" name="TUNES project">).
|
2001-07-16 15:48:50 +00:00
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
|
2000-11-03 14:59:28 +00:00
|
|
|
|
<sect1>Extra copy of IMPORTANT DISCLAIMER --- BELIEVE IT!!!
|
|
|
|
|
<p>
|
|
|
|
|
<quote>
|
|
|
|
|
<bf>
|
2000-11-05 17:56:43 +00:00
|
|
|
|
I hereby disclaim all responsibility for <em>your</em> use of 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.
|
2000-11-03 14:59:28 +00:00
|
|
|
|
</bf>
|
|
|
|
|
</quote>
|
|
|
|
|
</sect1>
|
|
|
|
|
</sect>
|
|
|
|
|
</article>
|