We often get asked, ‘Can Shield protect my site against brute force attacks on my login’?
The short answer is: “Yes, and no”
First, an understanding of Brute Force Attacks
It seems that many use the following terms interchangeably, as if they’re all the same:
- brute force
- DoS (Denial of Service)
- DDoS (Distributed DoS)
They’re not the same.
We’re not going to cover the different types in detail here, but give enough overview to get the main points across.
In general terms, ‘Brute Force’ attacks can be used to gain unauthorized access, while D/DoS is used for service interruption – e.g. to bring down a site.
An example of brute force is a dictionary attack against a site login. This means that the attacker will test logging in to your site using username/password combinations until they find 1 that works. They’ll normally use a “dictionary” of the most common passwords, and especially passwords that have been pwned. There’s a good chance they’ll find a combination that works if poor password policies are in-place.
Try to imagine the number of requests needed to find a combination that works. Hint: it’s a lot! But what happens when site gets a lot of requests, i.e. more than it can handle?
The site will likely crash, or at least slow to a crawl.
In the case of this type of brute force attack, it’s not in the attacker’s interests to take down your site -they need it up and running to continue with the attack.
How else can they test username/passwords?
A quick mention of D/DoS attacks
The purpose of D/DoS attacks isn’t (necessarily) to gain access. They’re primarily used to cause service disruption and to take down a site/app/service.
It’s based on the simple fact that if you bombard a site with too many requests, or force it to do too many high-load tasks, it’ll crash. Job done.
If you’re looking to gain access to a site, this is not probably the way to do it.
So how does Shield Security help with Brute Force attacks?
So let’s assume the attack is to try to find a login username/password combination. If they’re remotely clever, they’ll do so in a way that site performance isn’t impacted too badly.
But, they’ll need to send enough requests that they can make good progress.
Shield Security is ideally positioned to handle this. Shield will intercept every failed login attempt and black mark any IP address that makes a failed request.
Sure, many people can get their login wrong now and again, and that’s okay. Shield can be configured to allow a number of these requests through. This limit is down to the security admin to decide.
If all these requests come from the same place (i.e. same IP address), it’ll be easy for Shield to identify the culprit and block the IP address, preventing further attempts.
Unfortunately, it’s not always the case that the requests come from the same place. In this case, you can say that the attack is “distributed”.
Note: This is what the 1st ‘D’ in “DDoS” stands for – the attack is coming from more than 1 place.
Distributed makes it a little harder to prevent these sorts of attacks as there’s no way to know that they’re related. But that doesn’t actually matter too much, as it just needs the same IP address to make enough failed login attempts to get itself blocked.
So distributed or not, Shield will handle it.
What about the IP lists database? Doesn’t it get huge?
We’ve talked before about the inherent weakness of IP addresses – they should never be used as reliable identifiers of bad actors. IP addresses can change, and they do change. This is especially true of IPv6 where we have many more possibilities for addresses than ever before.
If an IP address was placed in a database and left there every time you blocked it, your block list would balloon over time. Especially during a “distributed” attack.
So what’s wrong with that, you might think?
If you have any IP addresses on your black list, then every single request to your site must be checked against it. That’s okay if you have a small database, but it becomes completely unusable if you have a huge block list that never gets trimmed.
Shield’s IP Manager handles this for you automatically, however. After it blocks an IP address, it’ll keep the IP on its list for a fixed period of time. Once this period has expired, it’ll release it automatically.
This is hugely important for performance and black list reliability, and is sadly overlooked by most black lists implementations.
What Shield settings can help with login protection?
Almost from the 1st release of Shield we included a powerfully simple brute force protection mechanism – the login cooldown.
This option enforces a cooldown period after each login attempt – the default is 10 seconds. This means that after you login, you must wait 10 seconds before WordPress will even consider allowing any other request to login.
That’s a maximum of 8640 possible logins per day. Sounds like a lot? With this restriction, a 10-character, alphanumeric password could take over 266+ billion years to crack.
With the cooldown alone, you’re protected by brute force attacks before you’ve employed any other “fancier” protection options.
As well as the cooldown, you have various bot attack prevention options, including our exclusive silentCAPTCHA AntiBot system technology.
Not only that, if you’ve turned on 2-factor authentication, it doesn’t really matter if someone gets your password, they now also need access to your email account or Google Authenticator.
Can Shield help with D/DoS attacks?
Generally speaking, no.
There is no WordPress plugin that can honestly state that they can mitigate a D/DoS attack.
The best place to stop such an attack is before the requests even reach your server. And for this, we recommend that every site you manage is run through CloudFlare.
The moral of the story is…?
Shield is ideally positioned to protect your site from brute force attacks. It comes with many mechanisms which handles them easily with no effort on your part, and no degradation in your site performance.
But don’t get ‘Brute Force’ mixed up with D/DoS attacks – they’re really not the same thing. D/DoS can’t ever be properly mitigated by any WordPress security plugin, no matter what their marketing materials tell you.
If you’re worried that you might be subject to an attack, load up Shield Security and as soon as it’s activated, your protection starts immediately.
