You are here:Home»KB»Web Design»CMS»Joomla»Extensions»RSFirewall - Questions and Answers
Monday, 23 January 2017 09:08

RSFirewall - Questions and Answers

Written by

Multiple question on my new setup

https://www.rsjoomla.com/my-support-tickets/view-ticket/138619-multiple-question-on-my-new-setup.html

1) do you have a database of attacks, nice to display this on your site

  • Not sure what you mean here. Are you referring to a sort of statistics on how many hack attempts prevented RSFirewall! ?
  • a database of attacks that you can show clients what is attacking joomla sites, this can be tied in with an attack map
  • We do have something similar on our TO DO list, but i can't provide an estimate for this. You are more then welcome to subscribe to our blog and get the latest news (and promotions of course): https://www.rsjoomla.com/blog.html

2) does you software send back information to help fight attaccks, perhaps a live attack map would be a cool thing

  • No, there is no "home callback" functionality, nor do we record the attacks that were performed on customer installations.
  • an optional feature to send information back to rsjoomla for a live attack map. this would help in preventing future attacks quicker because you could see attacks that have not been discovered yet.
  • Thank you for your suggestion.

3) rsjoomla what is a PBL - "protect forms from abuse ips", where is this list?

  • The list itself is provided by a third party service: https://www.spamhaus.org/pbl/
  • Because there is no information in the documentation can you explain further how this is used? you have given the list but not what it does.
  • If the form is submitted by a visitor that is marked in the PBL, he will be blocked by RSFirewall!.


4) when you click ignore file because it is missing, is this file ignore for everything going forward?

  • Yes, this is correct. The next time the System Check will run, the file won't be reported anymore.
  • When you click ignore, the message says the file will not be flagged unless it is changed again. Is it different for joomla system files and other files
  • Hope this will help you get a better understanding on how this works. Scenario:
    • standard, Joomla! file altered: test.php
    • detected by RSFirewall! System Check
    • you manually checked this and file is ok
    • clicked ignore
    • run the system check again -> the file won't be reported anymore
    • test.php was changed again
    • running the system check again, will detect the file as begin altered.

5) what constitutes an attemp for an auto blacklist event?

  • Any hack attempt is counted for. If the offender in question reaches a certain threshold (configurable within the Configuration area), it will be blacklisted.

6) is the default config the best configuration for rsjoomla or just best fit for initial installs

  • From our point of view this is a balanced configuration for most Joomla! installations.

7) active scanner/Uploads/Filter uploads - do all file uploads get filters ie. through jce editor? Is there anyway of setting up exceptions or a finer grain control of this. if this is the case you should consider this a feature request

8) why would i block access to the joomla installer, is this availble without being logged in.

  • Of course not, but 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.


9) block ip addressess - what is anonymous proxys, other countries, satelite provider,continent,other, how do you categories these. how would i find out what they relate to?

  • These are general concepts of course, not something RSFirewall! specific. Perhaps a wiki read would help on the proxy issue:

    https://en.wikipedia.org/wiki/Proxy_server#I2P_anonymous_proxy

    There are various ways to categorize IP addresses. Localization is one of them - that's why the Country or continent correlation.

    Other Continents (if checked): If, for the detected IP address, there is no continent correlation, then this will be blocked. The same applies for the Country section.

    The categorization is provided by some public IP databases. More on this here:

    https://www.rsjoomla.com/support/documentation/rsfirewall-user-guide/frequently-asked-questions/how-do-i-use-country-blocking-and-where-do-i-get-geoipdat-.html

    PS: Thank you for your suggestions. We are constantly adding new articles and improving the documentation for all of our products. If there are questions that are not answered by the product documentation, our customer support service will gladly help.

    Regards!
  • you have mentioned what the 'other' tick box does, but not satelite, anonymous proxy, you must of got these groups from somewhere. If you can point me to the page at GeoIP website where they discuss the different groups. ps this should be added to your documentation.
  • The same principle applies, just that "satelite" is used instead of a particular country or continent. I won't get into the details on what a proxy is and how it works, as this is yet again a generic concept, not something RSFirewall! specific. Yet again, the same principle is applied. If the site visitor connects to your website through an anonymous proxy, he will be blocked (given that you have the option enabled). You can get more information on GeoIP on the author website: https://www.maxmind.com
  • lol, i know what a proxy is, i just really mean where did yoou get the grouping information so you knew what ip belongs in which group. ie this page at maxmind tell yous what the groups are. if there is not page like this do not worry.
  • Not worried at all, i simply pointed out the author of the database. Here you should be able to find additional information on how the GeoIP works.
    the database must have the groups inside the database?

