- This topic has 21 replies, 5 voices, and was last updated 11 years, 4 months ago by
.
-
Posts
-
Sure enough. Every time my site bogs down I look at All-in-One and find a brute force attack in progress. It is usually from someone with the username “admin.”
Is there a way to just block that so I can get them to move off right away? Is that unwise? I certainly do not use that username on my site.
The IP addresses are never complete and they vary a lot.
I am so glad to have this plug in so that they don’t stay around for long!
Thank you 10 gazillions for this plug in!!!!
Hi Pam, You could put a .htaccess file in your “wp-admin” folder so that no one but you (from the IP address you specify) can access the login page.
We will add a feature in the all in one wp security plugin for this but for now you can manually do it by using the instruction here (look at the “Protect the wp-admin Directory” section):
http://www.tipsandtricks-hq.com/essential-wordpress-security-tips-is-your-blog-protected-987
If I might offer a suggestion: Rather than monitoring logins which consumes considerable resources, prevent all access to wp-admin based on the absence or presence of a cookie.
The cookie can be created and sent to the browser from any page (perhaps via an embeddable shortcode?), but obviously it would be safest to serve the cookie from a secure page. Anyone invoking wp-login or wp-admin who doesn’t have the cookie can (and should) be redirected away to a very small page that requires no resources to serve (e.g. a simple .html). Or you can do what I like to do and redirect them to “http://127.0.0.1/goawayjerk” where they will be using their own bandwidth to serve themselves – or time out trying – or perhaps to a honeypot.
In fact, if the required cookie is created behind a password protected page and is dynamic then this would constitute a two-factor authentication. The second factor being the actual login credentials.
http://www.willmaster.com/blog/contentprotection/htaccess-cookie.php
Thank you for the great feature suggestion. We plan to add a feature for this in the security plugin.
Two factor authentication can already be accomplished, using Google Authenticator.
Dear Peter and Ruhul,
Thank you so much for this! I love it when you stop the creeps!
A lockdown event has occurred due to too many failed login attempts with the following user details
Username: unknown
IP Range: 79.135.42
Cheers, Pam
My first instinct is that, because it is a Class “A” IP address; there is an infected or rogue device on your hosting provider’s network (maybe the NSA? LOL).
LOL wzp!
Better the NSA. Who wants to be bugged by just some neighborhood hacker in his basement. At least I attract the big guns but I have you guys with bigger blaster-ray guns. Mess with me, will ya?
But now if I block that whole Class A address am I’m shutting off my site to valid users? Can’t seem to clear this question up by googling. Don’t know if it means I’m am blocking all IPs of 79.135.42.XX.
Can you help clarify? Is it a bad move a Class A address?
Tx, Pam
Hi,
When you enter the following address range 79.135.42.* in the Blacklist menu of the plugin, it will write a rule in your htaccess file as follows:
Deny from 79.135.42.0/24
What this means is that it will deny any persons with an IP address which falls in the following range:
79.135.42.1 to 79.135.42.254
So in effect you are blocking 254 addresses.
Yes this does mean that anyone legitimate with an address with this range will also be blocked but this is also a trade-off when using this technique.
We might in future change the behaviour of the locked IP address listing to show the individual IP address instead of the range and let the user decide whether to block a single IP or a range.
I hope that answers your question.
Peter and Ruhul,
Now I had another interesting attempt. A string of different class A IP addresses trying variations of the admin username like adm, administrator…just 1 to 3 tries each.
I had no idea at all that attempts were being made so often and I was so vulnerable!
Okay, I’ll stop pestering with how incredibly useful this plug in is!
Pam
Two factor authentication can already be accomplished, using Google Authenticator.
Thanks for that tip, but using that plugin against brute force attackers means consuming hosting resources to serve the WordPress login page. I am currently seeing about 4,000 daily requests against my wp-login.php page. Any server overhead processing logins from an attacker eats my server resources at my expense. I am still looking for a good solution that will divert the traffic with very low overhead (CPU or bandwidth).
Keeping track of IPs, number of login attempts, etc. sounds like a good thing, but really it’s wasting resources. Case in point, I have the Redirection plugin installed and one side effect of that activity is that the default “missing page” logging consumed about 12 MB in my database in a few afternoons due to attackers.
I have seen people who have moved wp-login.php to somewhere else e.g. opensesame.php but I understand that tactic has issues. Once wp-login has been moved the new “wp-login.php” page could serve up a nice tasty empty document, or get redirected to the NSA
. Or better to 127.0.0.1 so that the attacker requests the resource from themselves!I’m entirely certain that my userid’s and passwords are secure from attack – I use LastPass [http://lastpass.com] to generate (and store) both the userid and the password. No attacker will manage to guess a userid of “w56mFry2U#5q” with a password of “zc9%nUFupv!e” **
I just don’t want my server wasting any time providing a login form or processing a response from a source that clearly is not me!
As for tracking where the attacks are coming from – that data is in the server logs. I already know that the attacks are distributed across thousands of servers – most of which are in China
http://blog.starcircleacademy.com/2013/05/chinese-robot-attack/
**Of course those are not my actual userids and passwords, but my actual UID and password were generated with the same randomness.
Hang tight for a few more days… we have the following feature in the works:
Redirect to the void zone if a *special* cookie is not set.
“Redirect to the void zone if a *special* cookie is not set.”
That’s good to hear!
Pamela,
Peter and others have given you some good tips but let me expand a little bit.
1. An IP address may represent not one person or machine, but hundreds (or thousands).
>> Because this is true by blocking any one IP address you may in fact be blocking whole companies, households or neighborhoods.
2. Because of things like “proxy servers” it’s possible for the same person to pull from your server from multiple addresses even though they are doing it from one machine.
>> Even if you block “BadGuy” from 123.45.67.89 it doesn’t stop him (gotta be a him, right!) from attacking you from 98.76.54.32 by using a proxy server.
3. There are HUGE armies of zombie botnet servers. These are machines that have been compromised in some way so that they do what they are told to do – like sending email spam or posting comment spam, or attempting to break into websites. Many of them were compromised when people foolishly installed “freeware” or clicked seemingly innocent sounding links. In fact, I’m pretty sure some “wordpress” plugins are in fact vectors for bad behavior.
>> In short, this means you should assume badguys are everywhere. Worst case they destroy your machine by stealing data, bandwidth, or services. And worst-worst case they turn your machine into a vector for attacking others.
I say these things not to scare you (though there is reason for worry), but to let you know that vigilance is a good thing. And secondly the “All in One” security tool is a great tool to help – but don’t get a false sense that you can blindly install plugins or software on either your server or your personal machine(s).
- You must be logged in to reply to this topic.