Admin Tools

#40055 Auto-ban for Suspicious Core Parameter not working

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
PHP version
Admin Tools version

Latest post by nicholas on Wednesday, 27 December 2023 02:53 CST


It seems that no matter what combination of settings I choose for the auto-ban function, it will not ban multiple instances of Suspicious Core Parameter (SCP).  I am receiving hundreds of blocks for SCP, many within only seconds, yet the IP address is not being banned.  

I have auto-ban currently set to occur after 4 instances in 5 minutes, but have tried multiple different combinations to no effect. I am attaching a log of blocks just from today (first 11 hours). You will see we are already at nearly 250 entries; yesterday was a total of 846 entries, nearly all SCPs.

Please advise how to resolve.

Thanks for your help with this--


Akeeba Staff

This feature is working and it is working really well. Everything you sent me is hacking attempts.

Let me tell you something. URLs like this

are NOT correct. The final slash is not part of the URL path, it's part of the URL parameter Itemid. It literally says "the Itemid parameter is one zero one slash slash". You thought that because is the same as the same thing applied here. You were wrong. The example has the trailing slash in the URL path where it is (mostly, but not always) ignored. The URLs you sent me, the trailing slash cannot be ignored in them.

If you have something on your site which keeps generating these URLs then please contact its author and let them know that they shouldn't be adding random slashes or paths to URLs. Joomla! has a URL manipulation class (Joomla\Uri\Uri) and a SEF router which should be used instead. As for the other URLs, I believe it's very obvious to you that they are SQL injection attempts which would have previously been caught by SQLiShield. 

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


Hi Nicholas--

Thank you for the quick reply.  Perhaps I have not explained the situation fully or properly. 

When a 404 Shield error is triggered repeatedly and within the parameters of the auto-ban setup, that address is blocked from further attempts, the address is added to the Auto-blocked IP Address list, and the appropriate message is displayed in the user's browser (see screenshot below).,

HOWEVER, when the SCP is detected, while site access is blocked momentarily, the blocked access is logged, and the IP address is added to the Auto-blocked IP Address list, the user is not restricted from further attempts as I understand Auto-ban is designed to function, and they do not receive the auto-ban browser message shown in the screenshot below. 

I have exercised both types of attempts just now on our site using different VPN/IP instances and, while the 404 Shield error is working just as expected, the SCP error is not. Even manually adding the SCP-source IP address to the IP Disallow list does not stop further SCP attempts from the same IP address

Perhaps you can run the same test I just ran.  Make five or more attempts in short succession to login to the site using as the URL The blocking process works, and you will be banned after the 4th attempt and the browser will display the front-end message. 

Next try from a different IP address to access the site with;%20AND%201=1%20OR%20(%3C%27%22%3EiKO)), five or more times in quick succession.  That will result in entries into the blocked attempts on the back-end, and you will be blocked from accessing the site each time, but the IP will not be auto-banned, you will not receive the auto-ban message in the browser, and you will be able to continue multiple attempts going forward.

It is this last situation that is creating a problem for us in that someone is repeatedly hitting the site with SCP URLs, up to nearly 1000 in a day.  Of those attempts, nearly all were done in rapid succession (within the auto-ban parameters) and from only one or two ip addresses.

My conclusion at this point is that auto-block is working for SCP URLs, but auto-ban is not working for SCP URLs as I understand is intended.  Certainly auto-ban is working differently for 404 Shield attempts when compared with SCP attempts.

If I have a misunderstanding of how the auto-ban should function, or on which types of accesses it does and does not work, then please help me understand.

Thanks for your patience--hopefully your quick tests/attempts to replicate the issue will help explain the situation.


Akeeba Staff

TL;DR It does not matter why a request is blocked, it participates to automatic IP blocking all the same. When your site gets many requests at the same time the consistency model of the database (BASE instead of ACID, if you want to be technical) means that it may take dozen to hundreds of requests before an IP-level block is established. When the IP-level block takes place there are no longer any log entries in Admin Tools to show you these requests are blocked. You can still see them being blocked in your web server's access log, therefore you can see that Admin Tools DOES work.