ps, all of these question and answers should be added to your documentation as they are the first thigns that popped into my head whilst learnign your software.

Questions – protection configuration ($_GET and $_POST$ PHP/SQL/JS ) protection

https://www.rsjoomla.com/my-support-tickets/view-ticket/138571-protections-configuration.html

Starter Question

Me

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?

advide please (PS> RSFirewall documentation should be a little bigger for sucha complicated product, which is great)

Alexandru Plapana

Hello,

Note that there is no predefined set of settings that can be applied for each and every website. Each website has its own requirements and this propagates to security related settings as well. For example you can't restrict the usage of a particular PHP function (that are commonly used by hack related scripts) if one of your installed extensions is using it. On the other hand why wouldn't you restrict if none of your extensions is using it ?

There is no such thing as full protection of an website - security applications won't ever be able to provide 100% protection, but it can help you reduce the chances of your site being hacked. Tighter security settings, can increase the chances of false positives and can affect the overall site functionality and even performance.

You are more then welcome to enable the protections, but you will have to test your site and make sure that it doesn't affect the overall functionality.

Regards!

Me

Hi,

unfortunately you have turned into management as this is a pointless answer but probably sounds great to you.

If you offer settings in a product you have to be able to tell me why they are there, in what circumstances you would use them, this would be an excellent feature for your documentation.

FYI: i know the difference between POST and GET but i am unsure on how to apply these settings of your firewall in a real life situation.

Please can you look into this and perhaps get me some real examples of why i would use them, leave as is etc...

You must understand that 99% of your cusrtomers will never touch these settings and this is why you dont get much feedback about them. some people might not even know the difference between post and get.

An example would be:

"If you have a standard joomla site wiht no 3rd part plugins or extensions turn GET and POST on for PHP/javascript/SQL to ge better protection"

Thanks

Alexandru Plapana

Hello,

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

If you actually hover over the options themselves you will notice additional explanations on this. 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.

Regards!

Me

the explanation you have just given me is great. This should be in the manual somewhere.

I did read the tooltips before i posted, but the tool tips tell you what the option does but not why you would choose it and the consequences.

thanks

Alexandru Plapana

Hello,

I am glad that i could help.
Let me know if you require further assistance.
Regards!

Followup questions

before i start i do appreciate all of the time you spend answering my questions but i have a few follow up question just to plug the hole in your documentation. You can have a copy of my notes when i am done:

I need the answers to these because i am going to be running my own custom modules, code and whatever so i want to be as safe as possible without killing my site

After reading the responses from RSFirewall and the active scanner configuration faq page and the tooltips in the software I need to answer the following

PHP

1) controller= is a joomla method to include files (from tooltip)?

  • This is actually part of the MVC architecture (or design pattern if you will). Joomla! relies heavily on the Model View Controller design, but in this instance, it just a parameter example.
  • Local File inclusions - This question stems from your example in the tool tip
    (This disallows directory traversal techniques (such as controller=../../../etc/passwd) that might allow an attacker to read sensitive files by exploiting poorly coded extensions.)
  1. So is it the ../../../ within a POST or GET that causes the block? (irrelevant of the rest of the line)
  2. why is there a button to turn it off, is this because some extensions are badly written and need this off?
  1. You should not consider "\..\" as being the only trigger for this. There are multiple patterns that are being used.
  2. I don't think that there are two Joomla! websites exactly the same. There can be situations here legitimate requests are being made, and RSFirewall! blocks them - naturally this will affect your overall website functionality. A quick solution would be required, thus turning it off. Note that the Exceptions feature was introduced at a later time.

