optimizing firewall

Hi @flowerhat

I would like to have a look at your Wordfence diagnostics report. Please go to the top of the “Diagnostics” tab on the Wordfence “Tools” page. There will be a “SEND REPORT BY EMAIL” button to send the diagnostics report. Enter wftest [at] wordfence [dot] com as the email and @flowerhat as the forum username please.

Once you have emailed me the diagnostics report can you reply here to let me know that it has been sent. This is important in the unlikely event that your installation of WordPress is having an issue with sending mail.

Hi, thanks for your reply. I sent the report.
Jeannet

Hi Jeannet,

Thank you for sending the report.

As long as you have sent the report for the correct website then the The firewall isn’t optimized because the auto_prepend_file PHP directive has a blank value.

If you expand the Basic Firewall Options section on the All Options page the Protection Level should say Basic WordPress Protection. When the firewall is optimized it will say Extended Protection.

Expand the Wordfence Firewall Current WAF configuration section on the Tools >> Diagnostics page.

Find the line below:

wordfence-waf.php path: /absolute/path/to/wordfence-waf.php

Your .user.ini file must have the following, matching your file path:

; Wordfence WAF
auto_prepend_file = '/absolute/path/to/wordfence-waf.php'
; END Wordfence WAF

If the code is set correctly then you will need to ask your hosting provider why this value is not being set for the auto_prepend_file PHP directive.

Hi @wfphil,

I’m helping Jeannet with this site and the WAF status is “Enabled and Protecting” and the path to the wordfence-waf.php is exactly the same as in the .user.ini file (that was created by Wordfence and not pre-existing or manually edited). The files both have the correct permissions (644).

In the PHP config report the auto_prepend_file is listing the location the same as in the .user.ini, but in the report you received and in Tools – Diagnostics I see that “WAF auto prepend active” is listed as “No”. So is the check failing or is the WAF failing?

I’m managing hundreds of WP sites with Wordfence, but I haven’t seen this before. Every settings looks correct, but the yellow notification that the WAF still needs to be optimized remains.

Is there anything you or we can check to see if the firewall is running correctly and we should just dismiss the notice?

Thanks,
Jos Klever
Web Support

Hi Jos,

Thank you for the update.

The firewall is not optimized as the value for the auto_prepend_file PHP directive is not being set by the code in the .user.ini configuration file.

You will need to ask the hosting provider why the value for the auto_prepend_file PHP directive is not being set.

The PHP SAPI is listed as FPM/FastCGI. In rare cases, when a host uses PHP-FPM, they may have PHP settings defined in a pool file. These settings can override options set in your custom .user.ini file. You may need to ask the hosting provider if they have settings in the pool file.

An example of an setting that would override your auto_prepend_file setting is php_admin_value[auto_prepend_file] = none. If the hosting provider is able to remove this option, it should fix it.

Hi Phil,

That’s the strange situation, because that value is missing in the report, but when I go to Wordfence – Tools – Diagnostics – Other tests – “Click to view your system’s configuration in a new window”, the directive “auto_prepend_file” has the local value “/www/htdocs/flowerha/wordfence-waf.php” (master value=”no value”) and that should be correct. It’s like both tests are run on a different environment.

I’m sure it’s something hosting related, but the hosting provider was contacted first and they checked everything (as they always say) and told us, that everything was okay (as they always say). So the conclusion was that they don’t want to cooperate or just don’t know how they can.

That’s why I hope there’s another test possible to check if the firewall is running as it should. Not by checking a config value, but by checking the behavior.

Hi @josklever

Apologies for the late reply.

Can you look to see if there are .user.ini files in the wp-admin and wp-includes directories that are possibly setting something like:

auto_prepend_file = none

If you don’t see a .user.ini file in the wp-admin and wp-includes directories can you create a .user.ini file in the wp-admin and wp-includes directories and copy into them the Wordfence code from the .user.ini file in the flowerha directory and let me know if the firewall then becomes optimized.

Hi @wfphil,

Sorry for my late reply this time (was on vacation).

There are no other .user.ini files in wp-admin or wp-includes. I’ve even done a complete compare with a clean WP download to check for additional or modified files.

But when I add the .user.ini to wp-admin the firewall notification goes away, so that seems to solve the issue. The same file in wp-includes made no difference (so, that’s removed again).

I guess we can contact the host and ask how they can explain this behavior, but maybe you have some more technical information we can give them?

Hi Jos,

Thank you for the update.

I think I have found out the problem.

Click on the Click to view your system’s configuration in a new window link in the Other Tests section on the Tools >> Diagnostics page.

In the PHP and server info page that opens scroll down to the PHP Variables section.

Now look at the file path for the $_SERVER[‘SCRIPT_FILENAME’] variable.

You will see two forward slashes at the start. There should only be one.

Here is a Stack Overflow topic that may explain the issue and your hosting provider can check their Apache web server configuration:

https://stackoverflow.com/questions/27226055/does-the-user-ini-file-work-for-subdirectories

Great find! That sounds really as a possible cause. We will contact the host and hope they will be able to fix it.

I can imagine that the firewall might not work for requests that hit a different file/folder (think about files from plugins/themes). Can you tell more about that?

Hi Jos,

Naturally you will want the .user.ini file to be processed recursively in all subdirectories in the WordPress directory structure.

Currently it isn’t from our test, and the additional information provided indicates a misconfiguration of the Apache web server.

The host has changed something (didn’t say what or how), but it works now without the extra .user.ini.

Thanks you very much for figuring this out! ??

Hi Jos,

Glad to hear that it is fixed!

It appears they have only fixed it for one of the sites and they said they have to see if it has impact on the server’s performance before they will change it for other sites. So we’re not there yet. If they keep this attitude, they will get a higher ranking on my webhost blacklist. ??