I use Wordfence as a WordPress security solution. Even the free version has a comprehensive set of features, and the premium version is even better. It’s very easy to install and configure Wordfence as a regular plugin. However, the step to “Optimize the Wordfence firewall” fails for many people. This is not the fault of Wordfence, since different steps may be required depending on how your web server is configured. My solution is for those who are hosting their own WordPress, but may be helpful to other situations. Please note that these instructions affect the security of your system, and are aimed at users with intermediate to advanced Linux knowledge.
If a problem occurs, the main symptom you will see is that Wordfence will demand your FTP user name and password when you try to optimize the firewall. You will see the heading “Connection Information” with text “To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.” You do not need to enter this information, and you don’t even need FTP access. The FTP dialog is just an indication that WordPress is unable to write to a directory or file. In fact, this troubleshooting process will work for any WordPress plugin or upgrade that demands FTP credentials. To diagnose and fix the underlying problem, read on…
The first difficulty in optimizing the firewall is that Wordfence has to create a custom PHP file for your site called wordfence-waf.php and saves it in the root directory of the WordPress installation. Various security measures may prevent Wordfence from saving a file in this path. For example, the Linux user that runs the Apache process (apache in the case of RedHat/CentOS/Fedora) may not have write permission to the root directory. You’ll have to temporarily change ownership and/or permissions to allow Apache to write to this directory.
The second main reason that saving wordfence-waf.php might fail is an SELinux denial. To work around this, temporarily set the SELinux mode to permissive. On RedHat/CentOS/Fedora:
- In a terminal, using sudo or as root, run:
ausearch -m avc --start recent
If you see denials of the form
type=AVC msg=audit(1547482570.350:117353): avc: denied { create } for pid=20141 comm="httpd" name="blocks" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=1then SELinux is blocking WordPress from accessing the directory it’s installed in.
- In the case of SELinux denials, run this command to temporarily set SELinux to Permissive only for web server files:
semanage permissive -a httpd_t
- In WordPress, optimize the Wordfence firewall
- Immediately run
semanage permissive -d httpd_t
to restore SELinux protections on files served by Apache.
Now, you should have the file wordfence-waf.php in the same directory in the root WordPress directory.
The second major obstacle is to set the PHP environment variable auto_prepend_file so that PHP runs wordfence-waf.php before every PHP script. The exact method will depend on which web server is installed and how PHP is configured. Wordfence tries to guess for you and configure the right option automatically. For Apache 2.4 running PHP 7 using mod_php, the correct method is to create a file called .htaccess in the root directory of the WordPress installation, and set the variable there:
php_value auto_prepend_file "/var/www/html/nistframework.com/wordfence-waf.php"
Edit the main Apache config file (/etc/httpd/conf/httpd.conf on RedHat/CentOS/Fedora). In the section change AllowOverride None to AllowOverride Options and restart httpd.
To verify that auto_prepend_file is being set, create a little test script called info.php in the root directory of your WordPress installation:
Now navigate to /info.php and verify that auto_prepend_file is set correctly.