Support

Hello,

I'm sorry but that's not possible. The rescue URL should be an emergency tool, it's just a step before manually disabling the system plugin. Only users that are really trusted (ie Super Users) are allowed to use it, since you're asking to the watchdog to turn blind and let someone that was flagged as an attacker into your website and unblock himself.

If you have several users being blocked, it's way better to spend some time to understand why they are blocked and adjust the firewall rules.

The Rescue Mode does NOT unblock a user's IP address. It simply adds a special flag in their user session which tells Admin Tools to remain completely disabled for this user until their session expires or they manually end Rescue Mode. The idea is that you are given a free pass from Admin Tools' restrictions long enough to log into the backend of the site, unblock your IP address (or fix whatever else problem you had), then go back to using the site.

Since configuring Admin Tools is critical to the security of the site we only allow it to be accessed by Super Users by default. This is why Rescue Mode is limited to Super Users.

At best, we could change this feature so it allows anyone who has full administrative and configuration access to Admin Tools to use Rescue Mode. Do not, though, that this would NOT unblock the user's IP address automatically; it would only allow them to access Admin Tools' backend interface to investigate what went wrong and take informed, responsible decisions on how to proceed. (Not that we will; I will explain in the last paragraph of this reply, after explaining what else can be done, and why.)

Do you really want to allow your clients to access Admin Tools configuration? Are you ABSOLUTELY SURE this is a good idea? If you really thought it to be true, why have you not made them Super Users? Just so they don't mess with things they don't understand? Yep. The site's security is one of them.

You are actually approaching this problem from the wrong perspective. We don't take action before understanding the problem. This shortcut leads to hacked sites.

There are two things you have to investigate:

• Why are people being blocked all the time?
• How long are people being blocked for?

The first is a simple matter of looking at the Blocked Requests Log for the IPs of your users who are reporting they have been blocked. As you may have noticed, we recently addressed the problem of people getting blocked because of the Administrator Secret URL Parameter by adding an option (enabled by default) which adds a cookie to their browser upon one successful secret word authentication and which substitutes the secret URL parameter if they forget to use it — and show an optional warning. This is security neutral as the cookie (and the necessary data in the database to support it) is removed once you log out, therefore even in a shared computer —using one to access privileged resources is a terrible idea, by the way— you do not leave behind an attack surface. If your users get blocked for another reason do check that feature's configuration and see if you can add WAF Exceptions or educate users better.

The second is what in my opinion is the most critical aspect of your configuration. You seem to have set up Admin Tools to have a very itchy trigger finger, blocking IP addresses too fast and for a too long period of time (or permanently). That's counter-productive! The idea is to block an IP when there's a lot of potentially malicious activity in a very short period of time indicating an automated attack (bot) and block them long enough to make it impractical for the attacker to use the automated method for attacking your site. Blocking an IP address for 12 hours after 2 blocked requests in the last hour is a recipe for disaster: it makes false positives a roadblock to using the site and your users will learn to distrust security, leading to security shortcuts and a hacked site. Security needs to be practical to be effective. It's best to use something like 5 attacks in 15 seconds and a block time of 10' or thereabouts. This will make it very unlikely that real humans are blocked by false positives (unless they spam F5 after getting a blocked request notice because you can't fix stupid) and even if they are locked it will be for a short enough period of time that it doesn't make sense to try and work around it; they can just wait and do something else in the meantime.

Having this knowledge, do you understand why Rescue Mode —just like renaming main.php— are tertiary troubleshooting steps, pertaining only to the Super User? They are meant to help the person setting up the site unblock themselves or others while they are tailoring the protection to the site. They are NOT meant to be an alternative to tailoring your site's protection, nor should they ever be downgraded to that. If there is a reason for a user to self-bypass security they will do it, they will also fall victim to a phishing email or other attack, and your site will be hacked by an unwitting insider despite being protected by Admin Tools exactly because you gave the unwitting insider a viable method of disabling the protection you added to the site to prevent anyone (including unwitting insiders) from hacking it. The two security bypass features we have require either full read access to the email of the most trusted users on your site (Rescue Mode), or access to the server itself (renaming plugin files). In both cases, if an attacker has this capability they have other ways to bypass the security of the site and attack it successfully, making these features neutral from a defence point of view. If we extended Rescue Mode to less-privileged users then Rescue Mode becomes a privilege escalation vulnerability in disguise and has a distinct, easily provable (if not blatantly obvious) negative impact to the security of your site.