Your analysis was wrong. You have not read the documentation and you are jumping to false conclusions.

Regardless of what the blocking reason is, the request is blocked. That's why it's called a blocking reason.

Moreover, regardless of what the blocking reason is, the fact that the request was blocked (including the target URL, blocking reason, and IP address) is recorded into the Blocked Exceptions Log unless you have explicitly told Admin Tools not to do that in Web Application Firewall, Configure WAF, Logging & Reporting, “Do not log these reasons”.

Every time there is a blocked request, Admin Tools evaluates the auto-blocking rules set up in Web Application Firewall, Configure WAF, Auto-ban. It will automatically block an IP address for a limited amount of time based on the “IP blocking of repeat offenders” settings and the contents of the Blocked Requests Log. If the same IP address is receiving temporary bans and you have set up “Add persistent offenders to the IP Disallow List” then Admin Tools will permanently block it.

There are two critical things you need to understand about how a request block turns into a temporary IP-level block, and eventually a permanent IP block.

The evaluation of the rules to block an IP address does not happen until there is a blocked request. Since you have a lot of requests coming in at about the same time, they are queued for processing by your web server, and are processed in parallel according to the number of PHP threads available on your server. When each request is processed, Admin Tools loads the list of temporarily and permanently blocked IP addresses. There is a small lag between an IP block record being written to the database and the database being able to return it when we ask it to list the contents of that table. This comes down to MySQL's consistency model which favours performance over consistency (all RBDMS work like that; consistency-first approach is only common across key-value storage databases like Redis and memcached which is why they hold the data in memory, so as not to obliterate performance due to the orders of magnitude slower permanent storage I/O).

The evaluation of IP blocking reasons means that Admin Tools asks the database to return the number of blocked requests from this IP address within a specific time period. Remember the database is being accessed (read to and written from) several threads handling different requests at the same time. As I explained, this means that for a very short period of time after a write, a thread reading from the database will see stale data i.e. what the data looked like before the write operation. Therefore, a number of requests are individually blocked without being able to “see” that there were a few dozen or a few hundred other requests being blocked at the same time in other threads.

The combination of these two factors means that if there are “too many” requests at the same time they will be blocked individually, but the IP block won't be triggered until some of the last requests are being processed, when the database finally returns the entire list of blocked requests, at which point we write another record in the temporary IP block table. Then a few more requests are individually blocked until the database finally returns the new temporary IP block record to Admin Tools, at which point any further requests are blocked without being logged.

If you check your access logs you will see that following the small barrage of requests blocked individually by Admin Tools and logged as blocked requests there's a continued deluge of requests being blocked by Admin Tools (at the IP address level) without being logged. Not logging requests blocked at the IP address level is a deliberate feature, implemented as a default value for the “Add persistent offenders to the IP Disallow List” option, to prevent an attacker from overwhelming your site's database by sending requests from a blocked IP address.

Technically, it is possible to have MySQL operate in a more-or-less consistency-first mode, by locking tables for reading and writing. The problem is that this approach is detrimental to performance. The web server can no longer process requests in parallel as the table lock means the database is waiting to be told it has the go-ahead to read from or write to the Admin Tools tables. When you have someone sending a few thousand requests within a few seconds this would mean that instead of processing them (and blocking individually) these requests within a couple of seconds we'd need several minutes to process each one of them individually, and arrive at an IP-level block sooner. In both cases, all requests are blocked. In the consistency-first mode, though, your web server's CPU usage spikes, and your site is unavailable for legitimate visitors for several minutes. That's why we did not choose to do this. Using the less consistent mode of operation we are STILL blocking all requests, and your server is unavailable for legitimate visitors for a few milliseconds to a couple of seconds.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!