Hey
Ah okay so yeah as others have pointed out, it’s a whole different game at that point.
Viktor’s last link will work really well if you only have one CF account, however if this is for a multi-user site, the solution will not work. The key in what he has though, is making WP failed logins and xmlrpc attacks log to the system log, so fail2ban can pick them up.
What we have with Fail2Ban + Apache + CF is a mod_security rule that blocks the visitors IP, and there is a fail2ban action that triggers the rule. You cannot use iptables as that’s layer 3 and only see’s the CF IP.
Being nginx, I don’t think you can use mod_security, but there’s probably a way to configure an X-Forwarded-For IP blacklist that nginx uses and fail2ban just to append to that list.
Another option would be that you modify wp-fail2ban to also log the users email and API key, and then setup a fail2ban action that reads that token from the log and uses it in action_ban and action_unban. Sort of like the f2b-tarpit-CF-apache-WP-LLA-itsec-LSEC link above.
We’ve been working on a WordPress plugin that does login/xmlrpc syslogging, user-agent and username blocking, along with CF integration, however it’s not quite complete yet. When it is I’ll share the source code here or put it in the WordPress directory. Hopefully we could all start working it and build something really powerful.
Cheers
The key in what he has though, is making WP failed logins and xmlrpc attacks log to the system log
There could be a misunderstanding.
I’ve written:
I log WP attacks into the webserver’s (Apache or Nginx) error log.
Because a botnet attack could flood syslog.
This is the list of events blocked by my home made plugin-like system (2 files)
List of HTTP request parts checked
login POST request size *
custom CDN headers *
author query field
request method to identify POST requests
log POST variable (the WordPress username) *
Accept header
Accept-Language header
Content-Type header
Content-Length header
Referer header *
action query field to allow requests for password protected posts
protocol *
Connection header *
Accept-Encoding
cookie named wordpress_test_cookie *
User-Agent header *
The list is in order of appearance, * means it can be disabled by an option.
WordPress events
prevent anyone logging in (disabled by default)
prevent redirections to admin (log in only at /wp-admin or /wp-login.php)
stop brute force attacks (multiple login probes and password reminder attacks from one IP address)
stop robots scanning non-existent URLs (404s, redirects, simple URL hacks, misinterpreted relative protocols)
reply with HTTP/403 Forbidden to robots on non-frontend requests
stop showing 404 pages to robots but send HTTP/404
ban sequential 404 requests (from the same IP address)
ban on any XMLRPC-based authentication (even on successful ones)
ban on invalid AJAX, XMLRPC and other wp_die()-handled requests
ban on unknown admin-ajax and admin-post actions
stop spammers in cooperation with Contact Form 7 Robot Trap plugin
log WordPress logins and logouts
Hey Viktor,
Sht nice work.
Yeah we log to syslog using
if(defined('LOG_AUTHPRIV')) {
openlog('wordpress(' . $_SERVER['HTTP_HOST'] . ')', LOG_NDELAY|LOG_PID, LOG_AUTHPRIV);
} else {
openlog('wordpress(' . $_SERVER['HTTP_HOST'] . ')', LOG_NDELAY|LOG_PID, LOG_AUTH);
}
syslog(LOG_NOTICE, $message);
closelog();
I think we may need to FOSS our plugin soon so we can collaborate on it.
Currently out list of support is:
- Alert admin on different attack options, eg: blocked user/useragent/IP or successful login
- Block commonly spammed usernames like ‘test’ and ‘admin’ – customisable list
- Block known bad user-agents such as “Go 1.1 package http” and more
- Block IPs that other hosting instances on the server have banned for repeated failed logins
- Block XMLRPC attacks
Cheers
