Brute-Force Login Drip Attack
![[ Brute-Force Login Drip Attack ]](https://perishablepress.com/wp/wp-content/images/2016/brute-force-login-drip-attack.jpg)
I’ve been noticing a new strategy for brute-force login attacks: the slow, incremental “drip” attack. Instead of slamming a login page with hundreds or thousands of brute-force login attempts all within a few minutes, some attackers have been taking a more low-key approach by slowing down the rate of login attempts in order to bypass security measures. The “drip” brute-force attack is extremely annoying, and possibly dangerous if any of your registered users are using weak login credentials. This article explains more about how it works, and then looks at some potential solutions for protecting against “drip” attacks.
A real nuisance
If you’re using strong passwords (and usernames), there really is nothing to worry about security-wise from brute-force threats. Performance-wise, on the other hand, yeah it can be a real nuisance, especially if you have multiple sites under simultaneous attack, drip or otherwise. You’re either paying for the extra server resources in large bursts or spread out over time, drip.. drip.. drip..
Either way, you should be conserving your precious resources for legitimate visitors. Not clueless kiddies with nothing better to do.
Unstoppable?
The real problem with the drip-style login attack is that there is no practical way of preventing or blocking it. From what I’ve seen, these sorts of slow-motion attacks occur at a rate of about one login attempt every 30 seconds, but it varies. That may not seem like anything to worry about, but you would be surprised at how few attempts are required to break a weak password.
And time is not even an issue when you’re running brute force on hundreds or thousands of sites at a time. It just means that you’re getting results at a slower rate, which actually may work in favor of the attacker, if you think about it.
So the threat is real, but can it be stopped? Consider the following general strategies for dealing with brute-force login attacks, slow or otherwise:
- Private/whitelisted IP-based login – very effective
- Secondary HTTP Auth Prompt Login – effective, but still prone to attack
- Two-factor authentication – effective, but still prone to attack
- Blacklisting based on User Agent – not effective, UAs are trivial to spoof
- Blacklisting based on IP Address or Host – can be effective as a short-term solution
- Block based on rate of failed login attempts – generally effective for typical brute-force, but ineffective for drip-force attacks
- Captcha fields and similar methods – can be effective, but still prone to attack
Clearly there are numerous ways of dealing with typical brute-force attacks, but when the login attempts are happening in slow motion, they are much more difficult to identify and block. This is because the recorded activity looks almost identical to typical user login patterns, especially when examining server access logs.
So unless you’re really paying attention, the drip attack is virtually invisible. Likewise for plugins and scripts: there is no easy way of distinguishing between normal user behavior and slow-motion drip attacks. I’m guessing that drip perpetrators are fully aware of this fact, and willing to spend the extra time in order to continue their attacks undetected.
Again, from strictly a security perspective, there are plenty of solid ways of protecting your site against password-guessing, brute-force, et al. But from a performance perspective, there aren’t any reliable, long-term solutions for stopping a slow-motion drip attack on publicly available login forms.
Just ignore it?
But then again, it may not be anything more than a harmless nuisance. Personally, however, I like to eliminate as many nuisances as possible, especially if they are decreasing performance and stealing my resources (i.e., memory, bandwidth, time and money). So for sites where I am the only person logging in, I whitelist the login page by IP address.
For example, with WordPress, I add the following snippet to the .htaccess file that’s located in the WP install directory:
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from 123.456.789
</Files>Problem solved. For all other login pages where registered users need to login to do stuff like download books and plugins, well, I’m still looking for an effective, long-term solution.
Short-term solution
As mentioned above, blocking by IP can be effective, but only when you are sure that you have identified an accurate, consistent set of addresses. Fortunately, you’ve got OCDs like me to monitor and scrutinize these sorts of details. And it turns out that I’ve managed to cultivate a working set of IP addresses associated with repeat drip-style login attacks.
Download
The following list is for informational purposes only. The listed IPs are implicated in ongoing drip login attacks. I’m making this list publicly available because it’s proven effective to stop the drip login attack on numerous occasions.
Based on the User Agent, Host, and other information reported with these IPs, most likely these addresses belong to a particular botnet or similar (as opposed to an elaborate proxy script). But this is speculative. Any feedback is appreciated.
15 responses to “Brute-Force Login Drip Attack”
well, how can you whitelist by IP adress when the IP adress is changing every now and then and when people login from different places?
I think the best and most effective way is password-protection with .htaccess /.htpassword….
by this the attacks are blocked before WP has to check the login credential, by this the database is not affected, overloaded
what do you think?
Great questions:
“how can you whitelist by IP adress when the IP adress is changing every now and then and when people login from different places?”
Not all IPs change. Mine does not. It’s also possible to have a set of fixed or changing IPs that can be whitelisted. Still others have dynamic IPs that either are predictable or set based on a specific range. In any of these cases it is recommended to whitelist.
“I think the best and most effective way is password-protection with .htaccess /.htpassword”
Secondary .htaccess password Auth/prompts also are useful, but can be a drain on resources and attacked just like the actual login form.
“by this the attacks are blocked before WP has to check the login credential, by this the database is not affected, overloaded”
True, but it still requires more resources than simply denying access if IP requirements are not met. Further, it’s possible to brute-force .htaccess password prompts, just like the form itself.
Ok, “my” IPs change so often and are not predictable because they are provided by Deutsche Telekomm ;=(
I do think that brute force attacks to WP Login are more frequent than to passwords prompts
so the .htaccess .htpassword-block is my “first choice”
that’s the problem with rules of thumbs, the reality is more complicated ;=)
thank you for the article, it is necessary to raise awareness
Thanks for the public list of IPs! Appended a “Deny from” to all of them and threw the list into my htaccess rockin’ your 6G Firewall. :-D
Exactly! ;)
Hey Jeff,
GREAT stuff always.
I’ve noticed an increasing number of drip-attacks across the sites I manage and have been brainstorming different ideas.
One idea that I got from iThemes Security is to change the login page to something other than /wp-admin. Example: Their default alternate setting is /wplogin.
I have noticed that the sites that I have this in place on do seem to have fewer login attempts.
Do you have any thoughts on this?
Also, many of the login attempts, that I see, try using the username ‘admin’ and ‘administrator’. I like the idea of automatically blacking the IP from logins attempting to login with a username that does not exist on the site.
Keep up the great work, and thanks!
-James
Hey James, I do like the idea of changing the URL of the login page, as it adds another layer of security/obscurity. It does help throttle login attacks, but also adds another of complexity. So it’s a trade-off between obscurity and complexity, and totally up to the web admin/developer as to the optimal/preferred approach.
And yes, if you’re sure that common usernames are not in use, then simply blocking such requests is an excellent idea. I may end up doing this on a few of my sites, and then posting an easy .htaccess technique to help others do the same. It’s a great idea, thanks for sharing.
How about setting up a few commonly-guessed user names as a sort of honeypot? Then if there are any attempts to log in as those users the IP is instantly blacklisted.
Hey Doug, yes I agree with you and James that blocking attacks that use common usernames could be very effective (assuming the usernames aren’t actually used on site). Either as a honeypot/trap or just straight-up blocking such requests. Will be posting a technique for this soon.
Is it possible, without great difficulty, for me to configure my browser to send a bit of “unique data” – that my website’s hosting server / htaccess file will detect – such that I can then condition access to my site’s wp-login file upon my browser’s ~unique setting(s)?
Anything is possible, but the easiest way would be to just use any of the existing pieces of information that already are sent, like IP address, User Agent, Host, etc. You can view your information using tools online or by installing a browser extension. Then once you’ve determined which data to use, you can use .htaccess or PHP to check for it upon each attempted login or visit to the login page, whatever.
My objective is to create a work-around for living with my dynamically assigned IP address. I’ve tended to think “Wouldn’t it be great if, as an added security measure, I had such a unique identifier”.
My thinking is that, if a unique IP is near the top of the list for defending against evil logins might not a simple alternative solution be to assign myself – via a browser setting – some other (additional) form of unique identifier – besides my (guessable) user name and (brute force hackable) password?
Perhaps my thinking is too simplistic? If so, I won’t mind you deleting this and I apologize for wasting your time.
Not at all, you could use any number of built-in variables already sent by your browser, including the things mentioned in my previous comment. For example, just requiring your specific Host and/or User Agent would be enough to stop a vast majority of attacks, spam, etc.
Also, as mentioned it’s possible to check/validate specific IP blocks, so even if your IP changes frequently, if say the first couple of octets or whatever remain static (such that only a part of the address actually changes), it would be super-effective to whitelist that portion of your IP for even greater security.
Of course you also/alternately could add your own special identifier that is sent with each browser request. To do so, you would need to build or use a browser extension that enables it. It’s actually not a bad idea, but would require much more in terms of effort implementing, etc.
I hope these ideas/infos are useful to you in some way.
It is possible (but not necessarily simple) to set up certificate-based authentication where access is restricted if a browser doesn’t have a particular certificate installed.
Interesting, maybe something that would be useful to Jeff in regards to his original question. Thanks for the infos.