Stopping WP-Admin brute foce attempts

Do you want to stop people from trying to brute force your Word press installation and you already have IIS ARR running?

I have to say that I have not really bothered so much about failed wp-login attempts but for the last 6 months or so I have been saving my IIS ARR logs into Kibana and created views for popular sites and pages on my webservers here at home.

For me it was a bit of an surprise that wp-login.php came up on the 2:th place as you can see below, 23k hits / month does takes up resources on the servers as it has to validate each request, not an ideal situation..


Therefore I decided to stop these requests. I have used IIS ARR as an reverse proxy for several years and have always had good results with it’s rewriting engine (actually not part of ARR itself but an essential part for the Reverse Proxy functionality) So I’ve decided to create an custom rule that would re-direct unknown users who access the wp-login url.

It’s quite simple as described in the following screenshot:


As can be seen It’s actually an Inbound rule (not a block rule) as I didn’t have much success with the blocking rules. Also they did not give me the flexibility I’d needed on the action as it only allowed for HTTP status codes to be sent back, i.e. 404.

In this case I’m doing a re-direct to just to give the attackers web script some hick-ups 🙂 depending on how well they have been written. The rule applies to all URLs that contains the wp-login page so I can protect all my sites. But this will not allow me access and therefore I would not be able to write this blog post. True and that would be an bad idea. Therefore I’ve added another condition using “Rewrite maps”. They are essentially a way for IIS to replace a value with an variable to give logic to an expression.

If the variable AllowedWPAdmins contains my own IP {REMOTE_ADDR} it will replace it with an “1” and the pattern will should not match and I will not be kicked out of wp-admin.

The actual IPs are stored in the Rewrite maps:


This will allow both my IPv4 private IP login and my public IPv6 adress access. The condition are replaced with the “New value” so that it can be matched in the Inbound rules section about.

Of course you do not have to redirect the users, you can do a simple 404 o a custom response, for example sending a HTTP 500 response with a custom text telling the attacker, well whatever you feel like 🙂

Direktorn Comments


Pin It

Comments are closed.