wp_kc

This change to Fail2Ban happened a few years back, and I had put the problem on the back burner. As I recall, it has to do with the changing size of the log file. If the NinjaFirewall file size reaches it’s maximum for the month and starts trimming lines off the beginning, then Fail2Ban barfs with an error message saying the system clock is wrong, and then ignores the log file for the rest of the month!

I had a long back-and-forth with the developer about this. He had made some changes to solve a problem with some other stuff, and was unwilling to change it back just for Ninjafirewall logs (which he viewed as weird and non-standard, whatever that standard is). His suggestion was to use iNotify to capture changes to the log file and append those changes to a different log file. But when I looked into that idea, it also has issues. I also looked into systemd path units and a few other kernel level file monitoring methods, and none of them are ideal.

What I came up with in the meantime was a Must-Use plugin that loads before 0-ninjafirewall.php, and adds a register_shutdown_function callback, then checks for new lines at php shutdown. It’s ugly, but it works, sort of. It tends to reban things that were already banned even though I am keying off the incident ID number, so I end up setting the max number of days to 1 just to minimize rebanning IPs that haven’t come back.

Just looking for a way back to what I had before this change to Fail2Ban happened. Two of my customers are on VPS’ one of whom had the premium version of NinjaFirewall for a couple of years, then stopped paying their bill, the other never had a premium version. So I’ll have to do a sales pitch to get them to subscribe to the premium version.

All my other customers are on shared hosting, so syslog was always out of the question since I have no control over the host’s Fail2Ban. But it would be nice to have a script running that can take NinjaFirewall logs and do a ban through an API call to CloudFlare.

Well done @gosuccess ! Thanks. And thanks @bruandet for rolling out the fix so quick.

Thanks for the reply. I was not aware of that constant and have not changed it. I do see this in your code…

/**
 * Select whether we want to use PHP or NF (default since v4.8.1) sessions.
 */
if ( is_file( NFW_LOG_DIR .'/nfwlog/phpsession') ) {
	require_once __DIR__ .'/lib/class-php-session.php';
} else {
	if (! defined('NFWSESSION_DIR') ) {
		/**
		 * NFWSESSION_DIR can be defined in the .htninja.
		 */
		define('NFWSESSION_DIR', NFW_LOG_DIR .'/session');
	}
	require_once __DIR__ .'/lib/class-nfw-session.php';
}

I did recently upgrade all my sites from php8.2-fpm to php8.3-fpm. Is it possible that the change in PHP versions messed it up somehow? Because I do see a /wp-content/nfwlog/session/ directory on my sites, and they have a bunch of session files with date-time stamps that end the day before I did the switch in PHP versions.

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

Forgot to mark resolved

It is not a publicly accessible web site, and it has WP_DEBUG enabled. These messages only show up in the debug log file while accessing /wp-admin area of the web site. Nothing special has to be done, simply log in to the site. The log file grows by about 2MB per day with these types of messages.

No front end issues are noticeable. I just thought you might be interested, since it looks like these message will turn into errors in the future.

I commented out both lines, but still got the same result.
30-Apr-21 05:25:32 ERROR Fatal error: forking process failed (cURL error 56: OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0: AJAX API). Aborting

It looks like the Elementor developers found the problem and fixed it. The latest version released 8 hours ago is no longer generating these messages.

It works again! Thanks, you guys are awesome.