Mitigating inadvertent IPv6 prefix advertisement with AWS automation

The Trusted Internet Connections (TIC) initiative, overseen by the Cybersecurity and Infrastructure Security Agency (CISA), establishes standards and guidelines for federal agencies to enhance securing their internet connections. The TIC standards provide a consistent baseline for secure cloud connectivity and internet access across federal agencies.

Federal agencies following TIC 2.0 standards are required to route external traffic through approved Trusted Internet Connection Access Providers (TICAPs), which act as centralized security gateways. Agencies must advertise their internet-bound IP prefixes towards the TIC network, and the TICAPs provide security capabilities such as intrusion detection and prevention, encryption, and web content filtering. The TIC 2.0 architecture does not allow agencies to access the internet through cloud service providers like Amazon Web Services (AWS).

Federal agencies advertise their internet-bound IPv6 prefixes towards the TIC network without utilizing the AWS internet gateway. However, as agencies migrate to the TIC 3.0 framework, they will use AWS to exit to the internet, bypassing the TIC network. This transition requires agencies to plan and coordinate migration activities to verify seamless IPv6 connectivity. Agencies need to coordinate advertising their IPv6 prefixes with AWS, using mechanisms like Bring your own IP addresses (BYOIP). The migration process could involve changes in routing policies, firewall rules, and security controls to accommodate the IPv6 prefix changes.

BYOIPv6 and VPC IPAM

In this post, we first discuss how an inadvertent modification to the advertisement parameter causes exposure of IPv6 prefixes. Second, we introduce an architecture using AWS services to identify and mitigate the configuration error. This post assumes that you bring your own IPv6 address space to AWS using the VPC IP Address Manager (IPAM). To understand how to design IPv6 pools in IPAM, please refer to this post on the AWS Networking & Content Delivery Blog.

Proposed architecture

The proposed architecture uses AWS CloudTrail, Amazon EventBridge, AWS Lambda, Amazon DynamoDB, and Amazon Simple Notification Service (Amazon SNS). AWS CloudTrail captures the change and triggers an EventBridge event with a Lambda function as the target. The Lambda function not only detects the configuration change but also takes remediation action by reverting the configuration change. This verifies that the IPv6 prefix configurations remain compliant and aligned with the approved configurations stored in Amazon DynamoDB. The Lambda function uses Amazon SNS to send notifications to the administrators, informing them about the inadvertent configuration change and the remediation action taken. This allows administrators to investigate the root cause and take further actions if needed.

Figure 1 depicts two BYOIPV6 prefixes, 2001:db8:1234:1a10::/48 and 2001:db8:1234:1b10::/48. In this example, the agency policy prohibits advertising the 2001:db8:1234:1b10::/48 prefix on the internet. However, an inadvertent configuration error advertises the prefix on the internet. This action triggers a CloudTrail event, which triggers an EventBridge event. Amazon EventBridge invokes a Lambda function to check in an Amazon DynamoDB table if the prefix can be advertised. In our example, the policies do not allow advertising the 2001:db8:1234:1b10::/48 prefix. The Lambda function remediates the configuration error and emails through Amazon SNS to the administrators, notifying them it has performed a configuration change to address the issue.

Figure 1. A high-level architecture showing how to remediate inadvertent advertising of IPV6 prefixes using AWS serverless services.

Walkthrough

Refer to the AWS CloudFormation stack or GitHub repo.

Prerequisites

Before deploying the solution, please follow the README from the GitHub repository and take the necessary steps to fulfill the prerequisites. This application can be deployed using the AWS Command Line Interface (AWS CLI) on your local machine or using AWS Cloud9. We recommend using the AWS Cloud9 IDE to simplify the deployment because it contains all of the necessary prerequisites and configuration to deploy this sample to your account with very little configuration.

Deploy the solution

1. From the code directory, start the deployment of the AWS resources required for the solution:

$ sam deploy –guided

Shown in Figure 2, enter a stack name, region and email address to receive notifications and accept the defaults for all other prompts. After completing the prompts, deployment can take several minutes.

Figure 2. Screenshot of starting the deployment of the AWS resources.

Figure 3 shows the output of the CloudFormation events after the deployment.

Figure 3. Screenshot showing a list of CloudFormation events after deployment is completed.

2. The deployed application will include a DynamoDB table where certain ranges can be allowlisted if those ranges are permitted to be advertised. The allowlist can be added to the DynamoDB table by navigating to the DynamoDB service in the AWS console. Figure 4 shows a DynamoDB dashboard.

Figure 4. Screenshot of the DynamoDB dashboard.

Once you have reached the DynamoDB service page, select Tables from the left navigation pane and select the DynamoDB table created by the SAM template.

Figure 5 shows the DyanmoDB created by the SAM template.

Figure 5. Screenshot showing the new DynamoDB.

To view the contents of the table, you will choose Explore table items in the top right corner of the console, shown in Figure 6.

Figure 6. Screenshot showing the table items in DynamoDB.

In the Explore items page, choose Create item near the bottom middle of the page to create a new item for the allowlist, as shown in Figure 7.

Figure 7. Screenshot showing the Explore items page in DynamoDB.

In the Create item page, select JSON view in the top right (Figure 8) and create an allowlist with the following format, replacing “CIDR#” with a list of your allowed CIDRs, as shown in the following code snippet.

{
  	"id": {
    "S": "Allowed_CIDRs"
  },
  "CIDRs": {
    "L": [
      {
        "S": "CIDR1"
      },
      {
        "S": "CIDR2"
      },
      {
        "S": "CIDR3"
      },
      ...
    ]
  }
}

Figure 8. Screenshot of the Create item page in DynamoDB.

Choose Create item at the bottom right to create your allowlist.

Testing the solution

1. To test the solution, navigate to one of your pools in the Amazon VPC IP Address Manager console and select a CIDR that is not listed in the allowlist.

Figure 9 shows how to select a CIDR block not in the allowlist.

Figure 9. Screenshot of the Amazon VPC IP Address Manager pools page.

2. Under the Actions menu in the CIDRs pane, select Advertise.

Figure 10 shows how to advertise the CIDR selected in step 1.

Figure 10. Screenshot of the Actions menu in the CIDRs pane, with Advertise highlighted as the fourth option in the Actions dropdown.

3. In the dialog box, choose Advertise CIDR.

Figure 11 shows how to advertise the CIDR selected in step 1.

Figure 11. Screenshot of the Advertise CIDR pane.

4. At this time, the CIDR should show as advertised in the console (Figure 12).

Figure 12. Screenshot showing the CIDR is advertised.

5. Within a few seconds, if you refresh the page, you should see that the advertisement has been withdrawn, showing that the automation is working as expected (Figure 13).

Figure 13. Screenshot showing the CIDR advertisement is withdrawn.

6. Assuming that a valid email address was utilized when deploying the stack, you should also receive an email (Figure 14) showing that the advertisement was removed at the email address specified.

Figure 14. Screenshot shows an email notification that the automation blocked the CIDR to be advertised.

Cleaning up

To avoid incurring future charges, delete the resources by running the sam delete command from the code directory:

$ sam delete

Conclusion

By implementing this architecture, organizations monitor their IPv6 prefix configurations, detect any deviations from the approved state, and receive timely notifications to investigate and remediate inadvertent configuration changes. This helps maintain compliance, confirm proper IPv6 prefix advertisement, and mitigate potential security risks or IP address conflicts.

If you want to get started with VPC IPAM, review the following documentation. If you have more questions about the architecture presented in this blog, contact your local account team.