Archive for the "EC2" Category

13 Practical and Tactical Cloud Security Controls in EC2


Cloud Security

Most cloud security blog posts, news articles, and other guidance found online address risks such as governance, contract language, forensics, and other higher-level topics. There isn’t a lot of tactical information that gives actionable advice on what you should be doing today to mitigate cloud-specific risks. Here at Stratum Security, most of our customers have some part of their infrastructure or corporate applications in some sort of cloud or outsourced hosting provider. Additionally, our ThreatSim SaaS is hosted entirely within Amazon’s Web Services (AWS) Elastic Computing Cloud (EC2). In this post I’ll list some of the things we’re doing to protect our own data in EC2.

I won’t spend too much time discussing the legal and contractual issues with the cloud. They are not too different from non-cloud outsourced hosting risks. There is a ton of resources and commentary available online that addresses this. It comes down to this: the stuff you care about, your data and availability of that data, lives and sleeps in someone else’s house. Yes, you own the data but it’s not 100% under your organization’s control. The biggest technical difference (among others) of having your data live in someone else’s data center or cloud is that you lose control over the hardware, and in some cases software, that stores, processes, and transmits your data.

If you are hosted on a cloud platform, you may share certain hardware components with other customers (e.g. the hypervisor). You need to understand what you can protect, where you lose visibility, and where you need/can apply extra security sauce.

Let me preface these recommendations with the following caveats:

  • This will be focused on EC2, and Infrastructure as a Service (IaaS) provider.
  • We’re an information security company with a niche SaaS solution. Our data may be more sensitive than your data.
  • Our recommendations are focused on security first, not necessarily performance. This is no one-size-fits-all.

As such, not all of the recommendations below are suited for every organization – but there are some controls that everyone can and should implement.

Below are a sampling of security controls we’ve implemented in our cloud.  While they are specific to Amazon EC2, most will apply to other IaaS services:

1. Use a Virtual Private Cloud (VPC)
EC2’s “public” instances are essentially all on one big 10.x.x.x network. When you launch a new instance, it is stood up on some random 10.x.x.x IP address. By default EC2 security groups prevent other instances from talking to your machine unless you start opening things up. We launch all of our instances inside our own VPC so that all of our instances are on a specific network subnet (It’s a class B) that we defined. We have two different subnets within our VPC:

  • DMZ – Contains boxes that have something open to the Internet (e.g. web servers, mail servers, jump box, etc.)
  • Private – Servers that store sensitive information and don’t have a need to be exposed at all to the Internet such as our MySQL servers. The machines in the DMZ each have an elastic IP associated with them, the machines on the private network do not.

The use of a VPC has several advantages:

  • You don’t need to keep track of a big list of transient EC2 10.x.x.x IP addresses that may change as you start/stop instances.
  • Security groups within VPCs give you the ability to do egress (outbound) filtering; something that non-VPC security groups do not support.
  • Organization. If your DMZ is the and your private range is it’s easy to tell what is what.

It’s easier to configure IP range security settings. For example, if you need to allow syslog (514/udp) from your DMZ to your central logging machine, you can easily permit rather than have to allow specific public cloud IPs.

Amazon Virtual Private Cloud Documentation

2. Create a DMZ and a Private Network Within Your VPC
The DMZ model has been in use forever for a simple reason: if your servers that are exposed to the dirty Internet are ever compromised, it limits the scope of where the attacker can go to (usually) one or two ports (e.g. SQL). This is a relatively “low cost” control for most applications and has been an accepted architecture forever.

3. Create Security Groups for Each Instance
Security groups are essentially simple firewall rules configured within Amazon’s hypervisor. Security groups are assigned to the instance at launch and cannot be changed later. That said, we created specific security groups for every instance in our environment with the exception of our landing web servers. Our landing servers are replicas of each other so it’s not a big deal to have a “one-size-fits-all” security group there. But our jump box, database servers, mail servers, etc. all have security groups named after the specific instances (e.g. mysql01, mailer02, etc.). This allows us the flexibility to apply very granular rules to every instance without having to worry about an unintended consequence of a security group change that has been applied to several instances.

