Following with interest. And maybe someone can help me figure the question below:
The auto configuration of the Wordfence WAF firewall isn’t working on Siteground hosting and I’m not sure I completely understand the instructions given by Wordfence here:
https://docs.wordfence.com/en/Web_Application_Firewall_Setup?utm_source=plugin&utm_medium=pluginUI&utm_campaign=docsIcon
When I’m in the PHP variables manager and I select the path for the relevant website
the path says something like:
/home/myaccount/public_html/jacqueline-audouard.com/php.ini
I just have one small box to enter a variable below that but the instructions talk about entering the variable and then the path so is it correct to end up with something like this ?
auto_prepend_file/home/username/public_html/wordfence-waf.php
I’d really rather not break anything… so in doubt I will abstain from using Wordfence WAF until I’m sure of what I’m doing
I assume all other functionality of Wordfence work as before even if the new WAF feature isn’t configured ?
Thanks in advance
Sue
(@suelaren)
Let me know if you get it working with SiteGround – I have three sites I manage on SiteGround hosting and it’s not working on any of them. The correct line should read:
auto_prepend_file = ‘/home/username/public_html/wordfence-waf.php’ and will be generated. You choose the variable from a drop down (start typing in the word auto and you will see choices), click add, then add only the path in the box that will come up.
It still didn’t work, even after following all the steps. I await the update/fix.
@rowlanda: Yes, the new Firewall feature can run along with ModSecurity. There will be a little more overhead per request, but at the same time, we have some WordPress specific rules that could catch attacks that ModSecurity may not.
The firewall setup message is also dismissible in the latest release. (The functions.php workaround was the quickest fix for anyone who needed it critically.)
If using the SiteGround workaround, make sure to enable the “Apply changes to all sub-directories” option when entering the auto_prepend_file value. Alternately, you can wait for the update for SiteGround sites (it won’t be in the next update, but most likely in the one after that.) If there seems to be a different issue, please let us know in a new post. Thanks!
-Matt R
I know this thread is about 1 year old, so sorry about this.
I’m having a problem with Wordfence conflicting with ModSecurity Rule 981247. See screenshot here: http://take.ms/UxWOJ
I have not taken the time yet to find out where this is being injected from, but as soon as I disable Wordfence plugin and re-visit the WP admin dashboard, the load-scripts.php file returns HTTP 200 instead of 302 from the mod security rule.
Any thoughts before I go diving into the code?
I’m also interested to learn from the experience and advice of others for the same reason as the original post:
“I already use ModSecurity with COMODO firewall rules, which I believe is largely redundant to the Wordfence WAF.”
We know that the two can run together because we’re doing it now.
Arguably two firewalls are better than one, e.g. because (maybe) a weakness in one is compensated for by a strength in the other.
Conversely I think there’s an excellent chance that the benefits of two firewalls are fully negated by the extra complexity associated with having two, starting with having to remember that you have two firewalls at play.
This Wordfence article clearly shows the limitations of a Cloud WAF versus Wordfence: https://www.wordfence.com/blog/2016/10/endpoint-vs-cloud-security-cloud-waf-user-identity-problem/ but doesn’t go as far as to say “and therefore the only firewall you need for a WordPress site is Wordfence”.
In summary: in the interests of “less is more” I’d prefer to run Wordfence only, and to whitelist such sites with ModSecurity so that it doesn’t attempt to protect them. But keen to hear from others on whether this is smart or not.
Comments anyone?
Thx.
