Cloud Front custom headers and AWS WAF help secure custom origins.

 

As we all know, Amazon CloudFront is an AWS content delivery service that, in addition to its main functionality, includes security capabilities such as field level encryption, TLS, and integration with AWS security services such as IAM and the AWS Web Application Firewall (WAF). Here's where you can learn more about Amazon Cloud Front.

The diagram below depicts how CloudFront delivers content to users. It caches material and delivers it to consumers via Edge locations (CloudFront POP) for a better user experience. By directing each user request over the AWS backbone network to the edge location that can best deliver your content, CloudFront speeds up the distribution of your content. More information can be found here.

Customers have used Amazon Cloud Front as a content delivery service (static or dynamic) using S3 or custom origin. Despite the fact that the Cloud Front is an AWS-managed service, it is secure by design thanks to AWS's worldwide network security measures.

But what if visitors try to bypass CloudFront and go straight to your original content? If the origin is S3, utilise Origin Access Identity with Bucket policy and leverage Security Groups, NACLs, and WAF to Allow/Deny particular traffic to custom origins like API Gateways, Application load balancers targeting EC2 or any other origin.

In this blog post, I'll show you how to secure the custom origin - Amazon API Gateway using Cloud Front Custom Header and AWS WAF.

The following are the setups that make up the solution:

1.Amazon WAF ACL to restrict traffic that does not include a custom header in the request Amazon API Gateway with lambda integration and WAF ACL applied

2.Create a custom header for your CloudFront distribution.

The first step is to construct a WAF ACL.

AWS WAF is a web application firewall that helps protect web applications and APIs from typical web exploits and bots that can cause downtime, compromise security, or waste a lot of resources. By allowing you to establish security rules that govern bot traffic and stop typical attack behaviours like SQL injection and cross-site scripting, AWS WAF offers you control over how traffic reaches applications. Here's where you can learn more about AWS WAF.

Go to the AWS WAF service and choose the resource type to which you want to apply the WAF. In this case, I'm using Amazon API Gateway to apply WAF to an API stage, therefore I choose the Regional resource type and the API resource.

Add a rule by clicking Next. 'Using the rule builder, I can add my own rules and rule groups.' We must construct a rule to monitor requests based on the condition that the request matches the header key 'x-origin-verify' and the header value exactly (you can give any value or best way is to generate the random string programmatically).

When a request matches the statements above, choose the action to take. Select 'Allow' in our case since we want to allow all requests with this header and value. Select 'Add Rule' from the drop-down menu.

For requests that don't match the aforementioned rule, choose the default web ACL action. We wish to block all requests that do not comply with the following rule:

Next, review and build a Web ACL by clicking Next. On API Gateway, we're all prepared to allow or restrict requests.

Step 2: Now we'll set up the API in Amazon API Gateway. I've included a very simple lambda function for simplicity's sake:

My API is up and running:

Let's now apply the Web ACL we made in step 1 to the API Gateway stage called test:

Step 3 is to set up a CloudFront distribution using API Gateway as a custom origin and include the custom header in the origin settings.

Use the API endpoint as the custom origin domain name, which CloudFront will recognise. The API stage/API resource will be the origin path. You can change the rest of the settings to suit your needs.

Now comes the most exciting part: the Custom Header. Configure the same header key and value in the CloudFront distribution that you did in the web ACL.

We've now configured CloudFront to include custom headers in the requests it sends to the API Gateway origin.

In the R53, I have a domain name with PHZ, which I utilised to generate the A records and CNAMEs records for this CloudFront distribution, as well as configure the CloudFront distribution.

Now everything is in place!! This is how it will work: I'll use CloudFront to send the request to the API Gateway endpoint. When CloudFront receives the request, it adds the custom header (which the viewer (or user) of the request is unaware of) and forwards it to the API Gateway, where the WAF Web ACL monitors all requests, with a rule that only allows requests with the custom header name 'x-origin-verify' and the value we have set, while all other requests are blocked.

If a user attempts to bypass the CloudFront distribution by directly accessing the API Gateway endpoint, WAF will block the request because it lacks the custom headers.

Let's TEST it out.

In the browser, I typed the address, and it successfully connected to the API Gateway. In this case, CloudFront adds the custom header to my request, which is sent to the API Gateway and receives the following response:

I've also used Postman to demonstrate that I'm not supplying any headers in the request (CloudFront does), and I get a successful response:

Let's check what happens if I try to contact the API Gateway endpoint directly without using CloudFront. Great! WAF is effective! Because there was no header 'x-origin-verify' and its matching value in the request, WAF blocked it.

Using Postman, do the same test - Request Blocked by WAF.

Let's assume that the request is coming from CloudFront by adding the custom header and value to the request. It's really good! If WAF allows it, make a request.

I detailed and demonstrated how to secure a custom origin using CloudFront custom headers and WAF in this blog. If you're interested in learning more about custom headers, click here.

Please let me know if you have any questions or comments on this topic, as well as the use case you'd like me to demonstrate.

I'll make another blog post soon on another fascinating use case.

Good luck with your studies!!

Keep yourself safe!