The key concept behind WPf2b is logging Events to
syslog. If WPf2b doesn’t log an Event, or logs it to the wrong place,
fail2ban won’t work as it should. If in doubt go with the defaults - they should work for most systems, and once you understand how the pieces fit together you can revisit this.
3.2.1. Choosing the Events to Log¶
If you’re unfamiliar with
syslog I recommend not enabling any extra logging to start with - skip ahead to configuring fail2ban. WPf2b automatically handles the most important things with sensible defaults that should work for most systems.
3.2.2. Advanced Users¶
Over the years WPf2b has accumulated a lot of logging ability (and there’re even more on the way):
|Blocked User Enumeration||WP_FAIL2BAN_BLOCK_USER_ENUMERATION|
|Attempted Comment: Post not found||WP_FAIL2BAN_LOG_COMMENTS_EXTRA|
|Attempted Comment: Closed post||WP_FAIL2BAN_LOG_COMMENTS_EXTRA|
|Attempted Comment: Trash post||WP_FAIL2BAN_LOG_COMMENTS_EXTRA|
|Attempted Comment: Draft post||WP_FAIL2BAN_LOG_COMMENTS_EXTRA|
|Attempted Comment: Password-protected post||WP_FAIL2BAN_LOG_COMMENTS_EXTRA|
You should consider enabling Comment: Spam and Attempted Comment: Closed post, and, if you don’t use WordPress’s commenting system at all, you should enable all the Attempted Comment Events.
By default, WPf2b uses the following
syslog Facilities and Levels:
|Blocked User Enum|
|Comment: Post not found|
|Comment: Closed post|
|Comment: Trash post|
|Comment: Draft post|
|Comment: Password-protected post|
Unfortunately, there is no way of knowing a priori which Facility goes where. There is a table of default locations of Logfiles for various OSs; if you’re running something not listed there and you know where the various Facilities go, please either submit a PR on GitHub, or let me know in the forum.