Our clients (with previously hacked Joomla websites that we fixed) often ask us: “What can one do to have ultimate security on a Joomla website?”
Our short and concise answer would be: “Have a development server and a production server. The development server is the one where you do the updates (and it’s usually behind the DMZ). These updates are then synced back to the read-only production server.”
Let us explain…
The main and only reason why a Joomla website is hacked is that Apache has write permissions on some (or, in many cases, all) files/directories and because MySQL has (usually) full permissions on the Joomla database. But, does your visitor really needs all these permissions?
Generally, most of the Joomla websites out there are content websites – which means that normal visitors do not have to alter the filesystem (e.g. upload new files, modify files, etc…), and typically they will only need to make a modification to just one table in the database (which is the #__session) table. But (and there’s always a but), this doesn’t apply to people working on the website. For example: super administrators logging in to the backend and installing extensions, administrators logging in to the backend and uploading images, creating new content, disabling some categories, etc…
So, because of backend activities, Joomla websites must grant these write/full permissions on the filesystem and the database to anyone, including visitors who don’t need them (for legitimate use). So, what can one do to address this issue?
As stated above, having 2 servers, one for development and one for production will solve the problem. The development server will host a copy of the website which will be used by the staff to make updates (including installing extensions and adding/modifying content), and the production server will host the actual website that will be used by the visitors. Typically, the development server should only be accessed from a VPN and should be behind the DMZ. Permissions on the development server can be as loose as they can be because everything happens behinds the DMZ. Now, every morning, the filesystem and the database changes from the previous day should be pushed from the development server to the production server. Here’s how:
- The filesystem should be rsync’d (all the files should be overwritten with the exception of the configuration.php file and the index.php file located under the administrator folder (we’ll explain later why). This should take care of syncing the filesystem.
-
Assuming the production’s database name is joomla_database, the development database should be copied to the production server, and it should be called joomla_database_v2.
-
The production database should be renamed to joomla_database_backup_[datetime], and the copied database (from development) should be renamed to joomla_database.
-
This’ll take care of a smooth database synchronization.
Note the filesystem sync and the database sync should be atomic, which means that if the sync fails on one of them, the whole sync process should be reverted. This can be quite complicated.
So, what kind of security should be on the production Joomla website?
Well, first of all, all the files and folders should be owned by root – and when we say all folders, we mean all folders, including the cache, the images, the logs, and the tmp folders. Additionally, the files’ permissions (across the board) should be 444, and the folders’ permissions (also across the board) should be 555. Note that the production website must use DSO and not suPHP. This’ll take care of the filesystem and ensures that no filesystem updates are possible by the website’s visitors.
As for the database, the database user accessing the production database must only be granted select permissions (and not all permissions) on all tables, with the exception of the #__session table, to which that user should also be granted delete, insert, and update permissions. Now, as you probably know, Joomla tracks hits on content items, which means that that database user must also have update permissions on the #__content table. However, we think that a better way to address this issue is to disable hit tracking on Joomla completely (if it’s not needed) – we’ll discuss how to do this in a future post.
One last thing that should be done is to remove the index.php file from the administrator folder. This ensures that no one can access the backend in the production website. (That’s why we excluded that file from being synced above).
As you can see, the security on the production Joomla website is ultimate. This Joomla website simply can’t be hacked. Of course, we are assuming that 1) Your production server is always up-to-date and 2) Your production server doesn’t have any other websites and doesn’t have any unnecessary software installed (in other words, your production server should have a very clean and up-to-date LAMP environment).
We helped very large companies implement the above strategy successfully. If your company runs a Joomla website and needs it to have ironclad security, then please contact us. We are security experts in Joomla, our work is fast and extremely professional, and our fees are very affordable!