Prerequisites

• Have either completed the Build a VPC with IaC lab, or understand how to use the CloudFormation template in that post.

The Lesson

Way back when I started on AWS, before IAM or VPCs, I encountered a feature which fundamentally changed how I thought about cloud security and the possibilities of network security.

Yeah, the title gives it away: we’re talking about Security Groups.

To understand why they are so cool and powerful I need to cover some quick firewall basics. The job of a firewall is simple: filter network traffic according to rules. Why? Because we all have a lot of things running on our systems and they’ve been under constant attack since the first cave person opened up one of those AOL CDs that kept falling out of the trees. Firewalls help protect us from network attacks. Mostly we put them between us and the Internet, and sometimes we put them inside our networks to reduce the “blast radius” of an internal compromise.

Outside of cloud (although they definitely also work in cloud) we have two main kinds of firewalls:

• Network firewalls are dedicated hardware or virtual machines.

• Host-based firewalls are software running on a system. If you are on Mac, Windows, or even most flavors of Linux, you are running a host firewall by default.

Let’s start with a quick overview of how they work. With a physical or appliance firewall, we typically route inbound traffic to a subnet through the firewall for filtering. It allows or denies traffic heading to the subnet based on its rules. The firewall doesn’t filter any of the traffic inside the subnet — just traffic from the outside to things on the inside. Remember, in a physical network there is an actual bundle of ‘external’ wires running into the box, and a different bundle of ‘internal’ wires running to the subnet. (Yes, modern systems have more to them, but largely this is how people still deploy).

In contrast, a host firewall runs on a system receiving the traffic, and filters in software. I’m currently running two different ones on this Mac: the one built into the operating system, and a more robust one installed as a background application.

Modern firewalls, called Next Generation Firewalls (NGFWs), do a lot more than basic connection filtering, and often capture all traffic to analyze it for attack patterns.

But there are limitations:

• Network firewalls require all traffic to be routed through them, and due to cost and complexity are usually only put in strategic locations. They are rarely configured to filter point-to-point traffic within a subnet, and can only do that if all the wires route through them.

• Host firewalls are more granular, and protect individual systems, but that makes them harder to manage at scale, and if an attacker does find a way in, they can just turn them off.

Firewalls use rules to decide what traffic to allow or block. These rules are usually made up of 5 tuples (a fancy word for “fields”). Here’s one to block SSH to a subnet:

The Magic of Security Groups

Security groups are different at each cloud provider, but here’s how they work in AWS:

• A security group is basically a container for rules, more of a policy than a device.

• Security groups deny all traffic by default, and only support allow rules.

• A rule includes 3 items (in addition to its ID): source, protocol, and port. They always allow, and anything not in a rule is denied. You can’t build a specific deny rule.

• We apply security groups to resources (technically a network interface when there is one). So we build a security group, run an instance, and tell the instance to use the security group. The rules are enforced at the individual resource level.

  • Each resource in a VPC must have a security group.

• Security groups can reference other security groups. Instead of putting 10.0.3.0/24 in the rule to allow access from that subnet, you could put sg-123456 into the rule.

• Security groups aren’t software or hardware an attacker can target — they are just rules in the fabric of the VPC.

What makes this so special?

A VPC is a default-deny network! Most networks allow all traffic unless you add a firewall or something. Attackers hack into one part of a network, and can then spread everywhere else. That is where we came up with the term “blast radius”. In a basic network the potential blast radius of an attack is everything on that network.

But in a VPC all traffic is blocked except what is allowed by the route table and the security group. So the blast radius is much smaller — unless you open it up.

Today is just our introduction to security groups. As simple as they are, it’s very important to understand their implementation nuances — and limitations. This is absolutely a case where doing is better than reading, so at the end of a few labs you’ll fully appreciate why security groups are such a big deal, and how to best use them.

Lesson Key Points

• Security groups combine the manageability of a network firewall with the granularity of host firewalls.

• Security groups are part of the fabric of a VPC. They are always required, and there’s no way around them.

• Security groups are default deny. We create inbound and outbound ALLOW rules, but anything not explicitly allowed is denied.

