As we say, the supreme force of network promotes connectivity among people at every comer of the globe. We may not enjoy its convenience or gain knowledge as we want it easily and casually but, we would all agree that a secure network is a must. And a secure network can be achieved by blocking certain servers manually. This method is known as the Network Access Control List.
What is Access Control List (ACL)?
Access Control List or ACL is an additional layer of security for your Amazon Virtual Private Cloud. Access Control List acts as a firewall for controlling ingress and egress traffic of one or more subnets. You can set up your ACL rules similar to your Security Groups. Remember, security groups and access control list are two different things because AWS Network ACLs are stateless, unlike security groups which are stateful. In simple words, changes in incoming rules will not be applicable to the outgoing rule in the access control list. For example, if you want to change the port of communication of your instances then you have to add an inbound as well as an outbound rule.
Basics of Network Access Control List:
1. When you create your VPC, it comes with a modifiable default Network Access Control List. And by default, it allows all inbound and outbound IPv4 and IPv6 (if applicable) traffic.
2. You can create your custom network ACL and associate it with a subnet. And by default, each custom ACL rejects all inbound and outbound traffic until you add rules.
3. Each of the VPC subnets must be associated with a network ACL. If you don’t associate the subnet with network ACL explicitly, it will associate your subnet with default ACL automatically.
4. A subnet can be associated only with one ACL at a time; however, an ACL can be associated with more than one subnet.
Why you should create a CloudWatch alarm for Network Access Control List changes?
Network Access Control List provides you with an additional layer of protection for your AWS virtual private cloud. Creating CloudWatch alarms to detect any configuration changes in the Network Access Control List will help you prevent unexpected alteration in the inbound and/or outbound traffic rule which may lead to unrestricted access and increase the opportunities for Distributed Denial of Service (DDoS) attacks.
Centilytics helps you ensure that your CloudWatch alarms are enabled
A CloudWatch alarm is triggered each time a Network Access Control List (NACL) configuration change is made. Every time when an AWS API call is performed to create, update or delete a Network ACL, CloudWatch alarm must notify you. Supervision of Centilytics becomes more important since it checks for the CloudWatch alarm required to be set up in your AWS account and lists down all the accounts in which the alarm have not been enabled. With our applicable filters and pigeonholing into categories, it becomes easier to understand the configuration of the Network Access Control List.
||Ok: Following trail has CW logs groups configured with metric filter, alarm, SNS topic with at least one subscriber.|
||Warning: No SNS topic exist OR No subscribers to the list Of SNS topics this alarm OR No alarm exist, hence no associated SNS topic OR desired filter pattern doesn’t exist on any of the alarm existing in this region OR Metric filter doesn’t exist, hence no associated alarm and SNS topic|
||Critical: Delivery to CloudWatch logs not configured|
Description of further columns are as follows:
Account Id: Shows the respective account ID of the user’s account.
Account Name: Shows the account name corresponding to the user’s account.
Region: This column shows the region of your instance where it has been used.
Identifier: Shows you the service with its trail name.
Log Group Name: It represents the name of the group which has permission to use the service.
Metric Filter Name: Shows you the name that you have given to the metric filter.
Alarm Name: Shows you the name of the alarm which you have assigned.
SNS Topic Name: SNS refers to the Simple Notification Service group. A group of individuals who receive the alert message.
Custom Severity Description: Shows the severity of your metric filter and its functions’ custom description.
|Account Id||Applying account Id filter will display all the public snapshots for the selected account Id.|
|Region||Applying the region filter will display all the public snapshots corresponding to the selected region.|
|Severity||Applying severity filter will display public snapshots according to the selected severity type i.e. selecting critical will display all instances with critical severity. Same will be the case for Warning and Ok severity types.|
|Resource Tags||Applying resource tags filter will display those public snapshots which have been assigned the selected resource tag. For e.g., If the user has tagged some public snapshots by a resource tag named environment, then selecting an environment from the resource tags filter will display all those snapshots.|
|Resource Tags Value||Applying resource tags value filter will display data which will have the selected resource tag value. For e.g. – Let’s say a user has tagged some resource by a tag named environment and has a value say production (environment: production). Hence, the user can view data of all the resources which are tagged as “environment: production”. The user can use the tag value filter only when a tag name has been provided.|
|Compliance||Applying the Compliance filter, you can further refine your security and health checks.|