This is the most coveted feature of our software, offering a
near-inclusive protection against the vast majority of known threats
when enabled. This feature's mission statement can be summed up with a
single phrase: nothing executes on your site unless you allowed it to.
By blocking access to front-end and back-end elements (media files,
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! 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,
Do note that enabling this feature will kill the functionality of some extensions which create arbitrarily named PHP files throughout your site, such as RokGZipper. In our humble opinion the security risk of having your site unprotected outweighs the benefits of such solutions by a dramatic factor. As a result, we strongly suggest disabling RokGZipper and other similar software using similarly questionable security practices.
There are three sections of configuration settings controlling the functionality of the Server Protection feature. The first one is the Protection Toggles which allows you to enable or disable the four main aspects of 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, unless you have enabled the administrator password protection feature. In the latter case this option is redundant and we recommend turning it off.
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.
The next section is called Fine-tuning and
contains the necessary options to tweak the protection's behaviour to
suit your site. Before describing what each option does, a small
explanation of how the protection works is in order. The protection
code in the generated
nginx.conf file blocks
direct web access to all files. Joomla!'s standard "entry point" or
index2.php, are automatically exempt from this
rule. However, your site also contains images, media, CSS and
and front-end protection we need a set of directories where such files
are allowed and the file extensions of those files. These are what
those options are all about. The default settings contain the most
common file types you'd expect to find on a site and the standard
Joomla! directories where they should be located. You only have to
tweak them if you want to add more file extensions or have such static
files in locations other than the default.
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.
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. Place one file extension per line, without the dot. For example, if you want to allow access to all PDF files you have to type in "pdf" (without the quotes) on a new line of this list. Do note that file extensions are case-sensitive. This means that PDF, Pdf, pdf and pDF are four different file extensions as far as your web server is concerned. As a rule of thumb, type in the extensions in lowercase and make sure that the extensions of the files you upload are also in lowercase.
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.
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. Place one file extension per line, without the dot. For example, if you want to allow access to all PDF files you have to type in "pdf" (without the quotes) on a new line of this list. Do note that file extensions are case-sensitive. This means that PDF, Pdf, pdf and pDF are four different file extensions as far as your web server is concerned. As a rule of thumb, type in the extensions in lowercase and make sure that the extensions of the files you upload are also in lowercase.
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 is 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
your template or installed on top of your site. Forum attachments 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
and expect them to be directly accessible from the web. While this is
a stupid 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 (e.g. Coppermine gallery,
phpBB forum, WordPress blog, or even another Joomla! site in a
subdirectory) 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
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.
Direct access to all files (except for .php files) will be granted if they are inside any of the directories in this list. 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. The example is Agora forum's user files directory. As with all similar options, add one directory per line, without a trailing slash.
This option should be used as sparingly as possible. Each and every directory placed in this list is no longer protected by Server Protection and can be potentially used as an entry point to hacking your site. As far as we know there are only three cases when its use is even marginally justifiable:
If you have installed another Joomla!, WordPress,
phpBB, Coppermine gallery 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
test in your site's root you have to
test to this list. This is the one
and only usage scenario which doesn't compromise your site's
Some templates and template frameworks may wrap their CSS and Javscript 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
cache directories 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 —most
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.
While it might seem very tempting to put several Joomla! system directories in here, like components and templates, don't. That's right. Do not do that. It is like using a tactical weapon to kill a mosquito in the same room as you. The mosquito will hardly ever survive, but you will go down with it. Or, in computing terms, you allow potential hackers to use any security vulnerabilities you haven't had the chance to fix yet in order to upload and execute malicious code. You killed the mosquito (the access problems you had with an extension) but you accidentally helped to take down your site. Ouch! Even if the chance of this happening is about one in ten thousand, are you willing to take that risk on your own site?
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.
Windows users beware! Do not use
Windows' path separator (the backslash - \) to separate
directories! We are talking about directories as they appear in
URLs, so you should always use the URL path separator (forward
slash - /) in those settings. In other words
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 NginX Conf Maker instead of the .htaccess Maker and you need to restart / reload NginX after adding the exceptions.