Server protection (partial screenshot)
This feature is based on the principle of ‘nothing runs on my site unless I explicitly allow it’ a.k.a. ‘deny-first’. This is a great policy which puts you in total control of your site, greatly reducing your attack surface area.
By blocking access to front-end and back-end elements (media files, Javascript, CSS and PHP files) it makes it extremely hard —but not outright impossible— for an attacker to hack your site, even if he manages to exploit a security vulnerability to upload malicious PHP code to your site. Additionally, it will deny direct access to resources not designed to be directly accessible from the web, such as translation INI files, which are usually used by attackers to find out which version of Joomla and its extensions you are running on your site to tailor an attack to your site.
On the downside, you have to explicitly enable access to some
extensions' PHP files which are designed to be called directly from
the web and not through Joomla!'s main file,
index.php.
Do note that enabling this feature will kill the functionality of some extensions which create arbitrarily named PHP files throughout your site. In our humble opinion the security risk of having your site unprotected greatly outweighs the benefits of such extensions. As a result, we strongly suggest disabling these extensions.
There are three sections of configuration settings controlling the functionality of the Server Protection feature. In short, you have controls for protecting the backend of your site (everything under the administrator directory), the frontend of the site (everything NOT under the administrator directory) and exceptions to these rules.
Starting with the backend section we see the following options:
- Back-end protection
-
Disables direct access to most back-end resources, except those in the exceptions lists. It is generally recommended to turn it on to enhance the protection of your site.
- Back-end directories where file type exceptions are allowed
-
This is a list of back-end directories (that is, subdirectories of your site's administrator directory) where you expect media files to be present. Place one directory on each line. Subdirectories of those directories are automatically added to the exceptions list without having to explicitly list them here. You can add more lines using the + buttons. You can remove a line using the - button. You can rearrange the order of the lines by clicking and dragging the button that looks like four arrows pointing North, South, East and West. You must not type the administrator/ prefix. As you can see, it's already added for you and can't be removed. You do not need to type a trailing forward slash. Please note that the path separator is the forward slash (/), even on Windows.
- Back-end file types allowed in selected directories
-
The extensions of back-end files which allowed to pass through the server protection filter, as long as the files with those extensions are in the list above. Do not type the leading dot for each file extension. Add file extensions by clicking at the end of the list, typing the extension and pressing ENTER. Delete file extensions by pressing the X next to them. Extensions are case–insensitive as of 7.0.6; this means that entering pdf will also match the extensions PDF and Pdf. The convention is to type in the extensions in lowercase. Regardless of the case–insensitivity of Admin Tools, it is a good idea to have the extensions of the files you upload in lowercase to avoid issues with third party extensions, Joomla itself and software running on case–sensitive–aware Operating Systems such as Linux.
Next up, we have the front-end section:
- Front-end protection
-
Disables direct access to most front-end resources, except those in the exceptions lists. It is generally recommended to turn it on to enhance the protection of your site.
Enabling this feature will prevent web access to all folders in your site's root, not just Joomla's folders (such as components). If you need to enable direct access to a folder you will need to place it in one of the front-end directory exception lists in the Fine-tuning or Exceptions section.
- Front-end directories where file type exceptions are allowed
-
This is a list of front-end directories (that is, directories in your site's root) where you expect media files to be present. Place one directory on each line. Subdirectories of those directories are automatically added to the exceptions list without having to explicitly list them here. You can add more lines using the + buttons. You can remove a line using the - button. You can rearrange the order of the lines by clicking and dragging the button that looks like four arrows pointing North, South, East and West. You must not type the administrator/ prefix. As you can see, it's already added for you and can't be removed. You do not need to type a trailing forward slash. Please note that the path separator is the forward slash (/), even on Windows.
Use this to allow access to specific types static media files inside specific directories. This is the least permissive exception to front-end blocking. Use this for folders which have a mix of public and private content, as long as the private content is NOT of an allowed file type (see below).
- Front-end file types allowed in selected directories
-
The extensions of front-end files which allowed to pass through the server protection filter, as long as the files with those extensions are in the list above. The same controls and rules as “Back-end file types allowed in selected directories” apply.
Exceptions
Finally, we have the Exceptions section. This allows specific files or all files in specific directories to pass through the Server Protection filter without further questions. This may be required for several reasons.
For starters, some extensions need to directly access PHP files,
without passing them through Joomla!'s main files. One such example is
Akeeba Backup Professional's restore.php used in
the integrated restoration feature, as it would be impossible to use
the index.php of a site which is in a state of flux while the
restoration is underway.
Other examples are CSS and Javascript minifiers, either included
in your template or installed in your site. Forum extensions are also
part of the same problem, as they tend to create a dedicated directory
for their attachments, avatar icons and so forth. Moreover, some
extensions place PHP files inside your site's tmp
and cache directories and expect them to be
directly accessible from the web. While this is a frowned upon
behaviour, contrary to the design goals of Joomla! itself, you still
need a way to work around them and we have to provide it. Finally, you
may have a third party script which doesn't install as a Joomla!
extension. The Server Protection feature would normally block access
to it and you still need a way around this limitation. So here we have
those workarounds:
- Allow direct access to these files
-
Place one file per line which should be exempt from filtering, therefore accessible directly from the web. The default settings include Akeeba Backup Professional and, of course, Admin Tools itself.
Please remember that you are entering the file path relative to your site's root, not a URL. If you want to allow the URL
http://www.example.com/mysite/components/com_example/foobar.php?test=1&whatever=2and your site is hosted athttp://www.example.com/mysiteyou need to entercomponents/com_example/foobar.phphere. Here's how we figured this out. Start by removing the question mark from the URL and everything that's to its right. Then, remove the site's root URL from the left part of the remaining URL. Finally, remove the leading forward slash — as you can see, it's already included for you and you can't remove it.You can add more lines using the + buttons. You can remove a line using the - button. You can rearrange the order of the lines by clicking and dragging the button that looks like four arrows pointing North, South, East and West. Please note that the path separator is the forward slash (/), even on Windows.
- Allow direct access, except .php files, to these directories
-
Direct access to all files (except for .php files) will be granted if they are inside any of the directories in this list AND their subdirectories. Normally you should only need to add your forum's attachments, avatars and image galleries directories, or other directories where you only intend to store media files. As with all similar options, add one directory per line, without a leading or trailing slash.
This is a middle ground in front-end blocking. You should use this only for folders which have only public content, i.e. if it's in that folder you are OK with it being shared with the rest of the world.
You can add more lines using the + buttons. You can remove a line using the - button. You can rearrange the order of the lines by clicking and dragging the button that looks like four arrows pointing North, South, East and West. You do not need to type a trailing forward slash. Please note that the path separator is the forward slash (/), even on Windows.
- Allow direct access, including .php files, to these directories
-
This option should be used sparingly as possible. Each and every directory placed in this list is no longer protected by Server Protection AT ALL and can be potentially used as an entry point to hacking your site. To be clear, if an attacker uploads a malicious file in one of these directories by exploiting a vulnerability which allows them to upload predictably named files in predictably named folders they will be able to access it over the web. This is how sites get hacked. As far as we know there are only three cases when its use is even marginally justifiable:
-
If you have installed another Joomla!, WordPress, or any other PHP application in a subdirectory of your site. For example, if you are trying to restore a copy of your site inside a directory named
testin your site's root you have to addtestto this list. This is the one and only usage scenario which doesn't compromise your site's security. -
Some templates and template frameworks may wrap their CSS and Javascript inside PHP files in order to deliver them compressed to your browser. While this is a valid technique, it's possible that the list of PHP files is too big to track down and include in the first list of the Exceptions section. In this case you may consider putting the template subdirectory containing those files in this list.
-
Some extensions do something silly: they place files inside your site's
tmporcachedirectories and expect them to be directly accessible from the web. This is plain wrong because these directories are designed to be protected system directories where direct access should not be allowed, most notably because they might contain sensitive information. However, if you have such extensions you need a way to allow direct access to those directories.If you decide that convenience is better than security we can't stop you. Add tmp and cache to this list and wish for the best. You are opening a security hole on your site and you do it at your own risk and potential peril.
It's best to use the Allow direct access to these files feature if possible, allowing access only to very specific .php files.
Remember that an attacker who has found an upload vulnerability on your site can upload a malicious script inside one of these folders and use it to hack you. These folders are totally unprotected. That's why we very strongly advise against using this feature unless it's absolutely necessary - keeping in mind that you are, at the same time, leaving a hole in your security defences.
You can add more lines using the + buttons. You can remove a line using the - button. You can rearrange the order of the lines by clicking and dragging the button that looks like four arrows pointing North, South, East and West. You do not need to type a leading or trailing forward slash. Please note that the path separator is the forward slash (/), even on Windows.
-
In order to figure out which custom exceptions you need to add on your site, take a look at the How to determine which exceptions are required section.
Please refer to the section on determining exceptions under the .htaccess Maker documentation. The exact same process applies. The only difference is that you enter the exceptions in the web.config Maker instead of the .htaccess Maker.