About the Fastly WAF rule management interface (2020)
Last updated 2020-12-07
As of June 30, 2021, the Fastly WAF (WAF 2020) offering became a legacy product. It will continue to be supported for all existing users. As an alternative, Fastly Next-Gen WAF (powered by Signal Sciences) offers proactive monitoring of and protection against suspicious and anomalous web traffic directed at your applications and origin servers. It can be controlled via the web interface dashboard or application programming interface (API). Contact email@example.com or your Fastly account team to evaluate or move to the Fastly Next-Gen WAF option.
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.
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 Home page appears displaying a list of all services associated with your account.
- 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.
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 firstname.lastname@example.org.
There are three types of rules: scoring rules, threshold rules, and application-specific rules. 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. An example scoring rule is shown below.
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.
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.
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. These rules check the total score (as calculated by scoring rules) against the value configured for the appropriate threshold. 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 Settings 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|
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.
Searching for rules
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
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.
Filtering rules by category
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.
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.
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.
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 or Block.
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 activating changes section to activate your changes.
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 Activate button to put these changes into production.
After clicking Activate, you'll see a confirmation message asking if you want to activate your changes. Click Yes to continue.
Changes to your WAF are applied only after you click the Activate button.
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.