AWS for beginners - Security Groups

Each EC2 instance must be protected by a security group, AWS doesn’t even let us create new instances without it.

1. What is a security group?

A security group (SG) is a virtual firewall, which protects the EC2 instance by only allowing configured traffic to reach and leave the instance. They play an important role in keeping the instance secure and protecting them from unwanted traffic.

Security groups provide instance level security, as opposed to the Network Access Control Lists (Network ACL), which protect the whole subnet, where multiple EC2 instances may reside.

2. SGs operate by rules

SGs can be configured to allow specific traffic to and from the instance. If a traffic type on a specific port is not explicitly allowed (i.e. not configured in the SG inbound and outbound rules section), it can’t reach or leave the instance.

This principle is called implicit deny. It’s impossible to explicitly deny traffic i.e. we can only allow traffic by configuration.

Security groups can be created and configured when an EC2 instance is launched and it’s also possible to create a custom SG separately and assign the custom it to one or more instances.

2.1. Inbound rules

A SG contains a set of inbound and outbound rules.

Inbound rules decide what traffic can reach the instance. They contain the type, port (specific or range) and the source of the traffic. The source can be a CIDR block (a range of IP addresses), a specific IP address (in CIDR form) or the ID of another security group in the VPC. With this, it will be clear what traffic comes and from where.

2.2 Outbound rules

Outbound rules govern that traffic that leaves the instance. We also need to define the type, port or port range and the destination of the traffic. The destination can also be an IP address, a range of addresses or a security group ID.

3. Instances must have SGs assigned

AWS emphasise security, and therefore it’s impossible to launch an instance without a SG assigned. Each EC2 instance must have a SG attached, and one particular SG can be attached to multiple instances. If nothing is assigned to the instance, AWS will attach the default SG to it.

4. Default and custom SGs

When a VPC (a virtual environment belonging to a customer where they can launch their application) is created, a default security group will also be created. It doesn’t matter if it’s a VPC that AWS generates for us when an account is created or we establish a new VPC, the default SG will always be there.

Of course, we don’t have to accept the default SG, and we can create custom SGs as well. Both the default and custom SGs come with their own basic set of rules.

4.1. Default SG

Default SGs allow all traffic from any instances that are assigned the same SG.

Look at the ID of the security group on the top and in the source column, they are the same.

On the outbound side, the default SG will allow all traffic on all port to any address.

The 0.0.0.0/0 CIDR block refers to the default route, and it specifies all networks.

The default security group cannot be deleted from the Actions menu in the Console, only if the VPC itself is deleted.

4.2. Custom SG

Custom SGs (the ones we create by clicking on the Create security group button in the AWS Console) come with slightly different configuration.

They don’t have any inbound rules defined, i.e. the implicit deny rule applies, which means that no incoming traffic is allowed. In most cases, this is not good for our purposes, and inbound rules are added to the configuration list.

The default outbound rule of the custom SG is the same as the default SG’s, i.e. all traffic is allowed.

5. Security groups are stateful

Let’s say we have an EC2 instance, a web server, for example.

If we want the web server to reach the internet, we can configure HTTP and HTTPS on the outbound side.

The destination is the internet (0.0.0.0/0) on ports 80 and 443, so far so good.

When the outbound traffic is enabled to a particular destination, the reply traffic is automatically allowed, regardless of the inbound configuration. This means that there’s no need to configure the response traffic on the inbound side, the response will reach the instance.

This feature of the SGs is called being stateful. When one direction (can be inbound or outbound) is allowed, the response will also be allowed without extra configuration.

As a result we don’t need any additional configuration on the SG of the instance if we want it to reach the internet.

Being stateful doesn’t mean though that the web server can be reached from the internet. Request and response are bundled together. Being stateful means that if the request from the instance is allowed, the corresponding response to that request will be allowed, but a request to the instance will not. This traffic needs to be separately configured in the inbound section of the instance’s SG.

6. Main rules

Some configuration rules occur more frequently than others.

The above picture shows the HTTP (port 80) and HTTPS (port 443) configurations from an instance to the internet.

It’s often a requirement to use SSH to securely log on to the instance. In order to enable this traffic, an inbound rule on port 22 should be allowed:

The source CIDR block (which is made up in this example) is the IP address range of the premise from where the user wants to log in (home or real office). Again, SGs are stateful, and the response traffic is automatically allowed.

It can also happen that we have to check if some instances can communicate to each other. In this case, the ICMP ping rule should be configured:

The request to instance A from another instance (let’s call it instance B, located in the subnet with CIDR 10.1.1.0/24) is configured as an inbound rule. The port range is N/A, and this part is automatically filled by the AWS platform.

As SGs are stateful, the Echo Reply (the response traffic to the ping request) from A to B doesn’t need to be configured on the outbound side.

But, in order to test if A is able to connect to B (the one in the 10.1.1.0/24 subnet) i.e. A can initiate the communication, the Echo Request needs to be configured on the outbound side of instance A.

7. Conclusion

Security groups are compulsory accessories of any EC2 instances, and they act as a firewall at the instance level.

They don’t have deny rules, only allow rules. If a specific type of traffic is not allowed explicitly by configuration, then it’s implicitly denied.

SGs are also stateful, which means that if traffic on one side (inbound or outbound) is allowed, the response traffic is also allowed, regardless of the configuration on the other side.

Thanks for reading and see you next time.