- First read the Amazon Security Whitepaper and the Amazon discussion of Security processes

- Ensure the system key is encrypted at start-up

- Ensure you plan for load balancing in case an instance goes down. Ensure you understand all the security implications of this and harden any other instances.

- Test or emulate the performance of applications deployed to the cloud in all geographies where you plan to deploy them. The latency could vary greatly for each.

- Never ever allow password base authentication for shell access.

- Encrypt all network traffic always.

- Always encrypt everything stored on S3

- Encrypt file systems for Block devices

- Open only the minimum required ports

- Include no authentication information in any AMI images

- Think about how your system can be hardened and what is out there such as SELinux, PAX,  ExecShield etc

- Don’t allows any decryption keys into the cloud – understand the perils of keys and security

- Install host based intrusion detection system such as OSSEC

- Regularly backup Amazon instances and store them securely. 

- Use Security Groups. With EC2 security groups, you can completely isolate every tier, even internally to the EC2 cloud.

- Design in a way you can issue security patches to AMI instances

The nightmare scenario that you cannot cater for is is that Xen has unforeseen security issues which would allow inter-VM communication and which in essence would enable instance spying. Amazons doomsday scenario…..

Security Groups

For Network security EC2 provides a security groups, security groups are essentially inbound firewalls  suited to the dynamic nature of EC2.  Using security groups you can specify which incoming network traffic should be delivered to your instance.

• The default mode is to deny access, you have to explicitly open ports to allow for inbound network traffic

• If no security group is specified a special default group is assigned to the instance. This group allows all network traffic from other members of this group and discards traffic from other IP addresses and groups. You can change settings for this group

• You can assign multiple security groups to an AMI instance.

• The security groups for an instance are set at launch time and can not be changed. You can dynamically modify the rules in a security group and the new rules are automatically enforced for all running and future instance, there may be a small delay depending on the number of instances

• You can control access either from  named security groups or source IP address range. You can specify the protocol(TCP, UDP, or ICMP) , individual ports or port range to open
• You can allow access to other users security groups using user-group pair

• The current API (Amazon EC2 on 2008-12-17) does not support port ranges for security group using command line tools or Query API, you will need to use SOAP API

• An account can have a maximum of 100 security groups

• Security groups are just access rules applied to a single or collection of instances, if two instances are part of the same security group this does not afford them any special access between them.

• An instance running in promiscuous can not sniff any traffic intended for a different instance.
• A running instance cannot change security group access rules. You need access keys or X 509 key to authorize change.

• In the instance you can get the security group information from the instance meta-data (curl http://169.254.169.254/1.0/meta-data/security-groups)

Key Pair

Amazon discourages the use of passwords and the normal way to access an instance is using ssh and a private key. Amazon EC2 provides facilities to generate the key(2048 bit RSA key), at instance startup you can attach the key name to the instance and this will allow root access. Normally you will customize the AMI with your own less privileged user public keys and disable root login

Securing Your Application

Now that we have covered the basics how can we use these to secure a distributed application. Below is the normal deployment architecture for a typical tiered application.

In the above deployment we have created 4 security groups

Web-Security group: Allows http (80) and https(443) to everyone to access the application

App security group: Only allows access from instances running in web security group on required ports e.g. 8080

DB security group : Only allows access from instances running in app security group on required ports e.g. 3306

ssh-admin security group: Only allows access to ssh port 22 and as a matter of policy access is allowed from specific host address or organization network. This allows easy management of permissions.

As you can start an instance with multiple security groups the web tier instances will run with web and ssh-admin security groups, app server instances with app and ssh-admin and finally database instances with db and ssh-admin.

You will not need to change web, app or db security groups, The cloud administrator will allow or revoke admin access by  just adding or removing hosts from ssh-admin group with port 22 access. You can write scripts or use any GUI (Elasticfox, Amazon admin console) tool


Other Best practices

• Make secure requests to Amazon Web Services see
• Restrict ssh port(22) access to  host or organization network
• You can and are encouraged by amazon to use an other firewall (e.g iptables) in conjunction with security groups  on an instance to restrict inbound/outbound traffic and have finer control
• Dont open any port unnecessarily
• Have separate application administrator (ssh access to instances) and cloud administrator(setting up security groups and key-pair generation with access to amazon EC2 certificate and access keys but no ssh access to running instances)
• Disable password based login( set PasswordAuthentication no in /etc/ssh/sshd_config) see
• Customize the AMI with your own user public keys and disable root login. If you need root login use sudo see
• Keep your AMI up-to-date with security patches and fixes

At Jana, we specialise in Cloud Computing and are available for Cloud implementations or Cloud advisory services. Please contact us for more details