Introduction
When securing hosted resources in the cloud, it’s crucial to employ robust methods to protect against unauthorized access and potential threats. Among these methods, security groups play a pivotal role in safeguarding our EC2 instances.
Amazon Web Services (AWS), a leading cloud provider, offers a multitude of services, including EC2 (Elastic Cloud Compute), which allows us to create and manage instances.
These instances, accessible over the internet, are vulnerable to unwanted visitors and cyberattacks. By utilizing security groups, we can significantly restrict access and enhance the security of our instances.
A security group functions as a virtual firewall, controlling both inbound and outbound traffic. It serves as an essential second layer of defense, ensuring that only authorized traffic can reach our instances.
Let’s delve explore how we can leverage security groups to secure our EC2 instances effectively.
Problems Associated With 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 process that we securely connect to our remote instance. Here, my sshd is consistently validating these random IP addresses. As a result, sshd is very busy and when an authorized user tries to connect to the instance using an SSH client, it will take much longer than normal.
[Also Read this: if you are looking for AWS Cost Optimization]
Best Practices for Configuring and Managing AWS Security Groups
RESTRICT ANYTHING THAT STARTS WITH ALL (ALL TRAFFIC, ALL TCP, ALL ICMP)
It is highly discouraged to add ALL Traffic in any security group attached to the frontend or backend instances. Allowing ALL Traffic will open all ports (0 -65535 ). Instances attached to this security group are 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 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 any IaC provisioning 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 the ssh entry. Despite being possible, it is not an optimal option. Let’s say when our 2nd instance out of 5 MySQL instances have some issue and we need to ssh into it. Now, we will edit the inbound rules and add the 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.
[Also Read: Migration of MS SQL]
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 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 threats by restricting ICMP. But if it is required in an organization, we should set its source to a custom CIDR value, preferably (VPC CIDR).
Restrict use of a WIDE port range
Ensure that our security groups don’t have a wide range of ports opened for inbound traffic 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 the 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 the Security Group Name starts with something like launch-wizard 6, it will be not helpful. We will have to check the rules to know the purpose of that security group. It is far better to use proper naming conventions.
Conclusion
Cloud computing’s revolutionary use of on-demand computing resources necessitates robust security measures to prevent unauthorized access and cyber threats. Security groups, acting as virtual firewalls, are essential for controlling traffic to EC2 instances. To fortify your security groups, avoid weak configurations by restricting access to necessary IP ranges and ports, and adhere to best practices such as applying the principle of least privilege, conducting regular audits, segmenting security groups, enabling logging and monitoring, utilizing automated security tools, and implementing additional security layers.
You can check more info about AWS Consulting Services.