Before I start writing about the tips, let’s assume our architecture is like that-

1.EC2 Instance with Linux machine

2.Database is Postgres/RDS

3.We are hosting a media application on AWS, so we need to manage the UDP traffic as well.

4.Our EC2 instances communicates with each other, so we need to manage ICMP traffic as well(for ping and other purposes)

5.Our EC2 instances communicates with third party EC2 instances (hosted on a different zone)

Also, I am assuming basic account configuration such as AWS Identity and Access Management (IAM), AWS App Config and cloud trail logs are already enabled in your account.

Now, Since the scope is clear and preconditions ae configured correctly, Let’s talk about the tips.

Tip #1: Have proper naming conventions for security group

It is very easy for hackers to play with the security groups if they know that particular security group is used to handle certain EC2 instance or certain application communication. So it’s always safe to create codes for security group naming.

For example naming code format can be-Application code+ Environment Code+ OS Type+Trafic Type+Rule Type.

Sample-A1359(Application code)+T1579(Testing Environment code)+CL0009(Centos with linux)+T6793(tcp traffic)+O3989(office users).

Tip #2: Have proper categorization of security groups

It is good to categorize your security groups. For Example all DB and web server connection ports in one security group, all the media connections port under one security group, all the third party connection port in one security group and all the office specific ports under one security group. Categorization helps you manage your different sets of connections efficiently so that you do not mess up your security groups whenever you need to change somethings for a specific port.

Tip #3: Do not create least restrictive security groups like (0.0.0.0/0) which is open to everyone.

Since web servers can receive HTTP and HTTPS traffic open, only their Security group can have permissive like (0.0.0.0/0), TCP, 80, Allow inbound HTTP access from anywhere (0.0.0.0/0), TCP, 443, Allow inbound HTTPS access from anywhere. All least restrictive Security created in your account should be alerted to SOC/MS teams immediately.

If there is specific port needed for UDP traffic then add an entry for specific port along with the required server IP under security group.

Tip # 4: Do not use default ports for server/db access

Default ports such as 2222, 5432, etc are always vulnerable to hacking attempts so to avoid that it is good to use the custom port number.

Tip # 5: Use port scanner tool like Nmap and netstat to identify open ports which are not required

It is a good practice to close unused/private ports, and port scanner tools like Nmap and netstat helps to find out unused ports which are kept open. Using this information change you security groups to close/remove ports

Tip # 6: Make sure SSH/RDP connection is open in AWS Security Group only for jump box/bastion hosts for your VPC/subnets.

Tip # 7: Avoid allowing UDP or ICMP for private instances in Security groups. Not a good practice unless specifically needed.

Tip # 8: Never add specific home IP address under security rules.

Tip # 9: Use Cloud trail for security changes alerts

Detection, alert and actions can be taken by parsing the AWS Cloud Trail logs based on usual patterns observed in your production environment.

Example: If a port was opened and closed in <30 or X mins in production can be a candidate for suspicious activity if it is not normal pattern for your production server.

Tip # 10: Use AWS Inspector for automatic assessment

Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for vulnerabilities or deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity.