AWS: A Security group primer

AWS Security at the network level.

AWS is the largest cloud vendor. They handle large workloads and each customer can have one or more accounts that are made up of many servers and AWS-specific and open-source services. Across each of these mixes of entities, there is a common fabric that links them all: networking.

Networking allows all entities to talk to each other and to the wider open internet so that end users can interact with the servers and services to send and receive data. This enables things like apps that help you order food online, or allow you to pick up a course on drawing, and much more.

With the widerange of possibilities, also come the risks. Bad actors are everywhere, and ensuring that only authorized users can use the service is only half the challenge. Organizations and people delivering these services have to ensure that they are safe from attacks on the network directly. To ensure that the user's data and the other mission critical systems are not overwhelmed or attacked.

The good news is AWS has already thought about this. And they have a provided a host of tools that allow your org to correctly setup good networking security rules in place so that attacks can be stopped at the network layer itself. This is done by different cloud security offerings. While this list is exapansive, we will be focusing our attention on the most widely used entities.

 Security Groups

Currently, AWS provides firewalls in the form of security groups that are applied to a specific virtual cloud known as a VPC.

Security group can be thought of as a set of rules that allow or deny traffic. The SG is then attached to any AWS entity that uses an Elastic network interface. This includes DB instances, VMs, Load balancers, and more. Each SG is associated with only one VPC, and if you need multiple SGs that have the same rules, you have to create multiple groups with the same set of rules.

A security group's rule is made up of an ingress and egress section, network protocol, and description. Each section be it ingress of egress can contain either CIDR blocks, other security groups, or prefix lists. These dictate from where the traffic is allowed to come in or go out to.

By default, when a new SG is created, there are no rules. So the group if attached, will block all incoming and outgoing traffic.

Usually, this is not desired, and the preferred plan of action is to add one or more rules to allow traffic to come in (ingress rules) or go out (egress rules).

Security Group rules

Diving deeper into an SG's rules, there are 3 main takeaways:

• Open only ports that are strictly required.
•  Don't use broad CIDRs like 0.0.0.0/0 (open to all internet), or privately broad CIDRs like 10.0.0.0/8 (open in the 10. x.x.x range)
  
•  Limit egress to known ports and IP ranges.
  

Let us examine each takeaway in more depth.

1. Open only ports that are strictly required.

When creating an SG, try to keep specific ports open for the purpose of the SG. For example, if the SG is being created for use on a DB like MySQL, open only port 3306, and no other ports.

Likewise, if the SG is being attached to a VM, open ports 22, 80 and 443 but ensure that 22 (ssh) is open only on internal

CIDR ranges.

2. Don't use broad CIDRs.

This is a very important takeaway. CIDR ranges is what determine what source IPs can access your system. If you open port 22 (ssh) on 0.0.0.0/0 then the entire world will be able to login to your server. This is a bad idea even if your server is up to date and patched regularly because attackers might gain access to the legitimate SSH keys or brute force their way in.

Instead, pick a CIDR range that is private to the VPC so that only authorized personnel can log in.

The second takeaway is that don't use too broad internal CIDRs as well. Just because your service is accessible inside a VPC, does not guarantee absolute safety. Limit the use of IP ranges internally as well and use proven strategies like allowing traffic only from load balancers or bastion hosts.

3. Limit egress to know ports and IPs.

A server does not need to be able to contact the entire internet. It is not a personal computer. Servers are built to run only specific software and should not be allowed to contact the internet willy-nilly. This ensures a sort of last-line defense, where if an attacker does make it past all defenses, they cannot phone home, and install malware that allows a takeover of the machine.

This is a very hard rule to establish, and often times, its overlooked but keeping a list of IPs and ports the server is set up to contact and blocking everything else is the best possible defense stratagem.

With these 3 key takeaways, your cloud security should be greatly improved, and the chances of an attack significantly reduced. However, oftentimes, the number of security groups that are in use or the VMs and DBs in use are so large and

AWS networks are so large , that it is very hard to ensure a secure environment. In these situations you can use tools like  the gearsec EC2 guard to scan and generate recommendations for updating security group associations. These can then beapplied automatically, or tracked via task management software like JIRA, to ensure that the environment is fully secure.

In the next following posts we will cover how to setup a secure VPC, and allocate subnets to create workloads that are secure out of the box.