Table of Contents
Content Error or Suggest an Edit
Notice a grammatical error or technical inaccuracy? Let us know, we will give you credit!
You’ve reached a draft 🤷♂️ and unfortunately, it’s a work in progress.
I was replying to a post on the Self Managed WordPress Facebook group and decided to write an article about this specific question a user asked
Anyone have security plugin recommendations? I’m using iThemes security pro for a pretty good while, but I keep running into issues with it on Gridpane, especially multisite.Self Managed WordPress Facebook Group
Or is GP’s built in security enough to not have to worry about a separate security plugin?
I’ve been doing lots of research in this area. There is a number of plugins to stop in-line attacks, similar to a WAF or what is called “virtual patching”.
Unfortunately, any plugin you add isn’t going to protect you 100% due to the fact it can only be initiated on WordPress pages. This means that you won’t have protection on PHP pages that don’t actually call WordPress core.
Granted you shouldn’t have non-WordPress files on your site. But if you’re already infected or a file is uploaded via FTP or another method. There is no real protection since WordFence or other plugins can’t see these files.
However, as per Scott’s comment on this post. This isn’t 100% true.
This isn’t 100% true. Wordfence already has the ability to at least begin processing any PHP request, which it does by specifying:Scott @ Disqus Comment
The extent to which they take advantage of this outside WordPress remains to be seen, but the architecture is in place.
WordFence does protect against this using the Extended Protection Mode.
“The Extended Protection mode of the Wordfence Web Application Firewall uses a PHP configuration called auto_prepend_file in order to ensure it runs before any potentially vulnerable code runs.”Wordfence Documentation
Traditionally this is supported using a .htaccess for Apache, however, with the rise of Nginx hosting stacks, this doesn’t work. Instead, you need to ensure your hosting provider allows you to specify PHP configuration in a
A traditional WAF will inspect traffic during the client connection to the server. Cloudflare does this as all traffic is passing through Cloudflare, unless the attacker knows your origin, watch out for the ftp.domain.com record.
There are also WAF’s available in popular web server software like Apache/NGiNX/LiteSpeed using modsec rules, which is what GridPane is using. However, it’s actually very taxing when you use a large number of rules, and will actually slow down the number of requests you can serve. So for large sites, this might be an issue.
The issue with a PHP WAF is that it’s coded in PHP which is at times slow and resource-intensive. Facebook tried to solve the PHP issue with HHVM, but that’s now abandoned due to PHP getting better overall performance-wise, and trying to make everything work properly started to become a toll. HHVM now only supports the Hack language.
Supposedly Varnish can do some sort of WAF, but now you have a pretty complicated stack of Varnish->NGiNX->PHP.
There are some pretty cool PHP modules that have some decent speed like
Anyways, I’m going to set this up as a draft and write more about it.