[ISN] SSH Tunneling part 2 - Remote Forwarding

From: InfoSec News (isnat_private)
Date: Mon Mar 10 2003 - 01:50:07 PST

  • Next message: InfoSec News: "Re: [ISN] Lost in cyberspace"

    |  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://
    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:
        Create a remote forward (bind a port on the remote machine [SSH
        server], and forward it back here through the SSH client
        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.
        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
        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 (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.
    [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 -
    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
    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
    Archives of this and previous newsletters are available at
    Copyright 2003, Brian Hatch.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Mon Mar 10 2003 - 04:40:38 PST