Default VPC Security Group Names and Set Rules

ACM.71 Identify and explicitly configure all networking in your AWS Account

Part of my series on Automating Cybersecurity Metrics and Network Security. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

The last post covered AWS Networking Services.

Next we’ll cover some of the AWS networking defaults.

When you create an AWS VPC as we did with our earlier automated VPC creation, you will get an associated security group by default.

Unfortunately, you cannot delete that security group. We could try to modify it and make it one of our other security groups but it just creates complicated code. I leave the default security group in place and rename it to identify it and we can associate our no access rule policy to that group.

You could also write IAM policies to disallow people from using it, but if you have fully automated deployments then that should not be a problem. Also, the group won’t allow connections anywhere so it’s not a big problem if someone does use it after our changes.

Add a Name to the Default Security Group

We want to add a name to our default security group. Where’s the best place to do that? I think it would be easiest to do from the VPC creation function because we already have a handle on the VPC name to add to the Security Group and that will help when adding our ruleset as well. However, because this could be a bit long and it’s really a separate action I’ll break it into it’s own function.

I also created a separate function to get VPC id based on a name which comes in handy:

Then it’s easy to call the new function from within our VPC creation function:

We’re adding a Name tag to the default security group which includes the VPC name so it’s easily identifiable in the AWS Console.

Add the No Access Ruleset to the Default Security Group

Now we can use our NoAccess template to add the rules to the security group. But wait. That template requires an output from our Security Group template as a parameter and we didn’t deploy this security group. What can we do?

If you recall our VPC template has a number of outputs using the available GetAtt values available to us — one of which is the default security group ID.

Note that I wish we also had the route table id here as that would allow us to more easily delete the default route table.

Check our outputs to get the correct name so we can use that in our code.

We’re going to use the Export name of the SecurityGroupOutput above which we can calculate using the VPC name.

Because I added this additional functionality I ended up renaming it to:

I added the code to add the security group:

What I noticed next (after getting the existing template working as explained in the last post) was check the rules on the default security groups. Although a new security group with no inbound rules will end up with no inbound rules, the existing default security groups have a rule that by default allows anything with that security group applied to it connect to anything else with the same security group applied to it. That includes IPv4 or IPv6 traffic.

We will need to override that rule, and it won’t hurt to create a restrictive rule for our other new security groups as well. Copy and paste the egress rule and turn it into an ingress rule.

Now we have default security groups with names and rules we control in our automated VPCs.

AWS Control Tower and non-automated VPCs

If you use AWS Control Tower it creates a VPC in your account with a no-name default security group. We can almost use this for any existing VPCs as well, but what about the export names?

You could write code to work around that and rename the Control Tower default security groups but it would be better to change the Control Tower code and redeploy it with the names you want. Unfortunately that is a bit challenging the way the code is written. You can manually rename the groups but that’s time consuming and those names might get overwritten later if Control Tower needs to make a change. Unfortunately I don’t have a good answer for you on that point.

You may also want to delete the default VPC unless you really need it and only have the VPCs you explicitly created and manage through code in your AWS accounts:

I really wish I didn’t have to spend time writing this blog post. It would be better if AWS allowed you to define the default security group as you wish instead of forcing you to do all this work after the fact. I suppose Amazon requires the default security group for some reason otherwise why would it get created at all? I don’t know.

But now we can move onto the topic I wanted to write about which prompted me to create all this networking at this point: VPC Endpoints.

Stay tuned for more about those and how they can help you when it comes to network security. Follow for updates.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2022

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab