Security Group Strategy for AWS
Grenadier Guards are an elite British Army infantry regiment. People say they are strong as a mountain and ruthless as hell. They protect the doors of Buckingham Palace which are the world’s most valuable residence. No one dares to enter. Likewise, our hosted resources in the cloud are of utmost important and valuable to us. We need some method to protect it and restrict the initial point of contact from the attacker an unwanted audience. Let’s discuss it further on how we can use the security group in the best way to secure our EC2 instances.
AWS is a cloud provider which means the services which we use are hosted at AWS data center. EC2 (Elastic Cloud Compute ), which we use to create instances, is one of many services provided by AWS.
These instances are accessed over the internet. So there is a huge chance of getting unwanted visitors. Using a security group we restrict the scope of access and hence make our instances secure.
Security Group is called a virtual firewall to control inbound and outbound traffic. It is also called the second layer of defence.
Problems
There are several known problems associated with the weak security group.
For example, in the picture above I have selected ALL Protocols in the security group with source “anywhere” (0.0.0/0). As we can see there are several random IP’s trying to gain access to my instance. Apart from the obvious threat, it severely declines the performance of my instance.
As we know, sshd( secure shell server daemon) is a daemon process using which we connect to our remote instance securely. Here, my sshd is consistently validating these random IP addresses. As a result, sshd is very busy and when an authorized user will try to connect to the instance using ssh client, it will take much more time than normal.
Best Strategy
RESTRICT ANYTHING WHICH STARTS WITH ALL (ALL TRAFFIC, ALL TCP, ALL ICMP)
It is highly discouraged to add ALL Traffic in any security group attached to frontend or backend instances. Allowing ALL Traffic will open all ports (0 -65535 ). Instances attached to this security group is highly vulnerable.
RESTRICT SSH PROTOCOL ACCESS
For ssh Protocol, Source “anywhere” (0.0.0.0/0 ) is fatal. What we should do is, for backend instances, keep the destination as VPC CIDR range only which in my case is 172.10.0.0/16 (Fig. 4). For frontend instances or instances in a public subnet, we can add our public IP’s to the security group Source. We can select our current IP with my IP Option (Fig. 5). This step will reduce our instance vulnerability considerably as ssh is a single point through which one can gain complete access.
DISCRETE Security groups
Any security group, generally, should not contain multiple protocols in one security group. We should create separate security groups for each protocol. Hence, having security groups in discrete amounts gives us the flexibility to attach or remove them accordingly. Here’s how:
Basically, we need ssh as a protocol to manage and configure our instance (mysql in this case) with Ansible or any other automation tool. After proper configuration, we would need to remove the ssh access. One may think that we can edit the inbound rules and remove ssh entry. Despite being possible, it is not an optimal option. Let’s say when our 2nd instance out of 5 mysql instances has some issue and we need to ssh into it. Now, we will edit the inbound rules and add ssh entry. This will end up opening ssh access for the remaining 4 mysql instances as well as they are attached to the same security group.
Instead, we can create two separate security groups. One for SSH and another for MYSQL
Attach both SG to your mysql instance
Complete your configuration changes. Then remove SSH SG by deselecting it.
RESTRICTED ICMP Protocol ACCESS
ICMP (Internet Control Message Protocols) is mainly used to determine whether or not data is reaching its intended destination timely. If this protocol has unrestricted access (0.0.0.0/0) to any host on the internet, it could be dangerous.
Attackers basically ping a range of IP addresses and when they get a reply, they start port scanning using nmap on that IP address.
Mainly instances in public subnets need to be taken care of as they have a public IP address. Better to avoid threat by restricting ICMP. But if it is required in an organization, we should set it’s the source to a custom CIDR value, preferably (VPC CIDR).
Restrict use of WIDE port range
Ensure that our security groups don’t have a wide range of ports opened for inbound traffic in order to protect our EC2 instances. Sometimes we open a range of ports for our ease other times it is required by service.
FTP requires two ports to be opened Port 20 for data and port 21 for connection control. So here our port range is small and both ports are serving. Therefore, if we are opening a port range, ports within range must be listened to by some service.
Proper naming convention and DESCRIPTIONS
Naming conventions help us in every scenario from categorization to auditing. If Security Group Name starts with something like launch-wizard 6, it will clearly be not helpful. We will have to check the rules in order to know the purpose of that security group. It is far better to use proper naming conventions.
CONCLUSION
Cloud Compute is a powerful technology that has and still shaping the innovative way of using on-demand compute resources. As it is accessed over the internet and hence we need to filter and allow certain users from certain specified IP address range.
We have emphasized a few points consider for the security group:-
- The problem associated with a weak security group
- Best practices which make a security group invincible
Reference — Fig. 1
Opstree is an End to End DevOps solution provider
Originally published at http://blog.opstree.com on October 20, 2020.
