Support

Documentation

This documentation page is for Joomla! 3.x

This documentation page does not apply to our software versions for Joomla! 4.0 and later versions. If you are not using Joomla 3 please consult the documentation index to find and read the correct version of the documentation.

Server protection
Prev The NginX configuration maker Next

Server protection

Server protection

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, 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! 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, 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:

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, unless you have enabled the administrator password protection feature. In the latter case this option is redundant and we recommend turning it off.

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.

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 "main" files, index.php and index2.php, are automatically exempt from this rule. However, your site also contains images, media, CSS and Javascript files inside certain directories. For each of the back-end 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.

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.

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. 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.

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.

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. 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.

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 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 prime examples are CSS and Javascript minifiers, either included in 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 tmp and cache directories 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 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.

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. 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.

Allow direct access, including .php files, to these directories

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 add test to 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 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 tmp or 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 notably certain Javascript and CSS minifiers— 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.

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.

[Warning]Warning

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 some/long/path is correct, some\long\path is WRONG.

How to determine which exceptions are required

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.

Prev Up Next
The NginX configuration maker Home The Kitchen Sink (Expert Settings)