Amazon Security Groups Documentation

4. Use A Jump Box to Access Your VPC
There’s likely no legitimate reason that every single instance needs SSH exposed to the Internet. If you have 10 instances, that’s 10 perimeters to worry about. Essentially this is a choke point that all administrative SSH access must use to get into the VPC. Once the user is on the jump box, he can then SSH into everything else within the VPC using SSH keys. The jump box is configured so that it is only able to SSH to other specific IP addresses within our VPC. All user actions are logged and only specific users have sudo rights. Furthermore, instances within the VPC are not allowed to connect to each other. All SSH access must be done via the jump box. This way, if something in the DMZ is compromised, the attacker won’t be able to hop to other devices within the DMZ subnet.

Since the security of this server is so important to the security of our environment we pile on several layers of security here. First, in order to login to this instance the user must be coming from a specific IP address. Second, the user must have a valid SSH key. Third, all users must use two-factor authentication (more on this next). We also do a lot of system level hardening that I won’t go into detail on here.

5. Use Two Factor Authentication on Your Jump Box
Just to be clear: passwords suck, are awful, and should never be the single thing between the Internet and critical data. Passwords of all length and complexity are lost, stolen, forgotten, guessed, key logged, reused, and cracked. There’s no reason that critical data should be protected with ONLY a password. Facebook, Gmail, Dropbox, and even our own ThreatSim service all support some form of two-factor authentication. Why would you not protect administrative access to your environment with at least the same effort as your Facebook account?

We use Duo Security for our two-factor solution. It’s free if you have 10 users or less and works great. One of Duo’s founders is Dug Song (of dsniff fame) who has a high degree of security street cred. For our setup, Duo has a Linux SSH module that sends me a push notification to my phone right after I successfully authenticate with my SSH key. If I approve the authentication request I press “Approve” in the Duo app and my terminal passes me to my shell. Duo is available for iOS, Android, Blackberry, etc. If you lose your laptop with your SSH keys, the attacker must have your phone in order to authenticate via SSH.

You can also use Google Authenticator with a PAM module if you want to go that route. You don’t need to buy SecurIDs for everyone. There’s a lot of easy ways to do this.

6. Restrict SSH Access To Your Jump Box With Security Groups
Lots of developers folks love to have SSH open to the entire Internet for emergency or remote support. The problem is that right at this very moment, as you are reading this, there is likely a non-public exploit for SSH being used by bad guys. By allowing the entire Internet access to your SSH port there is nothing stopping an attacker from exploiting your machine. At least if you only allow very specific IP addresses in your security groups you’d be protected. Or, if an attacker gets ahold of your SSH key (hacked/lost/stolen laptop, etc.) at least your instance (e.g. jump box) would be protected by an IP restriction.

Are you always on the go or have an often-changing dynamic IP? Try to get a static IP from your provider. Or, update your security group every time your IP changes. Yes, it’s a little bit of a pain but not as big of a pain of having your entire EC2 environment compromised.

7. Use Outbound Security Groups
This one isn’t always easy to implement but bear with me. There is no reason why highly critical servers within your VPC should be able to initiate a FTP connection to any server on the Internet. There isn’t. For example, would you consider it acceptable for your database server containing all of your customer data to make an outbound FTP connection to a server in China? What about IP ranges in Russia where the Russian Business Network is hosted? It’s better to use egress rules and only allow specific ports and protocols out to specific hosts. Here’s why: If an attacker ever does make it all the way into your database server within the VPC, why make it easy for him to transfer a dump of your database back to his server. Yes, you will need to allow your devices out to specific IPs on the Internet for patches, updates, NTP, etc. But that’s a short list that is worth making and maintaining.

