How to interpret Firewall entries in the Activity Log and whitelist parameters (examples)

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

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:

  • 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.

  • 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 Activity Log and look for Firewall entries.

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

How to interpret Firewall entry in the Activity Log 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: Aggressive Scan.

- 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 "Aggressive Scan" 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: WordPress Terms.

- 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 "WordPress Terms" 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 Scan

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.

Here is additional example of the whitelisted parameter:

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