Console Login
Home / Blog / Security & Compliance / Surviving the Packet Sniffers: Rolling Your Own OpenVPN Endpoint on CentOS
Security & Compliance 8 views

Surviving the Packet Sniffers: Rolling Your Own OpenVPN Endpoint on CentOS

@

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.

/// TAGS

/// RELATED POSTS

The Perimeter is Dead: Architecting 'Zero Trust' Security on Linux in 2015

The 'Castle and Moat' security strategy is failing. Learn how to implement a Zero Trust architecture...

Read More →

Automating Compliance: How to harden your Norwegian VPS without losing your mind

Manual security audits are a liability in 2015. Learn how to use Ansible and KVM isolation to satisf...

Read More →

Hardening the Stack: Defending Norwegian Web Apps Against the OWASP Top 10 (2012 Edition)

It is 2012, and SQL Injection is still king. A battle-hardened guide to securing LAMP stacks, comply...

Read More →

Paranoia is a Virtue: The 2012 Guide to Linux Server Hardening in Norway

Following the massive security breaches of 2011, default configurations are no longer acceptable. Le...

Read More →

Locking Down Your Linux Box: Essential Server Hardening Survival Guide (2011 Edition)

Stop relying on 'security by obscurity'. A battle-hardened guide to securing your Linux VPS against ...

Read More →

Fortifying the Castle: Essential Linux Server Hardening for 2012

With the rise of LulzSec and automated botnets in 2011, default configurations are a death sentence....

Read More →
← Back to All Posts