8. Enable EC2’s Two-Factor Authentication for EC2 Console Access
Earlier I talked about using two-factor on SSH and a bunch of other good stuff. None of it matters if someone can just guess your Amazon password (yes, the same one you use to order a ton of tube socks with free shipping), and login to your AWS account. Amazon supports hardware tokens as well as Google Authenticator so that when your AWS password is compromised, the bad guys would need your hardware token or phone to access your account. There is no excuse to not do dual-factor on your AWS login.

9. Use a Host-Based Intrusion Detection System (HIDS)
One thing you lose when hosting your app on EC2 is visibility into the network. Amazon doesn’t give you a span port to run your IDS to watch for bad things happening over the wire. That said, we still want to have visibility into anomalies and incidents within our environment. Enter OSSEC. OSSEC is a free HIDS that monitors system logs and events for events that match a known signature. The events are sent in real-time to a central OSSEC server that then sends the events to our operations personnel via email who can review the reports in real-time. For example we know when the md5 checksum of critical system binaries change, new users are added, or when our syslog shows something strange going on (e.g. segfaults, daemons starting/stopping, hardware problems).

10. Use A Central Log Server
We tested several open source and commercial log collection solutions and ended up pressing the “Easy Button” and going with Splunk. We considered using Log Stash but it was more complex than Splunk and required us to monitor and manage several different processes (redis, elastic search, java, etc.). I won’t waste blog space extolling the virtues of Splunk, but it’s great for collecting or correlating log events across our entire infrastructure. We use it for troubleshooting, security event investigations, etc. From a security standpoint, if a machine gets compromised, you can obviously no longer trust it. At least if it was sending logs in real-time to a centralized server you can go to Splunk and figure out what is going on.

11. Encrypt Sensitive Disk Volumes
This is a big one. Most organizations now use full-disk hard drive encryption on laptops. Why? Because laptops (and the hard drives they contain) are not physically in your direct control and may be stolen or seized without your knowledge since they aren’t locked in the data center down the hall. Virtual disk volumes in the cloud are arguably more difficult to protect because they are virtual – they can live in many places at the same time and be cloned within seconds. It is for this reason that every organization that stores data in the cloud should consider using disk encryption. Several solutions exist including native OS disk crypto as well as SaaS disk encryption providers.

The first thing to do is to think about what information needs to be encrypted. Sometimes it is obvious, like MySQL database files, customer documents, etc. Depending on the nature of your application is may include things like email logs that contain email addresses, Splunk logs, HIDS logs, application logs. All of these may contain fragments of sensitive information that require protection.

For Ubuntu, this is a great article that contains step-by-step directions on how to set up disk encryption in EC2.

One seemingly obvious mistake that many people make is storing the key in the cloud along with the encrypted data. This is like locking your door and then taping the key on the lock. The whole point is to make it so if an attacker gets ahold of your EBS volume that they can’t mount or read the drive. Since you can’t store the key in the cloud this means that you can’t add your encrypted volume to /etc/fstab where it will be automatically mounted at boot. Since Amazon doesn’t allow console access, you will have to mount the drive manually after boot. This obviously impacts the resilience of your application as an unscheduled (or scheduled) reboot requires human intervention to enter the key and mount the volume.

Disk encryption and key management is complex and requires a great deal of planning that deserves its own blog post. Another issue not discussed here is more complex distributed file systems and the impact of encryption on performance.

12. Alert On Application Errors
If you are running an application that is exposed to the Internet you should be logging and alerting on application errors. One of the challenges with application security is that applications hide malice. Meaning that if someone is attacking your application in a subtle way (flipping URL parameters for example) it may not match a signature that your IDS/IPS/HIDS may catch. Or if an attacker makes your application do something out of the ordinary, the application may not generate an exception that is useful or obvious. If a user changes accountID=123 to accountID=124, is that malicious? Will the application tell you that someone is poking around? Since we’re a security company, we worked closely with our developers to build in application errors that tell us when someone is up to no good.

We use the open source Errbit that lets us know when something odd happens with our application. Errbit isn’t a security tool by design but provides valuable and actionable security information. All Errbit errors are forwarded in real-time to our operations folks who can evaluate if it was just a benign, anomalous error or something more sinister. For example, if a user attempts to access an application resource that they do not have access to, we receive notification. We have it tuned so that we only see alerts where  someone intentionally tampers with our application.

