Joomla is popular, so it's a target
Joomla is great open source software. It has a huge, active community. It is well designed, well built and well supported. It is no wonder it is estimated that 3% of all web sites are based on Joomla (W3Techs). So it probably shouldn't come as any surprise that the bottom-feeders of the Web world are increasingly targeting Joomla sites for their attacks. If you have ever had a Joomla site infected with malware (which is probably why you are here) you know what a pain it is to clean up. Hopefully you have a clean backup or an easy way to migrate your content to a fresh install. There are some good resources out there that discuss cleanup options. If you are not at least using Akeeba Backup or something like it, you should look into that now.
When hackers try to use their various exploits to change your Joomla code files, they can't. You still need to take other precautions, like preventing hackers from gaining access to the Joomla back-end. We use Brute Force Stop within Joomla to stop brute force attacks against login. We use fail2ban on our Linux servers. But none of these stop hackers from exploiting any security vulnerabilities that may be in Joomla itself.
Easy-to-update makes Joomla vulnerable
One of the great things about Joomla is its ability to update its own code. You can run updaters to keep the software current and you can install all kinds of extensions to add functionality. But this is also what makes Joomla vulnerable. In order to update its own code, the user account that the web server runs under must have write access to the code files themselves. So if hackers can get that user account to run some malicious code they can change the web site's own code - usually to insert more and more malicious code, give them greater access, cause the site to spread malware code and so on.
So what do you do about this? You can lock down the file permissions so that the web server can run the code but not update itself. But this is not very Joomla-like. Now you can't run updates and install extensions. Plus there are a few directories that need more open access for content development and site operation, like the images directory and the cache and temp directories.
A lot of Joomla security blogs suggest that there is just no way around it. The web server user just cannot have write access to the Joomla code files. You open up only the directories required for content development and normal site functionality and lock down the rest. Sadly, they are right.
Yes, you could lock the file system down to the web server user and make your installs via something like FTP with a different user account. It is not a bad idea, but some extensions are pretty complex. Installing them by hand is tedious and error-prone. The installers provided by extension publishers might have more going on in them besides file copying - custom code execution, database operations, etc. In fact, manual install instructions are getting harder and harder to find for extensions. I avoid manual extension install whenever I can. There are just too many variables.
So, what is the answer? You need to be able to run updaters and installers. The web server account is required for this and it must have write access to the Joomla files, but thanks to the jerk hackers we can't do that. There are a few Joomla extensions out there that provide controls within Joomla's admin for this type of thing, but if Joomla's admin can adjust file permissions then you are back to the fox having the keys to the henhouse. In "locked" mode, Joomla simply cannot have write access to its own files.
Well, if your site(s) are like most Joomla sites, you might update content every day but you only run updates or install extensions every now and then - maybe even rarely. So what if you just open up security for the short time it takes to make your code updates and then shut it back down again?
We found a very nice article on this idea from IT Octopus. They take a slightly different approach based on changing account groups before/after installs. We didn't want to make the suggested group change they use, so our approach is to actually change file owners and permissions only when updating the Joomla or installing extensions. This could be done manually, of course, but there are a number of different operations, and not everyone is a hardcore Unix admin. So why not use a shell script? Let the computer do all the work.
Let's make locking down Joomla simple
Instead of making file permission changes manually, we prepared a shell script to make the changes. When you want to update Joomla or install extensions/modules, you use the script to unlock the site. Afterwards, you use the script to lock down the site.
You have to run this script from within its directory as the root user (or sudo). So you need command line access to the files in your Joomla installation and you need to be able to run scripts as root (or sudo). We realize this isn't perfectly user friendly, but instructions are provided. You run "unlock" when you are ready to run your updates and installs from the Joomla administrative back-end. When you are done, you run the "lock" and it locks down the site again to prevent malware attacks. It is a simple, one-line command and just takes a minute or two to run.
SSH into your server and once installed it works like this:
./mm_jlock.sh -a unlock
Follow the instructions, then when you are done:
./mm_jlock.sh -a lock
Installation is simple.
- SSH into your web site
> ssh -l root [web-server-ip-address]
- cd to your site root (the root of your web site)
> cd /var/www/www.yoursite.com
- Make the directory where the script will live
> mkdir mm_jlock
- Download mm_jlock.sh and place it in this directory
The current version is 1.0
- cd to this directory
> cd /var/www/www.yoursite.com/mm_jlock
- Run the script, and follow the instructions. It will check permissions, give you installation warnings, and display help.
- If you need to change the environment variables, edit the script in your favorite text editor.
v1.0: 2019-04-26 Download
mm_jlock is (C)opyright and released under the gpl-3.0 license for non-commercial distribution. See the enclosed license.