Browse securely with OpenVPN

Sometimes you find yourself in a situation where you are forced to connect to the outside world through a decidedly insecure connection. Perhaps you are in an airport, using free Wifi, or a hotel room. Or, maybe you happen to be on the Rogers network, and you've read about the tendency of that ISP to watch what you are doing on line. Whatever the case may be, you are in a situation where security is somewhat less than ideal. If you have access to a machine on a secure connection somewhere else in the world, and that machine has either a static IP address or is configured through a free service such as dyndns.org, you can set things up so that all your Internet traffic is encrypted, and passes through the known, secure machine before coming to your local machine.

This is not difficult to set up.

First, you have to have OpenVPN server set up on the remote machine. We have covered this before, so if you don't have it in place, then go install and configure it. The instructions here are virtually identical to those we set up before, with one important difference -- we are going to tell OpenVPN to redirect all traffic through itself, so nothing going to your local machine (which I'll call a laptop) or leaving it will pass unencrypted. You are browsing so that all traffic is SSL encrypted.

You will recall that OpenVPN server is conrtolled using a file in /usr/local/etc/openvpn (at least on FreeBSD). Copy that file to one called "openvpnredir.conf" and edit it. We are going to change two things: the port that OpenVPN listens to, and we are going to add a directive that tells OpenVPN to redirect all traffic through its secure connection. Here is the file, with the changes higlighted in red.

# Specify device
dev tun

port 1195

# Server and client IP and Pool
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp2.txt

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
dh /usr/local/etc/openvpn/dh1024.pem


# Routes to push to the client
# in the next line 192.168.xxx.0 should be the ip range of your internal network
push "route 192.168.xxx.0 255.255.255.0 default" 

# route all traffic through vpn
push "redirect-gateway def1"

# Use compression on the VPN link
comp-lzo

# change the ip address in the next line to whatever dns you want to use
push "dhcp-option DNS 192.168.0.100"

# Make the link more resistant to connection
failures keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon

As you can see, the changes are minimal. Now, on the client side, find the configuration file you use to set up a VPN connection. On Macs, it's in ~/Library/openvpn. On Windows, it's usually in C:/Program Files/OpenVPN/config.

Duplicate that file, and change the name to something meaningful (i.e. Redir OpenVPN, or whatever), and then change the line that reads "port 1194" to "port 1195".

Now, you should have a new vpn connection available to you, and all traffic will go through the VPN server.

Excellent IPTables firewall script

Last time I talked a bit about using pf as a firewall, on the various BSDs. Naturally, there are far more installations of Linux out there than there are of FreeBSD, OpenBSD, etc. The current firewall of choice on the linux platform is iptables. One of the best open source firewall configurations I've found using iptables is Arno's IPtables Firewall Script.

There are a few things that you want to keep in mind when you pick a firewall technology:

1) The firewall should be stateful - e.g. the firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.
2) The firewall should be easy to configure
3) The firewall should allow you to easily determine what's going on when you look at the log files.

Arno's script does all of these things, and more. Give it a look.

Using pf as a Firewall

I've long been a fan of FreeBSD (although I also use a Mac, Linux, and Windows machine -- right tool for the job, and all that), and one of the things I like best about the various BSDs is the ease with which you can set up a stateful packet-filtering firewall. To put it simply, pf rocks.

Setting it up for the first time, though, can be a bit of a chore. If you are interested in giving pf a look, here's how you do it on FreeBSD.

Recompile your kernel
For the sake of argument, let's assume that we are going to be setting up a machine called "zeus" as a gateway server with a few simple services running on it. We first need to compile the pf stuff into the kernel, and then install our new kernel. First, get to the right directory:

[tcs@zeus] ~> su -
Password:
1:28PM up 60 days, 3:54, 1 user, load averages: 0.03, 0.01, 0.00
[root@zeus] ~# cd /usr/src/sys/i386/conf/

