Data added from extensions.joomla.org and the FAQ config page for active scanner.

• created file inclusion section
• moved filter javascript below the get/ post box as it makes more logical sense
• added DoS to the denial of service title
• changed SQL Protections to SQL injection Protections (SQLi)
• renamed JS Protections --> HTML, Javascript and CSS Protections (XSS)
• rename Uploads --> File Uploads

General

From our point of view the default settings are a balanced configuration for most Joomla! Installations. However I would encourage you to go through the settings and make your own choices.

Enable Active Scanner

By enabling the Active Scanner all the protections will be enabled on your Joomla! website.

Enable Active Scanner in the /administrator section

By setting this to Yes the PHP, JS and SQL protections will be triggered in the backend as well. This should only be enabled if you don't trust people that have access to your /administrator section.

This is useful if you don't trust people that have access to your administration from making mistakes or uploading malicious code.

Log All blocked attempts

By setting this to Yes, every single attempt that's stopped by RSFirewall! will be logged. This is useful for debugging your website in case you have false alerts. We recommend setting this to No once you are done so that automated attacks don't fill your log.

Remove the Joomla! generator meta tag

Removing the generator meta tag from your website's template will protect you from spambots or attackers that target Joomla! Websites. This will also prevent some prevent 3^rd parties working out what CMS platform you are running for further attacks. This does not prevent fingerprinting attacks but is a good start to stop script kiddies.

Convert email addresses from plain text to images

This setting will convert all email addresses from plain text to images, in the same way as the Email Cloaking plugin will convert them to Javascript.

Joomlas inbuilt Email Cloaking Plugin is enabled by default that obfuscates email addresses by using Javascript but there might be times where it does not work or that a hacker can get around the prevention method. If an email is changed to an image hackers will not be able to read the emails addresses by using scripts so this is a very secure method of preventing scraping of your email addresses whilst still being able to display them to visitors.

Check core Joomla! Files integrity

Checks a few core Joomla! files for integrity, like the Joomla! login and index.php

This is a key feature of the active scanner and should always be used. Whenever your site is accessed RSFirewall will check the core Joomla! Files that have been accessed during the request to make sure their hashes match the internal hash database of RSFirewall which checks to see if they have been altered. This adds a proactive protection to your site allows you to stop a hack attempt at an early stage.

Monitor the following files for changes

If any of the following files will be changed, you will be alerted by email (if configured) and an entry will be posted in the System Log.

This section allows you to add your own files that you want to monitor for changes, such as your template files. If you want a suggestion for suitable files to monitor use the following as an example:

• /home/ myaccount /public_html/index.php
• /home/ myaccount /public_html/configuration.php
• /home/ myaccount /public_html/.htaccess
• /home/quanta/ myaccount /administrator/index.php
• /home/myaccount/public_html/templates/my_template/index.php

Open File Manager

This opens a modal box with a file browser that allows you to select what files you want to monitor. This is optional as you can manually adding the files to the list.

Grab IP from Proxy Headers

Some servers are behind a proxy or firewall and will not provide the correct IP. If this is your case, contact the proxy provider and ask them through what header are they sending the real IP. Otherwise just leave these all checked by default and RSFirewall! will attempt to grab the IP by looking through all of them.

System Protections

by default the following is set

PHP Protections - enable protections for (GET)
SQL Protections - enable protections for (GET)
JS Protections - enable protections for (POST)

why are, (POST),(POST),(GET) respectivly not turned on by default. Am I not fully protect without these or if i turn them on will it break my site?

If you are using a standard Joomla! installation, then use the standard active scanner settings provided by RSFirewall!.

The reason why $_POST is not enabled for the PHP or SQL sections is that standard Joomla! article, or module editing work with $_POST. Having this enabled would increase the chances of raising false positives, blocking the legitimate actions that are being performed. If you have tight control on the users that are allowed to perform such actions (or if these actions are performed only in the backend for example) you won't be needing to perform checks on the $_POST variable. Keep in mind that $_GET related attacks are more frequent then $_POST ones as well.

File Inclusion (LFI / RFI)

The File Inclusion settings should be left on unless you really need to turn them off for debugging or running some of your custom code. Well written extensions will not require LFI/RFI to work.

Local file inclusion (LFI)

This disallows directory traversal techniques (such as controller=../../../etc/passwd) that might allow an attacker to read sensitive files by exploiting poorly coded extensions.

Remote file inclusion (RFI)

