Using the vCanopy 7G Web Application Firewall on Nginx

Part 5. Real World 7G Whitelist Rule Examples 

Now that we’ve covered the basics in the previous section on how and where to add your whitelist rules, here are some real-world examples of whitelisting without all the steps involved in creating the file, and checking and reloading Nginx which you can learn from the previous 3 examples.

When crafting rules, you can target any request using available Nginx variables, including the $uri, $request_uri, and $args variables. You can view a full list of Nginx variables here:

Alphabetical index of variables

WHITELISTING A QUERY STRING FOR SEOPRESS AND GOOGLE SEARCH CONSOLE

Whitelisting via $args

NOTE: The following is great if you use SEOPress on a WaaS network and you expect multiple clients to be connecting to Google Search Console. If that isn’t the case, the easiest and best solution is to simply deactivate the two rulesets, run the authorisation, and then turn the rulesets back on.

When connecting SEOPress to Google search console, the authorisation link results in two separate errors that looks as follows in the 7G log:

[17/Nov/2020:15:05:35 +0000] [":bad_querystring_12::bad_request_15:"] 199.199.199.199 yourdomain.com "GET /wp-admin/admin.php?page=seopress-google-analytics&code=4/0AY0e-g44ZrE9024kffJQ2LbRdRxVLOQgAruyU9wAHI1jYFCDaUo10xmwW5rpilPzqNKOSoaWlA&scope=https://www.googleapis.com/auth/analytics.readonly HTTP/1.1" 403 "https://accounts.google.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36"

We can exclude these two results by targeting “page=seopress-google-analytics&code” and adding an exclusion for both errors like so:

set $exclusion_rule_match "";
if ( $args ~* ^page=seopress-google-analytics&code ) {
set $exclusion_rule_match 15;
}
if ($bad_request_7g = $exclusion_rule_match) {
set $7g_drop_bad_request 0;
}

set $exclusion_rule_match “”;
if ( $args ~* ^page=seopress-google-analytics&code ) {
set $exclusion_rule_match 12;
}
if ($bad_querystring_7g = $exclusion_rule_match) {
set $7g_drop_bad_query_string 0;
}

WHITELISTING THE WOOCOMMERCE DOWNLOADS QUERY STRING

Whitelisting via $args and capture groups “(.*)”

WooCommerce downloads get flagged by bad_querystring_35. In this case, we can use capture groups for the query to be recognised successfully, and used the following exclusion to whitelist any URL that contains “&order=wc_order_” for this one specific rule in the bad_querystring_7g ruleset:

set $exclusion_rule_match "";
if ( $args ~* ^(.*)&order=wc_order_(.*)$ ) {
set $exclusion_rule_match 35;
}
if ( $bad_querystring_7g = $exclusion_rule_match ) {
set $7g_drop_bad_query_string 0;
}

WHITELISTING JETPACK AND THE WOOCOMMERCE SERVICES PLUGINS

Whitelisting via $uri

If you need to whitelist a specific plugin, you can use this example to craft your whitelist exclusion. Below is an example we’ve brought over from our 6G article and modified for 7G. Here we whitelist these two specific plugins against bad_request_7.

You can do the same with any plugin that you catch getting flagged by whitelisting the plugins URI path as in the example below:

set $exclusion_rule_match "";
if ($uri ~ ^/wp-content/plugins/woocommerce-services/) { 
set $exclusion_rule_match 7; 
} 
if ($uri ~ ^/wp-content/plugins/jetpack/) {
set $exclusion_rule_match 7;
} 
if ($bad_request_7g = $exclusion_rule_match) { 
set $7g_drop_bad_request 0; 
}

WHITELISTING A QUERY STRING FOR THE AMELIA PLUGIN

Whitelisting via $args

We’ve had a few cases reported where the Amelia plugin is getting flagged by bad_request_6. One of our clients gave us some great feedback on whitelisting this, and the exclusion they created will allow you to exclude Amelia from this one specific rule within the bad requests ruleset:

set $exclusion_rule_match "";
if ( $args ~* ^action=wpamelia_api& ) {
set $exclusion_rule_match 6;
}
if ( $bad_request_7g = $exclusion_rule_match ) {
set $7g_drop_bad_request 0;
}

REDIRECTION PLUGIN DATABASE UPDATE

Whitelisting via $request_uri

The Redirection plugin database update has been flagged by 7G for breaking bad_request_25. The plugin listed where things were going wrong, and the following rule allowed the database update to proceed:

set $exclusion_rule_match "";
if ($request_uri ~ ^/wp-json/redirection/v1/plugin/database/) {
set $exclusion_rule_match 25;
}
if ($bad_request_7g = $exclusion_rule_match) {
set $7g_drop_bad_request 0;
}

Note: On this one, my recommendation would actually be to simply toggle off Block Bad Requests inside the UI, run the database update, and then toggle Block Bad Requests back on. The same goes for any other instances where you don’t require ongoing whitelisting.

KADENCE CLOUD

Whitelisting via $request_uri

The Kadence Cloud plugin gets flagged due to the second URL inside the string. This same thing happens with SEOPress and Google Console as detailed above. Here though we’re going to whitelist via $request_uri instead of $args:

set $exclusion_rule_match "";
if ( $request_uri ~* ^/wp-json/kadence-cloud/v1/ ) {
set $exclusion_rule_match 15;
}
if ($bad_request_7g = $exclusion_rule_match) {
set $7g_drop_bad_request 0;
}
set $exclusion_rule_match "";
if ( $request_uri ~* ^/wp-json/kadence-cloud/v1/ ) {
set $exclusion_rule_match 12;
}
if ($bad_querystring_7g = $exclusion_rule_match) {
set $7g_drop_bad_query_string 0;
}

WHITELISTING A SEARCH QUERY STRING

Whitelisting via $args and capture groups “(.*)”

We had a case where the search results were getting flagged by bad_querystring_36. In this case we used capture groups for the query to be recognised successfully, and used the following exclusion to whitelist any URL that contains “ajax_search” for this one specific rule in the bad_querystring_7g ruleset:

set $exclusion_rule_match "";
if ( $args ~* ^(.*)ajax_search(.*)$ ) {
set $exclusion_rule_match 36;
}
if ( $bad_querystring_7g = $exclusion_rule_match ) {
set $7g_drop_bad_query_string 0;
}