13. Internal and External Vulnerability Scanning
We perform regular internal external scanning of our infrastructure using Nessus. For the internal scanning we provide our scanner with an SSH key for authenticated (aka credentialed) scans that allows us to ensure that all devices have up to date patches and are configured properly. For external scanning not only do we scan exposed services for vulnerabilities but we also ensure that our security groups are configured as expected and there aren’t any surprises.

Shearing FireSheep with the Cloud

If your laptop ever connects to a network behind enemy lines (e.g. hhonors, attwifi, panera), this post is for you. The step-by-step directions below allow you to stand up a portable, cloud-based private VPN that you can use from anywhere – for around $0.50 a month. Once you get everything setup, you can feel good connecting to a hotspot and laugh at the guy running FireSheep.


Speaking of Firesheep, I’ve actually had some people close to me (including my wife) ask how they can prevent these types of attacks from happening. There are some nice “off-the-shelf” solutions like HTTPS Everywhere and BlackSheep but as a security professional I wanted to give a recommendation that would provide broader coverage than these solutions.


Enter Amazon’s recently introduced Free Tier for EC2. I’ll save my thoughts and comments on “The Cloud” and security for a later date (and after a couple of beers), but for the purposes of this solution, it works great to help you increase your security while using open wireless networks. Quite simply, the solution I came up with was to create an EC2 instance with Ubuntu 10.04 LTS server and setup OpenVPN and SideStep. This allows me to route all of my traffic over an SSL or SSH VPN to my EC2 instance and then out to the Internet.


To graphically represent what this solution offers, below is a picture of your laptop while surfing on an Open Wi-Fi network such as those at Starbucks.

Your Laptop @ Starbucks

The second image is the guy running Firesheep at Starbucks.

The Guy @ Starbucks Running FireSheep

The last image depicts your laptop running OpenVPN or SideStep at Starbucks.

Your Laptop Armed with OpenVPN or SideStep @ Starbucks

Enough with the ‘Behind Enemy Lines’ comparisons…I swear. I installed other services on my EC2 instance, like Privoxy and iodine (see my post on tunneling traffic via iodine), but for the purpose of this post, I will limit the scope to creating an EC2 instance, installing and configuring OpenVPN, and installing and configuring SideStep.


A couple of notes before we get started. While the instructions that follow utilize Amazon’s Free Tier, this setup will cost you roughly $.50 per month. There are ways to shrink your EC2 ami to fit within the Free Tier’s EBS limit of 10GB, but I will pay around $.50 a month to have this service available to me (the Ubuntu AMI we will use utilizes 15GB of EBS). Thanks to Martin’s post in the comments below, I have updated this post to utilize an 8GB ami, which is less than the 10GB allotted in the free tier for EBS storage.



So let’s get started…


1. If you haven’t already, head over to Amazon EC2 and create an Amazon EC2 account.


2. Once you have created an account, visit the AWS Management Console and click on the ‘Key Pairs’ link on the left side of the screen. Here you will create a Key Pair that will allow you to login to your EC2 instances. Click on the ‘Create Key Pair’ button and name the Key Pair something unique. I chose ‘JustinsAllEC2Key’. Save the file in your ~/Download folders and move it to your ~/.ssh/ folder by issuing the following commands:


Your Mac
jmorehouse@Old-Trafford:~$ cd Downloads
jmorehouse@Old-Trafford:Downloads$ mv JustinsAllEC2Key.pem ~/.ssh/
jmorehouse@Old-Trafford:Downloads$ chmod 400 ~/.ssh/JustinsAllEC2Key.pem


3. Now that you have a key pair, it is time to create and launch an instance. Click on the ‘AMIs’ link on the left side. Then select All Images from the ‘Viewing’ drop-down (it takes a minute to load all of the available instances), and search for ami-4a0df923 ‘ami-3e02f257’. This is an EBS instance of Ubuntu 10.04 LTS Server 64-bit 32-bit from Alestic. EBS allows for persistent storage, so that your setting will remain even when you power-cycle your instance.


