{"id":3046,"date":"2019-07-31T22:33:57","date_gmt":"2019-08-01T03:33:57","guid":{"rendered":"http:\/\/osric.com\/chris\/accidental-developer\/?p=3046"},"modified":"2019-08-10T12:45:47","modified_gmt":"2019-08-10T17:45:47","slug":"block-wordpress-scanners-fail2ban","status":"publish","type":"post","link":"https:\/\/osric.com\/chris\/accidental-developer\/2019\/07\/block-wordpress-scanners-fail2ban\/","title":{"rendered":"Blocking WordPress scanners with fail2ban"},"content":{"rendered":"

My web logs are filled with requests for \/wp-login.php<\/code> and \/xmlrpc.php<\/code>, even on sites that aren’t running WordPress. Every one of these attempts is from a scanner trying to find, and possibly exploit, WordPress sites.<\/p>\n

Why not put those scanners in a fail2ban<\/a> jail and block them from further communication with your web server?
\n<\/p>\n

Fortunately, someone else had already done most of the work here:
\nUsing Fail2ban on wordpress wp-login.php and xmlrpc.php<\/a><\/p>\n

I made a few changes to the suggested filter. For example, on this site (osric.com) there is no \/wp-login.php<\/code>, but there are other instances of wp-login.php<\/code> in subdirectories. Additionally, I am seeing primarily spurious GET<\/code> requests in my access logs. I modified filter.d\/wordpress.conf<\/code> to look for both GET<\/code> and POST<\/code> requests for these WordPress-related files at the site root:<\/p>\n

[Definition]\r\nfailregex = ^<HOST> .* \"(GET|POST) \/wp-login.php\r\n            ^<HOST> .* \"(GET|POST) \/xmlrpc.php<\/code><\/pre>\n
I also made a couple modifications to jail.d\/wordpress.conf<\/code>:<\/p>\n
[wordpress]\r\nenabled = true\r\nport = http,https\r\nfilter = wordpress\r\naction = iptables-multiport[name=wordpress, port=\"http,https\", protocol=tcp]\r\nlogpath = \/var\/log\/custom\/log\/path\/osric.com.access.log\r\nmaxretry = 1\r\nbantime = 3600<\/code><\/pre>\n
    \n
  1. \nI set maxretry<\/code> to 1 so that IP addresses will be banned after the first bad request.<\/li>\n
  2. I removed findtime = 600<\/code> because that’s the default setting in fail2ban’s jail options<\/a>.<\/li>\n
  3. I increased the bantime<\/code> from the default (10 minutes) to 1 hour (3600 seconds).<\/li>\n<\/ol>\n
    The other change I made was to add \/wp-login.php<\/code> and \/xmlrpc.php<\/code> to my robots.txt<\/code> file:<\/p>\n
    User-agent: *\r\nDisallow: \/wp-login.php\r\nDisallow: \/xmlrpc.php<\/code><\/pre>\n
    If a malicious user creates a hyperlink to osric.com\/wp-login.php<\/em>, well-behaved robots should avoid it. This way I’m not inadvertently banning Googlebot, for example.<\/p>\n
    It feels really good to slam the door in the face of these scanners! But unfortunately I have to ask…<\/p>\n
    Does this do any good?<\/strong><\/p>\n
    I analyzed some of the server logs from before I implemented this block, and as it turns out, most of these are drive-by scanners: they are checking for the presence of a potentially vulnerable page, logging it, and moving on. They are basically gathering reconnaissance for future use.<\/p>\n
    If a host makes a couple GET<\/code> or POST<\/code> requests in the span of one second and then leaves, banning the host’s IP won’t be very effective.<\/p>\n
    Also, I know that fail2ban is useful for brute-force ssh attempts, but how useful is it for scanners requesting WordPress files? According to my fail2ban logs, over the month of July, 2019:<\/p>\n