Escape the Firesheep: Deploying OpenVPN on Linux
If you have logged into Facebook or Twitter from a coffee shop in the last three months, your session was likely compromised. Since the release of Firesheep late last year, HTTP session hijacking has gone from a dark art to a point-and-click activity for script kiddies. The days of trusting the open airwaves are over.
Serious professionals don't rely on hope; they rely on encryption. While commercial VPN services exist, they are often black boxes. Do they log? Do they throttle? Who owns them? The only way to be certain is to own the endpoint.
In this guide, we are going to build a hardened OpenVPN server on a CoolVDS instance running CentOS 5.5. We choose Norway for the location not just for the low latency to Northern Europe, but for the legal framework. Unlike the US Patriot Act which allows broad data seizures, Norwegian privacy laws (governed by Personopplysningsloven) offer a sanity check that is becoming increasingly rare.
1. The Pre-requisite: Virtualization Matters
Before typing a single command, you need to know your underlying architecture. Many budget VPS providers use oversold OpenVZ containers where the `tun/tap` network device is disabled by the host kernel. If you cannot load the TUN module, OpenVPN will not start.
Pro Tip: We run CoolVDS on hardware-virtualized KVM/Xen stacks. This means you have your own kernel. You don't need to open a support ticket just to enable a network module. It works out of the box.
2. Installing the Software
CentOS 5 doesn't ship with OpenVPN in the default repositories. We need the EPEL (Extra Packages for Enterprise Linux) repo.
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum update
yum install openvpn easy-rsa
3. The PKI Infrastructure
Security is only as strong as your keys. We will use the included easy-rsa scripts to generate our Certificate Authority (CA). Don't use default values. Edit the vars file first:
cd /usr/share/openvpn/easy-rsa/2.0
vi vars
Change the export values at the bottom to match your organization. Then build the PKI:
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-key client1
./build-dh
This generates the Diffie-Hellman parameters. It will take time. On a standard shared host, this entropy generation can take forever. On CoolVDS dedicated tiers, the high-speed SAS storage and dedicated CPU cycles chew through the prime numbers significantly faster.
4. Server Configuration
Copy the sample config and modify it. We want to force all traffic through the tunnel to prevent DNS leaks.
cp /usr/share/doc/openvpn-2.1.4/sample-config-files/server.conf /etc/openvpn/
vi /etc/openvpn/server.conf
Make sure these lines are active to route your internet traffic through the Norwegian IP:
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222" # OpenDNS is reliable here
push "dhcp-option DNS 208.67.220.220"
5. IP Forwarding and Iptables
The VPN is useless if the server doesn't know how to pass traffic from the virtual interface to the physical ethernet adapter. Enable forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
Now, we apply the masquerade rule. This is where most setups fail. You must translate the VPN subnet traffic to the server's public IP.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
service iptables save
service openvpn start
Why Latency Kills the VPN Experience
Encryption adds overhead. If you are a developer in Oslo or Stockholm routing your traffic through a budget server in Texas, the speed of light is your enemy. You will feel the lag in your SSH sessions.
By hosting your OpenVPN node on CoolVDS infrastructure in Norway, you keep the physical path short. You get the privacy of an encrypted tunnel with the responsiveness of a local connection. Plus, our networks are peered directly with major Nordic ISPs (Telenor, Telia), ensuring your packets don't take a detour through Frankfurt just to get to a server next door.
Final Hardening
Don't stop here. Move your SSH port off 22, disable password authentication in favor of SSH keys, and consider installing fail2ban to watch your logs. The internet of 2011 is not a friendly place; ensure your gateway is a fortress.