WAF Setup: Blocking Phases


This article answers

  • What is Phased Blocking? 
  • What blocking modules are tuned in each phase?
  • What attack types are mitigated in each phase?

Note: This is just a guide. Modules can move between phases at the discretion of the SOC and the customer.



  • Silverline WAF
  • WAF Policy / Policies 


What is Phased Blocking?

The SOC recommends tuning policies in phases.

  1. In each phase, the listed modules are observed in Transparent mode for a limited period of time.
  2. Then the customer approves the SOC moving the modules into Blocking mode.
  3. SOC moves modules into Blocking mode so the modules can protect the application. 

For more information on this process, see:


What Blocking Modules and Attack Types are Tuned in Each Phase?


  • Silverline WAF has been examining incoming traffic in transparent mode.
  • Silverline WAF has satisfied user requirements pertaining to the site flow patterns.
  • Sufficient learning and tuning have taken place to ensure a low false-positive rate prior to blocking enforcement.



In this initial phase, we tune attack signatures, expected HTTP methods and HTTP status response codes.

Blocking Modules

Blocking Modules tuned in this phase:

Attack Types

Attack Type categories mitigated in this phase include:

  • Command Execution Signatures
  • Cross-Site Scripting Signatures
  • Directory Indexing Signatures
  • HTTP Response Splitting Signatures
  • Information Leakage Signatures
  • OS Command Injection Signatures
  • Path Traversal Signatures
  • Remote File Include Signatures
  • SQL Injection Signatures
  • Server-Side Code Injection Signatures
  • XPath Injection Signatures
  • Information Leakage
  • Forceful Browsing



In this phase, we tune RFC-compliance modules, look for bad format patterns that don’t comply with current RFC standards. This can be indicative of an attempted attack.

Blocking Modules

Blocking Modules tuned in this phase:

Attack Type

Attack Type categories mitigated in this phase include:

  • Detection Evasion 
  • HTTP Parser Attack 
  • Abuse of Functionality
  • Parameter Tampering



In this phase, we allowlist “known goods,” such as cookies, parameters (user name and password), and URIs. This helps us mark known good users so they will always be let through.

Blocking Modules

Blocking Modules tuned in this phase:

  • Parameter related violations (when configured)
  • Illegal File Type
  • Illegal Redirection Attempt
  • Modified Domain Cookies
  • Illegal URL (for allowed URLs, when appropriate for the application)
  • Malformed JSON data
  • Malformed XML data

Attack Types

Attack Type categories mitigated in this phase include:

  • Abuse of Functionality
  • Cross-Site Scripting (XSS)
  • Cross-site Request Forgery
  • Forceful Browsing
  • Illegal Redirection
  • Parameter Tampering
  • Path Traversal
  • Predictable Resource Location
  • Remote File Include
  • Server-Side Code Injection
  • Session Hijacking
  • SQL-Injection
  • Trojan/Backdoor/Spyware
  • Vulnerability Scan
  • Web Scraping
  • XML Parser Attack


OTHER MODULES (optional)

These modules are not enabled by default but are typically enabled in consultation with the SOC and/or in response to specifically identified application protection requirements.  Such modules are transitioned to blocking as agreed between the SOC and the Customer, and they are not considered part of any specific Phase.

Blocking Modules

Common additional modules:


Attack signature logic

  • How to distinguish between false positive requests that triggered an attack signature violation and malicious requests.

1. High Occurrences of an Attack Signature

a. Classic False Positive – The attack signature does not comply with the application logic. Options:

• Disable attack signature (either globally or on a parameter level)
• Create a user defined attack signature (could be complex)
• Open a case with F5 SOC requesting to tune the attack signature

b. Malicious Attack – Could be a malicious worm or script that is endlessly hitting the web application. How could this be determined?

• Are there any additional attack signatures that are triggered with these requests?
• Check the user-agent on the request. Is it a valid browser?

2. SQL Injections/XSS Attacks – SQL/XSS based attack signatures look for a combination of words and Metacharacters, an efficient malicious SQL/XSS based injection attack will most probably trigger a number of different attack signatures in WAF. When encountering false positives where legitimate users are getting blocked on valid texts follow the below procedures:

     a. Disable the specific attack signature

• Disable the attack signature on the specific parameter
• Disable the attack signature globally

b. Open a support ticket and request to have the attack signature less generic and more specific.


Related Content

Was this article helpful?
4 out of 4 found this helpful
Have more questions? Submit a request