Fastly WAF logging (legacy)

Fastly provides a number of WAF-specific logging variables to help you monitor and identify potentially malicious traffic. These variables provide specific details about the actions Fastly WAF performed on a request.

Setting up a logging endpoint

To begin monitoring requests for potential malicious activity, set up remote logging so you can log WAF variables. You can use an existing logging endpoint or add a new endpoint specially for Fastly WAF. You'll use the information provided in the logs to monitor WAF events.

OWASP rules

A single request can trigger multiple OWASP rules. By default, logging occurs in vcl_deliver or vcl_log. When logs are captured in vcl_deliver or vcl_log, it will show the last WAF rule triggered and the cumulative anomaly score.

waf_debug_log

The waf_debug_log subroutine allows logging of each OWASP rule triggered for a single request. You can use the web interface or the API to update the logging placement parameter to waf_debug.

Using the web interface

Follow these instructions to set a logging endpoint's placement parameter to waf_debug:

  1. Log in to the Fastly web interface.
  2. From the All services page, select the appropriate service. You can use the search box to search by ID, name, or domain.
  3. Click the Edit configuration button and then select the option to clone the active version. The Domains page appears.
  4. Click the Logging link. The Logging endpoints page appears.
  5. Click the name of a logging endpoint to edit it. The Edit this endpoint page appears.
  6. Click the Advanced options link.
  7. In the Placement section, select the waf_debug (waf_debug_log) setting.

    the logging placement setting

  8. Click the Update button.
  9. Click the Activate button to deploy your configuration changes.

Using the API

You can also update the logging placement parameter to waf_debug by running the following cURL command in a terminal application:

1
$ curl -X PUT -H 'Fastly-Key: FASTLY_API_TOKEN' -H 'Content-Type: application/json' 'https://api.fastly.com/service/<your Fastly service ID>/version/<version_id>/logging/<logging_integration>/<logging_name>' --data-binary '{"placement":"waf_debug"}'
  • waf_debug_log accepts the logging format via the web interface only
  • waf_debug_log is called in vcl_miss and vcl_pass. The logging format can include request headers and WAF variables. Response headers will result in an error message.
  • <logging_integration> can be found listed in our remote logging API.

We recommended creating a request_id header to track a single request through multiple OWASP rules:

1
set req.http.x-request-id = digest.hash_sha256(now randomstr(64) req.http.host req.url req.http.Fastly-Client-IP server.identity);

Using WAF-specific variables

Fastly provides a number of WAF-specific logging variables to help you monitor and identify potentially malicious traffic. These variables provide specific details about the actions Fastly WAF performed on a request:

  • Whether or not Fastly WAF inspected a request. Fastly WAF only inspects traffic that is forwarded to your origin server (e.g., MISS or PASS requests for content that is not already cached).
  • Whether or not a rule matched the request. When Fastly WAF inspects a request, it checks to see if the request matches any of the rules in your rule set.
  • The severity of the rule that matched. If the request matches a rule, the log indicates the severity of the rule.
  • The action taken, if any. If the request matches a rule or OWASP threshold, the log indicates whether Fastly WAF simply logged the request or blocked it.

You can use the following variables to examine Fastly WAF log events.

Variable Description
waf.executed A response header indicating if WAF was executed or not. Appears as 1 (true) when executed or 0 (false) when not.
waf.blocked Set to true when the request matches and the specific rule or OWASP threshold is configured to block. Will appear in log files as 1 (true) when blocked or 0 (false) when not.
waf.logged Set to true when the request matches and the specific rule or OWASP threshold is configured to log. In active (blocking) mode, set to true when waf.blocked is also true. Will show up in the logs as 1 (true) or 0 (false).
waf.failures A request exits the WAF rule set due to a failure to evaluate. Will show up in the logs as 1 (true) or 0 (false).
waf.logdata Why (specifically) this rule matched. Includes the portion of the request that triggered the match, so it may look different depending on the rule.
waf.message A message describing the generic condition this rule matched. For example, SLR: Arbitrary File Upload in Wordpress Gravity Forms plugin.
waf.rule_id The rule ID for this rule.
waf.severity The severity of the rule. 0 is the highest severity and 7 is the lowest severity. 99 indicates that severity is not applicable (e.g., the request did not match any rules).
waf.anomaly_score Cumulative score returned if request triggers OWASP rules. See OWASP category score variables.
waf.passed Indicates if the request doesn't match any rules in the WAF rule set. Will show up in the logs as 1 (true) or 0 (false). waf.passed is readable in vcl_deliver and vcl_log. It is not readable in waf_debug_log. The value is determined after the request has gone through the WAF rule set.

OWASP category score variables

As a request goes through the OWASP rules, it can trigger different rule IDs from different attack categories. OWASP category score variables track which categories were triggered and the scoring that contributed to the cumulative score. They can be used to get a sense of minimum, average, and maximum values for a specific attack category and set thresholds individually. When in active (block) mode, if a request exceeds the category threshold, it will be blocked.

  • waf.sql_injection_score
  • waf.rfi_score
  • waf.lfi_score
  • waf.rce_score
  • waf.php_injection_score
  • waf.session_fixation_score
  • waf.http_violation_score
  • waf.xss_score
Back to Top