+------------------------------------------------------------------+ | 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 brianat_private -------------------------------------------------------------------- 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-requestat_private 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 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