4. Select the AMI and then click the ‘Launch’ button at the top. You will be prompted with a number of options, and I recommend using the following:
  • Number of Instances: 1
  • Availability Zone: No Preference
  • Instance Type: Micro
  • Launch Instances
  • Click ‘Continue’


  • Kernel ID: Default
  • RAM Disk ID: Default
  • No Monitoring
  • No User Data
  • Click ‘Continue’


  • Key = ‘Name’
  • Value = ‘Free Tier EC2 Ubuntu 10.04 Instance’
  • Click ‘Continue’


  • Choose from your existing Key Pairs – ‘JustinsAllEC2Key’ -> This is the key you previously created in Step 2 and moved to your ~/.ssh/ folder.
  • Create a new Security Group – ‘InternetAccessible’ -> This akin to a firewall ruleset group. I created a new once called ‘InternetAccessible’, but you can just as simply use and edit the ‘Default’ group.
  • Describe your security group – ‘Services allowed from the Internet’
  • Select ‘SSH’ from the drop-down ‘Applications’ menu -> I left ‘All Internet’ as we want to access this instance from wherever we are on the Internet.
  • Click ‘Add Rule’
  • Select ‘HTTPS’ from the drop-down ‘Applications’ menu -> This will give us access to our OpenVPN server. I also left this open to ‘All Internet’ for the same reason we configured SSH this way.
  • Click ‘Add Rule’
  • Click ‘Continue’


5. You are then be presented with a confirmation page where you should confirm your setting and make any necessary changes. If everything looks good, go ahead and launch your instance.


6. Your instance is now launching. Click on the ‘View your instances on the Instances page’ link to access information about your instance.


7. Now we will assign a static IP address to your instance as Amazon makes this feature available for free (what IPv4 shortage?). Click on the ‘Elastic IPs’ link on the left side. Then click on the ‘Allocate New Address’ button in the center of the page. Click the ‘Yes, Allocate’ button, and then click the checkbox infront of the newly added IP address. We want to associate this IP with your newly created instance. You can do this by now clicking on the ‘Associate’ button at the top. Select the ‘Instance ID’ for the instance you just created (there should be only one Instance ID in the drop-down) and click ‘Associate’. Copy the IP address somewhere handy as we will need it in a couple of minutes.


8. Once you have done this, it’s time to login to your EC2 instance! You can perform this from Terminal using the following:


Your Mac
jmorehouse@Old-Trafford:Downloads$ cd ~
jmorehouse@Old-Trafford:~$ ssh -i ~/.ssh/<filename>.pem ubuntu@IPAddress


9. Type ‘yes’ to accept the RSA key fingerprint and you should see something akin to the following:

Linux ec2 2.6.32-309-ec2 #18-Ubuntu SMP Mon Oct 18 21:00:50 UTC 2010 x86_64 GNU/Linux
Ubuntu 10.04.1 LTS

Welcome to Ubuntu!
* Documentation:

System information as of Fri Dec 3 00:40:20 UTC 2010

System load: 0.0 Processes: 60
Usage of /: 6.2% of 14.76GB Users logged in: 1
Memory usage: 6% IP address for eth0: 10.XX.XX.XX
Swap usage: 0% IP address for tun0: 10.X.XX.X

Graph this data and manage this system at
At the moment, only the core of the system is installed. To tune the
system to your needs, you can choose to install one or more
predefined collections of software by running the following

sudo tasksel –section server

14 packages can be updated.
4 updates are security updates.

Last login: Thu Dec 2 23:22:38 2010 from

10. At this point you want to perform some hardening and maintenance on the box.


Update passwords
EC2 Instance
ubuntu@ec2:~$ sudo su -
ubuntu@ec2:~$ passwd ubuntu