2) The reason for being able to turn these on/off is because some people might have badly written extensions that use this command? And they should not use this?

  • I presume that you are referring to local and remote file inclusions. A wiki article should help you in understanding the overall concept:

    https://en.wikipedia.org/wiki/File_inclusion_vulnerability
  • Remote inclusion - I understand why a remote file inclusion is dangerous but why is there a button to turn it off? Is this to allow bad extensions to run? what issues does turning this option of solve?
  • I think you got this backwords - because of badly coded extensions, you might need the extra security provided by RSFirewall!.  Once again, false positives can occur, this is why we introduced a configurable option for it.

3) Can you point me to the documentation on joomla for this (i dont need technical/in-depth but just what it is)

4) POSTs  are used to submit forms all the way through joomla so what harm can turning this PHP scan on cause, ie false positives.

  • It can essentially block legitimate submissions. For example, one of your forms incorporates a WYSIWYG editor. The editor can automatically add certain HTML elements (iframes, style, script tags) that can trigger an RSFirewall! alert. The elements in question are often used in hack attempts.
  • WYSIWYG by their nature block these things getting posted HTML elements (iframes, style, script tags) . So if we ignore WYSIWYG for now and only consider $_POST,
  1. with this option on, all joomla $_POSTS are scanned for 'any' PHP code. ie base64(),  eval()
  2. certain tags are removed or altered? can you confirm what they are (i think this is for the javascript section)
  3. When is the POST is blocked, are all posts blocked when any PHP code is found
  4. (iframes, style, script tags)  are not strictly PHP, do you lump all HTML and PHP together or were you incorrectly referencing JS section
  • You are assuming that everyone uses latest updates, but it is far from being the truth. Further to this, not every Joomla! installation has such filters in place (configurable). Yes, i mixed these up a little bit here. The PHP protection is designed to prevent a specific type of attack where hackers load their scripts via a local or remote resource. The GET method is the most common for such attacks. Having this enabled does not imply that it can break your site, but it can stop legitimate requests. You won't have problems with this using standard Joomla! functionality ( included extensions).


5) Can it affect the normal operation of a website. can you give examples of how this can break a site

  • I think point 4, covers this as well.
  • can you give 1 scenario where having $_POST scanned for PHP can break the site, i am trying to understand why by default you have this turned off? but also point 4 references Javascript scanner not PHP, you would never legitimatly post PHP code in a wysiwyg or form except a code module and this would only really be done in the admin.
  • Yet again, it won't break anything, but it can stop legitimate requests. For example you are using a third party plugin that allows you to add PHP code just about anywhere. If you have this option turned, it will most likely block the POST if script signatures are detected.
  • PHP $_POST - better on and in some small circumstances can cause false positives such as code modules. On a standard Joomla site this is better to have on.
  • Yes, this is correct.


 

SQL

6) POSTs are used to submit forms all the way through joomla so what harm can turning this SQL scan on cause, ie false positives. Can it affect the normal operation of a website. can you give examples of how this can break a site?

  • Yet again the same example as point 4. If the submitted value is used in a database query and not properly filtered (or escaped), it can stop normal SQL execution. Once this happens the hacker can execute his own queries.
  • you say that SLQ $_POST scanning is not on by default because "If the submitted value is used in a database query and not properly filtered (or escaped), it can stop normal SQL execution. Once this happens the hacker can execute his own queries. " is this not what you scanner is supposed to stop and you are saying turning this on can break your site and let a hacker in.
  • Having this enabled for POST would generate too much false positives.
  • if this is to dangerous to have on, should it not be removed as an option, i thought all legitimate Mysql command would never be submitted by a post but stay within joomla files?
  • If SQL $_POST causes so much issues why is it left as a feature. Because you segment between PHP/JS/SQL i just need to figure what attacks this feature would prevents vs the issues it causes.
  • We shouldn't there be an extra protection available even though it can cause a lot of false positives? Perhaps there are some use case scenarios that can make use of this.


 

JS

