Support

This happens because you have removed one of the defaults in the .htaccess Maker configuration.

Go to administrator, Components, Admin Tools for Joomla!, Control Panel, .htaccess Maker.

Find the Allow direct access to these files setting and add a new line reading administrator/components/com_joomlaupdate/extract.php

Click on Save and Create .htaccess

Don't remove this line from your .htaccess Maker configuration again. Direct access to the extract.php file is safe. Not only it's part of Joomla! itself, it's a file I contributed myself to the Joomla! project, having taken into account all the security failure modes it could suffer. It's designed to only accept very specific requests protected by a temporary password for a limited period of time between finishing the download of an update package, and having finished extracting it. When it finishes extracting the update package, it deactivates itself automatically. That's why it's allowed by default in the .htaccess Maker configuration.

Based on this information and the contents of the file, the problem is unrelated to Admin Tools per se. It is, however, related to the "Custom rules to add at the top of the file" you put yourself in the .htaccess Maker. It's all wrong. Let's take it step by step:

RewriteEngine On

Redundant. Remove it.

RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^(www\.)?enclave-coa\.org$ [NC]
RewriteRule ^(.*)$ https://enclave-coa.org/$1 [L,R=301]

This interferes with HSTS, the www to non-www redirection etc. This could indeed be causing your problem. Remove it.

Header always set Content-Security-Policy "upgrade-insecure-requests;"

This is wrong and could be contributing to your problem. Remove it. Instead, use the HSTS feature in the .htaccess Maker. That's the correct way to do it. HSTS tells the browser "hey, don't ever try to contact this domain over plain old HTTP even if the user explicitly asks you to do that". Therefore, HSTS can work around downgrade attacks in browsers. The header you added does not do that; HTTP access will take place every time, which might be enough to steal some cookies.

Speaking of cookies, Joomla's cookies will not be set up to be HTTPS-only unless you go into your Global Configuration and set Force HTTPS to Entire Site. Only then will Joomla's cookies be impossible to steal with an HTTP downgrade attack.

So, remove this ineffective and problematic line. Set Force HTTPS to Entire Site in Joomla's Global Configuration. Enable HSTS in Admin Tools' .htaccess Maker (and generate a new .htaccess). You will be fixing two problems, one you knew you had, and a more important one you did not know you have.

RewriteRule ^sucuri-(.*)\.php$ - [L]
RewriteRule ^\.sucuri-(.*)\.php$ - [L]
RewriteRule ^cloner.php$ - [L]

This is dangerous! OMG, is this what Sucuri tells you to add to your .htaccess?! 😱 It tells your server that if there's a .php file in your site's root whose name starts with sucuri- it should be immediately and fully trusted, skipping over all the protection put in place by Admin Tools. I strongly recommend against it. Ask them for a list of filenames you should explicitly allow and add them to "Allow direct access to these files" instead.

Your first mistake was using GoDaddy for hosting. There are oh-so-many reasons people – especially web software developers – call them "NoDaddy". I guess you fell victim to their relentless advertising like so many others.

GoDaddy's attitude to security is that it stands in the way of "maximizing their bottom line", to put it as politely as I can. The reason they slap Sucuri on top of every site is that they obviously found it cheaper to strike a mass provisioning deal with Sucuri than hire real engineers who can secure their servers properly.

If it sounds pretty harsh, it's not. I am not a systems administrator by either education or trade. I am a Mechanical Engineer by education, and a web software developer by trade. But even I can see that the blatantly obvious way for them to resolve this security concern is putting the file access exceptions in their hosting configuration and limit them to the list of IP addresses Sucuri conveniently publishes as part of their proxying troubleshooting guide.

Unfortunately, you're not the only one who got reeled into GoDaddy. Their best product is... their advertisements. Every Joomla! developer and site integrator I have spoken to refers to them as NoDaddy.

As for my hosting recommendation and taking into account you're in the USA, that would be either Rochen or CloudAccess.net. I am using both of them for my own sites. For Europe I recommend either Rochen or papaki.gr.

Full disclosure: Rochen provides a managed server package used to host our business site free of charge. I have a regular, paid (at full retail price!) Reseller account with them which I use for all my personal sites, grandfathered-in client sites, and various projects. My opinion and recommendation on Rochen is based entirely on my experience with the paid account, which is exactly what anyone else would get purchasing the Reseller package.

All of that being said, would you remove the first two "sucuri-" rules? I think I'd have to leave in the "cloner-" rule in order for my backup to work.

You do not need the cloner- rule for Akeeba Backup to work. GoDaddy, as per their usual M.O., used misleading language. They are talking about the backup they offer through their control panel. If you don't need that, you can remove the rule.

About the sucuri- rules, it depends on whether you use their security scanner through GoDaddy. If you don't use it and don't care about it, you can remove the rule. Of you are using it, you have no alternative than to use them as things stand at the moment.