(Enter in a new password for the ‘ubuntu’ account. This is the default account on your EC2 instance. I recommend storing these passwords in KeePassX)

ubuntu@ec2:~$ passwd

(Enter in a new password for the ‘root’ account. This account should be need no explanation.)


Update packages
EC2 Instance
ubuntu@ec2:~$ exit
ubuntu@ec2:~$ sudo apt-get update

(This updates the list of known packages.)

ubuntu@ec2:~$ sudo apt-get upgrade -y

(This upgrades the installed packages to their latest version.)


If you are prompted for grub-pc config update, just hit enter. Also select ‘Yes’ at the next Grub message window.


Time Zone
EC2 Instance
ubuntu@ec2:~$ sudo dpkg-reconfigure tzdata


Follow the instructions to setup the proper timezone information for your EC2 instance.


ubuntu@ec2:~$ sudo reboot now

(This will reboot the sytem. Wait about 2 minutes before you try and reconnect to the EC2 instance via Terminal using the above ssh command.)


11. At this point I setup a host record for my EC2 instance so that I could use DNS to access it. I also configured the hostname on the system to match the DNS record. This is an optional step, and if you aren’t sure what I am talking about or aren’t sure how to do it, don’t worry about it.


12. Now that we have our EC2 instance configured and ready to go, it is time to install and configure OpenVPN. To install OpenVPN on your EC2 instance, simply type the following from within your SSH session:


EC2 Instance
ubuntu@ec2:~$ sudo apt-get -y install openvpn libssl-dev openssl


13. Now we need to create the certificates to use with OpenVPN. First let’s copy the easy-rsa tool to the OpenVPN folder.


EC2 Instance
ubuntu@ec2:~$ cd /etc/openvpn/
ubuntu@ec2:/etc/openvpn$ sudo mkdir easy-rsa
ubuntu@ec2:/etc/openvpn$ sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
ubuntu@ec2:/etc/openvpn$ sudo chown -R $USER /etc/openvpn/easy-rsa/
ubuntu@ec2:/etc/openvpn$ cd /etc/openvpn/easy-rsa/


14. We now need to edit the ‘vars’ file to provide some information for our SSL certificates. You will need to know how to use the ‘vi’ text editor. If you don’t know how to use it, I recommend this tutorial.


EC2 Instance
ubuntu@ec2:/etc/openvpn/easy-rsa$ sudo vi vars


Change export ‘KEY_SIZE=1024’ to ‘export KEY_SIZE=2048’
Change export KEY_COUNTRY=”US” to your country.
Change export KEY_PROVINCE=”CA” to your state. I.e. ‘KEY_PROVINCE=”FL”‘
Change export KEY_CITY=”SanFrancisco” to your city. I.e. ‘KEY_CITY=”Tampa”‘
Change export KEY_ORG=”Fort-Funston” to your organization or something else. I did my family (‘KEY_ORG:”Morehouse-Family”‘)
Change export KEY_EMAIL=”me@myhost.mydomain” to your email address.


Save the file by hitting the ‘ESC’ key and then typing ‘:wq’ and press enter.


ubuntu@ec2:/etc/openvpn/easy-rsa$ source vars
ubuntu@ec2:/etc/openvpn/easy-rsa$ ./clean-all
ubuntu@ec2:/etc/openvpn/easy-rsa$ source vars
ubuntu@ec2:/etc/openvpn/easy-rsa$ ./build-ca


You should be prompted for the following. You can hit ‘enter’ to keep the default value you already setup by editing the ‘vars’ file.


Country Name (2 letter code) [US]:
State or Province Name (full name) [FL]:
Locality Name (eg, city) [Tampa]:
Organization Name (eg, company) [Morehouse-Family]:
Organizational Unit Name (eg, section) []:Personal
Common Name (eg, your name or your server’s hostname) []: -> Enter your hostname here if you created a DNS record. Otherwise enter your EC2’s Elastic IP address from Step 7.
Name []:Justin Morehouse
Email Address []:


Now execute the following commands:


