Are security groups really that dumb ?

Saurabh Jain
3 min readJul 16, 2024

--

only one way to find out.

Hello my AWS junkies, I'm intrigued that the title brought you here. And if you’ve made it finally and reading this let’s not delay further.

I am sure you’ll be learning something new or at least re-kindling a few amazing behavioral facts about the AWS Security Groups

my biggest pet peeve is job boards displaying security guard jobs when looking for security engineer roles.

While preparing for AWS Certified Security — Specialty certification I encountered a sample question in an online learning group.

The question was as follows, read it carefully

You’ve identified a potential compromise on one of your EC2 instances serving as a Bastion Host, located in its own subnet within a VPC. Which of these steps is best to restrict access and prevent further compromise while allowing your security team to investigate?

i meant to break down the question, damn it.

Let’s break down the question into the following different parts !

  1. A security incident is described (EC2 is compromised, OKAYYYYYY !)
  2. EC2 is the bastion host itself.
  3. Located in the same subnet inside a VPC (Interesting, cause it does not makes a logical sense due to the security benefits of separation. It’s usually recommended to place bastion host in a different subnet.)
  4. Usage of 2 keywords “best” and “prevent further” in the question Which of these steps is best to restrict access and prevent further compromise ?

These were the options available to answer

A. Modify the security group rule to block all access except to an internal IP address used by the security team

B. Modify the NACL to block all access except to an internal IP address used by the security team

C. Stop the Bastion Host instance to prevent any more compromise. Take a snapshot of the instance, and then transfer the snapshot to the dedicated digital forensics AWS account

D. Change the IAM roles associated with the Bastion Host instance to restrict access based on the security team’s role permissions.

oh ! someone please save me

I quickly eliminated option D as the mitigation method wasn’t clear, was not to the point and lacked an overall clarity.

Option C was not a “best” option as stopping the bastion host would result in loss of volatile data present on the machine which might be important.

As of the remaining 2 options A & B, my sub-conscious memory quickly recalled that EC2s are governed by SGs and VPCs/Subnets are governed by NACLs. And I choose option A.

Now if you don’t know what these are or need a full-blown technical documentation. Please click here

Turns out, this is a wrong option. BUT WHY ?

okay, let’s understand.

To understand this we need to know that security groups are stateful.

What it means actually is that some connections can remain temporarily alive even after blocking them if they were already established.

Since NACLs are stateless, changing rules will immediately block access and are preferred whenever you can block access to entire subnets (which is not always possible).

I would like to also recommend to watch this video.

we solved it, but at what cost.

I hope you liked this blog, please clap and follow me for more such posts. Will see you in the next blog.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Saurabh Jain
Saurabh Jain

Written by Saurabh Jain

Web & Application Penetration Tester

No responses yet

Write a response