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.
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.
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.
No Comments