Part 3: WordPress Firewall – Shield Security Plugin for WordPress

• Part 1: Why we built the Shield
• Part 2: WordPress Super Admin Protection
• Part 3: WordPress Firewall Feature
• Part 4: WordPress Login and Brute Force Hacking Protection
• Part 5: The WordPress Comment SPAM Killer
• Part 6: WordPress Automatic Updates Management

The Firewall module is just one part of the whole Shield security system.

In this part of the series we’ll detail what exactly the firewall is, what it does, how it works, and how you should configure it.

What is the WordPress Firewall and how does it work?

The firewall component of the plugin is an Application Level Firewall.

This means it only acts, and can only act, at the WordPress level. It does not, and cannot ever, affect lower levels on the server. It can never block incoming connections from IP addresses and/or to ports on the server.  No WordPress plugin can do this.

No WordPress plugin can do this, no matter what they tell you.

We don’t write to the core .htaccess files on principle, so we don’t affect how Apache handles web requests. Instead, we examine the data in these requests and then allow or block WordPress from loading depending on the rules you have chosen.

The plugin analyses the information contained within the GET and POST data sent to your site. This is explained in more detail here.

When it detects something that it doesn’t like – it’ll kill that web request and prevent WordPress from loading any further.

In this way, it prevents WordPress from receiving/using malicious data that’s been sent to it to for the purpose of causing trouble.

Understanding the WordPress Firewall options

The firewall component of the plugin has a number of options associated with it. Below is an outline of these to help better understand each section:

Firewall Block Response

This option specifies how the plugin will respond when the firewall detects malicious data.

You have 4 possible responses:

• [default] kill the running PHP process and display a friendly message
• immediately kill the running PHP process
• redirect the web request to a 404 page
• redirect the web request to the homepage

Whichever you choose is down to your personal preference. We recommend the first one (the default) so that in the case a legitimate visitor trips the firewall with a false positive, it can be more easily identified and reported.

Send Email Report: This option, when enabled will send the administrator an email notifying them of a firewall block incident.

We recommend to keep this turned off. There is just no need to bother with these notices. It’s useful however when you are debugging the firewall when you suspect interference with/from other plugins.

---

Firewall White Listing and Ignore Options

It’s possible to specify certain factors that completely by-pass all Firewall checking.

These options should be used sparingly and with caution since you never want to white list anyone, even yourself, unless you really must.

Whitelist Parameters: This is an advanced setting where you can by-pass the firewall for a given page such as ‘hello.php’, or by-pass the firewall for a given parameter sent to that page. This is useful where certain pages/plugins submit data that you always want to leave untouched by the firewall.

Ignore Administrators: This is not a recommended option, but if you want to ensure that administrators are never affected by the firewall, turn this option on.

In general, there is no need to white list anything unless there is a compatibility issue to deal with.

---

Firewall Blocking Options

There are 7 firewall 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.

Here are just a few of them:

Directory Traversals: Default – On. There is typically no need for file paths that indicates attempts to move between directories on the filesystem. Be careful, as this might interfere with sites that publish content containing code snippets – it might be an idea to use the “ignore administrators” option mentioned above.

SQL Queries: Default – Off. This will block sql in application parameters (e.g. union select, concat(, /**/, ..), etc).

WordPress Terms: Default – Off. Malicious requests might try and reference common WordPress terms in their attacks – this option ensures that some of the most common terms are restricted. If any option is likely to interfere with normal operations, it’s probably this one.

Field Truncation: Default – On. Much like file system traversals, you typically shouldn’t have SQL queries in data submitted to your site. This option will try to look for keywords and patterns associated with SQL queries.

PHP Code: Default – Off. Again, just like SQL, WordPress terms etc., you typically shouldn’t have PHP code in data submitted to your site. If you use the plugins/themes editor, this might trip the Firewall checks.

Exe File Uploads: Default – Off. When files are uploaded to your site, it looks for executable file extensions such as .dll, .php, .exe, .py etc.

Aggresive Scan: Default – Off. Employs a set of aggressive rules to detect and block malicious data submitted to your site. May cause an increase in false-positive firewall blocks.

---

WordPress Firewall Feature Summary

As you can see, Shield’s Firewall component is full-featured and easily customized to fit as many site configurations as possible.

Firewall checking begins right after all site plugins are loaded and before WordPress really begins to kick-off. Of course, adding all this checking to every page request adds extra processing, but we’ve written the firewall component (just like the rest) to be as efficient as possible and to only scan where there is data to process.

If you have any questions about the firewall, or wish to request some features, please drop us a message in the comments section below, or contact us in our support centre.