Skip to content

Wallarm Connector for Amazon CloudFront

CloudFront is a content delivery network operated by Amazon Web Services. Wallarm can act as a connector to secure and monitor traffic delivered through CloudFront.

To use Wallarm as a connector for CloudFront, you need to deploy the Wallarm node externally and run Wallarm-provided Lambda@Edge functions to route traffic to the Wallarm node for analysis.

The CloudFront connector supports both in-line and out-of-band traffic analysis:

If Wallarm is configured to block malicious activity:

Cloudfront with Wallarm - in-line scheme

Cloudfront with Wallarm - out-of-band scheme

Use cases

Among all supported Wallarm deployment options, this solution is recommended in case when you deliver traffic through Amazon CloudFront.

Limitations

  • Lambda@Edge function-level restrictions:

    • Lambda@Edge functions are not triggered by viewer responses with HTTP status codes 4xx.
    • Lambda@Edge does not allow access to the response body in both origin response and viewer response events, restricting the ability to perform any actions based on the content of the response.
    • The body size is limited to 40 KB for viewer requests and 1MB for origin requests.
    • The maximum response time from the Wallarm node is 5 seconds for viewer requests and 30 seconds for origin requests.
    • Lambda@Edge does not support private networks (VPC).
    • The default limit for concurrent requests is 1,000 per region, but it can be increased up to tens of thousands.
    • Wallarm Lambda@Edge functions operate at the origin level, meaning they do not monitor requests handled by CDN cache. Thus, potential attacks in such requests go undetected.
  • Feature restrictions:

Requirements

To proceed with the deployment, ensure that you meet the following requirements:

  • Understanding of AWS CloudFront and Lambda technologies.

  • APIs or traffic running through CloudFront CDN.

Deployment

1. Deploy a Wallarm node

The Wallarm node is a core component of the Wallarm platform that you need to deploy. It inspects incoming traffic, detects malicious activities, and can be configured to mitigate threats.

You can deploy it either hosted by Wallarm or in your own infrastructure, depending on the level of control you require.

To deploy a Wallarm-hosted node for the connector, follow the instructions.

Choose an artifact for a self-hosted node deployment and follow the attached instructions:

2. Obtain and deploy the Wallarm Lambda@Edge functions

To connect your CloudFront CDN with the Wallarm node, you need to deploy the Wallarm Lambda@Edge functions on AWS.

There are two Python-based functions: one for request forwarding and analysis, and another for response forwarding and analysis.

  1. Proceed to Wallarm Console → Security EdgeConnectorsDownload code bundle and download a code bundle for your platform.

    If running a self-hosted node, contact sales@wallarm.com to get the code bundle.

  2. Proceed to your AWS Console → ServicesLambdaFunctions.

  3. Select the us-east-1 (N. Virginia) region which is required for Lambda@Edge functions.
  4. Create function with the following settings:

    • Runtime: Python 3.x.
    • Execution role: Create a new role from AWS policy templatesBasic Lambda@Edge permissions (for CloudFront trigger).
    • Other settings can remain as default.
  5. Once the function is created, on the Code tab, paste the Wallarm request processing code.

  6. Update the following parameters in the code:

  7. Proceed to ActionsDeploy to Lambda@Edge and specify the following settings:

    • Configure new CloudFront trigger.
    • Distribution: your CDN that routes traffic to the origin you want to protect.
    • Cache behavior: the cache behavior for the Lambda function, typically *.
    • CloudFront event:

      • Origin request: executes the function only when CloudFront CDN requests data from the backend. If CDN returns a cached response, the function will not be executed.
      • Viewer request: executes the function for every request to CloudFront CDN.
    • Check Include body.

    • Check Confirm deploy to Lambda@Edge.

    Cloudfront function deployment

  8. Repeat the procedure for the Wallarm-provided response function, selecting responses as the trigger.

    Ensure the response trigger matches the request trigger (origin response for origin request, viewer response for viewer request).

You can deploy both functions directly from the AWS Serverless Application Repository (SAR). The functions will be deployed in the us-east-1 (N. Virginia) region which is required for Lambda@Edge functions.

  1. Go to Wallarm policies on AWS Serverless Application RepositoryDeploy.
  2. Leave the deployment settings as default.
  3. After the deployment is complete, go to the created IAM roles → Trust relationships, and update both roles (one for requests and one for responses) with the following policy:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": [
                        "edgelambda.amazonaws.com",
                        "lambda.amazonaws.com"
                    ]
                },
                "Action": "sts:AssumeRole"
            }
        ]
    }
    
  4. Proceed to your AWS Console → ServicesLambdaFunctions.

  5. Open the serverlessrepo-wallarm-connector-RequestHandler-xxx function.
  6. On the Code tab, update the following parameters:

  7. Proceed to ActionsDeploy to Lambda@Edge and specify the following settings:

    • Configure new CloudFront trigger.
    • Distribution: your CDN that routes traffic to the origin you want to protect.
    • Cache behavior: the cache behavior for the Lambda function, typically *.
    • CloudFront event:

      • Origin request: executes the function only when CloudFront CDN requests data from the backend. If CDN returns a cached response, the function will not be executed.
      • Viewer request: executes the function for every request to CloudFront CDN.
    • Check Include body.

    • Check Confirm deploy to Lambda@Edge.

    Cloudfront function deployment

  8. Return to your AWS Console → ServicesLambdaFunctions.

  9. Open the serverlessrepo-wallarm-connector-ResponseHandler-xxx function.
  10. Repeat the procedure for the Wallarm-provided response function, selecting responses as the trigger.

    Ensure the response trigger matches the request trigger (origin response for origin request, viewer response for viewer request).

Testing

To test the functionality of the deployed functions, follow these steps:

  1. Send the request with the test Path Traversal attack to your CloudFront CDN:

    curl http://<CLOUDFRONT_CDN>/etc/passwd
    
  2. Open Wallarm Console → Attacks section in the US Cloud or EU Cloud and make sure the attack is displayed in the list.

    Attacks in the interface

    If the Wallarm node mode is set to blocking and the traffic flows in-line, the request will also be blocked.

Upgrading the Lambda@Edge functions

To upgrade the deployed Lambda@Edge function to a newer version:

  1. Proceed to Wallarm Console → Security EdgeConnectorsDownload code bundle and download the updated Wallarm Lambda@Edge functions.

    If running a self-hosted node, contact sales@wallarm.com to get the updated code bundle.

  2. Replace the code in your deployed Lambda@Edge functions with the updated bundle.

    Preserve the existing values for parameters like wlrm_node_addr, wlrm_inline, and others.

    Keep the existing function triggers unchanged.

  3. Deploy the updated functions.

  1. Repeat the steps outlined in the 2nd step using the new version of the functions.
  2. After linking the updated functions to your distributions, remove the previous versions of the functions from the CloudFront triggers to avoid conflicts.

Function upgrades may require a Wallarm node upgrade, especially for major version updates. See the Native Node changelog for the self-hosted Node release notes and upgrade instructions or the Edge connector upgrade procedure. Regular node updates are recommended to avoid deprecation and simplify future upgrades.