Automating the deletion of specific inbound rules from any security groups in AWS via Config
Tags: aws, cloud, security, ai
Published: 2023-02-13 23:29:36

### Hello everyone 👋👋. Thanks for taking out time to read my blog. I hope you'll endup having little more knowledge and practical experience after completing this one.

**Here is the simple workflow to understand what we want to achieve here.**
![Image Workflow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ri02sydea7h8waqg0zp5.png)


As much as it is so much fun to create resources in cloud like AWS, it is also very important to keep your security checks in place. Because even one security breach is enough to take your cloud infrastructure down in some cases. 
So i tell you a little story now, I used to create application on **Elastic beanstalk** as a developer since its very easy to create and managed which is aws managed service. Then after a while I noticed that elastic beanstalk creates the whole think as a cloudformation stack. One of the drawback of this is, it created the EC2 server with default security group rules (like **SSH (port 22)** open to anywhere i.e. **0.0.0.0/0** which is BIG NO NO !!)
So everytime EB create, rebuild or update the scurity groups, this SSH rule comes as default. Earlier i used manually delete those ssh rule after warning from Trust Advisor, which is very tedious but most important risky as we never know what could happen if we let SSH port open for even 5 minutes.

Now i found out a way by which you can automatically set the rule in **AWS Config** (it helps you assess, audit, and evaluate the configurations and relationships of your resources) and delete those rules with AWS SSM(Systems Manager) whenever config detects that rule in any of your security groups. So lets get started and understand the whole process.

AWS config continuously monitors the resources and configuration and takes the remediation actions on the basis of config rules.

### Create the IAM Role for Systems Manager(AWS SSM)
1.) Go to **AWS Management Console**.

2.) Create a IAM role and give permissions to **Allows SSM to call AWS services on your behalf.**
 Click on create a role, then select AWS services.

![Image 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jkfurdjld4ebm3zz24y7.png)
and usecase as **Systems Manager.**

![Image 3](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aph898obkdg6qz3fgphp.png)

On Next step choose the **AmazonSSMAutomationRole** policy from the list.
![Image 4](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0mx9i8cbho11k9afrphz.png)
3.) Finally give the name and review the permissions of **SSMAutomationRoleForConfig** and create the Role

![Image 5](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0u1ao292a44hnps5h60a.png)

4.) After this attach one inline policy for giving the Role access to delete the Security groups. Below is the IAM policy for that.

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeSecurityGroups"
            ],
            "Resource": "*"
        }
    ]
}
```

### Setup the AWS Config rules for Restricting the SSH access.

5.) Go to AWS Config, click on **Add Rule.**
![Image 6](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w0rr8aevivzq2pua0r49.png)

6.) Now select the rule type as **AWS Managed rule** i.e. **restricted-ssh** from the Rules list.

![Image 7](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hn2kbx6q0cj2dotx1fep.png)

7.) Configure the rule and give the intuitive name like **restricted-ssh**
![Image 8](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/shd9wgeir5tvfridqrzv.png)
then choose the Resources as **security groups** in the scope of changes section in Evaluation mode.

You can leave the other optionals like parameters and tags as default. 
Finally review the Config rule and click on Add Rule once done.

![Image 9](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b44hgw7qmyoqpb5lgry1.png)

### Manage the remediation of Config rule.

8.) After creating, select the rule and in the **Actions** click on **Manage Remediation.**

![Image 10](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/obdxzq2djxcp8160znog.png)

Now select the Remediation action as automatic. 

![Image 4rtwfe](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wqsbh7a4y4m9ou1nr4z2.png)
Then choose the remediation action as **AWS-DisableincomingSShOnPort22**. This will disable the **unrestricted incoming SSH traffic** on port 22 for EC2 security groups.

![Image dsanc](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p98l0gfqpf7wznr0fynn.png)

You can update the Rate limits as per your usecase or leave it default for now. And in the resource Id parameter, select the **SecurityGroupIds**(or else you can pass the resource ID of noncompliant resources to a remediation action by choosing a parameter that is dependent on the resource type.). But here we want do it for all security groups.


![Image 11](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i63h186n04j8674y817f.png)


In the next section of parameters, the **SecurityGroupIds** will be greyed out, so no need to worry about that. And in the **AutomationAssumeRole**, put the ARN no. of Role that you created in above i.e. **SSMAutomationRoleForConfig** in our case.

Finally review everything and **Save Changes.**

### Test if it really works 🤔.

- Go that EC2 dashboard, select any instance and edit the inbound rule of that security group as 🚨🚨 **SSH (port 22) allow to 0.0.0.0/0 (Warning: Please don't do that with production resources(or serious resources), use only testing servers that doesn't have anything to be compromised in any case.)**

![Image 12](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/88tcuxlpjza46z0s4xo6.png)
- If some body trys to allow ssh (port 22) inbound rule to a critical server so that he can ssh inside it and take away any data or harm the Application in someway. 
- Even if it is 5 minutes, we won’t even know that someone has taken away the data or has done ssh into the virtual machine. You won’t get any alarm also. But with config we can completely resolve this issue and secure our AWS Cloud infrastructure.

- In a while you will see the remediation like below. 

![Image edfgsic](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5ej4hwlj3s0r4cjrnrdf.png)

![Image dejjnjnon](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ruuj6o3fn7danber09ws.png)

![Image 342](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fj9yfghjtxafp15z65as.png)

And you'll found that ssh rule will be deleted by config rule and AWS SSM **StartAutomaticExectionAPI.**

![Image ddsfsvon](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lnc1ui2scfio84oco432.png)

### BONUS:
-  If you want to setup alerts and notification if if find any resource as uncompliant.
[Get notified when an AWS resource is non-compliant using AWS Config?
](https://aws.amazon.com/premiumsupport/knowledge-center/config-resource-non-compliant/)
- If any problem while setting this up, you can [troubleshoot failed remediation actions in AWS Config?](https://aws.amazon.com/premiumsupport/knowledge-center/config-remediation-executions/)

 

If you find any issue while doing this please let me know in comments or you ca connect me directly. 

[Linkedin](https://www.linkedin.com/in/tanmay-shukla/)

[Bio.link Profile](tanmayshukla.bio.link)