Using SSH Tunnelingby Rob Flickenger
They say that the Wired Equivalent Privacy protocol has been cracked. What's a wireless user to do?
Secure Shell (SSH) is open, free, fast, secure, and easy to setup (once you know how).
WaveLAN's silver and gold cards
In November, I wrote an introduction to Lucent's WaveLAN wireless card, the 802.11b PC card that we've been using at the O'Reilly Network to bring our machines online in a wireless local area network.
A lot can happen in a couple of months. In that article, I explained the difference between the WaveLAN silver and gold cards, and suggested that since the gold cards were only a few dollars more for much stronger encryption, it was worth it to buy the gold cards (assuming that breaking total compatibility with the 802.11b spec wasn't an issue.)
Since then, a team of cryptographers at the University of California at Berkeley identified weaknesses in the way the Wired Equivalent Privacy (WEP) algorithm was implemented in 802.11b, potentially making the strength of encryption irrelevant.
This news should not be cause for alarm, or even discomfort. WEP was not designed to be the ultimate "killer" security tool (nor can anything claim to be). Its acronym makes the intention clear: wired equivalent protection. In other words, the aim behind WEP was to provide no greater protection than you would have when you physically plug into your Ethernet network.
So, if it has been cracked, what good is WEP? And how can one protect oneself if WEP isn't the answer?
802.11b's security weaknesses
|"You can try it for yourself; run tcpdump on your laptop, and watch the traffic going through your access point just fly by!"|
WEP has never provided much more than a form of access control to your
wireless nodes. With a shared private key, everyone participating in your
network has the potential to eavesdrop on everyone else. You can try it for
tcpdump on your laptop, and watch the traffic going through
your access point just fly by! Passwords, private e-mails, web traffic,
everything could potentially be logged and pored over later by anyone who
can associate with your access point.
Plus, key management under 802.11b is difficult. Who wants to distribute a shared password, only to have to change it regularly (and revisit all of those clients who weren't adept enough to set it up themselves in the first place?) Some drivers try to cope with this by letting the user assign multiple keys and pick between them, but this just postpones the inevitable.
Tunneling for security
WEP insecurity really isn't a problem for people who are already tunneling their traffic. Sure, Johnny and Jane Cracksalot may point their high-gain dish at the company from two blocks away, and even take the 5+ hours and gigs of disk space necessary to track every packet. But if you're using an SSH tunnel from your laptop to your servers, they'll still have the insurmountable task of cracking strong cryptography (Blowfish, 3DES, Arcfour, etc.). Until someone finds a cheap way to build a quantum computer (and perhaps a cold fusion cell to power it) this is generally considered a waste of time. Ditto for SSL (Secure Sockets Layer) connections to secure web servers.
A tunnel is a networking term with an appropriate name. It refers to a connection, usually encrypted, that connects two computers together across another, usually untrusted network. Picture a mountain of evil 3l33t d00dz sitting between your laptop and a server on your internal, protected network. You don't want to just throw your traffic really hard at the mountain and hope it gets there; you want to first form a protected tunnel from you to your machine, and then send the traffic through it.
Take this typical scenario:
You're at work or at home, merrily typing away on your wireless laptop. You want to retrieve your e-mail from work with a POP client (Netscape Mail, Eudora, fetchmail, etc.). If you connect to the machine directly, your e-mail client will send your login and password "in the clear." This means that a nefarious individual somewhere between you and your mail server (either elsewhere on your wireless network, or even "on the wire" if you are separated by an untrusted network) could be listening, and grab a copy of your information en route. This login could then be used not only to gain unauthorized access to your e-mail, but in many cases will also grant a shell account on your mail server!
SSH, The Secure Shell: The Definitive Guide
To prevent this, you can use the tunneling capabilities of SSH. An SSH tunnel works like this: Rather than connecting to the mail server directly, we establish an SSH connection to the internal network that the mail server lives in (frequently, the mail server itself). Your SSH client software sets up a port forwarding mechanism, so that traffic that goes to your laptop's POP port magically gets forwarded over the encrypted tunnel and ends up at the mail server's POP port. You then point your e-mail client to your local POP port, and it thinks it is talking to the remote end (only this time, the entire session is encrypted.)
With the tunnel in place, anyone who tries to monitor the conversation between your laptop and the mail server will get something resembling line noise.
Setting up SSH
To set this up, you'll need an SSH client capable of tunneling. My personal favorite is OpenSSH. Under Windows, you'll need a client like SecureCRT (which is commercial software). You might have luck with OpenSSH under Cygwin. (I haven't tested this; let me know if you manage to get it working!)
Once you've installed an SSH client, you can use it to tunnel POP traffic from your local laptop to your mail server (called "mailhost").
We'll assume you have a shell account on the mail server for this example, although any machine on your internal network that accepts SSH connections should suffice.
Step One. Establish the connection
laptop# ssh -L 110:mailhost:110 -l user -N mailhost
user with your username, and
mailhost with your
mail server's name or IP address). Note that you will have to be
your laptop for this example, since you'll be binding to a privileged port
(110, the POP port). You should also disable any locally running POP daemon
/etc/inetd.conf) or it will get in the way.
Assuming you have your RSA or DSA keys setup, you can even run this in the
background (tack on a
&). This sets up the tunnel, and starts
forwarding your local ports to the remote end through it. The
tells SSH to not bother running an actual command on the remote end, and
just do the forwarding.
Under SecureCRT (Windows):
Create a connection for your mail server. Under "Protocol," select
Type in your mail server's hostname or IP address in the Hostname field.
Click the Advanced button and the Port Forwarding tab. Fill in 110 as the local port, the mail server's hostname (or IP address) for the remote hostname, and 110 for the remote port. Click the Save button (not the New button!) Click OK.
Make the connection, and give it your username and password. Voila! You now have your very own tunnel.
Step Two. Configure your mail software
You now need to tell your mail software to connect to your tunnel rather
than connecting to your mail server directly. This is different in each
application, but the idea is always the same: You want your e-mail client to
localhost instead of
Here's how to set it up under Netscape Communicator; other clients may have different menu choices, but the principle is the same:
Go to Edit > Preferences. Expand the Mail & Newsgroups tree, and
select Mail Servers. Remove your existing incoming mail server, and add a
new one. Under General, type
localhost as the Server Name. Select POP3
as the Server Type. Hit OK, make sure your tunnel is established, and
retrieve your mail.
Naturally, it doesn't have to end with POP. You can also forward SMTP for
outgoing mail (port 25). This is mostly left as an exercise to the reader,
but here's a hint: A single
ssh line can have multiple
-L entries, like
ssh -L 110:mailhost:110 -L 25:mailhost:25 -l user -N mailhost
And for Windows users, SecureCRT can have multiple active tunnels. Just stack 'em on, and it will take care of the rest.
All of the above can be automated. Make it as easy as possible to use the tools, and you'll find that you will get in the habit of using them. Security doesn't have to be hard. And SSH is a very flexible tool to help keep your data secure -- WEP or no WEP.
Return to the Wireless DevCenter.