[linux-elitists] default route = loopback

Rick Moen rick@linuxmafia.com
Sat Jun 3 20:42:36 PDT 2000


This is just so demented that I needed to post it somewhere it would 
be appreciated:



>From: zblaxell@myrus.com (Zygo Blaxell)
To: linux-net@vger.rutgers.edu, ssh@clinet.fi, firewalls-owner@GreatCircle.COM
Subject: Transparent proxy success / loopback abuse
Date: 8 Oct 1996 18:38:15 -0400
X-Date: 19961008
Organization: Smoke & Myrus Design, Inc.
Lines: 116
Message-ID: <53el4n$kml@fludd.myrus.com>
NNTP-Posting-Host: fludd.myrus.com
Xref: fludd.myrus lists.linux.net:1362 lists.ssh:750
lists.firewalls:1266
Sender: owner-ssh@celestial.com
Precedence: bulk

Wow.  Linux's transparent proxy support is fun with ssh.

I actually found a use for this command:

        route add default lo

The application is a combination of transparent proxy support,
firewalls, and ssh.  It is designed to make a host have secure virtual
connectivity to a protected internal network.

Here's my firewall structure:

        outhost (along with the    ->  firewall  ->  internal network
        rest of the Internet)                        (inhost is here)

Outhost is a machine with only a PPP interface.  The PPP interface has a
dynamic IP address.  There is the standard loopback interface, plus a
'dummy' interface that has an IP address/unique host name (so 'telnet
outhost' on outhost works; this seems to be useful for mail).

We want this to work as if outhost was on the same side of the firewall
as inhost:

        outhost$ telnet inhost (IP address 10.0.0.1)

Outhost runs Linux, and has 'default' routed to 'lo' (the loopback
interface), and has a firewall rule to activate a transparent proxy
whenever a connection is made to non-loopback addresses on the loopback
interface.  This rule intercepts network requests to most IP addresses
and feeds them to a proxy program.  The proxy connects to the firewall
via ssh, then launches netcat ('nc') to forward data from the proxy
client to the intended destination server.  ssh encrypts the data
between the firewall and outhost, as follows:

(telnet 10.0.0.1 23.  'a -> b' indicates a TCP connection from a to b)
127.0.0.1:1xxx -> 10.0.0.1:23   (follow the route to loopback)
(ipfwadm -I -a accept -W lo -S 127.0.0.1 -D 0/0 -P tcp -r 100)
10.0.0.1:23 -> 0.0.0.0:100      (firewall rule for transparent proxy)
(transparent proxy program runs 'ssh firewall nc 10.0.0.1 23 -w60')
(ssh session begins from outhost (with dynamic PPP address) to firewall)
1.2.3.4:1xxx -> 5.6.7.8:22      (connect via PPP to firewall)
(sshd runs 'nc 10.0.0.1 23 -w1' on firewall)
10.0.0.2:1xxx -> 10.0.0.1:23    (connect from firewall to inhost via nc)

outhost (1.2.3.4) -> ssh -> firewall-outer (5.6.7.8) 
                            firewall-inner (10.0.0.2) -> nc -> inhost (1.0.0.1)

After all this, the telnet process is connected to a server (so telnet
is happy).  The server happens to be an ssh client process connected to
a server on the firewall.  The server on the firewall happens to be
netcat connected to the final destination telnet server.  ssh and nc
just forward data blindly between the telnet client and server, with ssh
doing encryption and compression goodness to the data as it goes outside
of the firewall.  There is unencrypted TCP at either end, but these are
both reasonably secure (certainly more secure than the public Internet
between the ssh session endpoints).  Of course, both ends have firewall
rules set to disallow all non-ssh and non-local traffic.

Some notes:

1.  The connections have all the benefits of ssh, including security and
compression.  Security could be improved by smarter use of ssh, e.g. use
ssh to connect to the destination directly instead of connecting to the
firewall and using ordinary unencrypted TCP:

        outhost -> ssh -> firewall-outer 
                          firewall-inner -> ssh -> inhost 
                                                   inhost -> nc -> localhost

2.  Connections are really expensive to create.  Whether you're logging
into a host or just fingering it, ssh does the whole secure key and
options exchange, multiple times if there are multiple ssh-based
proxies.  A smarter implementation than mine might start an ssh process
with port-forwarding on a random local port, and then forward all
further connections to the same destination address via the new local
port, saving the ssh authentication overhead for every connection to the
same destination address:

       (on first connection set up an ssh in port-forwarding mode)
First: outhost -> ssh -L36024:inhost:23 -f firewall sleep 86400 -> firewall ...

       (on all subsequent connections (and indeed the first one too),
        just forward data to the local end of an existing ssh tunnel)
Next:  outhost -> outhost:36024

3.  Yes, I know about launching a PPP server at both ends and using ssh
to encrypt and forward the PPP traffic to form a VPN.  The two
techniques are different.  Each performs better under different
circumstances and each has different auditing, logging, and control
capabilities.  PPP over TCP dies horribly if there are lots of lost
packets on the underlying TCP connection, and it requires root access at
both ends to run pppd, and it requires IP addresses recognized by all
hosts at both ends.  Forwarding each connection in a different ssh
connection via transparent proxy can kill the server running the
transparent proxy if there are dozens of connections, but it only
requires root access at one end of the connection, and many outhosts can
use the same IP addresses.

4.  With a dummy interface on outhost and the firewall, and careful
choice of IP addresses, the transparent proxy could be bidirectional
(allowing connections to outhost from inhost) or even totally invisible
(at least if all you can see is TCP).  nc would have to bind to a local
port to match the peer of the transparent proxy connection.  

However, I think there may be nasty details that would prevent this
from working (the fact that dummy is not a loopback interface seems to
be the first one, if it really is a fact.  Anyone?).

5.  This works well enough to run quake, if you make some adjustments
to handle UDP.  'Nuff said.

-- 
Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for 
(name withheld by request). 10th place, ACM Intl Collegiate Programming Contest
Finals, 1994.  Admin Linux/TCP/IP for food, clothing, anime.  Pager: 1 (613) 
760 8572.  "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong



More information about the linux-elitists mailing list