+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 16-March-2003 | | http://www.hackinglinuxexposed.com/articles/20030316.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 3 - Where does the crypto end? By Brian Hatch Summary: Want to encrypt an otherwise cleartext transmission? SSH Tunneling may be the tool for you. Over the last two weeks I've shown the syntax of SSH tunnels. Either can be created using command line arguments or via entries in ~/.ssh/ config, as follows: Local Forward specified on the command line -L port_on_client:destination_host:destination_port Local Forward defined in ~/.ssh/config LocalForward port_on_client:destination_host:destination_port Remote Forward specified on the command line -R port_on_server:destination_host:destination_port Remote Forward defined in ~/.ssh/config RemoteForward port_on_server:destination_host:destination_port Most frequently, people use SSH tunnels when the tunnel's endpoint is either the SSH client or server. For example they may have an account on the IMAP mail machine at their ISP so they would SSH to it and point the forward at localhost (the IMAP server): # set up forward home_desktop$ ssh mail.my_isp.net -L 1143:localhost:imap # read email via the encrypted tunnel home_desktop$ mutt -f imap://user@localhost:1143/ Or they're doing a remote forward in a similar way, for example this firewall-traversing, security policy-violating version: # connect out to our home machine before going home for # the evening work_mailserver$ ssh home_machine -R 1143:localhost:imap # read our work from home through the tunnel # without using the corporate-mandated PPTP VPN. home_machine$ mutt -f imap://user@localhost:1143/ However, there is no reason the endpoint of the tunnel need to be the SSH client or server machine. For example if you did not have shell access to the work_mailserver machine in the second case above[1] then you could still create a functional SSH tunnel as follows: # From your Linux desktop at work, you SSH to your machine # at home. Connections through the tunnel from home will # get forwarded to work_mailserver, which is a different # machine at your office. work_desktop$ ssh homemachine -R 1143:work_mailserver:imap In this case the IMAP connection is *not* encrypted end-to-end. It is encrypted inside the SSH tunnel from home_machine to work_desktop, but is cleartext from work_desktop to work_mailserver. This means that your email content and your mail password is being sent over the work network in the clear. Is this a problem? It depends on how much security you need. If you normally read your email from work_desktop using plain unencrypted IMAP, then your password is already going across the work network in the clear. The only parts of this connection that are unencrypted are the same parts that were already unencrypted when you checked your email at the office. So, you have successfully enabled yourself to check email from home in a no-less-secure way than you do being in the office itself. Excellent. So let's revisit the first example above. Say we have don't have SSH access to mail.my_isp.net. This means you can't directly log into mail.my_isp.net with a LocalForward and have your IMAP connection encrypted end-to-end. However if you have a shell account on shell.my_isp.net that is available via SSH, you can do the following instead: home_desktop$ ssh shell.my_isp.net -L 1143:mail.my_isp.net:imap Your IMAP connection will only be unencrypted between the ISP's shell server and mail server - the rest of it will be completely encrypted. You could do this from anywhere, from work, a friend's house, or an Internet cafe. Again, is this safe? Well, the only people who can read the cleartext traffic between the shell machine and the mail machine are those folks who have root access on one of the two machine, or a machine that can sniff the network traffic between those two machines. Hopefully, that would only include the legitimate administrators of the ISP, who would have several other ways of reading your email or resetting your password anyway. If an attacker has this level of access on the ISP's machines, your data was already in trouble. So again, setting up an SSH LocalForward allows you to check email from anywhere with encrypted connections except for that last leg which was never crypto-enabled anyway. This was, in fact, the very setup that Alice was using to check her email.[2] Alice didn't have shell access on her ISP's mail server, but was using a LocalForward from home and/or work to access the mail server (via POP in her case) with an encrypted connection for all but that last leg. Bob said it wasn't secure. Alice said it was. Both Alice and Bob understood that the last bit of her connection was not encapsulated in any encryption, so I did not need to clear that up for them, which was the point of contention I imagined they had. So, to their original question "is Alice's email access secure" I had to reply "As secure as the link between the shell server and the mail server." I don't think they were happy with my response. After much debate, we decided that they both knew the facts, and that her threat model considered the short unencrypted connection to be secure enough, and his did not. They agreed to disagree, and I decried that they both needed to buy each other dinner. Tunnel Forwarding Examples Some time next month[3] I'll dedicate an issue of the newsletter to many sample SSH tunnels. Most uses of tunnels are variants of the examples I've already given - tunneling POP, IMAP, or SMTP, getting into your office from home by using a RemoteForward back through your firewall for SSH or a web proxy, etc. If you have any weird useful tunnels you like to use, drop me a line and I'll include them. Happy Birthday Results Thanks to all 50ish people who wished my sister a Happy Birthday. You guys confused and amused her more than I would have imagined. What an excellent turnout.[4] And congratulations to Jennifer Welch, who was person #20 and gets a free signed copy of "Building Linux VPNs." NOTES: [1] Say they're running Exchange, god forbid. [2] Yes, believe it or not, I'm finally getting back to the question that started this whole topic. Luckily I contacted Alice and Bob before I started writing it. [3] I think I need to give everyone a break from crypto-related issues before they kill me. [4] I suspect that the possibility of free stuff might have helped, but I'm always willing to bribe. ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's really going to try to stop talking about crypto for a while. Promise. Well, with the exception of the upcoming Easter Egg Hunt. 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 17 2003 - 05:51:31 PST