This disallows access to URLs (such as controller=http://www.malicious-site.com/exploit.txt) that might allow an attacker to download and run malicious scripts by exploiting poorly coded extensions.

PHP (PHP)

Enable protections for

Inspect the selected system variables for PHP injections.

• Form data ($_POST) enables filtering for information submitted through forms (eg. article editing, user registration etc)
• URL data (_$GET) enables filtering for variables that are located in the URL (eg. http://www.yoursite.com/index.php?option=com_test&parameter1=value1)

PHP $_POST and $_GET Defaults

• Default = $_GET only
• PHP $_POST should be on by default

SQL injection (SQLi)

Enable protections for

Inspect the selected system variables for SQL injections.

• Form data ($_POST) enables filtering for information submitted through forms (eg. article editing, user registration etc)
• URL data ($_GET) enables filtering for variables that are located in the URL (eg. http://www.yoursite.com/index.php?option=com_test&parameter1=value1)

SQL $_POST and $_GET Defaults

• Default = $_GET only
• Should $_POST be on?

HTML, Javascript and CSS (XSS)

Enable protections for

Inspect the selected system variables for XSS/JS injections.

• Form data ($_POST) enables filtering for information submitted through forms (eg. article editing, user registration etc)
• URL data ($_GET) enables filtering for variables that are located in the URL (eg. http://www.yoursite.com/index.php?option=com_test&parameter1=value1)

JS $_POST and $_GET Defaults

• Default = $_GET only
• JS $_POST should be on by default
• still not sure why having SQL $_POST will cause issues
• they leave the deafult installation as it to reduce false positives but this also reducves security. notes should be made when to turn the other option on.

Filter Javascript

By setting this to Yes, the Javascript will be filtered instead of the connection being dropped.

File Uploads ($_FILES)

Every file upload that is being performed, ends up in the $_FILES variable. RSFirewall! checks this particular variable for attack vectors as well.

Filter Uploads

By settings this to Yes, the uploads will be deleted instead of the connection being dropped.

Filter uploads by deleting the file(s) instead of the connection being dropped. This alloes data still to be accepted but delete the potential malicious file which is better for customer interaction.

Check for multiple file extensions

Uploading files with multiple extensions might trick you or any other user that the file has a safe extension.

Verify if uploaded files have multiple extensions

Check for known malware

Verify uploaded files for known malware patterns, such as PHP shell scripts.

Banned Extensions

Files with the following extensions will be deleted as soon as they've been uploaded to the temporary directory on your server. If you enable the "Multiple extensions check", this will check all the files extensions, as opposed to the last one.

Don't upload files with the configured list of banned extensions

Access Control

Denial of Service (DoS)

Deny access to the following User Agents

Select the User Agents you want to prevent from accessing your site.

The following User Agents are usually automated requests to your website and should not be allowed.

• empty User Agents are usually DoS attack attempts or automated connections to your website
• perl scripts are used for automated connections to your website
• cURL is used for automated connections to your website
• Java performs automated connections as well

Protect against DoS (Denial of Service) attacks for User Agents (perl, cURL, Java or empty User Agents)

Protect forms from abusive IPs

Enabling this option will protect your forms from abusive IPs by checking if they exist in a PBL list.

Protect forms from abusive IPs - checks if IPs of form submitters exist in the Spamhaus XBL and SBL lists.

If the IP is in a PBL then the submission will be blocked.

Deny access to the following referrers

Referers are visitors coming from another website (domain). You can block multiple domains by specifying them each on a new line. You can also use wildcards, such as *.domain.com which will block any requests coming from all subdomains of domain.com (eg. www.domain.com, images.domain.com etc). Remember to add domain.com to the list as well, otherwise only subdomains will be blocked when using wildcards. You can also use wildcards anywhere in the domain name, eg. blocked-domain.*, blocked*domain.com

Deny access to the following referers - Referers are visitors coming from another website(domain). You can block multiple domains by specifying them each on a new line. You can also use wildcards, such as *.domain.com which will block any request coming from all subdomains of domain.com(e.g www.domain.com, images.domain.com etc.).

Automatic Blacklisting

Automatic blacklisting

Automatic blacklisting will automatically add to the blacklist repeat offenders based on the minimum number of attempts specified below.

Enable automatic blacklisting(even for the backend login): if repeated threats are detected with the same IP address, this will automatically be added to the Blacklist area

Automatic blacklisting for /administrator login

With this option enabled, failed backend logins will lead to an automatic ban. This option is independent from the CAPTCHA challenge configurable below.

Same as above but for the admin area

# of attempts

This is the minimum number of attempts before the attacker will be added to the blacklist and banned from your website.

CAPTCHA

Enable CAPTCHA

This will prompt a CAPTCHA security code in the /administrator section. CAPTCHA will appear after the number of failed login attempts you specify below.

# of failed attempts

Activate CAPTCHA after this number of failed login attempts a CAPTCHA will show up in the /administrator section login page.

Backend Login

Capture login attempts

By enabling this, everytime a user fails to login in the /administrator section will trigger an event in the System Logs.

Store Passwords

Set whether to store the passwords used in the failed login attempts or not.

Lockdown

Protect the following users from any changes

This will create a snapshot of the selected users. If any changes will happen to any of them, it will get reverted back immediately. If you want to update your snapshot, you will have to deselect all the users, press Apply and then select the users again and finally Save the configuration.

Protect Joomla! users from any changes

Disable access to the Joomla! Installer

By setting this to Yes, the Joomla! installer will no longer be accessible.

You would use this when you have multiple admins and do not want them to have access to the installer to prevent over enthusiastic admins from breaking your site.

e.g. Perhaps you are in situation where you have multiple backend users. Would you like them to be able to install anything on your Joomla! ? It basically ads an extra layer of protection for the installer access.

Disable the creation of new Administrators

By setting this to yes, new users that can login in the /administrator section will be deleted as soon as they are created. Keep in mind that new users (such as the ones added in the Registered group) will not be affected, unless you are trying to add Super Administrator rights to them (in this case, they will be deleted as well).

This feature is a second line of defense. Should a hacker get basic access to your site this feature prevents him from getting administrator rights to your Joomla! Installation. It can also be used to prevent other admins on your site giving administrator rights out to other Joomla! Users.