Escaping Restrictive/Untrusted Networks with OpenVPN on EC2

Perhaps you are behind a corporate firewall which does not allow you to access certain types of resources on the Internet. Or, perhaps you are accessing the Internet over an open wifi where you do not trust your network traffic to your fellow wifi users or the admins running the local network.

These instructions guide you in setting up an OpenVPN server on an EC2 instance, sending all your network traffic through a secure channel to port 80 on the EC2 instance and from there out to the Internet.

EC2 Instance

Run the latest Ubuntu 9.10 Karmic image. You can find the most current AMI id in a table on https://alestic.com

ec2-run-instances --key <KEYPAIR> ami-1515f67c

Make a note of the instance id (e.g., i-6fceba06). Watch the status using a command like this (replace with your own instance id):

ec2-describe-instances <INSTANCEID>

Repeat the describe instances command until it shows that the instance is “running” and make a note of the external hostname (e.g., ec2-75-101-179-94.compute-1.amazonaws.com).

Connect to the instance using the external hostname you noted.

remotehost=<HOSTNAME>
ssh -i <KEYPAIR>.pem ubuntu@$remotehost

OpenVPN Server

Upgrade the EC2 instance and install the necessary OpenVPN software:

sudo apt-get update &&
sudo apt-get upgrade -y &&
sudo apt-get install -y openvpn
sudo modprobe iptable_nat
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A POSTROUTING -s 10.4.0.1/24 -o eth0 -j MASQUERADE

Generate a secret key for secure communication with OpenVPN:

sudo openvpn --genkey --secret ovpn.key

Start the OpenVPN server on the EC2 instance. We are (ab)using port 80 because most closed networks will allow traffic to this port ;-)

sudo openvpn                     \
  --proto tcp-server             \
  --port 80                      \
  --dev tun1                     \
  --secret ovpn.key              \
  --ifconfig 10.4.0.1 10.4.0.2   \
  --daemon

OpenVPN Client

Back on the local (non-EC2) workstation, set up the software:

sudo apt-get install -y openvpn
sudo modprobe tun # if necessary
sudo iptables -I OUTPUT -o tun+ -j ACCEPT
sudo iptables -I INPUT -i tun+ -j ACCEPT

Download the secret key from the EC2 instance:

ssh -i <KEYPAIR>.pem ubuntu@$remotehost 'sudo cat ovpn.key' > ovpn.key
chmod 600 ovpn.key

Start the OpenVPN client:

sudo openvpn                    \
  --proto tcp-client            \
  --remote $remotehost          \
  --port 80                     \
  --dev tun1                    \
  --secret ovpn.key             \
  --redirect-gateway def1       \
  --ifconfig 10.4.0.2 10.4.0.1  \
  --daemon

Edit /etc/resolv.conf and set it so that DNS is resolved by the EC2 name server:

sudo mv /etc/resolv.conf /etc/resolv.conf.save
echo "nameserver 172.16.0.23" | sudo tee /etc/resolv.conf

You should now be able to access any Internet resource securely and without restriction.

Teardown

When you are done with this OpenVPN tunnel, remember to shut down the EC2 instance and restore the DNS configuration:

sudo killall openvpn
ec2-terminate-instances <INSTANCEID>
sudo mv /etc/resolv.conf.save /etc/resolv.conf

If you have ways to improve this approach, please leave a comment.

Disclaimer

These instructions are not intended to assist in illegal activities. If you are breaking the laws or rules of your government or college or company or ISP, then you should understand the security implications of the above steps better than I do and be willing to accept consequences of your actions.

[Update 2009-01-15: Upgrade instructions for Karmic]

New releases of Ubuntu AMIs for Amazon EC2 2008-08-04

New updates have been released for all of the Ubuntu and Debian AMIs listed on:

https://alestic.com

The primary enhancements in this release are:

  • Build using latest debootstrap v1.0.10

  • Output new ssh host key fingerprints to console log for security.

  • Use newly built kernel modules where fuse supports NFS export.

  • All Ubuntu packages upgraded to latest versions

How to get the ssh host key fingerprint from the console output and compare it when using ssh to connect to the instance is described in the “Connecting to your instance” section of the EC2 Getting Started Guide:

http://ec2gsg-running.notlong.com

This is not necessary, but does add a bit of extra security if you are worried about folks intercepting and modifying your ssh connections to EC2 instances.

The NFS support in fuse should let you share an S3-based fuse file system (like PersistentFS) with other hosts over NFS.

Enjoy

New releases of Ubuntu AMIs for Amazon EC2 2008-05-14

New updates have been released for all of the Ubuntu AMIs listed on:

https://alestic.com

The focus of this update includes enhanced security for ssh host keys, cleaning up the boot process and making it a bit faster, and upgrading desktop AMI software. Specific changes to the AMIs include:

  • All Ubuntu packages upgraded to the latest versions as of 2008-04-14.
  • Create new ssh host keys on first boot.
  • Don’t try to set the hwclock under Xen and save 4 seconds on boot.
  • Don’t try to run apparmor as we don’t have the kernel module installed yet.
  • Silence grep warnings about missing authorized_keys file on boot.
  • Create /tmp earlier in the boot process to avoid warnings.
  • Desktop AMIs upgraded to NX Server 3.2.0 (Free Edition).

Additional changes available in the build script include:

  • Support for building 64-bit desktop AMIs.
  • Add –retry to ec2-upload-bundle.
  • AMIs built by the script will not claim they were built by Eric Hammond in /etc/motd :)

Thanks to Thomas Shealy and Hans Omli for many of the above ideas and patches.

The most likely change to cause problems is the generation of new ssh host keys on the first boot. Yesterday’s Debian/Ubuntu ssh key security alert is not directly related, but it did prompt me to reconsider the risk with the current practice of having a single ssh host key for an AMI.

Most public AMIs on EC2 use a fixed ssh host key which means that the entire world can look at it and know what the secret host key is for every instance you start. This spoils the secret and allows man-in- the-middle attacks with no warnings when you ssh to your instance.

Generating a new ssh host key on the first boot solves this problem, but it adds additional complexity in the following case: If you assign a hostname to different instances at different times (dynamic DNS or round robin) then you are more likely to get warnings from ssh about the host key changing when connecting to that hostname.

If you rebundle one of these AMIs, the ssh host key will be shared among new instances of that AMI unless you do the following before bundling:

ln -s ../init.d/ec2-ssh-host-key-gen /etc/rcS.d/S50ec2-ssh-host-key-gen

Bonus for reading this far: I occasionally hang out on IRC channel ##ec2 so swing by and chat sometime.

irc://irc.freenode.net/##ec2