So far, in the free version, inotify is your only option. In the premium version, it’s possible to write events to the Syslog server too.
There’s not hook because in Full WAF mode, WordPress isn’t loaded.
What kind of action would you like to perform?
Thread Starter
wp_kc
(@wp_kc)
Changes in Fail2Ban broke my custom filter that looked at the NinjaFirewall log files. Fail2Ban is expecting a log file to only be appended to, with a consistent end of file index. So the rolling log file nature of NinjaFirewall, where old events are removed from the start of the file, messes up NinjaFirewall. How about instead, making an option that disables the rolling log file feature?
The latest versions of Debian don’t have a syslog any more, everything goes to the journal. I assume the OS probably redirects software syslog writes to the journal. This is also problematic for Fail2Ban, since NinjaFirewall is not a systemd unit as Fail2Ban filters expect, and there is no way to redirect syslog writes to a text log file.
Thanks.
How about keeping the last log entry when rolling the log? I assume Fail2ban keeps reference of that last line only, no?
I have no issue with Debian 13. Everything is written to systemd-journald ( journalctl -t ninjafirewall ) and, after installing rsylog, it will also write to /var/log/auth.log (brute-force protection, free and premium version) and /var/log/user.log (firewall events, premium version).
Thread Starter
wp_kc
(@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.
So, a “hook” will likely be the easiest solution.
I made a quick change to the code. To test it, make sure you are running version 4.8.7 (free WP Edition).
- Download the new
class-firewall-log file: https://plugins.trac.wordpress.org/export/HEAD/ninjafirewall/trunk/lib/class-firewall-log.php
- Over FTP, upload it into the
wp-content/plugins/ninjafirewall/lib/ folder.
- Create a .htninja file: https://blog.nintechnet.com/ninjafirewall-wp-edition-the-htninja-configuration-file/ .
- Create a
nfw_custom_user_log function, which has one parameter: the log line to be written to the firewall log. For instance, retrieve the line and append it to a /tmp/firewall.txt file:
<?php
/*
+===========================================================================================+
| NinjaFirewall optional configuration file |
| |
| See: https://blog.nintechnet.com/ninjafirewall-wp-edition-the-htninja-configuration-file/ |
+===========================================================================================+
*/
/**
* Retrieve the line written to the firewall log.
* Note: $line doesn't include the Line Feed (\n).
*/
function nfw_custom_user_log( $line ) {
file_put_contents('/tmp/firewall.txt', "$line\n", FILE_APPEND);
}
When the firewall writes to its log, it will check if the function nfw_custom_user_log exists and will forward the data to it too.
As indicated, $line doesn’t include the line feed \n; don’t forget to add it if you need it ("$line\n").
