Knock ! Knock !! What happened with my ingress/egress ??
Tags: aws, cloudtrail, securitygroup, howto
Published: 2021-11-16 05:20:36

###AWS Security Groups###
AWS Security Groups is basically our gate control feature which controls on how people connect to the EC2 instances in AWS. It defines list of ingress(which is the rules which takes care of connections taken towards or coming inwards into our EC2 instances) and egress(which is about connections made outside to internet or other sites from the EC2 instances. Both these traffic will be classified against some protocol type like TCP/RDP, port numbers like 22/3389, for example

###AWS EC2 Instances###
Elastic Compute Cloud are the virtual machines that we launch on cloud from our AWS accounts, in order to use them for compute purposes, hosting applications etc. For these EC2 instances to be accessible, we need to have control to allow the connections inside instances and outside the instances for operational purposes. This is achieved using AWS Security Groups. 

### How do we track AWS Security Group Changes ###
While there are a few ways, to identify or track what is happening with security groups' inbound and outbound rules, in this post let us see how to analyze the order of changes happened against the security groups from AWS Cloudtrail

####AWS Cloudtrail ####
This AWS Service is basically doing the event logging for your AWS resources, on enablement. Trail logs will be stored in S3 bucket and is available from console as event history, against various categories like Resource Type, Resource Name etc

Let us create a security group with no inbound rules and try add any ingress and understand how to track that activity of change from AWS Cloudtrail console logs. This will help in tracing the changes to security group or any other resource for that matter

**Step 1**

Login into your AWS account, ensure that you have permissions to use AWS EC2 Management Console & AWS Cloudtrail Console as well

**Step 2** 

Create a security group without any inbound rules, as below
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o494r4xzpyukjywpc4z4.png)

**Step 3** 
Also navigate to the AWS Cloudtrail console page, and enable the logging. Do note that AWS Cloudtrail enablement isn't priced but the S3 bucket where the logs are stored will be billed
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8vaj4gzk99s7s7c7vypb.png)

**Step 4** 
Now from the security group add any inbound rule, as required  
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mrv6esdazu27e4o0ukrf.png)

**Step 5** 
From the AWS Cloudtrail console, click on "Event History" in order to see the logs against our security group. Find the details about when, which user, amended details being captured and available for analysis from this event history. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p9ppthmx2abb8ogw50a5.png)

Also there is a event record created which shows the complete details of changes made, for example, user, access key, port, protocol added in this security group 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4grsnry5gmg7trtcqncj.png)

**Step 6** 
As an additional option, we have the privilege of filtering Cloudtrail records by Resource Type, as well
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bvx6csji3snmmb16vaw3.png)

**Step 2** 
Find a sample view, the logs filtered based on Resource Name; This will take us straight to the concerned resource in discussion
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kjm8yy5ip53ngqc3zrbp.png)

Thus, this is one way of tracing back; The event classifications available under AWS Cloutrail helps us to view details, against each action triggered by an event via API calls, management console and from logs, as well

In the upcoming posts, let us see other ways of tracing the changes to an AWS Security Group