Support

The number of blocked requests is not a KPI. If there are no attacks against your site, that figure will be zero. On our business site we have between 500 to 800 attacks blocked every day. Moreover, what's blocked depends on which options you have enabled.

I deliberately tried to log in incorrectly.

Meaning what exactly? I can see three obvious ways you are testing the wrong thing.

Administrator password protection? That's handled at the server level, before PHP, let alone Joomla and Admin Tools load. That's why it won't ever be logged and is the entire point of this feature as documented. I see that you do have this feature enabled. You will see my IP in your server logs (with an HTTP 401 response), but not Admin Tools. This feature did its job; it kept someone who doesn't know this username and password from even accessing PHP.

Wrong administrator URL parameter? By default, your browser has a cookie upon first successful use of this feature. When present, this cookie overrides the check, as documented. I cannot test that on your site as I don't have the username and password for the administrator password protection.

Wrong username and password? Won't be blocked unless "Treat failed logins as a reason for blocking the request" is enabled. I can see that you have not enabled it. I tried an invalid login (username: invalid, password: login) from your site's frontend and wasn't blocked. Yes, I can trigger the login even if you do not have a login menu item or module, and even if your site is configured to not allow user registration. I know how Joomla works, in great depth, which is why the "Treat failed logins as a reason for blocking the request" feature exists.

Without having the context of your configuration and what you actually tried doing I can't tell you what's going on, but my money is on you testing something that shouldn't and isn't blocked.

Admin Tools is definitely working. I tried a SQL injection against your site and I got immediately blocked with the default Admin Tools message of “WE DETECTED THAT YOUR LATEST REQUEST MAY HAVE BEEN PART OF SUSPICIOUS ACTIVITY AND HAS BEEN BLOCKED. IF YOU BELIEVE YOU ARE GETTING THIS MESSAGE IN ERROR PLEASE LET US KNOW THROUGH OUR SITE'S CONTACT FORM.” Hey, congratulations, now you have one item in your Blocked Requests Log! My IP is still not blocked since I only tried one SQL injection. If I did it repeatedly it would've been blocked.

So, yeah, I am pretty sure that your sites just don't get this many attacks to begin with, you are looking at the (permanently) blocked IPs instead of the blocked requests log, and you're running invalid tests which shouldn't and don't get blocked by Admin Tools. Makes perfect sense why you see nothing even though Admin Tools works perfectly fine.

You did not read my response carefully enough.

I already told you that you must be looking at the Blocked ⭐️⭐️⭐️ Requests ⭐️⭐️⭐️ Log. Not the site IP disallow list, not the auto-blocked IP addresses. I hope the horrifyingly garish formatting of that word in this reply finally draws your attention to it. It's a request that's blocked, not an IP, at this stage.

It's as explained in the documentation.

When a malicious request is blocked, it ends up in the Blocked Requests Log. 

When it happens enough times as per the “IP blocking of repeat offenders” settings, it will end up in the Auto-blocked IP Addresses. This is a temporary IP ban. I explicitly stated I did not do that, therefore my IP cannot possibly be in that log.

When an IP appears enough times in the Auto-blocked IP Addresses as per your “Permanently disallow IP after this many automatic blocks” settings then and only then will the IP be permanently blocked, i.e. put in the Site IP Disallow List.