[Owasp-modsecurity-core-rule-set] anomaly score range
ryan.barnett at breach.com
Tue Aug 11 13:50:12 EDT 2009
Director of Application Security Research
Phone: (703) 794-2248
Cell: (703) 269-8998
Breach Security, Inc.
2141 Palomar Airport Road, Suite 200
Carlsbad, CA 92011
On Tuesday 11 August 2009 06:40:43 am Gil Vidals wrote:
> I just installed the latest core rules and I see this anomaly score:
> SecRule TX:ANOMALY_SCORE "@ge 20" \
> What is the range of the anomaly scores? Does it go from 0 to 100?
> I need help in understanding the score and what to set it to. Currently I
> have it set to 10.
> The only documenation I could find so far is:
> # Uncomment the anomaly sections you wish to use.
> # You should set the score to the proper threshold you would prefer. If
> kept at "@gt 0" # it will work similarly to previous Mod CRS rules and will
> create an event in the error_log # file if there are any rules that match.
> If you would like to lessen the number of events # generated in the
> error_log file, you should increase the anomaly score threshold to #
> something like "@gt 20". This would only generate an event in the
> error_log file if # there are multiple lower severity rule matches or if
> any 1 higher severity item matches. #
> # You should also set the desired disruptive action (deny, redirect,
Yeah, the OWASP CRS project - Documentation section will need to be filled out
with this type of information about how the anomaly scoring works. Side note
- one benefit of moving the CRS to OWASP is that the project is wiki-based now
so anyone can help to update the documentation. So, if anyone wants to help
out, please jump in!
In previous versions of the CRS, each rule was self-contained. This means
that the rule would inspect the specified variable/targets with the operator
data chosen (usually a regular expression) and then the action list would
specify both the logging and blocking settings.
The idea with new CRS is that we want the rules to be more collaborative
meaning that we have decoupled the logging/blocking actions from the rules
that do the initial inspection. Most of the inspection rules will issue a
setvar to increase the TX anomaly score data for the current transaction and
this score will be evaluated at the last possible request blocking point at
the end of phase:2. The scoring numbers are tied to the severity levels of
the issue. Take a look at the updated Severity data from the CHANGELOG file -
- Updated Severity Ratings
The severity ratings in the rules have been updated to the following:
- 0: Emergency - is generated from correlation where there is an inbound attack and
an outbound leakage.
- 1: Alert - is generated from correlation where there is an inbound attack and an
outbound application level error.
- 2: Critical - is the highest severity level possible without correlation. It is
normally generated by the web attack rules (40 level files).
- 3: Error - is generated mostly from outbound leakage rules (50 level files).
- 4: Warning - is generated by malicious client rules (35 level files).
- 5: Notice - is generated by the Protocol policy and anomaly files.
- 6: Info - is generated by the search engine clients (55 marketing file).
The normal web attack categories (such as XSS and SQL Injection, etc...) have
a severity of 2/Critical and will increase the score by 20 points. 3/Error =
15 points, 4/Warning = 10 points and 5/Notice is 5 points.
So, what all of this means, in relation to the modsecurity_49_enforcement.conf
file, is that you can set an anomaly scoring threshold that you deem
appropriate for your site. These thresholds can control logging and/or
blocking. For instance, let's say that you don't really care about clients
that are missing 1 or 2 request headers (which is something that is flagged in
the 21 protocol anomalies file), then you should set your anomaly score at 15.
This means that if a client violates any 2 of the severity 5 rules, this would
only amount to an anomaly score of 10. If, however, they violate any 3
severity 5 issues, then they would trigger. In the previous CRS, the XSS/SQLi
types of rules issued blocking actions so that is why the comment section
above mentions setting the score to 20. This would result in an anomaly
scoring match if *any* severity 2 rule matches.
Another item to consider with anomaly scoring and that is that you can
actually combine 2 issues together -
1) Confidence level in blocking
Due to the fact that we have broken out the highly optimized regex, this means
that we have many more individual rules that could possibly contribute to an
anomaly score. This means that the *higher* the anomaly score, the more
confident you can be that something malicious is being detected.
2) Handling exceptions
If you are running into a false positive match, for say an XSS attack, against
one particular parameter payload in your app, chances are that the anomaly
score for it is rather low and is just barely going over it. An exception may
be as easy as bumping up the anomaly score by 20 points. There are other
exceptions mechanisms (that we will document later on the OWASP site) that are
easy as well but this is the easiest.
Hopefully this info helps.
Ryan C. Barnett
WASC Distributed Open Proxy Honeypot Project Leader
OWASP ModSecurity Core Rule Set Project Leader
Tactical Web Application Security
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-modsecurity-core-rule-set