Support

First of all, you DO NOT need to block an IP address for Admin Tools to protect your site. Please read our documentation where I explain this very explicitly. In fact, Admin Tools blocking the attack is a prerequisite for evaluating whether an IP address should be added to the temporary or permanent block list.

The file you sent me does not contain all the options which works together to block a request. It only says that you will be blocking an IP address for 180 days after detecting 3 blocked requests in 2 hours.

Sire note: what you are doing makes no sense. The idea of this feature is to block persistent bots. Something like 5 attacks in 2 minutes blocking the IP for somewhere between 5 and 30 minutes is what it's meant to be used for. What you are doing is essentially banning an IP address for a massive amount of time on the slightest suspicion of even a false positive. This is shooting your own feet. 

Also note that IP blocking is evaluated based on the records in the blocked requests log. According to your screenshot, you only have some template= in the URL which are false positives to begin with. There is no indication of an IP address being blocked for a 404Shield. Are you excluding that from being logged?

Ah, I think I know what happened to your site. There is an option that has no visible control in the user interface, “IP blocking of repeat offenders”.

When you use the Quick Start Wizard and enable automatic IP blocking this is turned on. If you do not use the Quick Start Wizard or choose to not enable this feature there this option is turned off. In the latter case the settings in the Auto-ban section of the Configure WAF page have no effect.

It would appear that everyone goes through the Quick Start Wizard which is why nobody had reported the missing option. After replying to you I started toying around with options trying to reproduce your issue which is how I discovered the reproduction steps.

I will make a new release on Monday to add this control in the Auto–ban tab of the Configure WAF page.

We released the new version yesterday evening our time (yesterday morning your time). You can update to it now.

Database error

The database warning about the missing #__admintools_waftemplates table seems to be something not working right in Joomla itself. Joomla handles the extension installation and update, including database table installation and update. Every time you install / update an extension it records that version in the #__schemas table. When you update the extension it checks that version and only runs the database update files which are newer than the version in the #__schemas table.

You got an error from the file 7.0.0-20210527.sql which shouldn't have run at all since you had already installed Admin Tools 7.0.7. There was no database update file for version 7.0.8. Joomla should have tried to run none.

The only reasonable explanation I have for you is that you had installed a dev release — even though I didn't tell you to do so — which does cause a problem with the way the #__schemas table is being handled. I was actually working on that yesterday, reworking the dev release versioning to avoid this kind of issues. In any case, I'll add a workaround for this particular database issue in the next release scheduled for January (we don't do releases during the holidays unless it's an urgent fix).

IPv6 allegedly not being recorded in the blocked requests log / no IP recorded

It DOES get recorded since several years ago if AND ONLY IF your server fully supports IPv6, i.e. it receives traffic from IPv6. If your domain does not have an AAAA record you will receive no IPv6 traffic and no IPv6 address will be recorded since there is no IPv6 traffic to begin with!

Our own site's server is nominally IPv4 only. However, our site is behind CloudFlare which does support IPv6. Its DNS zone is managed by CloudFlare which does add a AAAA record. We do see IPv6 addresses in our blocked requests log.

Also note that the visitor's IP is reported by the OS to the web server which sets up an environment variable which is read by Joomla itself. We ask Joomla for the IP address of the visitor. If you are behind a proxy, load balancer or CDN you need to enable the relevant option in your site's Global Configuration. If Joomla continues reporting no IP address at all it's either a bug in Joomla or something is wrong with your server setup.

404Shield not being triggered

It actually depends on your server configuration and how Joomla works under the hood.

When you try to access, let's say, /wp-admin.php on your site, a file which doesn't exist, the server normally throws a 404 error and shows its own server error page. Joomla is not loaded therefore Admin Tools doesn't run. As a result nothing is recorded.

When you use Joomla's .htaccess file or create one with the .htaccess Maker (likewise for NginX configuration or IIS web.config if you are using those servers) the instructions in that file are different. There are two different cases here.

1. Joomla's default .htaccess / web.config / documented NginX configuration tell the web server to pass all missing files, regardless of extension, to Joomla for further processing as a potential SEF URL. 

2. If you are using the .htaccess Maker / NginX Conf Maker / web.config Maker in Admin Tools with the frontend protection feature enabled then you are immediately blocking (403 Forbidden) any access to .php files other the index.php and any explicitly allowed files / folders, regardless of whether they exist or not. As a result Joomla is not loaded.

In both cases, if Joomla is asked to handle a non–existent file/folder it doesn't mean that the 404Shield will be triggered. First of all, Joomla needs to throw an exception with code 404. If there's something on your site creating a response for that URL without throwing an exception Admin Tools' 404Shield exception handler will not be called at all. Moreover, the exception must be unhandled. If it's handled by something else in Joomla, again, Admin Tools' 404Shield exception handler will not be called at all.

Moreover, Joomla itself or a SEF plugin may rewrite the URL in a way that is no longer caught. I'll give an example. Joomla 4 with its multi–language plugin enabled automatically rewrites /wp-admin.php to /en/wp-admin?format=php. This URL no longer matches the 404Shield URLs, therefore it's not blocked. When this kind of rewriting takes place we can't catch the URLs. At best we can change the way this feature words to make it trigger on all of these URLs, regardless of whether they would throw a 404 or not on your site. I think that we are going to do exactly that.