• A few things I’ve noticed:

    1) You are now defaulting some logs to LOG_USER, which (on ubuntu) uses syslog rather than auth.log, yet the README only points the jails to look at auth.log, so fail2ban misses those entries. To fix this, I needed to add these lines to my wp-config.php file:

    define(“WP_FAIL2BAN_COMMENT_LOG”, LOG_AUTH);
    define(“WP_FAIL2BAN_PINGBACK_LOG”, LOG_AUTH);

    2) In most cases, an XMLRPC attack will hit the file many times in succession. By default, ubuntu rsyslog is set to combine these into a single line in the log file that says something like:

    message repeated 23 times: [ Pingback requested from XXX.XXX.XXX.XXX]

    Which fail2ban rules don’t look for. To resolve this, I had to update this setting in /etc/rsyslog.conf:

    $RepeatedMsgReduction off # used to be on

    I would suggest adding that to the README or modifying the regexps to account for combined messages. Seems to me the latter would be the nicest. I can help with this plugin if you want to add me as a dev.

    3) Enabling WP_FAIL2BAN_LOG_PINGBACKS does nothing practical, because there is no regexp to look for the message that it generates.

    Great plugin, but these few details made it rather time consuming to setup correctly.

    https://www.ads-software.com/plugins/wp-fail2ban/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author invisnet

    (@invisnet)

    Thanks for the feedback.

    1) Pingbacks have always logged to LOG_USER; it made sense to do the same with comments. The logging is primarily for informational purposes – it doesn’t belong under LOG_AUTH. Spam and pingback errors are logged to LOG_AUTH.

    Do you have a problem where you need to rate-limit comments and/or pingbacks? That’s the only reason I can think of to filter on them, and it doesn’t seem like a problem that’s common enough to include a default filter. Am I wrong about that?

    2) OK, that’s another Linux-ism. On BSD it’s the the traditional ‘last message repeated n times’, so there’s always at least one message to match. I’ll add this to the README.

    3) As above, it’s for information, not filtering.

    Thread Starter etsythemeshop

    (@etsythemeshop)

    for #1) There is a DDOS XMLRPC attack that is carried out by hitting xmlrpc.php many times in succession without triggering the authentication failure — it’s very common so I do believe it should be rate-limited.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Couple of Bugs – 3.5.1’ is closed to new replies.