Hear from Slack, the ACLU, TED, & more at our customer summit in San Francisco Register
LOG IN SIGN UP
Documentation

Fastly WAF logging

  Last updated April 15, 2017

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.

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. To point your logging endpoint to this subroutine, update the logging placement parameter to waf_debug by running the following cURL command in a terminal application:

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"}'

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

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:

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 requirement is configured to block. Will appear in log files as 1 (true) when blocked or 0 (false) when logged but not blocked.
waf.logged In monitoring mode, set to true when the request matches and that specific rule is configured to log. Will show up in the logs as 1 (true) or 0 (false). 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.


Additional resources:


Back to Top