Installation and Configuration

The Netacea Cloudfront integration detects bot activity and performs mitigating actions in line with the client blocking strategy.

Pre-requisites

To successfully integrate using Netacea, you will need:

1. An AWS account with administrative priviledges for Lambda and CloudFront.

2. A working Amazon CloudFront distribution.

3. Lambda code file (.zip) - provided by Netacea*

4. Details of the relevant API and Secret keys, and a Kinesis endpoint - provided by Netacea.

*The .zip file that Netacea has shared with you contains the code dependencies, the three Lambda functions and the configuration file NetaceaConfig.js which should be populated with the details of your integration with Netacea.

Creating the Lambdas

Lambda functions must be created in the us-east-1 AWS region, otherwise they will not be available for use with CloudFront.

Create Function

You will need to create the following three functions, by completing the steps outlined further below:

• netacea_origin_response

• netacea_viewer_request

• netacea_viewer_response

Creating the Function

Each function should be created with the default settings under "Basic Information".

Create Function Example Screenshot

Permissions

When creating the Lambdas, it is important ensure they have the correct default execution role. The policy it should contain is Basic Lambda@Edge permissions (for CloudFront trigger). If there is no role with this policy, one will need to be created. Please see below:

Permissions Example Screenshot

Uploading the Zip File

Once the Lambda function has been created, the Netacea code will need to be added by uploading the supplied zip file.

Upload the Netacea supplied zip file.

Upload the zip file

Once the file has been uploaded to the function, open the NetaceaConfig.json from the code source UI and populate it with the details Netacea has shared with you.

For more information regarding each attribute in the config file, please see below:

The code snippet below shows the NetaceaConfig.json file discussed above. This must be populated with the details Netacea has provided for your organisation.

{
  "apiKey": "API-KEY-PROVIDED-BY-NETACEA",
  "secretKey": "SECRET-KEY-PROVIDED-BY-NETACEA",
  "mitigationType": "PREFERRED-MITIGATION-TYPE",
  "kinesis": {
    "kinesisStreamName": "NAME-PROVIDED-BY-NETACEA",
    "kinesisAccessKey": "KEY-PROVIDED-BY-NETACEA",
    "kinesisSecretKey": "KEY-PROVIDED-BY-NETACEA"
  },
  "cookieEncryptionKey": "ENCRYPTION-KEY-PROVIDED-BY-NETACEA",
  "netaceaCookieName": "_cookieName",
  "netaceaCaptchaCookieName": "_captchaCookieName"
}

The attribute mitigationType is used to determine the mode of the integration. This can be one of three values:

• "INGEST" - This integration mode is monitoring only, meaning that no mitigation actions will be executed. This is recommended during POCs.

• "MITIGATE" - This is the "normal" integration mode, meaning that the Netacea solution will monitor and actively mitigate requests.

• "INJECT" - This mode is used in custom solutions in which the mitigation action by Netacea will only be a recommendation using HTTP headers added to the request.

The last three configuration variables are used to increase security by concealing Netacea's default cookie names and values from public view.

Once the NetaceaConfig.json code has been updated, click the Deploy button to save your changes.

Edit Runtime Settings

The Runtime settings will need to be updated.

Edit Runtime Settings

Scroll below Code Source to the Runtime settings section and click the Edit button.

Here, change the default handler from index.handler to the relevant funtion's name you are creating (e.g. use OriginResponse.handler for the netacea_origin_response function) . Use the below list to correlate the function name with the correct handler function:

• netacea_origin_response -> OriginResponse.handler

• netacea_viewer_request -> ViewerRequest.handler

• netacea_viewer_response -> ViewerResponse.handler

Once the correct handler has been specified, click Save.

Adding the Triggers

Once the changes have been saved and deployed, a CloudFront trigger needs to be added to the Lambda function. This allows the CloudFront distribution to execute the Lambda. At the bottom left of the Function overview section, click Add Trigger.

A Trigger configuration page will be displayed, where the option to select a trigger from the dropdown will be presented to the user. For the source, select CloudFront.

Select Deploy to Lambda@Edge and select the correct distribution, and CloudFront Event, which will be the same name as the function you just created (e.g. Viewer Request).

For the Viewer Request based event, select the option to Include Body.

Select Confirm deploy to Lambda@Edge and then click Deploy.

Once deployed, this will create a new version of the function and associate the CloudFront trigger. This function will be replicated across all regions and the associated distribution will be updated also.

Please ensure the above steps for creating the function and adding a trigger have been completed for each Lambda@Edge function (netacea_viewer_response, netacea_viewer_request, and netacea_origin_response)

Testing

To test the Lambdas, select the Test tab and create a new event.

CloudFront

From within the CloudFront dashboard, you will be able to see the Lambda functions associated with the distribution.

If you select your CloudFront distribution and select Behaviors, you will see the Function associations at the bottom of the page. This shows the Function Type (Viewer request, Viewer response, Origin request) and their associated Lambda@Edge function.

Finishing Up

Once the the above steps have been completed and the functions are deployed, the Netacea plugin will be active.

Please get in touch with Netacea to discuss the next steps and ensure the implementation of the integration with Netacea has been successful.