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

IMPORTANT: This guide only applies to Next-Gen WAF customers who cannot access the WAF in the Fastly control panel. If you can access the WAF in the Fastly control panel, refer to the Edge WAF deployment using the Fastly control panel guide instead.

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 edgemodule version

Any time new Next-Gen WAF functionality is released, you need to update the edgemodule version of your Edge WAF deployment to use it. The update process is safe to run at any time, even if no update is required.

IMPORTANT: Once you've updated the edgemodule version of your deployment, you cannot roll back to a prior version.

To update the edgemodule version of your deployment, 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, 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 edgemodule version of your deployment, and activates the cloned service version.

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

Synchronizing origins for CDN services

IMPORTANT: This section only applies to Next-Gen WAF customers who cannot access the WAF in the Fastly control panel. If you can access the WAF in the Fastly control panel, refer to the Edge WAF deployment using the Fastly control panel guide instead.

If you change your origins in the Fastly control panel and don't have dynamic backends enabled, you need to synchronize your origins. Failure to synchronize origins may result in your traffic not being inspected properly. Requests sent to a backend that does not exist in the Edge WAF will be served a 503 Unknown wasm backend error.

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, which would appear in the set bereq.http.x-fastly-ngwaf:edgemodule = "vcl <VERSION>;backendtoken"; line. 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

In addition to these conditions, Fastly will occasionally synchronize your origins to ensure accurate configuration of the WAF.

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 WAF includes a health check, which skips security processing entirely if the Edge WAF is unhealthy for any reason.

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 WAF. 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 edgemoduleversion 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 WAF and processing will be skipped.