WP fail2ban logs over the network

It also says:

Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field.

It’s quite possible that the regex in the filter conf file isn’t suitable for networked syslog, but the <SERVER> part in your example should never be truncated as the opening bracket should start the CONTENT field.

it’s not the <SERVER> which gets truncated, but the pid. And instead of having something like
wordpress(some.longwebsite.com)[12345]: Authentication failed ........
will get something like:
wordpress(some.longwebsite.com)[12 Authentication failed .......
which will cause fail2ban not to match it (unless the filter is modified).

And it’s not about having non-alphanumeric chars in the TAG (causing it to terminate it), it’s about the TAG exceeding 32 characters; everything what’s after the 32nd char in the TAG will be discarded.

How can I modify the filter then? My weekly logwatch is getting huge with unmatched entries of
wordpress(something >= 17 chars): Authentication failure for ____ from ___: 1 Time(s)

Well, I’ve modified wp-fail2ban.php like this:

original:
…
function openlog($log = LOG_AUTH, $custom_log = ‘WP_FAIL2BAN_AUTH_LOG’)
{
\openlog(‘wordpress(‘.$_SERVER[‘HTTP_HOST’].’)’,
LOG_NDELAY|LOG_PID,
defined($custom_log) ? constant($custom_log) : $log);
}
…

modified:
…
function openlog($log = LOG_AUTH, $custom_log = ‘WP_FAIL2BAN_AUTH_LOG’)
{
\openlog(‘wp(‘.$_SERVER[‘HTTP_HOST’].’)’,
LOG_NDELAY|LOG_PID,
defined($custom_log) ? constant($custom_log) : $log);
}
…

However, a proper solution would be to truncate the tag if it’s longer than 32 characters. With what I’ve modified it will still fail if the server name it’s longer than 22 characters.

Thanks for the reply … I suppose that a change to the fail2ban filter is also in order (_daemon = wordpress -> _daemon = wp). Correct?

@reconmail
indeed.

Just going through old threads – that was fixed in 3.0.