Maintaining Edge WAF deployments using the Next-Gen WAF control panel

Once the Edge WAF is deployed, Fastly will manage the deployment and regularly update the Edge WAF's detection engine (e.g., SQL injection detection improvements). However, you may need to perform the occasional maintenance task, such as:

• updating the VCL version of your deployment when Fastly releases a new Next-Gen WAF feature that you want to use.
• synchronizing the origins if you don’t have dynamic backends enabled and you changed your origins in the Fastly control panel.
• enabling health check logic to skip inspection when something is wrong with the Edge WAF.

Updating the VCL version

Any time new Next-Gen WAF functionality is released, you'll need to update the VCL version of your Edge WAF deployment to use it. You can do this using the following steps:

1. Log in to the Fastly control panel.
2. From the Home page, select the appropriate service. You can use the search box to search by ID, name, or domain.

3. Go to Service configuration > VCL snippets.

4. In the Dynamic snippets area, check whether the following Next-Gen WAF snippets exist:

   • ngwaf_config_init
   • ngwaf_config_miss
   • ngwaf_config_pass
   • ngwaf_config_deliver

5. If the snippets exist, call the `PUT deliveryIntegration/{fastlySID} API endpoint in a terminal application:

   $ curl -H "x-api-user:${SIGSCI_EMAIL}" -H "x-api-token:${SIGSCI_TOKEN}" \
   -H "Fastly-Key: ${FASTLY_KEY}" -H 'Content-Type: application/json' -X PUT \
   "https://dashboard.signalsciences.net/api/v0/corps/${corpName}/sites/${siteName}/deliveryIntegration/${fastlySID}"

   This API call clones your active CDN service, updates the VCL version of the Next-Gen WAF snippets, and activates the cloned service version.

6. If the snippets don't exist, ask Fastly Support to update your VCL version.

Synchronizing origins for CDN services

If you change your origins in the Fastly control panel and don't have dynamic backends enabled, you need to synchronize your origins.

Checking whether dynamic backends are enabled

You do not need to synchronize your origins if you have dynamic backends enabled. To check if you have dynamic backends enabled, complete the following steps:

1. Log in to the Fastly control panel.
2. From the Home page, select the appropriate service. You can use the search box to search by ID, name, or domain.
3. Go to Service configuration > VCL snippets.
4. In the Dynamic snippets area, click View source next to the ngwaf_config_init snippet.
5. Search the snippet code for backendtoken. If backendtoken exists, you have dynamic backends enabled and don't need to synchronize your origins.

Conditions that cause automatic origin synchronizing

Some conditions cause origin syncing to occur automatically:

• site (workspace) configuration changes
• Agent mode (also known as Protection mode) changes
• Enabling or disabling IP Anonymization
• Rule changes (e.g., request rules, signal exclusion rules, CVE rules)
• Rule list changes (only if the list is being used by a rule)
• IP addresses flagged

Manually synchronizing your origins

To synchronize your origins, call the following endpoint in a terminal application:

$ curl -v -H "x-api-user:${SIGSCI_EMAIL}" -H "x-api-token:${SIGSCI_TOKEN}" \
-H "Fastly-Key: $FASTLY_KEY" -H "Content-Type:application/json" -X PUT \
"https://dashboard.signalsciences.net/api/v0/corps/${corpName}/sites/${siteName}/deliveryIntegration/${fastlySID}/backends"

This call makes sure origin changes applied in the Fastly control panel are reflected in the edge security service.

Skipping inspection when the deployment is unhealthy

The edge security service includes a health check, which skips security processing entirely if the edge security service is unhealthy for any reason. The health check works by sending a periodic probe every 15 seconds and checking for HTTP status code 200 as an expected response. Should a check indicate an unhealthy service, all security processing is skipped until the service becomes healthy again. It may take up to 60 seconds for all security processing to be skipped.

The edge security service is modeled as an origin using the backend type. The health check lives inside the edge_security function and uses the backend.health property to check the status of the edge security service.

Determining if you already use health check logic

You can check if your service already uses health check logic by inspecting the value of the x-sigsci-edgemodule HTTP header, which is added to the request prior to being sent to the edge security service. If the value is greater than or equal to 1.6.0, then your VCL includes the health check logic.

Enabling health check logic

To enable the health check for an existing service, make sure your VCL is updated to the latest version. Then, test the health check logic by toggling the Agent mode (Protection mode) to Off. This will simulate an unhealthy state for the edge security service and processing will be skipped.