Collaboration

Patching all the gaps: Securing Amazon EC2

Nick Hardiman tackles the security issue with his new Amazon EC2 machine. Now that he's ready to start uploading and storing sensitive data, it's time to batten down the hatches.

I don't want anyone to abuse my new EC2 machine so I must put in a little work on Internet security. I am not going to do anything clever like implement security-as-a-service, protect against DDOS attacks or escape cross-site scripting. I am going to make a few basic updates to begin.

Everyone knows the Internet is full of hackers, right? I must secure my server. However, a hacker (malicious or otherwise) may be internal to my organization, not external. Most security problems come from within the enterprise, not from the Internet. I must examine the client end, the server, and the network in between.

There is a continuous flow of software updates patching security holes. Internet security has been big business since the Morris Worm scared the pants off everyone in the 1980s. Bugtraq mailing list contributors, organizations like US-CERT (United States Computer Emergency Readiness Team), and the ISC (Internet Storm Center) help find security vulnerabilities, collect information on how they are being exploited, and help get them fixed.

Secure the client end

I have three clients to examine. I can control my instance from my desktop computer, my laptop, and my phone. (Curiously, almost half of iPhone users do not consider updating their software a priority. I wonder what changed the minds of the other half.)

I have taken several security precautions to secure my end. First, my Amazon account password cannot be easily guessed by a password cracking tool, and I have not written it on a Post-it stuck to my screen.

My SSH session uses key-based authentication for login but it's no good having a strong lock if an employee stole the key. Even if someone has copied my key file, it is encrypted and useless to them. Cryptologists are so rare I don't worry about key cracking.

Both the console and the SSH session are wide open when I am using them. If I leave myself logged into the AWS console, forget to lock my screen and go to the toilet, my disgruntled colleague can damage all my machines and my career.

Secure the network

No network changes are required. My Internet conversations, between my web browser and the AWS server and between PuTTY and the SSH server, are encrypted. I am not vulnerable to man-in-the-middle attacks.

At the Amazon end, most paths to the server are blocked by my Security Group. Only a few TCP ports are open.

Secure the server end

My brand new EC2 machine is out of date. Old software is likely to be frail, confused, unwell, and generally vulnerable. The Amazon AMI I copied was made a few months ago and many software updates have been made since then. Some AMIs are a couple years old - these should not be used.

I need to update software to patch software vulnerabilities. This process is made easy by the yum package manager.

Update software

The software updates I am interested in are not updates to add features or support new hardware - they are updates to remove security vulnerabilities and fix broken stuff.

Computers are the most complicated machines made by man - mistakes are made all the way through the design and build. If I patch each vulnerability as soon as it is found and fixed, I should be able to stay a step ahead of the automated exploit tools that regularly probe my public services.

Programmers fix an application, create a package from the updated files and distribute the update package to Amazon's "amzn-updates" security and maintenance repository.

Patch vulnerabilities using yum

My EC2 machine tells me how many of these update packages are available every time I log in.

...
       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|
See /usr/share/doc/system-release/ for latest release notes.
There are 13 total update(s) available
[ec2-user@ip-1-2-3-4 ~]$

The image version implies it was made in September.

[ec2-user@ip-1-2-3-4 ~]$ grep image_version /etc/image-id
image_version="2011.09"
[ec2-user@ip-1-2-3-4 ~]$

So between September and now, thirteen of the hundreds of packages installed on my EC2 machine have been updated. The commands sudo yum list updates and sudo yum list installed also give me these numbers.

Patching the holes in my new EC2 machine is a manual process. The YUM package manager does most of the work, fetching all available update packages and installing them.

[ec2-user@ip-1-2-3-4 ~]$ sudo yum update
Loaded plugins: fastestmirror, priorities, security, update-motd
Loading mirror speeds from cached hostfile
 * amzn-main: packages.eu-west-1.amazonaws.com
...
Upgrade      13 Package(s)
Total download size: 13 M
Is this ok [y/N]:

The whole process takes seconds.

Server work for the future

I must do more work before my first customer service goes live.

My storage will need to be secure. None of the data on my server is encrypted. It does not yet need to be: I have not copied any sensitive information to the server. When I do, I will have to protect it with encryption tools.

My business applications will need to be secure. I don't want poor coding or bad configuration to introduce more vulnerabilities. Of course, no vulnerability will make it past QA, right?

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

8 comments
Ariel Rivera
Ariel Rivera

About your statement that stealing EC2's key file would be useless. I just tested moving my EC2 key file to a different machine, then I tried connecting ( ssh -i keyfile.pem ) to my EC2 instance using it from that other machine, and it worked without problems. This confirms that If someone steals my key file, they can successfully use it. I would like to know If there's something I need to do to prevent this from appening..??

Michael Kassner
Michael Kassner

I would like to know how you are sure enough to make this statement: " I am not vulnerable to man-in-the-middle attacks."

Nick Hardiman
Nick Hardiman

Here's an example of a man-in-the-middle as someone at my ISP, with his laptop plugged into a network switch. He's not blocked by firewalls and he's not missing any IP packets. He's copied all the traffic and stored all the conversations. What can he do with my session? He can add a load of garbage, but can't hijack my conversation, or inject anything meaningful. he can't even read the requests and responses - the public cipher and symmetric cipher encryption are ridiculously hard to crack. What else is he going to do?

Nick Hardiman
Nick Hardiman

I may be more protected than you assume. What am I missing? What is your illustration? No-one has all the answers - we all need to work together to make the Internet the repository of human knowledge in the 21st century. I am happy to listen to what you have to say.

Michael Kassner
Michael Kassner

Any ISP and .gov could intervene. You are not as protected as you assume.

Nick Hardiman
Nick Hardiman

Hi Michael, I read it, excellent post. But it's about firewalls. My theoretical man in the middle is not being blocked by any firewall.