You should be thinking that I already know security groups and using it daily. What is new in that? So here, I will explain the things which you already know are different than reality. I also believed just like you before I started preparing for the AWS Security Specialty exam. So let's get started.
I will try to be cover the advance part in this blog. So if you don't already know about security group then you might not understand what I am trying to convey.
Where actually it is attached?
Security Groups not associated with Resources! Yes, you read it right. Instead, it is associated with Network Interfaces. You will say what's the difference in that! Suppose, I have 2 network interfaces in an instance and associated different security groups for both of them. In this case, I can have different kind of traffic allowed with the different interface but Same Instance. So it will be useful if I have a different purpose for different interfaces. Like both hosted separate web applications or one is for public traffic and other interface is for company internal traffic and firewall is only included in the public interface.
It's different than a Firewall:
- Unlike a firewall, rules defined in Security groups are not sequential. That is, they are evaluated all at a time. In a firewall, we have precedence based on the rule number and it can be more rigid and limiting.
- Security Groups can't explicitly block traffic. In other words, we don't have a rule that blocks traffic from a specific IP address. You can definitely allow traffic and other traffic is blocked by default, but you can't specify DENY rule in that.
Intelligent firewall:
- We can say the security group is an intelligent firewall. It means a response to the request is allowed. (Firewall can be dumb because it can't say that it is a response of user's request). It is called Stateful.
- Suppose, I have not allowed any inbound rules but outbound still allows traffic. Now, if I try to surf from the instance, Sg will allow request (as per outbound rule) and it will identify response coming from the web server you just requested and you will have the result of your request.
Reference other SG:
What is a reference in the security group?
- A security group can allow traffic from resources attached to the referenced security group. Let me explain that. Suppose, I have set of production servers through with I want to allow traffic to database instances. In this case, I can add IP ranges for all of that production servers. That's feasible. But what if in the future I have hundreds of EC2s! Every time I need to add IP. We can add a rule that has a Production server's security group mentioned. So now onwards, any server that has a production security group attached, can communicate with my database instances. Isn't it simple enough!
- Let's take an interesting example.
I have different resources in different VPCs. I want to communicate some resources in both VPCs. All are in different subnets so IP ranges are not good to track resources. In this case, I can have one security group in VPC1 which is attached to all the resources that need to communicate with VPC2. And in VPC2 just reference that security group id of VPC1. So all the resources that has SG attached can communicate with resources in VPC2. The peering process is needed to reference different SG in VPCs.
Be careful here! If you are attempting to reference cross-account than keep in mind that the owner of another account can have ANY number of resources communicate with your SG!
Best Practices:
- EC2 Security groups should not have rules with a larger port range.
- Flow logging should be enabled for production VPC.
- Database security group should only open to Web Security group.
- Limit outbound access to required ports only.
That's it. I hope you learned something new. Let me know your valuable feedback.
Comments
Post a Comment