Support

TL;DR: Your request is something we have considered, but it's actually dangerous in non-obvious ways, and does not make anything easier. We have already planned features for the next release of Admin Tools which better address the use cases which lead to the problem.

You are correct that the number of people who have been complaining about the number of blocked request emails has increased the past few months. This did not escape my notice. There's a reason I do support, not just development; I want to see exactly this kind of feedback. It tells me there's a problem and needs fixing. It just takes time for us to talk to the users, understand what they're doing and why they're doing it, deduce the actual root causes, and then coming up with a good solution. Implementing a bad solution which cures the symptom without taking into account the root cause is worse than nothing; it introduced new issues, and it becomes very hard to remove in a future version without causing even more friction with the users.

We have actually thought of a kill-switch like what you described but quickly decided against it. A kill-switch like this would disable all emails from Admin Tools including emails on modified core files, users escalating their or another user's privileges, backend logins, etc. This means that a large part of the proactive nature of Admin Tools would be neutered, without most people using this option realizing it. That's a non-obvious security nightmare. Moreover, implementing this feature would still require you to log into each site, go to the Configure WAF page, locate this toggle, and toggle it. It is no easier or harder than logging into each site, going to the Configure WAF page, locate the email this address on blocked request field, and removing its contents, something which has been possible for the past 15 years.

So, let's start understanding the problem.

Surely, people didn't just start enabling this feature now. So, why did it start happening now and not, say, 15 years ago when the email on blocked requests was first introduced? Based on my sources –including those in the enterprise WAF space– the number of attacks has increased exponentially over the past few years, and has started spilling over to less trafficked sites. In the past, most attackers would either do it for the street cred, or to send mildly lucrative spam. In the last few years attackers are trying to compromise sites for (geo)political reasons, and to launch crypto scams which are far more lucrative than spam ever was.

Knowing that what we see is just an amplified signal of a deeper issue, we need to backtrack a bit, identify the actual deeper issue, its root causes, and then come up with solutions.

The deep-seated problem we're trying to solve is that people leave the email on blocked request feature enabled on production sites even though it's only meant as a troubleshooting aid. Why do they do that? I have identified three broad categories.

One category is those who get frequently locked out of their own site and need to use the Rescue URL. That's primarily a documentation and discovery issue. The Rescue URL will work even when you have not been sent an email. The condition for it working is that the IP you are trying to access the site from is blocked. We will improve the documentation and discoverability of the feature.

The second category is those who simply forgot about it, or where not aware of it being a troubleshooting aid. The best we can do to address it is to show a permanent, annoying message on the backend of your sites when the email on blocked request feature is enabled, with a quick link to disable this particular feature and nothing else. The only kill-switch we will provide –hidden away in the plugin's options– is to disable this annoying reminder, in case you truly want to leave this feature enabled without being reminded about it. This is coming in the next version of Admin Tools; it's on my to-do list. It will also be faster than looking for an option in the Configure WAF page.

The third category is the people who deliberately leave this feature enabled, despite knowing it's a troubleshooting aid, to monitor the volume of blocked requests so as to detect when they are under attack and possibly take some action – which, ironically, makes the effect of massive attacks far worse. The next version of Admin Tools will have a new feature, one which can email you when the number of blocked requests in a predefined unit of time exceeds a certain threshold, and will not repeat for a time period you define. How's that different to leaving the blocked request emails enabled? When you are under attack, you will not receive thousands of emails for blocked requests in the span of a few minutes. You will receive one, and only one, email which tells you that you're effectively under attack. An email you can act upon. This, we have already implemented in code and I finished testing it before the holidays.

If you have a different use case, I want to hear about it. It's always possible I missed something.

Hello Pieter,

Thank you for your kind words!

I need you to remember something important. The level of effort it takes to improve the level of security of your site increases exponentially. Also, we are only talking about what is in scope for the web server and web application. We are not talking about physical security, operational security etc.

Joomla! out of the box offers protection level 1. It's a good baseline, but not quite all you need in most practical cases i.e. when you do not plan to have an obscure, read-only site you spend too much time maintaining. On the plus side, it takes no effort on your part.

Taking it to level 2 is fairly simple, and can be done with some of the free, and simplistic security plugins out there which address some basic issues in third party extensions and Joomla! itself (some design choices in Joomla have to take into account that a lot of its users have zero technical knowledge). That's enough for fairly simple sites which don't use any other third party extensions – which is barely at the level of a high school project, if we're being honest. The total effort required is installing a free extension without even bothering to configure anything.

We wrote Admin Tools so you can take your sites to the next protection levels which are needed for most practical implementations of Joomla!.

The default settings in Admin Tools are set up to offer you a protection level of 3 or 4 out of 5 – depending on whether you enable the Quick Setup Wizard option to apply the security tightening .htaccess which applies the default .htaccess Maker serrings. The effort you expend is pretty small. You need to know there's such a thing as a paid security extension, install it, and accept the defaults. A very small investment in time has gotten you to a very good security state which is good enough for the vast majority of sites you'll deal with, as it does stop the majority of attacks you are likely to witness on your sites.

Going to level 5, is about the minute details. You need to go through the optional settings in Admin Tools to see if they make sense on your site. If they do, enable them, and they might stop or at least warn you about an exceedingly rare attack you hadn't even thought of. The same goes for optional .htaccess Maker options which can and will get in your way if you don't know what you're doing, but might block a very rare attack which would require the stars to align just right to succeed. You'd also need to set up the PHP File Change Scanner and allocate the necessary time to inspect the results, in the exceedingly unlikely case nothing else stops an attack – at least you will be warned. You'd also need to look beyond just Admin Tools, e.g. set up a CDN such as CloudFlare in front of your site to absorb the impact of a (Distributed) Denial of Service attack; that may cost money, depending on your site. If you want to go down that route, sure, we have features which will help you to implement that. Should you do that? Not unless your site has a big target painted on its back. The good news is that it's very unlikely you are managing a site like that, let alone more than one of these.

I hope that helps.