Shield's Firewall module is designed to analyse data sent to your WordPress website and block any requests that appear to be malicious. 


There are 9 Firewall Blocking options that determine what data is checked on each page request. Depending on certain incompatibilities with other plugins, you may need to disable certain options to ensure maximum compatibility, or to whitelist parameters.


Firewall Blocking options are as follows:

  • Include Cookies - The Firewall tests GET and POST, but with this option checked you can also have it check the site cookies.
  • Directory Traversals - Blocks directory traversal paths in application parameters (e.g. ../, ../../etc/passwd, etc).
  • SQL Queries - Blocks sql in application parameters (e.g. union select, concat(, /**/, ..), etc).
  • WordPress Terms - ensures that some of the most common terms are restricted. It will block WordPress specific terms in application parameters (wp_, user_login, etc.).
  • Field Truncation - Blocks field truncation attacks in application parameters.
  • PHP Code - Blocks any data that appears to try and include PHP files. It will probably block saving within the Plugin/Theme file editors.
  • Exe File Uploads - Blocks executable file uploads. When files are uploaded to your site, this option looks for executable file extensions such as .dll, .php, .exe, .py, etc.
  • Leading Schemas - Blocks leading schemas http:// and https:// in application parameters (off by default; may cause problems with other plugins).
  • Aggressive Scan - Aggressively blocks data. It employs a set of aggressive rules to detect and block malicious data submitted to your site.
    Important: Be careful with this option. It may cause an increase in false-positive firewall blocks.

Read more about Firewall Blocking here.


When Firewall blocks something on your site, the first thing to do is to go to your Audit Trail. Please see here.


Once you find the Firewall entries (what's triggering the block), go to Firewall module => Whitelist => and whitelist parameters that's getting blocked. Please see here.

How to interpret Firewall entry in the Audit Trail and whitelist parameters

Here're a few examples of the Firewall entries and what should be whitelisted (please also see the screenshot at the end of the page):


Example 1


Firewall block  Page parameter failed firewall check. The offending parameter was \"redirect\" with a value of \"https://testsite.com/\".
- Firewall Trigger: Leading Schema.
- Firewall Block Response: Visitor connection was killed with wp_die() and a message.


The parameter to whitelist is "redirect". So the rule would be:


*, redirect


Alternatively, you can turn off the "Leading Schema" option as that's the firewall rule being triggered.


Example 2


Firewall block  Page parameter failed firewall check. The offending parameter was \"fusion_patch_contents_415804\" with a value of \"xxxxxxxxx=\".
- Firewall Trigger: WordPress Terms.
- Firewall Block Response: Visitor connection was killed with wp_die() and a message.


In this case the white list rule would be:


*, fusion_patch_contents_415804


Alternatively, you can turn off the "WordPress Terms" option as that's the firewall rule being triggered.


Example 3


Firewall block     Page parameter failed firewall check. The offending parameter was \"w2dc-field-input-url_7\" with a value of \"http://www.testsite.com\".
- Firewall Trigger: Leading Schema.
- Firewall Block Response: Visitor connection was killed with wp_die() and a message.


In this case, according to the logs, you'd be adding something like:

*, w2dc-field-input-url_7

... as that's the name of the parameter holding the value that's triggering the block.

Alternatively, you can turn off the "Leading Schema" option as that's the firewall rule being triggered.


Example 4


Firewall block    Page parameter failed firewall check. The offending parameter was \"page\" with a value of \"xxxxx\".

Parameter to whitelist is: 


page

Example 5


Firewall block    Page parameter failed firewall check. The offending parameter was \"test-field-input-url_7\" with a value of \"https://www.testsite.com\".


Parameter to whitelist is:


*, test-field-input-url_7


... as that's the name of the parameter holding the value that's triggering the block.


Example 6


Firewall block     Page parameter failed firewall check. The offending parameter was "customized" with a value of "{"old_sidebars_widgets_data":{"wp_inactive_widgets":[],"sidebar-1":["search-2","recent-posts-2","recent-comments-2","archives-2","categories-2","meta-2"],"sidebar-2":[],"sidebar-3":[]}}". Firewall Trigger: Aggressive Rules

Firewall Block Response: Visitor connection was killed with wp_die() and a message.

Parameter to whitelist is:


*, customized


How to use asterisk


The asterisk refers to the page name, so you can say "all pages" using asterisk "*", or specify a page: plugins.php, parameter_name.


For example, you want to whitelist the following parameters for all pages:

  • s
  • post_type
  • shop_view
  • add_to_wishlist


To achieve this, you use the following rule as each page (or asterisk) can only appear once:

 

*, s, post_type, shop_view, add_to_wishlist

 

This will whitelist those 4 parameters for all pages.


Another example is if you want to do this for 1 particular page, e.g.:

 

posts.php, s, post_type, shop_view, add_to_wishlist