- About the web interface controls
- Always-on DDoS mitigation
- Browser recommendations when using the Fastly web interface
- Content and its delivery
- Fastly POP locations
- Getting started with Fastly
- How caching and CDNs work
- How Fastly's CDN Service works
- HTTP status codes cached by default
- Self-provisioned Fastly services
- Sign up and create your first service
- Working with services
Domains & Origins
Domains & Origins
- Changing origins based on user location
- Connecting to origins
- Enabling global POPs
- Failover configuration
- IPv6 support
- Maintaining separate HTTP and HTTPS requests to origin servers
- Routing assets to different origins
- Setting up redundant origin servers
- Specifying an override host
- Using Fastly with apex domains
- About Dynamic Servers
- Authenticating URL purge requests via API
- Cache control tutorial
- Caching configuration best practices
- Controlling caching
- Creating and using pools with Dynamic Servers
- Creating and using server entries with Dynamic Servers
- Enabling API caching
- Enabling automatic gzipping
- Failure modes with large files
- Getting started with surrogate keys
- HTTP/2 server push
- Implementing API cache control
- Large File Support
- Logging purge requests
- Making query strings agnostic
- Purging API cache with surrogate keys
- Request collapsing
- Serving stale content
- Setting Surrogate-Key headers based on a URL
- Setting Surrogate-Key headers for Amazon S3 origins
- Single purges
- Soft purges
- Streaming Miss
- Wildcard purges
- Accept-Language header VCL features
- Authenticating before returning a request
- Basic authentication
- Creating location-based tagging
- Custom responses that don't hit origin servers
- Delivering different content to different devices
- Enabling URL token validation
- Guide to VCL
- Isolating header values without regular expressions
- Manipulating the cache key
- IP geolocation variables: Migrating to the new dataset
- Overriding which IP address the geolocation features use
- Response Cookie handling
- Support for the Edge-Control header
- Understanding the different PASS action behaviors
- Using edge side includes (ESI)
- VCL regular expression cheat sheet
Access Control Lists
Monitoring and testing
Web Application Firewall
- Log streaming: Amazon S3
- Log streaming: Microsoft Azure Blob Storage
- Log streaming: Cloud Files
- Log streaming: Datadog
- Log streaming: DigitalOcean Spaces
- Log streaming: Elasticsearch
- Log streaming: FTP
- Log streaming: Google BigQuery
- Log streaming: Google Cloud Storage
- Log streaming: Honeycomb
- Log streaming: Kafka
- Log streaming: Log Shuttle
- Log streaming: LogDNA
- Log streaming: Logentries
- Log streaming: Loggly
- Log streaming: Heroku's Logplex
- Log streaming: OpenStack
- Log streaming: Papertrail
- Log streaming: Scalyr
- Log streaming: SFTP
- Log streaming: Splunk
- Log streaming: Sumo Logic
- Log streaming: Syslog
User access and control
About the Fastly WAF rule management interface
Last updated June 20, 2019
IMPORTANT: This feature is part of a beta release. For more information, see our product and feature lifecycle descriptions.
The Fastly WAF rule management interface provides visibility and management for rules enabled on a WAF associated with a Fastly service. If you've been assigned the role of engineer or superuser, you can use the rule management interface to inspect the details of WAF rules, search and filter by rule ID or category, manage thresholds and scores, change rule modes, and deploy changes into production.
The Fastly WAF rule management interface currently has the following limitations:
- You can disable threshold rules, which is not recommended. We don't recommend disabling these because it removes categories of protection from your WAF.
- You can't roll back or undo individual rule mode changes. If you change a rule mode inadvertently, you have to change the specific rule back to its original mode. For more information on making production changes to your WAF, see the section on deploying changes.
IMPORTANT: This interface allows you to modify the rule modes on your production service. Lowering threshold scores or changing rules from log to block may cause unexpected false positives.
Accessing the Fastly WAF rule management interface
You can access the Fastly WAF rule management interface from the WAF dashboard. To access the Fastly WAF rule management interface, follow the steps below:
Log in to the Fastly web interface. The All services page appears.
- Find your Fastly service in the list, and then click the WAF link. The WAF summary page appears.
Click the Manage Rules link. The Manage rules page appears.
Using the Fastly WAF rule management interface
The Fastly WAF rule management interface displays the rules currently enabled on the WAF associated with the selected Fastly service. If you haven't enabled rules or you don't see any rules on your WAF, contact email@example.com.
The Fastly WAF rule management interface consists of the following main sections:
WAF status bar
The status bar summarizes the status of your WAF.
- Status Indicator: Displays Active (green) when the WAF is active on your service and protecting your origin.
- WAF ID: Displays the WAF ID with a feature that allows you to copy the ID to the clipboard. The WAF ID may be used when accessing the Fastly WAF API.
- Abbreviated Rule Summary: Shows your active rules and their associated mode.
- Deployment Date: Shows the date and time (UTC) of the last successful service deployment that includes the VCL generated from the WAF rules enabled on this service.
The rule view shows a list of all of rules currently enabled on your WAF and their associated mode. There are three types of rules: scoring rules, threshold rules (also called threat categories), and application-specific rules.
Rules have a rule name, tags, revision indicator, rule ID, mode selector, and Details link. The revision indicator is used to indicate whether or not a rule has been revised. A revised rule may provide additional protection over and above the earlier revision.
Scoring rules increment a score based on anomalies detected in the incoming HTTP request, and threshold rules check that total against the value configured for the appropriate threshold. An example scoring rule is shown below.
TIP: Fastly sets default anomaly scores for four categories of rules. When an HTTP request trips a rule in a category, that numeric value is added to the total score for that category. The sum of all the rules' scores is the anomaly score for the HTTP request. For example, if an HTTP request trips a critical rule and an error rule, and the critical anomaly score is set to 6 and the error anomaly score is set to 5, the score for the HTTP request would be 11.
We don't recommend changing the values of the anomaly scores. Instead, we recommend changing the values of the thresholds on the Thresholds and Scores page.
Scoring rules have two possible modes:
- Scoring: This mode means a rule is active and looking for threats. Rules in this mode will increment scores and log their result to your currently configured logging provider based on the setting for the corresponding threshold rule. For more information on threshold rules, see the section on threshold rules.
- Disabled: This mode means a rule is inactive. Threats detected by this rule will NOT count towards your total anomaly score and their result will not be logged.
You can click the Details link to see the format of a rule in the Apache ModSecurity format as well as the corresponding generated VCL.
IMPORTANT: The generated VCL shows a general transformation from the Apache ModSecurity language to VCL. The VCL shown here does not show how a rule increments your anomaly score based on your configured values.
Threshold rules cover a specific category of attack against your web application or API. An example threshold rule is shown below.
The threshold rule has a category name, revision indicator, tag, rule ID, mode selector, and Details link.
Threshold rules perform an action and either log or block and log client HTTP requests. These rules take action when a score exceeds a given threshold value. The corresponding threshold value for each category is configured on the Thresholds and Scores page.
Lowering thresholds increases the sensitivity of your WAF. Raising thresholds reduces the sensitivity of your WAF across the various threshold categories.
The Fastly WAF includes the following threshold rules organized into categories. Each rule has a corresponding threshold value that controls its sensitivity.
|ID||Threshold Name||Rule Action Condition||Corresponding Threshold Value||Action Choice|
|1010090||Inbound Anomaly Score||Action taken when the inbound anomaly score exceeds the configured inbound anomaly threshold||Inbound anomaly threshold||Log or Block & Log|
|1010080||Session Fixation||Action taken when the session fixation score exceeds the configured session fixation threshold||Session fixation threshold||Log or Block & Log|
|1010070||HTTP Violation||Action taken when the HTTP violation score exceeds the configured HTTP violation threshold||HTTP violation threshold||Log or Block & Log|
|1010060||PHP Injection||Action taken when the PHP injection score exceeds the configured PHP injection threshold||PHP injection threshold||Log or Block & Log|
|1010050||Remote Command Execution (RCE)||Action taken when the RCE anomaly score exceeds the configured RCE threshold||RCE threshold||Log or Block & Log|
|1010040||Local File Inclusion (LFI)||Action taken when the LFI score exceeds the configured LFI threshold||LFI threshold||Log or Block & Log|
|1010030||Remote File Inclusion (RFI)||Action taken when the RFI score exceeds the configured RFI threshold||RFI threshold||Log or Block & Log|
|1010020||Cross-site Scripting (XSS)||Action taken when the XSS score exceeds the configured XSS threshold||XSS threshold||Log or Block & Log|
|1010010||SQL Injection||Action taken when the SQL injection score exceeds the configured SQL injection threshold||SQL injection threshold||Log or Block & Log|
IMPORTANT: Disabling a threshold rule removes an entire category of protection from your WAF. Use caution when disabling threshold rules.
Application-specific rules look at incoming HTTP requests to find signatures designed to take advantage of specific vulnerabilities within the context of a specific library, framework, or component. They take effect immediately. Application-specific rules have three possible modes:
- Logging Mode: This mode means a rule is active and looking for threats. Rules in this mode will log their result on an exact match. The result is logged to your currently configured logging provider.
- Blocking Mode: This mode means a rule is active and looking for threats. Rules in this mode block the HTTP request and prevent it from going to the origin. Rules in blocking mode also log the result to your currently configured logging provider.
- Disabled: This mode means a rule is inactive. HTTP requests that match a rule will flow directly to your origin.
The rule search box allows you to search for a specific rule using the rule ID or keyword. The result is shown in the Rule View.
Keyword search allows you to search for rules that contain a specific query string in the rule source. For example, you can search for rules that contain keywords such as
ddos. Keyword search compares your query string against the rule's mod_security source.
You can control the scope of the search through the use of the Include all and Exclude applied filters. Selecting Include all expands the search to the entire rule library as well as the rules currently active on your WAF. Selecting Exclude applied searches only the rules in the library that are not currently active on your WAF.
The category filters allow you to view the different types of rules currently configured on your WAF. Filters can be combined.
- Status filter: Allows you to filter by rule mode for log, block, or disabled.
- Publisher filter: Allows you to filter by rule publisher. Currently supported publishers include OWASP, Trustwave, and Fastly.
TIP: Use the Publisher filter and select OWASP to show all rules in scoring mode.
- Attack type filter: Allows you to show the rules enabled on your WAF that offer protection for specific categories of attack.
Thresholds and scores
The Thresholds and scores page allows you to configure thresholds and other OWASP security policy settings. You can access these settings by clicking the Thresholds and Scores link.
This page can be used to tune the sensitivity of your WAF with respect to thresholds and scores.
Adding new rules to your WAF
You may want to add new rules to your WAF based on changing attack patterns and risks to your application. You can add new rules by using the scope filters displayed under the search box to browse, search, and select new rules. Selecting the Include all filter will display all rules in the current rule library in the Rule View.
TIP: By selecting Include all, you will see considerably more rules than you have currently active. Pagination allows you to browse through the rule base.
Once the rules are available to browse, you can use the search box to search for a specific rule ID or keyword. For example, if you're interested in protecting against Apache Struts2 vulnerabilities published in CVE-2017-9805, you might search for
The Rule View will appear as follows.
You can view the rule source by selecting the Details link. This provides you with more information about how the rule executes in VCL.
You can enable a rule by selecting Options and changing the mode to either Log only or Block.
TIP: The available options for OWASP rules are Scoring and Disabled. To enable a new OWASP rule, select Scoring.
Verifying a rule is active
After you select the rule mode, the rule appears at the top of the rule view. To verify that your rule was added, you should deselect the Include all filter and use the Status, Publisher, or Attack type filters and confirm that the rule has been added to your WAF.
After you verify that the rule has been added, follow the instructions in the deploying changes section to deploy your changes.
WAF policy execution
When the Fastly WAF processes an inbound request, scoring rules execute first followed by threshold rules. Application-specific and Fastly rules are executed last.
If the accumulated score exceeds the configured threshold, the threshold rules take action. For more information on the threshold categories and action condition, please see the table in the threshold rules section.
The Fastly WAF rule management interface allows you to change rule modes and threshold values that change the way rules behave in the face of potential web-oriented attacks. After changing rule modes, you can click the Deploy button to put these changes into production.
After clicking Deploy, you'll see a confirmation message asking if you want to deploy your changes. Click Yes to continue.
Once the deployment is complete, you can verify that the changes were deployed by looking at the date below the deploy button.
IMPORTANT: Changes to your WAF only occur after you select the Deploy button.