Wordfence suddenly sets entire site to “Access denied”

Hi @cwangersky, thanks for dropping us a message about this.

For your reference, after renaming the “wordfence” plugin directory, you can actually name it back after logging in, then refreshing your site, without the need for a reinstall should you need to do any repeat testing.

The access denied message does probably mean a folder is owned by a different user though, so the permissions on your WordPress site’s directories should be 755 and the owner on your WordPress root directory (and all contained directories) should be www-data. Web servers such as Apache, Nginx, etc will require www-data to be an owner so that WordPress and plugins can update and run functions required to do so.

Let me know if you’re on a different platform so would be unable to grant these permissions.

Thanks,

Peter.

The thing is, if I rename the folder back to “wordfence”, the “Access denied” message returns on every page of the site. If I have it renamed “wordfence-“, I can access the admin pages of the site, and from there I can select Add Plugin, and retrieve a fresh copy of the Wordfence plugin from the repository; it does not complain while installing, which would suggest thatpermissions are correct; and as soon as I activate the new plugin, the site returns to Access Denied status again. I don’t have CLI or SSH access to the site – it’s shared hosting using cPanel – so checking ownership of files and folders is a long and onerous process involving several mouse-clicks on each and every file in the Wordfence distribution. But as the site dies given an absolutely fresh and error-free installation of the plug-in’s code, I believe I’m safe in assuming that the directory permissions are set correctly.

My current working hypothesis is that a database issue resulted in some data – WordFence Network block info perhaps – being only partially loaded into the database, and the resulting inconsistency is resulting in the WAF blocking all site access. Why that would generate “Access denied” (plain black text on a white screen, nothing else) I don’t know, unless that’s what the host has decided to show for a 500 range error. An error is generated; what I’m seeing is:

PHP Fatal error: Cannot redeclare get_blog_permalink() (previously declared in /home/comme854/public_html/wp-content/mu-plugins/theme-functions/post.php:41) in /home/comme854/public_html/wp-includes/ms-functions.php on line 328

But why that would be generated on a WAF data problem I cannot for the life of me figure out.

Hi @cwangersky,

As the block pages are not Wordfence-branded ones and just a regular plain server error and the fatal error doesn’t relate to Wordfence’s folders I don’t think this is being caused by Wordfence which I understand seems odd considering disabling Wordfence is the only way to view your site after the issue appears.

The issue to me looks like a must-use plugin “Theme Functions” is declaring the get_blog_permalink() function but the WordPress multisite files are trying to subsequently declare it later in the execution without first checking whether it’s already declared.

Try looking at the “Must-Use” tab in WordPress > Plugins > Installed Plugins and disabling “Theme functions” if it appears to see if that combats the fatal error. I would also recommend disabling ALL plugins and custom themes and then trying to install Wordfence again. If Wordfence works as a sole plugin, try re-enabling plugins one-by-one and finally your theme to see when the error reoccurs.

Let me know how you get on!

Thanks,

Peter.

I’m sorry, I should have responded sooner with a bit of detail. It would appear that the message being logged was from something else, because while it seems to occur with approximately the same frequency, the timing is not quite the same. Annoyingly, the failure seems to generate no log message at all.

And I’m certain at this point that it is WordFence failing, because the eventual cure was to remove the wp-content/wflogs directory. Of course, that also put the WordFence firewall back into learning mode, but even learning mode is better than nothing, particularly as evidence suggests mine is one site that’s targeted in a current brute-force attack.

If there is useful diagnosis that can be done using the wflogs directory at this point, I have saved its contents; I can zip that up and forward it if that would be useful.

Hi @cwangersky,

Before sending anything over, we have a feature to bypass the wflogs folder entirely if it is causing persistent problems. Setting Wordfence to write to the MySQLi storage engine instead of a file could solve this issue: https://www.wordfence.com/help/firewall/mysqli-storage-engine/

Let me know how that goes for you and we can always try to troubleshoot the files you mention if there’s no change.

Peter.

The only way to get the site back on line was to rename the wflogs folder and create a new one, which WordFence started populating as soon as site access was regained. We had been using Wordfence without issue for several years before that, and the issue has not recurred in the two weeks or so that we’ve been back on line; so I’m not sure of the value of switching to database access at this point. I’m reasonably certain that reverting to the saved wflogs directory will result in the problem reappearing. If the issue does reappear, we’ll definitely try the mysqli approach as a recovery technique.

Hi @cwangersky,

Thanks for your feedback on that. As wflogs repopulates automatically within about 30 minutes, changing this folder looks to have had the desired effect. If no issues reoccur or simply deleting it again in the future solves any issues then you can continue to do that. By all means try the MySQLi approach if it feels appropriate to do so.

If you have any further Wordfence questions in future, by all means start a new topic and we’ll always be glad to help out.

Thanks,

Peter.