The Lab

We will launch our VPC from CloudFormation again, create two security groups, and then delete everything.

And a quick note: I’m starting to skip the screenshots for some of the tasks we’ve done dozens of times by now, like navigating to a service in the console. Let me know if you think I should add those back.

Video Walkthrough

Step-by-Step

From your sign-in portal go to TestAccount1 > AdministratorAccess. There you have a choice:

• If you know your URL for the template in the S3 bucket CloudFormation created last week, skip ahead to Now that you have your template.

• If you didn’t do that lab, go to the Build a VPC with IaC lab and follow those instructions. No need to delete — we will pick up from there.

• If you know you have the template, but forgot your bucket, follow these next steps:

Go to S3 and click the bucket that starts with cf-templates. You should only have one:

You should only have the one template in the list of objects. Click the checkbox and then Copy URL:

Paste it someplace in case you lose it, or go commando and keep rolling.

Now that you have your template

Go to CloudFormation > Create Stack. Select Choose an existing template > Amazon S3 URL, paste in the URL for the VPC, and Click Next:

Name it CloudSLAW (thanks for the free advertising) and click Next:

Click Next on the next page and then Submit. Then wait until it’s finished:

Now go to VPC > Security Groups and click the one group that was created automatically. This is your default security group. Since all resources require a security group to be on a VPC, this one is there. In a future lab we’ll learn how to lock it down:

Interesting. Let’s read this. It says that all traffic for all ports and all protocols for anything in the same security group is allowed.

I don’t like this rule — it is too open and allows everything in that security group to talk to everything else. Security groups work anywhere in a VPC, and are not constrained or tied to subnets — this will make more sense when we start running things in the VPC.

Let’s build our own. Go to Security groups > Create security group: 

Name it Database and enter a description. Then select the only VPC that’s available, and click Add rule to create our first inbound rule. You can build a security group without any rules, and use it to block all traffic.

Now create two Inbound rules which look like the image below.

• First, choose Custom TCP, then 3306 for the port range, with a custom source of 123.4.5.6 (no idea who owns that IP, but I’m sure one of you will let me know). Call it Database access. This is a common port, usually used for MySQL and MariaDB databases.

• Then click the dropdown and pick SSH. It will fill in the port for you; next set 10.0.0.0/16 as the source. This is somewhat dangerous — it allows SSH traffic from anything on the same network.

As you scroll down you’ll notice there is a default Outbound rule which allows all traffic to the Internet (0.0.0.0/0). In an enterprise environment you might not want that, but then you’d need to specify all permitted outbound connections. We’ll do that in a future lab. Remember, this rule can’t override your route table — routes and security groups work hand in hand.

Click Create security group:

Sweet! Let’s make one more. Go to Security groups > Create security group. Then give it the name Backup and a description, for the rule pick any random port from the list (I used NFS), and where you enter the source start typing “sg-” into the box. Notice it starts pulling up all the other security groups in the same VPC? Select Database and then Create security group:

This is a very important rule to understand. It says anything with the Database security group can talk to anything using the Backup security group, but only via port 2049.

It doesn’t matter what the subnet or the IP address is — this effectively allows access based on which policies are attached to which things!

Okay — that’s it for building, now let’s clean up. This is a two-step process:

• Delete your new security groups. You can’t delete the VPC until you do that.

• Delete the CloudFormation template, which will remove everything it built.

Oops! Notice that it won’t let you delete one if there is a reference to it in another. Backup has that rule allowing Database access, so we can’t delete Database first.

That’s okay, type delete, then click Delete, then go back and repeat the process to delete Database. Don’t worry about the default — you can’t delete that, you can only change its rules.

With those out of the way go to CloudFormation > CloudSLAW > Delete:

Be careful and make sure you see it delete, or you might rack up some NAT Gateway charges.

Lab Key Points

• This week we kept it simple. We introduced security groups and created our first two.

• Security groups can use CIDRs or reference other security groups in their rules.

• There is always a default security group. You can change its rules but you can’t delete it.

• If one group has a rule allowing access from another, you need to delete it before you delete the referenced group so it doesn’t break.

-Rich