Cloud Computing on Ulitzer

In this post I will walk you through the  high level  of securing a normal tiered application running on EC2. First I will cover the basics of what EC2 provides and then briefly discuss how this can be used in a real life 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 does not support port ranges for security groups 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

Read the original blog entry...