Support

Admin Tools

#31332 Implementing .htaccess security retrospectively

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
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by tampe125 on Thursday, 09 May 2019 03:26 CDT

Thursday, 09 May 2019 00:44 CDT

webcoast
Hi Nicholas & Dale,
I have some questions regarding implementing .htaccess maker retrospectively on sites. I maintain about 70 sites which were built from 2011 onwards.

With the release of Joomla 3.9.3 and the Post-Installation message warning about improvements to security by making a few changes (.htaccess and web.config) I was initially relieved to see that Admin Tools already takes care of this, since a Admin Tools release in 2015. (eg https://www.akeebabackup.com/support/admin-tools/Ticket/30917-htaccess-post-installation-message.html) BUT, only, it seems, if the Admin Tools .htaccess maker was used. Is this correct? I've looked everywhere in WAF settings and can't see any hardening rules for MIME types?

Most of my sites were built before .htaccess maker was released, and by 2015 then I knew Admin Tools so well (WAF configuration at least) that I didn't need to run the wizard (assuming that .htaccess maker is part of the wizard process?). So, now I need to either apply the recommended actions by the Joomla core release team, or run the Admin Tools .htaccess maker on each site.

Do you have any suggestions for the correct steps that I should take to implement .htaccess maker on existing sites which may have the following complications:
- Some sites are in a sub directory, so use a redirect from root to eg /cms
- Some sites have a bunch of redirects from old URLs to new equivalents

When Admin Tools .htaccess maker runs, will it find existing custom redirects and automatically include them, or do we need to enter them again manually? In my instance, some redirects were done via cpanel, which I think puts them at the end of the .htaccess file, if .htaccess maker includes them automatically, will it still find them at the end of the existing .htaccess file? (None of these sites use SEF URLs (index.php still present), which is why custom redirects are at the end of the .htaccess file works, otherwise I think they need to be included in the specific 'custom redirects' place of the joomla .htaccess file?)

Regarding shifting sites around:
If the .htaccess maker is in place, is there any special things we need to be careful of when copying a site to a development environment? Eg for revamping, and then overwriting the original site?

Thanks for your help.
Nicola

Thursday, 09 May 2019 03:26 CDT

tampe125
Hello,

let me address your questions one by one.
BUT, only, it seems, if the Admin Tools .htaccess maker was used. Is this correct? I've looked everywhere in WAF settings and can't see any hardening rules for MIME types?
Yes, you are right.
Those rules are used to tell your webserver to handle files properly, so it must happen in the .htaccess file, which is parsed by your server even before Joomla has a chance to run.

So, now I need to either apply the recommended actions by the Joomla core release team, or run the Admin Tools .htaccess maker on each site.

Do you have any suggestions for the correct steps that I should take to implement .htaccess maker on existing sites which may have the following complications:

- Some sites are in a sub directory, so use a redirect from root to eg /cms

- Some sites have a bunch of redirects from old URLs to new equivalents

Htaccess Maker default values already are the suggested ones. I'd strongly suggest you to review the documentation for a proper explanation of every option.
Regarding your two examples, you can act in this way.

Website in a subfolder
You're good to go. You simply have to run the Htaccess Maker within that installation. Remember that .htaccess files are hierarchical: starting from the top folder, your webserver will load and parse any .htaccess it will encounter.
For example:
Your website is inside public_html/cms.
Your webserver will look into plublic_html folder for an .htaccess file and load it. Then look into the cmsone and load it. As you can see, when you use the Htaccess Maker to create the file in the cms folder, it will be automatically included.

Handling existing redirects
Admin Tools will NOT parse the old .htaccess file, it will be renamed to .htaccess.admintools so you can have a backup copy, and then a new file is created. What you'll have to do is to copy your redirects inside the field Custom .htaccess rules at the top of the file. Those custom rules will be applied every time you run the Htaccess Maker, so you won't lose them.
I think cPanel is adding them at the bottom of the file to avoid any conflicts, it's not required to put them at the end.

If the .htaccess maker is in place, is there any special things we need to be careful of when copying a site to a development environment?
No, all the directives are using relative names (unless you wrote your Custom rules with absolute URLs). Usually if your website is working fine locally, it should work live, too.

Final tip: .htaccess files are pretty picky. They will work or your server will throw a 500 error, raising a general "Internal error" message, which is not very helpful. I'd suggest you to make one change at time, review if everything is working and then move on to the next one. I know it's pretty time consuming, but if you change 10 options at time and your site breaks, you don't know what caused that.
If things really go south and you don't know how to fix them, you can always grab Joomla htaccess.txt file, rename it to .htaccess and do a fresh start.

Hope this was helpful!

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
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!