Secure your Wi-Fi traffic using FOSS utilities

A recent Slashdot item on Wi-Fi security was a timely reminder of the weaknesses of default Wi-Fi encryption protocols, and the dangers of using unencrypted, public Wi-Fi connections. Fortunately, you can use FOSS utilities to securely tunnel your Wi-Fi connection sessions and protect your Web and email traffic.

To facilitate encrypting your Wi-Fi traffic, first set up dynamic DNS service so you can locate your server when you’re away from home. You then port-forward SSH connections through your router to an SSH server, configuring the server to accept only key-authenticated connections. You can then tunnel your email and Web traffic from a remote client through an encrypted SSH tunnel into your home network, and then on to the Internet.

To start, be sure you have an SSH client on your laptop and a Linux server on your home network that is running the sshd daemon, and be sure that the server’s iptables-based software firewall is configured to allow SSH connections.

On my own network I have a Linksys WRT54G Wireless-G Router that serves as my home’s gateway router, an SSH daemon running on a CentOS 4 server on my home network, and Ubuntu Dapper Drake running on my laptop, where I use the Firefox browser and the Thunderbird email client.

Finding your SSH server when you’re on the road

Most ISPs provide dynamic IP addresses for residential customers, which can complicate your connection efforts when you are on the road. Dynamic DNS lets you specify a domain name that always points to your residential server. To start using dynamic DNS, register an Internet domain with a low-cost registrar. I use GoDaddy, and I have been pleased with how easy it is to make changes in the DNS server properties for my domains. For dynamic DNS service, I’ve been using ZoneEdit, which has provided reliable service and support. ZoneEdit does not charge you for the first five domains for which they provide DNS service, as long as traffic levels are reasonable.

For complete details on getting started with dynamic DNS, read this Linux.com article.

Configuring the SSH client and server

Prior to exposing your SSH server to the Internet, and the inevitable automated scans and username/password brute force attacks, you will want to make some configuration changes to restrict SSH connections to public key/private key exchanges, and to eliminate the username/password logins that are subject to random guessing efforts. This is not only easy to configure, but simplifies SSH access in general.

Begin by generating a public/private key pair for your laptop to use for connecting to your SSH server. Log on to your laptop and enter the following command at the user prompt:

ssh-keygen -t dsa

This will generate a public/private key pair that will be used to connect to the SSH server. The keys are stored in the directory /home/user/.ssh.

You now have to append the user’s public key to a specified file on the SSH server. Create an account on the SSH server for the user, and in the home directory for that account, create the following directory and file:

mkdir .ssh
touch .ssh/authorized_keys

The easiest way to append the user’s public key to the file is to use SSH from the laptop:

cat ~/.ssh/id_dsa.pub | ssh user@sshserver_ipaddress "cat >> .ssh/authorized_keys"

Change the permissions on the file on the SSH server so that it is readable only by the user:

chmod 600 .ssh/authorized_keys

Now you should make the changes to the SSH server’s configuration file to tell it that only public/private key connections are allowed. On CentOS 4, the configuration file is /etc/ssh/sshd_config. Before you start, make a backup copy of this file, and make sure you have console access to the server in case you err and lock yourself out. As root, scroll through the file and make changes and additions so that the following lines are the only ones uncommented, and that they read as indicated:

#Port 22
Protocol 2

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_dsa_key

# Logging
SyslogFacility AUTHPRIV

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

ChallengeResponseAuthentication no

UsePAM no

AllowTcpForwarding yes

GatewayPorts yes

TCPKeepAlive yes

Compression yes

# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server

Again as root, restart your SSH server:

service sshd restart

Then, from your laptop, test the connection:

ssh user@sshserver_ipaddress

The connection should be automatic, and you should not be prompted for a password. You can also test that no connections are allowed for users without public keys on the server:

ssh smith@sshserver_ipaddress

This should not generate a request for a username/password, and should instead result in:

Permission denied (publickey).

You will want to repeat these steps for each client that you plan to allow to connect to your SSH server.

Port forwarding your SSH traffic to your server

When you start your remote SSH session from the command line with ssh yourdomain.com, the DNS lookup will be directed to dynamic DNS provider’s DNS servers, which will respond with your current IP address. When the SSH connection request arrives at your home network’s gateway router, it must be forwarded to the correct computer on your internal network.

You must configure port forwarding on your gateway router, generally by accessing its configuration application with a browser from inside your home network. On a Linksys router like the one I use, select the menu item Applications & Gaming, where you will find the configuration settings for port forwarding. By default, SSH traffic uses port 22. Any inbound traffic that arrives on port 22 must be forwarded to the internal network IP address of the computer running the SSH daemon. Responses sent back to the client will be directed by the router to the appropriate requesting client. Here is an image of the Linksys WRT54G settings I use:

Now you’re ready to set up an encrypted tunnel. On the laptop, launch the encrypted connection from the command line with a command like:

ssh -D 2000 yourdomainname.com

The -D 2000 switch sets up a persistent connection listening on port 2000 on the laptop. After you finish testing, you can put this command in a bash script and launch it from your laptop’s menu bar.

Configure applications to forward traffic through the tunnel

Once you have a good connection, you have to tell your applications to use it. In both Firefox and Thunderbird, choose the menu items Edit -> Preferences -> Connection Settings. Select the radio button for manual proxy configuration, and at the section for SOCKS Host, enter localhost and then Port: 2000. Above is an image of my settings:

That’s all it takes. All future Thunderbird and Firefox traffic on the laptop will be forwarded to the listening SSH client on port 2000, sent down an encrypted tunnel to the SSH server on your home network, and then forwarded out to the Internet through your home router. As an additional benefit, as far as your ISP is concerned, your laptop will always be at home, and will therefore have access to your ISP’s SMTP server for outbound email. And you’ll no longer have to worry about crackers sniffing your Wi-Fi traffic, no matter where you are.