From: Abdellah Tantan <adtantan@...>>
Date: Wed, 9 Feb 2011 10:59:58 -0600
To: "mod-security-users@...>" <mod-security-users@...>>
Subject: [mod-security-users] help with modsec 2.5.13 CRS
I recently installed modsec 2.5.13 and configured it to block attacks in anomaly mode. However modsec does not seem to be blocking any attacks.
The ModSecurity code and the OWASP ModSecurity Core Rule Set (CRS) are developed on separate intervals (CRS versions are released more frequently). I suggest you do two things -
1. Download the latest CRS version (2.1.1) - http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project#tab=Download
2. For CRS issues/questions – we have a separate mail-list - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
If you upgrade and you still have issues, please send an audit_log example of a transaction that was not blocked.
-Ryan
I created URL with xss attacks but nothing is being blocked. I can see in modsec_audit_log file that it detects XSS attack but it lets the request go through.
Here is an log example and my modsec_crs_10.conf file. I have to say that I am new to modsec and I have read ivan ristic’ modsecurity new book.
Please take a look at my configuration file and let me know if I am doing something wrong.
Log
[09/Feb/2011:10:26:59 --0600] [X.X.X.X/sid#2b847354fd30][rid#2b84733e0320][/"javascript:alert('XSS Exploit!')">Innocent link</a>][2] Warning. Match of "within %{tx.allowed_http_versions}" against "REQUEST_PROTOCOL" required. [file "/etc/httpd/conf/modsecurity-2.5.13/rules/base_rules/modsecurity_crs_30_http_policy.conf"] [line "77"] [id "960034"] [msg "HTTP protocol version is not allowed by policy"] [data "HTTP/1.1"] [severity "CRITICAL"] [tag "POLICY/PROTOCOL_NOT_ALLOWED"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.10"]
Configuration file
# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.0.10
# Copyright (C) 2006-2010 Trustwave All rights reserved.
#
# The ModSecurity Core Rule Set is distributed under GPL version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------
## -- Configuration ----------------------------------------------------------
#
# Specify CRS version in the audit logs.
#
SecComponentSignature "core ruleset/2.0.10"
#
# Review your SecRuleEngine settings. If you want to
# allow blocking, then set it to On however check your SecDefaultAction setting
# to ensure that it is set appropriately.
#
SecRuleEngine On
#
# -=[ Mode of Operation ]=-
#
# You can now choose how you want to run the modsecurity rules -
#
# Anomaly Scoring vs. Traditional
#
# Each detection rule uses the "block" action which will inherit the SecDefaultAction
# specified below. Your settings here will determine which mode of operation you use.
#
# Traditional mode is the current default setting and it uses "deny" (you can set any
# disruptive action you wish)
#
# If you want to run the rules in Anomaly Scoring mode (where blocking is delayed until the
# end of the request phase and rules contribute to an anomaly score) then set the
# SecDefaultAction to "pass"
#
# You can also decide how you want to handle logging actions. You have three options -
#
#
# - To log to both the Apache error_log and ModSecurity audit_log file use - log
# - To log *only* to the ModSecurity audit_log file use - nolog,auditlog
# - To log *only* to the Apache error_log file use - log,noauditlog
#
SecDefaultAction "phase:2,pass,log"
#
# -=[ Anomaly Scoring Block Mode ]=-
#
# This is a collaborative detection mode where each rule will increment an overall
# anomaly score the transaction. The scores are then evaluated in the following files:
#
# Inbound anomaly score - checked in the modsecurity_crs_49_inbound_blocking.conf file
# Outbound anomaly score - checked in the modsecurity_crs_59_outbound_blocking.conf file
#
# If you do not want to use anomaly scoring mode, then comment out this line.
#
SecAction "phase:1,t:none,nolog,pass,setvar:tx.anomaly_score_blocking=on"
#
# -=[ Anomaly Scoring Severity Levels ]=-
#
# These are the default scoring points for each severity level. You may
# adjust these to you liking. These settings will be used in macro expansion
# in the rules to increment the anomaly scores when rules match.
#
# These are the default Severity ratings (with anomaly scores) of the individual rules -
#
# - 2: Critical - Anomaly Score of 5.
# Is the highest severity level possible without correlation. It is
# normally generated by the web attack rules (40 level files).
# - 3: Error - Anomaly Score of 4.
# Is generated mostly from outbound leakage rules (50 level files).
# - 4: Warning - Anomaly Score of 3.
# Is generated by malicious client rules (35 level files).
# - 5: Notice - Anomaly Score of 2.
# Is generated by the Protocol policy and anomaly files.
#
#
SecAction "phase:1,t:none,nolog,pass, \
setvar:tx.critical_anomaly_score=5, \
setvar:tx.error_anomaly_score=4, \
setvar:tx.warning_anomaly_score=3, \
setvar:tx.notice_anomaly_score=2"
#
# -=[ Anomaly Scoring Threshold Levels ]=-
#
# These variables are used in macro expansion in the 49 inbound blocking and 59
# outbound blocking files.
#
# **MUST HAVE** ModSecurity v2.5.12 or higher to use macro expansion in numeric
# operators. If you have an earlier version, edit the 49/59 files directly to
# set the appropriate anomaly score levels.
#
# You should set the score to the proper threshold you would prefer. If set to "5"
# 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 "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.
#
SecAction "phase:1,t:none,nolog,pass,setvar:tx.inbound_anomaly_score_level=5"
SecAction "phase:1,t:none,nolog,pass,setvar:tx.outbound_anomaly_score_level=4"
#
# -=[ Paranoid Mode ]=-
#
# There are many different transactional variables that can be inspected for
# attacks. Some variables, such as ARGS, has the best false negative/false
# positive ratio where it will catch the vast majority of attack payloads and
# not have a high false positive rate. This is also true for some security
# checks such as @validateByteRange checks where we are initially only inspecting
# for Nul Bytes.
#
# There are, however, some possibilities for false negative issues with inspecting
# parsed data and this could lead to missed attacks. If you
# want to lessen the chances for false negatives, then you should enable
# "Paranoid Mode" processing by setting the following line to 1. This will process
# additional rules that are inspecting variables with a higher false positive rate.
SecAction "phase:1,t:none,nolog,pass,setvar:tx.paranoid_mode=1"
#
# -=[ HTTP Policy Settings ]=-
# Set the following policy settings here and they will be propagated to the 23 rules
# file (modsecurity_common_23_request_limits.conf) by using macro expansion.
# If you run into false positives, you can adjust the settings here.
#
# Only the max number of args is uncommented by default as there are a high rate
# of false positives. Uncomment the items you wish to set.
#
## Maximum number of arguments in request limited
SecAction "phase:1,t:none,nolog,pass,setvar:tx.max_num_args=255"
## Limit argument name length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.arg_name_length=100"
## Limit value name length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.arg_length=400"
## Limit arguments total length
SecAction "phase:1,t:none,nolog,pass,setvar:tx.total_arg_length=64000"
## Individual file size is limited
SecAction "phase:1,t:none,nolog,pass,setvar:tx.max_file_size=1048576"
## Combined file size is limited
#SecAction "phase:1,t:none,nolog,pass,setvar:tx.combined_file_sizes=1048576"
# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction "phase:1,t:none,nolog,pass, \
setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded multipart/form-data text/xml application/xml application/x-amf', \
setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/'"
#
# Check UTF enconding
# We only want to apply this check if UTF-8 encoding is actually used by the site, otherwise
# it will result in false positives.
#
# Uncomment this line if your site uses UTF8 encoding
#SecAction "phase:1,t:none,nolog,pass,setvar:tx.crs_validate_utf8_encoding=1"
#
# Create both Global and IP collections for rules to use
# There are some CRS rules that assume that these two collections
# have already been initiated.
#
SecAction "phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}"
|