Now, copy the file GENERIC to some new file (I'm calling my zeus):

[root@zeus] ~# cp GENERIC ZEUS

Edit the file ZEUS and add the following lines just below "options ADAPTIVE_GIANT":

#PF Support
device pf #PF OpenBSD packet-filter firewall
device pflog #logging support interface for PF
device pfsync #synchronization interface for PF

#ALTQ Support
options ALTQ
options ALTQ_CBQ # Class Bases Queueing
options ALTQ_RED # Random Early Drop
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler
options ALTQ_CDNR # Traffic conditioner
options ALTQ_PRIQ # Priority Queueing

Now, we need to compile and install the kernel. Go to the /usr/src directory and execute this command:

make buildkernel KERNCONF=ZEUS

Wait (quite a while). When it's done, type this:

make installkernel KERNCONF=ZEUS

Wait a bit longer. Reboot. If it comes up, congrats -- you have a new kernel.

Enable PF in rc.conf
We need to tell the OS that we want to use pf. Enter the following in /etc/rc.conf

pf_enable="YES"
pf_rules="/etc/pf.conf" # rules definition file for pf
pf_flags="" # additional flags for pfctl startup
pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup

Set up the firewall: pf.conf
The default rules for pf.conf are very, very detailed. We are going to ignore them, and make our own. First, back up the /etc/pf.conf file that is (probably) there by default:

cd /etc
mv pf.conf pf.conf.dist

Now, edit a new file called pf.conf and enter the file below (each service is mentioned in the comments preceding it):

# define our interfaces. Find yours by typing ifconfig as root
lo="lo0"
ext_if="fxp1" #your external nic
ext_gw="19x.xx.xx.254" #change this to the ip of your gateway router
int_if="fxp0" #your internal nic
oip1="19x.xxx.xxx.222" #change this to your external ip address

#clean everything up (reset to defaults)
scrub in

# nat for internal clients
nat on $int_if from 192.168.0.0/24 to any -> ($int_if)

# Pass/block rules

block in

pass quick on { $lo $int_if } all

# we shouldn't have to do this, but seem to have to on freebsd
pass out on $lo all

# allow ssh to local machine
pass in on $ext_if proto tcp to ($ext_if) port ssh keep state

Save, and you are ready to give things a try!

Helpful hints:

To enable the firewall rules:

pfctl -f /etc/pf.conf

To enable pf:

pfctl -e

To disable pf:

pfctl -d

Secure your ssh with PKI

It shocks me how many otherwise intelligent people leave port 22 wide open on their machines. In case you didn't know, this is the default port for ssh -- an widely used method of making connections to a machine from remote locations.

ssh is a wonderful system. The default install on virtually every unix like system out there (including Linux, the various BSDs, and Mac OS X) is inherently insecure, and subject to brute force attacks. We see these on our servers virtually every day. A brute force attack is shockingly simple to implement -- the attacker simply runs a script that tries many, many username/password combinations until they get in. Once they have an account, it's only a hop, skip and jump to root access.

Then bad things happen.

There are a number of ways to make it tougher for attackers, of course. First, configure your firewall to only allow incoming ssh requests from known, safe IP addresses. Additionally, you should implement PKI security on your ssh system. This is, fortunately, very simple to do.

The process is simple:

1. Generate your public/private key pair
   
2. Install the keys on the machines you are going to use to access the server
   
3. Modify your ssh server's config file to require known keys
   
4. Restart your server

We are going to generate RSA keys for our client. The public key will live on the remote server, and both keys will live on the client machine. For simplicity, we will generate our keys on the server, and then transfer them to our client machine. Log onto the server as the account you want to generate keys for, and then execute these commands:

server$ cd ~

server$ mkdir .ssh

server$ chmod 700 .ssh

server$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa

Enter passphrase (empty for no passphrase):

Enter same passphrpase again:

Entering a passphrase is optional.... but do it anyway.

Now lock down the file permissions...

chmod go-w ~/.ssh

Now copy the contents of .ssh directory to your client machine. Use a USB key or some other secure method, just to be safe.

Now we need to modify the /etc/ssh/sshd_config file for our ssh server. Mine looks like this:

Protocol 2
ListenAddress 192.168.5.100
HostKey /etc/ssh/ssh_host_rsa_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile .ssh/id_rsa.pub
HostbasedAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
AllowUsers tcs

This is a bare minimum. Note the items in red:

• your public key must exist in /home/yourhomedirectory/.ssh/id_rsa.pub
• ChallengeResponseAuthentication disables simple username/passwords to log on
• AllowUsers is another safety check -- only users who exist here will be able to log in regardless as to what keys they have.

Now, restart your sshd server, and give it a try.

Internet Cafe Security

This PDF discusses a simple (and free) way to foil keyloggers on public terminals such as those found in Internet Cafes. It's common for thieves to install malicious software such as keyloggers in an effort to steal personal information, passwords and so forth from those who use the systems.

Since I hate reading PDFs in web browsers, I copy the relevant bits here:

Rather than hide the password our approach is to embed it in a sequence of random characters. So we seek a way of entering random keys so that they will be seen by the keylogger, but will not affect normal login. The trick lies in the fact that keyloggers employ very low level OS calls. The keylogger sees everything, but it doesn’t understand what it sees. The browser also sees everything, but it doesn’t use everything that it sees: it does not know what to do with keys that are typed anywhere other than the text entry fields, and lets them fall on the floor. The keylogger has no easy way to determine which keys are used by the browser and which fall on the floor. It is very easy to record all of the keys or mouse events (this is true both for Windows and Linux based systems). It is also very easy to determine which application had focus at the time of the event (e.g. this key went to the browser). But it is very hard to determine what the application did with those events. Between successive keys of the password we will enter random keys. In the spirit of chaffing and winnowing, the string that the keylogger receives will contain the password, but embedded in so much random junk that discovering it is infeasible. Observe that we are not exploiting a particular feature of any particular browser: this trick works with all versions of Internet Explorer, Netscape Navigator and Mozilla Firefox. We are exploiting the difficulty from the OS layer of determining how the GUI of an an application handles events. It involves typing random characters between successive characters of the password, and changing focus to and from the password field using the mouse. Instead of the password snoopy2 the keylogger now gets:

hotmail.comspqmlainsdgsosdgfsodgfdpuouuyhdg2

Here a total of 26 random characters have been inserted among the 7 characters of the actual password. In general a total of n extra characters in a length k password will yield so many possible passwords that attack is infeasible (recall the password that can only be tested by attempting login). There are various attacks on this method as we explain below. However, none of the keyloggers reviewed ... appear to have to functionality to defeat this simple trick.

Simple, neat trick.

Easy Certs

FYI, I stumbled on a nifty (and free) utility to generate the certificates you need to use with OpenVPN.

You can find it here:

http://openvpn.se/mycert/

OpenVPN client configuration

Configuring OpenVPN for client use turned out to be rather simple. We installed the OpenVPN GUI found at http://openvpn.se, and then went to the configuration files stored in this location:

c:\program files\openvpn\config

First, we copied the files we generated on the server to this folder. Since I was installing on a laptop, I named my key files "laptop.key" and "laptop.crt". I placed copies of those files in this folder. I also need the "ca.crt" file from the server stored in this location. All three files were copied over using a USB thumb drive, so there is no risk of them getting into the wrong hands.

My configuration file looked like this:

client
remote 205.174.168.29 1194

dev tun
# proto udp
comp-lzo
ca ca.crt
cert laptop.crt
key laptop.key

verb 3

I then double clicked on the OpenVPN icon in the system tray, and lo and behold, I was connected to the local network at work!

After a bit though, it started randomly dropping the connection and then reconnecting. This was annoying, so I did a bit more digging.

By adding these lines to the config, the connection became much more stable:

persist-key
persist-tun

OpenVPN Server configuration

As promised, here are some more details about how I configured my OpenVPN server. The machine in question is running a recent build of FreeBSD, with ports installed. If you haven't used FreeBSD, you might want to consider it. It's a very easy to use, stable system (although if you've ever tried to run a serious Java application on it, you'll quickly become frustrated. FreeBSD + threads = headache, IMHO).

Installing OpenVPN on FreeBSD is as simple as this:

admin@max>cd /usr/ports/security/openvpn
admin@max>make install clean

And that's it. After a few minutes, I had a nice, clean installation of OpenVPN. Now to configure it.

In the FreeBSD world, configuration files are stored in /usr/local/etc/openvpn. So, I went there, and followed the instructions found here: http://openvpn.net/howto.html#config (Please note that the docs indicate helpful scripts for setting up keys etc. are in /usr/share/doc/openvpn, but in the BSD world they seem to be in /usr/local/share/doc/openvpn).

The only hiccup I ran into was that the docs give examples using the bash shell, and I tend to stick to tcsh. Not a big deal. I just ran these commands:

admin@max>pkg_add -r bash
admin@max>rehash
admin@max>exec bash

and I was in bash, where things all worked the docs indicated. Simple enough.

Once I had all my certs set up, my final openvpn.conf file looked something like this:

[tcs@max] /usr/local/etc/openvpn> cat openvpn.conf
# Specify device
dev tun
proto udp

# Server and client IP and Pool
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
dh /usr/local/etc/openvpn/dh1024.pem

# Routes to push to the client
push "route 10.10.132.0 255.255.255.0"

# route all traffic through vpn
push "redirect-gateway def1"

# Use compression on the VPN link
comp-lzo

push "dhcp-option DNS 10.10.132.123"

# Make the link more resistent to connection failures
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon

Finally, since I wanted to use my server as a gateway to my internal LAN, I had to change my pf.conf file (the firewall configuration). The relevant line looks like this:

# nat for vpn
nat on $int_if from $vpn_net to any -> ($int_if)

where $inf_if is the interface device connected to the internal network, and $vpn_net is the subnet I've assigned to the VPN (10.8.0.0/24).

More on this, and on client configuration, when I have a bit more time.

Update: Part three is here.

Virtual Private Networking for Everyone - OpenVPN

I own a small tech firm on the East coast, and have long wanted a safe, secure method of connecting from my residence (about 15 miles outside of the city) to the LAN at the office. My network at the office is mixed, consisting of Windows XP machines, various Macs, and both Linux and FreeBSD servers. At home we have a single XP machine, and several Mac notebooks (iBooks and Intel-based MacBooks).

Naturally, the best solution for connecting between the two locations would be a Virtual Private Network of some sort. Given the fact that I am notoriously cheap, I decided to search around and see if I could come up with some sort of open source solution... and it took me all of fifteen minutes with my favourite search engine to come up with a viable alternative: OpenVPN. It took me a bit longer to get everything working as well as I wanted to, but not all that long. Read on if you'd like to see how I did it.


Why use a VPN?
There are any number of reasons why you might want to have a VPN in place. For example, with a properly set up VPN, you can access resources at one location from the other. So if I want to print something at the office from home, I can do that. Similarly, if I need to recover a file from offsite back up (read: the backup server I keep in my basement) I can do that without having to drive all the way home.

Of course, there are the more obvious things a VPN will give you. If you use a wireless home router that's more than a year or two old, chances are it uses one of the more archaic forms of encryption, like WEP. The problem with these encryption methods is that they don't actually protect your data; anyone with the inclination could park outside your house, apartment building, whatever, and "sniff" your network traffic. Encrypting all traffic between your web browser and some secure gateway will take the wind out of some potential hacker's sails. Remember, just because you're paranoid doesn't mean they're not out to get you....

Or, if you're so paranoid you don't even trust your ISP, you can use a VPN between your home computer and a secure gateway you control somewhere else (like your office) and encrypt allthe traffic that exists on your ISP's network. It won't get decrypted until it hits your gateway machine. Of course, assuming you are a relatively law abiding citizen, this might be going a bit far (unless you are partial to tinfoil hats, that is).


Why OpenVPN?
OpenVPN is free, cross platform, and relatively easy to install and maintain. It also uses a very secure ecryption algorithm -- 128 bit Secure Sockets Layer (SSL) or the same level of encryption you probably use when you access your banking information online. I figure if it's good enough for the major North American financial institutions, it's probably sufficient for my purposes.


Installing OpenVPN
We decided to install OpenVPN on a FreeBSD box, using ports. It was trivial. We'll post a detailed howto here in a week or so. But if you have access to a FreeBSD box, ports is the way to go. Trust me.


Installing OpenVPN clients
Reading the documentatation found on OpenVPN's web site suggests that this is a daunting task. It probably is, if you elect to go their route. We decided to stand on the shoulders of those who have gone before, and use some simple solutions where the heavy lifting is done for us.

For the Windows clients, we went with OpenVPN GUI (http://openvpn.se). Installing it took about 30 seconds, and configuring it took a bit longer (but not much).

For the Macintosh clients, we went with Tunnelblick (http://www.tunnelblick.net). Granted, it has a rather silly name, but it works very, very well, and didn't give us any problems on either the G4 based Macs, or the Intel based machines.

Stay tuned for the technical details of how we made this all work...

Update: Part two is here.