ubuntu@ec2:/etc/openvpn/easy-rsa$ ./build-dh

(This takes some time. Like 2 minutes.)

ubuntu@ec2:/etc/openvpn/easy-rsa$ source vars
ubuntu@ec2:/etc/openvpn/easy-rsa$ ./pkitool --server server
ubuntu@ec2:/etc/openvpn/easy-rsa$ cd keys
ubuntu@ec2:/etc/openvpn/easy-rsa/keys$ openvpn --genkey --secret ta.key
ubuntu@ec2:/etc/openvpn/easy-rsa/keys$ sudo cp server.crt server.key ca.crt dh2048.pem ta.key /etc/openvpn/


15. Now we have created the CA and Server certificates. Now we need to create keys for our users. For the purpose of this blog, we will create one key for one user. You can repeat this step for each additional user you wish to allow to access your OpenVPN server.


EC2 Instance
ubuntu@ec2:/etc/openvpn/easy-rsa/keys$ cd..
ubuntu@ec2:/etc/openvpn/easy-rsa$ source vars
ubuntu@ec2:/etc/openvpn/easy-rsa$ ./pkitool <yourname>

(I typed ‘./pkitool justin’)

ubuntu@ec2:/etc/openvpn/easy-rsa$ cd ..


16. Now we need to create an archive to download all of the necessary files from the server to the system you want to configure to use OpenVPN (Your laptop). I recommend using Cyberduck to access the .tar file we create. Remember to use your EC2 key to login with Cyberduck. It is the key we created in Step 2 and stored in your ~/.ssh/ folder (JustinsAllEC2Key.pem). Remember, the keys.tar file will be located in the /etc/openvpn/ directory. Download the keys.tar file to your Downloads directory.


EC2 Instance
ubuntu@ec2:/etc/openvpn$ sudo tar czf keys.tgz ca.crt ta.key easy-rsa/keys/<em>yourname.crt</em> easy-rsa/keys/<em>yourname.key</em>


17. Now it’s time to configure your OpenVPN server. You can most likely use the pre-configured template I posted online. It uses the IP address scheme of for VPN clients, so unless you are using that network somewhere else, you don’t need to change a thing in the configuration. If you do need to edit the network, you can download the server.conf file here or issue the commands below and use vi to edit it as you would like. Use the commands below to download the server.conf file to the /etc/openvpn folder on your EC2 instance.


EC2 Instance
ubuntu@ec2:/etc/openvpn$ sudo wget


18. Now we have to setup ip forwarding on your EC2 instance. We’ll use sudo to perform these commands.


EC2 Instance
ubuntu@ec2:~$ sudo su -
root@ec2:~$ modprobe iptable_nat
root@ec2:~$ echo 1 &gt; /proc/sys/net/ipv4/ip_forward
root@ec2:~$ iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
root@ec2:~$ iptables-save &gt; /etc/iptables.conf
root@ec2:~$ echo '#!/bin/sh' &gt; /etc/network/if-up.d/iptables
root@ec2:~$ echo "iptables-restore &lt; /etc/iptables.conf" &gt;&gt; /etc/network/if-up.d/iptables
root@ec2:~$ chmod +x /etc/network/if-up.d/iptables
root@ec2:~$ echo "net.ipv4.ip_forward=1" &gt;&gt; /etc/sysctl.conf
root@ec2:~$ reboot now


19. Back on your Mac, download and install Tunnelblick. It is is a free, open source Graphic User Interface (GUI) for OpenVPN on Mac OS X. You can download the latest stable version from here.


20. Once you have installed Tunnel blick, go do your ‘Downloads’ folder and extract your keys.tar files. Copy the ca.crt, ta.key, <yourname>.crt, and <yourname.key> files from the extracted .tar file to the Tunnelblick directory located at ‘~/Library/Application\ Support/Tunnelblick/Configurations/‘. (<yourname>.crt and <yourname.key> will be in the ‘easy-rsa/keys’ folder. Make sure all of the extracted files are in the ‘~/Library/Application\ Support/Tunnelblick/Configurations/‘ folder!)