7) Filter Javascript - By setting this to Yes, the Javascript will be filtered instead of the connection being dropped. In what circumstances would this be employed. Can you give an example

  • We will consider yet again the example pointed at item 4. If a script signature is detected, RSFirewall! will eliminate (or scramble) the actual script from the POST without blocking the request.
  • just to confirm the 'Filter Javascript' option will allow RSFirewall to remove/scramble
  1. ALL javascripts and <iframe>, <script>
  2. from $_POST and $_GET (this depends on 'Enable Protections for')
  3. without dropping the connection
  4. if this option is not on, the whole post is dropped
  5. what determines whether the script is removed or escaped? (this is useful so i know what will stay)
  1. should javascript scanner section be renamed to 'javascript and html' because <iframe> is html and not javascript, and this scanner looks for more than javascripts
  • Yes, this is correct. From a hacking perspective this won't really make any difference - if the connection is being dropped, then the POST information won't be saved at all. If the filtering option is enabled the script will be scrambled (not removed) and can't be executed. Turnig "ifram" into "i-frame" isn't "escaping": http://php.net/manual/en/function.mysql-escape-string.php
  • can you confirm the only translations are <iframe> --> <i-frame>, <s-cript> --> <s-cript> and <style> --> <s-tyle>
  • These are just some common examples. If you wish to get a better understanding on how this works have a look here:

    administrator/components/com_rsfirewall/helpers/xss.php


8) why is JS GET not turned on by default, does JS not use GET a lot of the time (ajax?)

  • One of the reasons would be various tracking scripts that often use URL parameters of course. This would trigger (in our opinion) more false positives.
  • thansk for the example, these tracking script would be incoming links from other websites and would these links be from 3rd party sources ie adwords or would this be something a client would need to set up 3rd party software on their website. I am trying to assertain on a basic joomla site if there would be times where this feature can cuase false positives to the detriment of the site with any extra software.

    i.e a basic 4 page website with no 3rd party extensions would benefit from JS $_GET being turned on
    ie. why have the option to turn this on if it does more harm than good?
  • If you read more on XSS attacks you will be able to understand how these manifest. For example you can inject in an article content a Javascript popup with "buy viagra".

    All security related features cause false positives.
  • filling in the blanks here - turning on the $_GET for JS is an absolute must as it protects from XSS, but it can interfere with incoming tracking links or perhaps badly written internal 3rd party plugins but other than that there is no issue with it.
  • Yes, this is correct.

9) can you give examples of how this can break a site

  • XSS attacks: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
  • XSS attacks - these are attacks and are not false positives or how JS $_GET would potential break a site? can you supply a scenario where turnsing $_GET would break my site or stop it working?
  • Given that most (i won't say all) of the standard Joomla! functionality relies on POST not GET, then no, i can't provide such an example.

10) Does this feature control the warping of <script> and <iframe> to <s-cript> and <i-frame>


 

General

11) In your tooltips you say that URL data (GET) enables filtering for variables that are located in the URL, but does your software not scan more that the URL because I have seen in the blocked attempts in my RSFirewall logs code in IP addresses and the referrer.

  • Not sure i understand your question, but when an alert is triggered, some server related variables are being stored (IP and referrer).
  • a request includes more that the actual URL, such as the IP address. In my RSFirewall i noticed hackers adding code in to the 'referer' or the 'ip' address showing they have created custom requests. Does RSFirewall scan these extra fields/data rather that just the URL or post variables?

    i.e. that is not a proper IP i will now block you.
  • The referrer is not actually scanned, but RSFirewall! incorporates an option to block a request if it has a particular referrer. As for the IP address, you can't really insert scripts in a server side variable. I think you might have some idea about a particular bug available in a different security extension that was grabbing a proxy address, instead of the actual IP address. The short version of the answer would be "no".

    PS: You can't communicate over networks without an IP address.
  • please see the attached image. it shows code in the IP block. I have also had this code in the referrer and i have seen it in a dodgy user agent as well. There are different types of dodgy code i have seen here but i am just using this one as an example to help answer the question. This is what i mean by no ip. Does RSFirewall check the environmental variables and then block them if dodgy.
  • The reported IP address is wrong - this is a bug caused by Admin Tools that incorrectly replaces the IP address with that string. Please update Admin Tools (as I understand this has been fixed in their latest versions) or contact the extension's developers for a fix.


Uploads

  • This scanner only works on files uploaded through the 2 entry points index.php and /administrator/index.php i.e. Joomla not the server

Questions not asked

  • Add the PBLs that are used into the tooltip.
  • What happens when you are on the block list, do you get a 404
  • Does the DoS protection on work on POST “Protect forms from abusive IPs”
Read 2178 times Last modified on Monday, 23 January 2017 09:11