SSH Tunneling part 2 - Remote Forwarding

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  09-March-2003                                                   |
|  http://www.hackinglinuxexposed.com/articles/20030309.html       |
+------------------------------------------------------------------+

This issue sponsored by Hacking Linux Exposed, Second Edition.

Hacking Linux Exposed, Second Edition is out in stores and online.
This new version of the best-selling first edition includes almost
200 new pages of hacking and cracking materials for Linux and
Unix-like systems. HLEv2 shows you, step-by-step, how to defend
against the latest Linux attacks by understanding the hacker's
methods and sinister thought processes.

For reviews, sample chapters, or to order, go to http://
www.hackinglinuxexposed.com/books/  

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

SSH Tunneling part 2 - Remote Forwarding
By Brian Hatch

Summary: Want to encrypt an otherwise cleartext transmission? SSH
Tunneling may be the tool for you.

Last week we discussed SSH's ability to create LocalForwards, and a
quick application of them. This week I'll discuss the converse,
RemoteForwards. Next week[1] I'll discuss a very important
distinction about what part of Local and Remote forwarded connections
are crypto encapsulated, and settle "Alice" and "Bob"s debate from
last week.

As a reminder, an SSH local forward is a tunnel from your local
machine through the SSH server. An SSH Remote Forward is just the
opposite - a tunnel from the remote machine through the SSH client.
The syntax is similar:

  -R remote_port:destination_host:destination_port

where the bits are defined as follows:

-R
    Create a remote forward (bind a port on the remote machine [SSH
    server], and forward it back here through the SSH client
    machine.)
   
remote_port
    The port on the remote machine [SSH server] that /usr/sbin/sshd
    will listen on. This can be a port number or a service name like
    http, pop3, or mysql.
   
destination_host
    The destination host (name or IP address) from the perspective of
    the SSH client machine. This can be a host that is not accessible
    at all from the SSH server. For example if your SSH sessions ends
    outside a firewall and the SSH client can resolve
    "somebox.internal.our_company.com" that's fine, even if the SSH
    server can't reach or find an IP address for that machine
    directly.
   
destination_port
    The port on the destination_host to which it should connect.

For example if you used the following

  workbox$ ssh mail.my_isp.net -R 2323:localhost:23 sleep 99999

then when you connected to port 2323 on homebox, it would be silently
tunnelled to localhost's TELNET port (23). Remember - in this case
localhost is being evaluated on the SSH client, so localhost is the
SSH client 'workbox', not mail.my_isp.net. The sleep 99999 line just
makes sure that the connection stays alive for a while. From another
window you can run the following:

  mail.my_isp.net$ nc localhost 2323

  **********************************************
  Welcome to workbox.internal.our_company.com,
  here at BigCompany, Inc.  This machine can
  only be accessed from inside our firewall.
  That's why we allow Telnet, because everything
  is secure inside here, you know.
  **********************************************

  workbox login: 

You can see that connecting to the local port 2323 on the SSH server
(mail.my_isp.net) resulted in a connection to the TELNET port (23) on
the SSH client machine, 'workbox'. Since this connection was
tunnelled inside the existing SSH session, it is completely[2]
encrypted, with almost no work on your part, requiring no knowledge
of cryptographic algorithms whatsoever.

As with LocalForward's, you can use ~# from the window that ran ssh
to see active connections:

  ~#
  The following connections are open:
    #1 127.0.0.1 (t4 r2 i0/0 o0/0 fd 7/7)

You can open multiple connections at a time, and each is tunnelled
securely through the encrypted SSH channel.

Recent versions of OpenSSH only allow the remote SSH server machine
to connect to the tunnelled connection.[3] If you need to allow other
machines to use this tunnel[4] then you can supply the -g option to
ssh as well.

Above I've described how to create these tunnels from the command
line. Luckily you can also define your tunnels inside your ~/.ssh/
options file. For example if I want to create the above tunnel any
time I connect to my external mail server by running 'ssh
revTelnetTunnel' I can add the following in my options file:

  Host revTelnetTunnel
  HostName mail.my_isp.net
  LocalForward 2323:localhost:23
  GatewayPorts no

Then any time I 'ssh revTelnetTunnel' it will automatically create
this remote forward. (I included 'GatewayPorts no' above, but that is
actually the default anyway.) If I want to connect without the port
forwarding, I just ssh mail.my_isp.net like normal.

I find that RemoteTunnels are most frequently used when connecting
from a more secure network (inside a corporate firewall) to a less
secure network (your ISP, home machine, etc) to allow a tunnel back
into the secure network. This may very well violate your company's
security policy, and you could get into a lot of trouble.

NOTES:

[1] Yes, slight change in our timeline.

[2] "Completely" because the endpoint was the SSH client

[3] It does this by only binding the port for localhost 127.0.0.1 -
no other machines should be able to reach this IP address.

[4] You better do this with great care if it is a protected resource
you are accessing - you do not want to let some random cracker into a
private network.

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He's mighty glad that, long
ago, he replaced Sendmail with Postfix, and BIND with DJBDNS. He's
particularly glad that both have come out with vulnerabilities - the
dry spell was making him worry that they might finally be secure, and
he'd need to pick new software to use as the butt of his jokes. Whew
- that was close. Brian can be reached at
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

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

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.