Another brute force attack thread

With all the attacks going on we see a number of servers increasing their work load because all the login attempts trigger disk i/o. So we decide to block all attempts not coming from an approved ipaddress.

<FilesMatch "wp-login.php">
order deny,allow
deny from all
Allow from 1.2.3.4
</FilesMatch>

Usually this works. The site’s accesslog file will show the following:

4.3.2.1 - - [30/Aug/2013:11:23:24 +0200] "POST /wp-login.php HTTP/1.1" 403 431 "http://whatchamacallit.fake/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0"

Note the ‘403’ after the post statement. Apache throws a 403 error (Forbidden), as it should be.

However, sometimes when we put up this block, we get a different result:

[30/Aug/2013:11:46:40 +0200] "POST /wp-login.php HTTP/1.0" 302 473 "thingamabob.fake/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

Note the ‘302’ after the post statement. Apache does a redirect to the wp-login.php file, which puzzles me, because we blocked the access. Yet, it redirects and redirects and redirects and redirects… about 9 – 12 times. I have yet to figure out why this happens. The load on the server doesn’t deminish though, it stays the same.

Removing wp-login.php doesn’t help either. For some reason going to http://whatever/wp-login.php doesn’t actually call the /wp-login.php file.

Some sites have the default .htaccess as posted by the wordpress installation, namely

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Some sites throw the 403, some do the 302.
When removing the last rewrite rule ( RewriteRule . /index.php [L] ) the 302 redirects stop, but when someone requests a different page on the site, you get a 404. So, this then doesn’t help.

I read somewhere that editing wp-includes/functions.php and adding

update_option('siteurl','http://siteurl');
update_option('home','http://siteurl');

should fix this, but all it does is break the site.

And no, we don’t run mod_security. It is not an option right now. How does one fix that 302 off wp-login.php? Anybody?