21. You will now need to edit the client template that I have posted here. Download the file to ‘~/Library/Application\ Support/Tunnelblick/Configurations/‘ and edit the following three items:
  • Line 42: Change ‘<IP or hostname>’ to your EC2 instance’s IP address, from Step 7, or the DNS name you gave it.
  • Lines 89 & 90: Change cert <yourname>.crt & key <yourname>.key to the names of the .crt and .key files you extracted from the keys.tar file. This the client certificate you created for yourself in Step 15.
22. Once this is done, open up a web browser and go to IP Chicken. Obesrve your current source IP address. Then open Tunnelblick and from the menu bar at the top, select Connect ‘ec2’. Reload your browser and notice that you now have a source IP address of your EC2 instance! Congratulations on getting OpenVPN on an EC2 instance setup. Now let’s setup SideStep.


23. While Tunnelblick allows you to create an on-demand SSL tunnel to proxy all of your network traffic through your EC2 instance (for both wired and wireless) networks, SideStep takes the guess work out of when to use a proxy to secure your network when you are on an open wireless network (it currently only works on wireless networks, but Chetan is going add the capability to use it on an wired network as well). First download and install SideStep.


24. SideStep uses passwords or keys to create an on-demand SSH tunnel that proxies your traffic. As our EC2 instance doesn’t allow for password logins via SSH, we need to create a new keypair to use with SideStep. Using Terminal on your Mac, issue the following commands:


Your Mac
jmorehouse@Old-Trafford:~$ cd ~
jmorehouse@Old-Trafford:~$ ssh-keygen -t rsa -f ~/.ssh/id_ec2


Enter in a passphrase twice, and store it some place safe (KeePassX) because you will need it later.


jmorehouse@Old-Trafford:~$ scp -i .ssh/JustinsAllEC2Key.pem .ssh/ ubuntu@IP:~/.ssh/

(Key created in Step 2 and IP address from Step 7.)


25. Still within Terminal, log back into your EC2 instance and append the public key to your authorized_keys file.


Your Mac
jmorehouse@Old-Trafford:~$ cd ~
jmorehouse@Old-Trafford:~$ ssh -i ~/.ssh/&lt;filename&gt;.pem ubuntu@IPAddress

(Key created in Step 2 and IP address from Step 7.)


EC2 Instance
ubuntu@ec2:~$ cd .ssh/
ubuntu@ec2:~/.ssh/$ cat &gt;&gt; authorized_keys
ubuntu@ec2:~/.ssh/$ chmod 640 authorized_keys
ubuntu@ec2:~/.ssh/$ exit


26. Now we need OSX to prompt us for the passphrase for the id_ec2 key, so from Terminal, enter the following:


Your Mac
jmorehouse@Old-Trafford:~$ cd ~
jmorehouse@Old-Trafford:~$ ssh -i .ssh/id_ec2 ubuntu@IP


You should be prompted for a password. Check the save the password to your Key Chain and hit ok. You should now have an SSH session to your EC2 box using your new key. You can go ahead and exit from your SSH session and close out all of your Terminal sessions and quit the Terminal application.


27. Now fire up SideStep and click the ‘Next’ button. Under ‘I already have one’ enter ‘ubuntu’ as the Username, your IP address from Step 7 as the hostname, and press ‘Test Connection to Server.’ You should receive a ‘Connection to server succeeded!’ message. Now click the ‘Next’ button. Read the notes and check the box that reads ‘Run SideStep on login.’ Click ‘Finish.’


28. SideStep is now on the menu bar next to Tunnelblick. I added Tunnelblick to my login items so that it is launched when I boot. Understand the differences between these two tools (Tunnelblick and SideStep) and when to use each.


Congratulations! If you made it this far, pat yourself on the back. This was a long tutorial, but it should work if you followed each step. If you have any problems, hit me up on Twitter (@Mascasa).


Enjoy surfing open wireless networks or hostile wired network securely!