About this blog

'Going Spatial' is my personal blog, the views on this site are entirely my own and should in no way be attributed to anyone else or as the opinion of any organisation.

My tweets on GIS, Humanitarian, Tech, Games and Randomness

Tuesday 30 April 2013

AWS Security Groups to allow all ELB traffic

Sometimes, working with computers - only a facepalm will do....
Really enjoying using AWS at the moment as it's made thing so much easier and quicker for me and my team to deploy cool application and data, quickly, reliable and efficiently.

However it is not without it's bugs and 'tear-my-hair-out' moments. I was going through and reviewing our current Security Groups. One of the things I wanted was to be able to only allow traffic from an attached elastic load balancer (ELB) and nothing else to the attached instances.

A quick reminder is probably required: one can have a standalone instance with an associated security group (SG) controlling access, as soon as an instance is 'spun' up. It is assigned a public DNS which one can use to access it over the internet. You can also resolve this hostname to an IP address but this might change over time. It is always best to use the public DNS. 

An AWS security group is essentially, a firewall. It restricts access to ports on an instance according to a number of rules: which port it is, protocol and source address. With sensible settings you can configure the security group to allow only Remote Desktop connections from a certain IP range for example. All instances need a security group.

Sometimes, I imagine a firewall to be more than just a bit of software....a firewall ROBOT!

This is great but it can get complicated when you add an AWS Elastic Load Balancer (ELB) to the mix. 

The AWS ELB has it's 'listeners' that are incoming ports with a matching outgoing port. At its simplest it acts like a proxy. It sits in front of your EC2 instance.

Now, if you have allowed port 80 (http) on your SG, you will probably need port 80 opened on the ELB and have it mapped to port 80 on the appropriate security group. This actually allows two things to happen: internet access via port 80 is allowed through the firewall or directly to the instance itself. The latter option, in effect, by-passing the ELB you have just set up. This may or may not be a desireable outcome.

Similarly, if you have a port open ONLY on the security group (say port 21 for FTP) and not the corresponding ELB; then access can only be through a direct connection to the instance and not through the ELB.

Again, this may or may not be a desireable outcome.

So, you need to be sure that things are consistent. However, you can get easily bogged down with too many security groups and ports open/closed. Wouldn't it be nice to configure the ELB and then set it so that the attach instances allow the ELB to talk to it on whatever ports it has been configured? Sort of like inheriting the permissions?

Well, it is NOT at all obvious what you need to do to configure your Security Group to support this very commonly desired configuration.

Well you can you know.  Let me show you.

Very useful

Use the not-so-documented 'amazon-elb/amazon-elb-sg' Security Group name as the Inbound Source for your Security Group rule to filter on traffic coming from your AWS ELB ONLY.

What this means is that, your SG now allows any traffic from an attached ELB. No other rules need to apply. You just need to configure the ELB (for example, HTTP on port 80) and your SG will allow this through to your instance without the need to pop the relevant port 80 into the SG group. It has been done by the ELB security group.

Of course you can be a bit more elegant:

Allow only port 80 and 442 on the ELB. This will allow ONLY traffic on port 80 & 443 on the ELB to be accepted by the instance. However, you can then add additional rules to your EC2 specific SG, such as port 3389 for remote desktop. This means, RDP can only be accessed if one goes directly to the instance, to further secure it, add an IP restriction to the source.