Support

Thank you for your detailed message and for doing the homework on what's available in Admin Tools.

To answer your questions directly:

1. Is there a configuration option in Admin Tools Professional for Joomla 6 that blocks an IP after failed logins?

No. Admin Tools does not currently have a built-in mechanism to track failed Joomla administrator login attempts and auto-block the originating IP. The Auto-ban feature in Admin Tools works from its own Blocked Requests Log (WAF violations, honeypot hits, etc.), not from Joomla's authentication failures. The "Deactivate users on failed login" hardening option also requires the username to exist on the site, so it does not help against the kind of username-cycling attack you described.

Nicholas told me he has thought about adding this feature, and the reason it has not reached the product yet is that tracking failed logins for usernames that do not exist on the site carries a significant risk of false positives. Users frequently mistype their username, conflate their username with their email address, or are not sure which of their three usual usernames they used on a given site. Blocking their IP in those cases would be worse than useless — it would create support tickets. He may add this as an option with a prominent warning about this behaviour in the future.

Another feature Nicholas has in mind is the ability to block logins using "forbidden" usernames. This was part of a two-pronged concept: disallowing registration of forbidden usernames (already implemented), and disallowing login to the site using those usernames (not yet implemented). This will come.

However, and regardless of these future changes, if an attacker follows a "spray" strategy — using a large number of IPs in a credentials stuffing attack — these features will not fully protect you. They will still see blocked requests because there are simply too many IPs involved. You cannot stop that. You have no control over what other people do. Your control is on your site, and that control comes from making credentials stuffing fail, not from trying to block every attacker at the network level.

2. Is this provided by Akeeba LoginGuard or another product?

Akeeba LoginGuard as a standalone product no longer exists. Its features were contributed into Joomla itself starting with Joomla 4.2. Joomla's native Multi-factor Authentication is Akeeba LoginGuard — under a different name. This is covered in point 3 below.

3. What is the currently recommended configuration?

Our recommendation is a layered approach:

Frontline defense: Administrator Password Protection — This is the primary defence layer. It requires a pre-shared password in addition to the standard Joomla credentials, making it extremely hard for automated tools to even attempt login.

Backup: Administrator Secret URL Parameter — You are already planning to enable this. It hides the administrator login URL behind a secret path, effectively removing the login page from public visibility.

Last line of defense: Multi-factor Authentication (MFA) — The Akeeba LoginGuard suite was contributed into Joomla 4.2+ as the native Multi-factor Authentication system. We strongly recommend enabling MFA on all administrator accounts. We are also preparing a companion plugin that will allow you to disable password-based logins entirely for accounts with two or more passkeys configured — passkeys provide the strongest possible authentication.

While MFA and passkeys will not stop attackers from trying to log in, they guarantee that they will fail to gain access. Hiding the door (via Secret URL) is useful, but making the door's lock virtually unpickable is what truly matters.

If you'd like an immediate fix for the current attack, you can add the attacking IP (216.107.136.107) to the Manual IP Deny List (Admin Tools → WAF Configuration → Manual IP Deny List). This will block it right away, though it does not scale for future dynamic IPs.

In case you're wondering about the third person in my reply – I had my developer draft the reply, I edited it, I posted it, and forgot to change it to first person. Oops!

Another point that was probably lost here is that the Treat Failed Logins As Blocked Request will indeed block these IPs after a few failed attempts each. Still, you perceive it as non-effective because the attack is spread across multiple IPs. If you have a threshold of three attacks in 5 minutes and the attacker is using 100 IPs they do get 300 tries.

Also, I just remembered something.

Having had this kind of attack launched against me. It's ultimately impossible to stop it in any meaningful way on your server, be it automatic or manual. The attacks come from a variety of IPs from different providers, countries, and continents – I bet that's a botnet comprised of compromised devices and servers. Because of that, you can't block an ASN or IP block and call it a day. The only giveaway is the rate of requests, but filtering on the rate of requests requires having Redis (or a similar in-memory database), as using an RDBMS like MySQL or PostgreSQL to keep count of request rate per IP will lead to performance degradation on your site, ultimately turning a merely annoying credentials stuffing attack into a Denial of Service.

One thing you can do is use something like CloudFlare which can indeed notice the rate of requests and throw a CAPTCHA page to the attacker. Even if they use automated methods to solve the CAPTCHA (with varying degrees of success) this slows them down and wastes their resources badly enough that they eventually stop even trying. That said, most of these credentials stuffing attacks are not that sophisticated; when they are met with a CAPTCHA page they just move onto the next credentials pair. When they fail enough CAPTCHA pages their IPs get flagged as spammy and CloudFlare just declines serving them altogether.

Do note that Apache does have built-in modules which can rate-limit requests. However, I recommend NOT using them. If you make the limits sensitive enough to block these attacks (which consist of a single HTTP GET and POST request pair for each credential) they will be sensitive enough to block legitimate traffic (which consists of dozens of requests to fetch all the media files that go with your page). If you make them lax enough to allow legitimate traffic, they won't be stopping the malicious traffic – and they might indeed stop some of the legitimate traffic regardless. This is why having CloudFlare show a CAPTCHA page is a better solution. It will catch legitimate traffic, but it will mostly just be a 2–3 second delay while a small piece of JavaScript checks it's a real browser accessing the site, with a fallback to a traditional CAPTCHA if JS is disabled or the auto-detection fails. Legitimate visitors caught in error will be marginally slowed down or ever so slightly inconvenienced whereas malicious traffic will be stopped dead on its tracks. This is not something you can do without a fairly elaborate setup that's beyond what is realistic on commercial hosting, and definitely beyond what I could realistically ship in a mass-distributed extension (that is to say, I know how to implement it, which is how I know it won't work for the vast majority of my clients who can't have access to the server software and environment configuration necessary).