nintechnet

That’s normal: the WordPress task scheduler uses UTC timestamp and thus is not “DST compatible”. That’s not an issue with NinjaFirewall.
If you want to readjust the cron task time, simply go to the “Plugins” page, deactivate NinjaFirewall and immediately reactivate it. That will recreate the task and WP will use the new time.

You can also use this plugin to view/edit all scheduled tasks: https://www.ads-software.com/plugins/wp-crontrol/

• This reply was modified 3 months, 3 weeks ago by nintechnet.

I’m not sure I understand your question: it seems to be related to when the notification is sent but the function you pasted in your message checks which lines of the log should be parsed in order to establish the report.
1. The notification is sent by WP-CRON, WordPress task scheduler at 5mn past midnight (assuming you have some traffic that can trigger WP-CRON).
2. The log data parsed is indeed the last 24 hours.

That’s odd if there’s nothing in the log because any action taken by the firewall is written to it.
Can you check those policies too : NinjaFirewall > Firewall Policies > Permissions

Did you check the firewall log (NinjaFirewall > Logs) ?

Go to “NinjaFirewall > Firewall Policies” and tell me which policy you enabled in each of the following sections:
* WordPress AJAX
* Protect against username enumeration
* WordPress REST API
* WordPress XML-RPC API

@getupworks: I really can’t recall, that message has been there for years! I had even forgotten we were hiding it. We are currently rewriting a lot of code in NF and I came across the code that hid the notice last week. I decided to stop hiding it, but that wasn’t a good idea: it’s scary and useless.
I reversed the change and within the next few hours, the message should be gone. Go to “NinjaFirewall > Security Rules” and click the “Check for updates now” to make sure you have the latest rules. Then go to site health to check if the scary message is gone.

Also, to those who don’t want to use PHP sessions, we introduced NinjaFirewall sessions in the latest 4.7 version.

@scinews: your issue is not related to this discussion. NinjaFirewall calls the wp_mail() function and your site cannot find the PHPMailer library (which is included with WP) :

#4 /home/whatever/public_html/wp-content/plugins/ninjafirewall/lib/utils.php(1668): wp_mail()

Check your WordPress installation, and make sure it’s not corrupted. You can reinstall WP without affecting your current configuration: “Dashboard > Update > Re-install version {current_version}”

Make sure to update NinjaFirewall’s rules to the latest version and the message will go away: NinjaFirewall > Security Rules > Check for updates now.

Prior to version 4.7, NinjaFirewall was hiding that message because it was scary and was displayed even if there was no error. NinjaFirewall does use session but it closes it before any HTTP requests. Still, Site Health displays the scary message anyway.
Since version 4.7, we don’t hide it any longer because we think it’s not NinjaFirewall that should handle that, but rather the developers of Site Health.
In your case, unless you have another critical error displayed by Site Health, there’s nothing to worry about.

Go to NinjaFirewall > Dashboard. If you see a warning about Cloudflare, it means you must use the .htninja configuration file to add its HTTP_CF_CONNECTING_IP variable: https://blog.nintechnet.com/ninjafirewall-wp-edition-the-htninja-configuration-file/#variables

I found the problem. I will be fixed in the next release.

I’m currently looking at it.
The issue seems very new but the code where the error occurred hasn’t been changed for years.

Go to “NinjaFirewall > Logs” and check all events in the firewall log: do they all have the same IP address or different ones ?

Can you enable debugging in WordPress and see if there’s anything written to the PHP error log:
1. Edit your wp-config.php
2. Search for:?
define('WP_DEBUG', false);
3. Replace with:?
define('WP_DEBUG', true);
4. Add this line below:
define( 'WP_DEBUG_LOG', true );

Run a scan. The log (if any) will be saved to “/wp-content/debug.log”.

You can also adjust the configuration to use less server resource:
1.Basic Settings:
?-File Size > Scan only files smaller than : Set it to 100kb
?-Ignore file extensions: Add the following extensions:
po,pot,mo,css,png,jpg,gif,tiff,xml,json,woff,woff2,ttf,eot,yaml,svg,txt
?2. Advanced Users Settings:
?-Files and folders > Warn if executable files: Disable it.
3. Nerds Settings
?-File integrity checksum: Select “MD5”

You can try to bypass your CDN by directly accessing the site via its IP address and adding the host field:
1. In the “Page to profile”, select “Custom post/URL” and enter the server real IP address instead of the domain. For instance: https://1.2.3.4/some-page-to-profile/
2. Then click the “Advanced Options” button and in the “HTTP headers” section, enter the “Host” field with your domain name. For instance: Host: example.com

If you block IP addresses that don’t originate from the CDN at your server level, that won’t work.

Go to the profiler’s main page, click the “Support” tab and search for [admin-ajax].
Do you see [access] => OK or an error instead?