Handling Wordpress Brute Force Attacks

[animalstyle]

So my rep over at knownhost calmly pointed out to me that memory spikes I see in my logs are due to brute force attacks on my wp-login.php file. It seems that brute force attacks are designed to either get into your admin, or consume server memory until it crashes. I have a non-'admin' username and a very secure password so I don't feel a need to quickly jump into a solution

He suggested installing a plugin called Wordfence.

I am really not excited about anything, especially a plugin that restricts access to my site for fear of messing something up.

Wordpress has a lot to say on the subject: https://codex.wordpress.org/Brute_Force_Attacks

Hoping someone can give me some guidance on what they do to handle these attacks.

 

[built]

Change your login URL to something unique. I like Ithemes security, you can ban people if they create too many 404s, ban people who use "admin", change the login url etc

 

[Ryuzaki]

Using the plugins that block attempts after 3 fails or whatever... that's just loading up your database full of proxies and there's always more proxies.

I'd use .htaccess to block all traffic unless it's your own IP. You can always login via FTP wherever you are if you need to add one and remove one.

 

[SmokeTree]

I'd recommend a variation of this using Fail2Ban: http://envyandroid.com/fail2ban-wordpress-login-attacks/ As @Ryuzaki stated, you really don't want all those IPs in log files. With Fail2Ban, you set an expire time so you only ban an offending IP for an hour or so or even 15 minutes then drop the entry from the firewall when the rule expires so you don't end up with every proxy IP in the world in your firewall rules. That's more than enough time to discourage a brute force attack and Fail2Ban is using iptables for the actual banning which is how you want to block IP address you are serious about blocking.

You can set your own IP up so Fail2Ban will ignore it. If you notice certain IPs or ranges that are persistently attacking the server, you can block them in iptables for good. Keep in mind when you use .htaccess, that this file is read/evaluated with each request and honestly, Apache makes a pretty slow/poor firewall.

 

[Tucky]

For my main site I use the guys at sucuri.net who keep the baddies out for $99 a year.

 

[animalstyle]

@SmokeTree Fail2Ban looks a little over my head. Maybe the guys at knownhost could handle it for me tho?

@Ryuzaki The .htaccess looks like it would work, my ip changes sometimes so this would require some maintenance. Not a big deal, but:

This solution seems like the one that I could set and forget, plus it has advantages for also helping with comment spam. Am I making a good move trying this?

Deny Access to No Referrer Requests
Extended from Combatting Comment Spam, you can use this to prevent anyone who isn't submitting the login form from accessing it:

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
    RewriteCond %{HTTP_REFERER} !.*example.com.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]
</ifModule>

 

[BigWhite]

Restrict access to the page by IP from your apache configuration. This is your best bet. If you are on the go, you can just temporarily add your other IP via SSH or SFTP without needing to be on that IP.

Wordfence is a great plugin though, so that is actually a solid recommendation regardless. I use it on sites that I don't pay attention to frequently.

 

[dresden]

I recently dealt with the tricky xml-rpc brute force attacks. the attacker can send tons of attempts with each request - and it kept bringing down mysql with memory issues. lots of fun to deal with - so a friendly reminder to disable xml-rpc if you're not using it for anything.

 

[Terrestrial]

Hey all,
I'm gonna say that some of the comments above went over my simple monkey brain.
I have used both wordfence and scuri. I have not noticed issues with wordfence myself, but I have heard tales that it can (possibly) mess with your site being crawled and indexing new posts/pages due to some blocking issues. Again, I have not seen that, but I have heard it from folks who I believe test pretty well.
That said, I want to copy/paste something that I got from a group I'm in. If that's ok with admin and everyone. If not then just delete please. :

In our company we do a lot of testing on our development server. Right now we really like a plugin called Shield https://wordpress.org/plugins/wp-simple-firewall/. Formally called Simple Firewall this bad boy is way beyond simple. It does for free what a lot of plugins charge for and does it in a very elegant way. We particually like the way it limits logins and kills off *all* spam comments. We had a client getting a lot of spam comments on her blog while running wordFence. We installed Shield and all the spam comments disappeared thanks to how Shield ensures that a real person is making a comment. She also stopped getting attacks on her wp-login.php after we made the switch.

Ok, so I haven't tried this out cause I'm focused on one site right now, but I had never heard of this one. Anyhow, it's an alternative to wordfence and Scuri.

Please resume your ht.access conversation.

 

[Frequencies]

I did use .htaccess to block all traffic to admin. But otherwise I do not know how to keep my site secure. That's why I chose for websynthesis hosting.

 

[turbin3]

For a server-side method, a good way to entirely bypass this issue is add a bit of server-side code to IP restrict wp-login.php, /wp-admin/, wp-signup.php, or any other possible attack vectors a normal user has no business accessing, to only the specific IP's you use. This will deny all others. Taking this a step further, in an effort to reduce memory consumption, instead of serving an entire 404 or 403 page for restricted users, you can send a HTTP 403 header response. This way there is no page load, save for the small size of the response header. Here's some example code for Apache servers:

Order Deny,Allow
Deny from all
Allow from xxx.xxx.xxx.xxx
ErrorDocument 403 ""

Obviously, you'd insert your IP instead, and any others you need to whitelist.

Also, for NGINX servers, something similar to this should work:

location ~ wp-(login|signup)\.php$ {

            set $allow false;
            if ($http_x_forwarded_for ~ "^XXX\.XXX\.XXX\.XXX") {
                set $allow true;
            }
            if ($allow = false) {
                return 403;
            }
        }

Just beware, based on your server setup and site configuration, the exact pages you're trying to block, etc. you may have to customize some of that code to work properly. Test and verify it.