Are security groups really that dumb ?
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
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?
Let’s break down the question into the following different parts !
- A security incident is described (EC2 is compromised, OKAYYYYYY !)
- EC2 is the bastion host itself.
- 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.)
- 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.
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 ?
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.
I hope you liked this blog, please clap and follow me for more such posts. Will see you in the next blog.