Fail2Ban filter for NinjaFirewall WP+ Edition syslog events

OVERVIEW

The NinjaFirewall (WP+ Edition) plugin is a very fast, reliable Web Application Firewall for WordPress. Fail2Ban is a daemon that scans a server’s log files once per second. If it finds evidence of an attack on the server, it can ban the IP address that the attack is coming from. This article outlines how to add a syslog file filter to Fail2Ban that detects critical, high, and medium level security events written to syslog by NinjaFirewall so that it can ban the attacker’s IP address.

tl;dr version: You can get all the files you need in the fail2ban-filter-ninjafirewall-syslog files Github repository.

PROCEDURE

First, purchase, install, and configure the NinjaFirewall WP+ Edition plug-in on your WordPress website. Next, go to the NinjaFirewall+ | Firewall Log settings page, and make sure Firewall Logging is enabled. Check-mark the Write events to the Syslog server too option and save these settings. NinjaFirewall+ will now save firewall events to your server’s syslog file.

Now, log in into your web server (assuming you have Fail2Ban already installed and working) and create a new recipe file with the following command…

sudo vi /etc/fail2ban/filter.d/ninjafirewall-syslog.conf

Insert the following text…

[INCLUDES]
after = common.conf

[Definition]
_daemon = ninjafirewall
failregex = ^%(__prefix_line)s(?:(CRITICAL|HIGH|MEDIUM):)\s+(?:(#[\d]{6,7}):) (?:[\w ]+) from <HOST> on
ignoreregex =

Next, enable the filter by editing or creating a jail.local file with…

sudo vi /etc/fail2ban/jail.local

and insert the following text…

[ninjafirewall-syslog]
port = http,https
filter = ninjafirewall-syslog
logpath = %(syslog_ftp)s
backend = %(syslog_backend)s
maxretry = 2
enabled = true

Keep the maxretry override value low; 2 is good, 1 is too low. Attacks are often distributed, with each IP address only being used once. This will create a lot of unnecessary IP bans. Heavier attacks, or smaller bot-nets, will reuse IP addresses, so a setting of 2 will block those attackers.

Finally, restart the service…

sudo service fail2ban restart

TESTING

To test the new filter run this command…

sudo fail2ban-regex /var/log/syslog /etc/fail2ban/filter.d/ninjafirewall-syslog.conf

If there are any entries from NinjaFirewall in the syslog file, fail2ban-regex will show you the number of matches.

If there are any IP addresses that are currently banned you can see them by running this command…

sudo iptables -L

PRECAUTIONS FOR CACHING AND PROXY SERVICES

When your web server is accessed through a caching or proxy service, such as CloudFlare, the connecting IP address in an attack will be a proxy server IP address. Banning the connecting IP address could result in your web site becoming inaccessible to some or all of the internet. Simply banning the true client IP address will not help either, since that IP address most likely would never connect directly to your web site. In this case, you may not want to use this Fail2Ban filter at all.

Another possibility is to setup cloudflare action for the ninjafirewall-syslog filter. See the example implementation in the CloudFlare REST API V4 Fail2Ban filter and NinjaFirewall Fail2Ban AUTH log filter articles.

DEBUGGING

If fail2ban won’t restart after you have edited configuration files, you can try manually starting it with verbose messaging enabled to find out where it is failing as it is starting up.

fail2ban-client -vvv -x start

Once you have fixed all errors in your configuration files, restart it as a service.

fail2ban-client -x stop
service fail2ban start

You can get the latest version of the Fail2Ban NinjaFirewall WP in the GitHub Repository.