Difference between revisions of "OWASP ModSec CRS Paranoia Mode"

Revision as of 06:26, 30 January 2016

Abstract

This is a page about the development of a paranoia mode aka bringing back the rules that used to yield a high number of false positives. This little project is aimed at inclusion into the 3.0.0 release of the OWASP ModSecurity Core Rules, where some rules have been removed in order to reduce the number of false positives with vanilla installations.

FIXME: Detailed description

Back to the OWASP ModSecurity Core Rules Set.

Sub-Project Infos

• Status: active (January 2016)
• Schedule: Pull request in January 2016
• Who: Christian Folini (dune73), Noël Zindel (zino), Franziska Bühler (franziskabuehler), Manuel Leos (Spartan), FIXME
• Documentation: Here on the OWASP Wiki
• Discussion / Archive: [email protected] / archive: http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/
• Github Link: https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1
• Final Pull Request: FIXME

Tasks

Open Tasks

Please define state as follows: new, assigned, waiting, closed. When a task it is closed, it is moved to the seperate closed tasks table below.

Closed Tasks

Rules

Paranoia Mode Candidates

The 3.0.0-rc1 has all rules renumbered. Existing numbering was fairly crazy and the new numbering follows the numbering scheme of the rules files (-> 9<2-digit-rulefile><3-digit-id>) A mapping table exists [IdNumbering.csv] We need to make sure, we do not mess things up, so let's add both IDs to the table, the old one and the new one.

Please set status as follows : candidate, cloning-candidate, unsure, dropped.

• 'cloning-candidates' are rules, that could be cloned into an even stricter variant with a stricter limit in a higher paranoia setting.
• If dropped, please provide reasoning in the remarks.

Rules from 2.2.X, missing in 3.0.0-rc1

It looks as if only the base_rules made it into 3.0.0. In fact there are a few rule ids know from the optional and experimental rule folders in 2.2.X, but it is more likely, these are new 3.0.0 rules reusing old rule ids as the rules (regexes and msg) do not match at all.

When trying to generate the list below, be aware that the rule ids have been renumbered between 3.0.0-dev and 3.0.0-rc1. IdNumbering.csv in your friend.

Stricter siblings for existing rules

The siblings detection rates and the anomaly ratings are drastically adjusted. To prevent loads of false positives, the rules can be filtered for common FP cases through chaining.

981173 : SQL Injection Character Anomaly Usage

Original ID (2.2.X): 981173
Change: Regex counter decreased to '1', anomaly score set to 'critical'
FP Filter: UUIDs

 #
 # -=[ SQL Injection Character Anomaly Usage ]=-
 #
 # This is a paranoid sibling to 2.2.9 Rule 981173.
 # The regex limit is set to {1,}, adjust to your own needs.
 # For dealing with false positives caused by uuids, the rule is now chained.
 # Also the anomaly score is now set to critical.
 #
 SecRule ARGS_NAMES|ARGS|XML:/* "([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\´\’\‘\`\<\>].*?){1,}"\
       "chain,\
       phase:request,\
       rev:'2',\
       ver:'OWASP_CRS/3.0.0',\
       maturity:'5',\
       accuracy:'6',\
       t:none,t:urlDecodeUni,\
       block,\
       msg:'Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded',\
       id:'10000',\
       tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
       logdata:'Matched Data: %{TX.1} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
       severity:'CRITICAL',\
       setvar:'tx.msg=%{rule.msg}',\
       setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"
       SecRule MATCHED_VARS "!@rx ^[a-f0-9-]{36}$"\
               "t:lowercase,\
               setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
               setvar:tx.sql_injection_score=+1"