Origin cloaking

Origin cloaking is a set of techniques aiming at reducing the attack surface of web applications. It's a best practice to use CloudFront as a single-entry point to web applications, where security controls, such as protections against DDoS attacks and undesired bots, are applied. Origin cloaking stops malicious actors from by-passing CloudFront and its security controls to attack the origin directly, using firewall rules to block any traffic not coming from the CloudFront entry point. Origin cloaking can be achieved at multiple layers of the OSI model.

Origin cloaking on network layer protects your origin from all attacks targeting your origin directly. However, an attacker could configure a CloudFront distribution with your discovered origin domain name, and targeting your origin with application layer attacks through their CloudFront distribution, effectively bypassing your security controls configured on your own CloudFront distribution.

In addition to obfuscating your origin domain name (e.g. avoid origin.example.com !), you can add application layer access controls between CloudFront and your origin to mitigate the above risk. This can be implemented in different ways according to the origin type and the security requirement.

OAC is functionality of CloudFront that allows you to sign requests to certain types of origins natively using AWS Signature Version 4 algorithm (sigv4) based on IAM policies. Today, OAC is compatible with S3, MediaStore , MediaPackage, Lambda Function URLs, and S3 Object Lambda. When OAC is used with S3, you can keep your S3 bucket private, with exclusive access to CloudFront based on S3 Bucket policies.

When the origin type is not supported by OAC, you can sign requests to your origin using edge functions. Example implementations iare explained in the following blogs:

• Sign requests using Sigv4 with Lambda@Edge to AWS API Gateway
  
• Sign requests using MD5 with Lambda@Edge to NGINX servers

If your origin does not support request signing, or you don't consider that this level of access control is needed for your application, then you can configure CloudFront to send a custom header containing a shared secret with your origin, that can be validated by your origin to process the request. Consider the following example implementation:

• ALB based origin. You can validate the secret header on an ALB based origin using an ALB rule or using an AWS WAF rule if your ALB is already associated with an AWS WAF WebACL.
• API Gateway based origin. You can validate the secret header on an API Gateway using API keys.
• NGINX based origin. Assuming that CloudFront sends a custom header X-CloudFront with value abc123, you can validate the secret header on Nginx based web server (Cloud based or On-premises based) by adding the following code in the server tag of the /etc/nginx/nginx.conf Nginx configuration file:
  
  if ($http_x_cloudfront != "abc123") {
      return 403;
  }
• Apache based origin. Assuming that CloudFront sends a custom header X-CloudFront with value abc123, you can validate the secret header on Apache based web server (Cloud based or On-premises based) by adding the following code in httpd.conf configuration file (and ssl.conf file if used):
  
  RewriteEngine On
  RewriteCond %{HTTP:x-cloudfront} !^abc123$ [NC]
  RewriteRule ^ - [F]

In all cases, tt's recommended to rotate this shared secret on a regular basis to reduce the risk of leaked secrets. In the sample implementations shared above, both the one with API Gateway and with ALB include an automation for secret rotation.

CloudFront publishes the IP addresses used to establish TCP connections with your origin, with the CLOUDFRONT_ORIGIN_FACING value of the service field. You can implement an ACL on your origin's firewall to block traffic not originating from CloudFront origin-facing IPs. With this approach, you need to subscribe to IP changes to update your ACL. Check this blog post to learn how to implement origin cloacking on on-premise web servers using third-party firewalls.

If your origin is hosted in an amazon VPC, you can simply implement origin cloaking by adding the AWS-managed prefix list for Amazon CloudFront to the security group attached to your origin (EC2, NLB, ALB, etc...).

In both cases, it's recommended to establish secure connections over TLS between CloudFront and your origin.

If your origin is on your premises, consider setting up AWS Direct Connect between your on-prem infrastructure and AWS using a public virtual interfaces on the Direct Connect connection. This way, traffic between your origin and CloudFront is transported on a privately managed network, not reachable from the internet.