Never mind I found the issue. it's on my side.

 

From: [email protected]
[mailto:[email protected]] On Behalf
Of Abdellah Tantan
Sent: Wednesday, February 09, 2011 1:02 PM
To: [email protected]
Subject: [Owasp-modsecurity-core-rule-set] (no subject)

 

I am having modsecurity  running in a traditional mode but it's not blocking
attacks. Attached is the transaction log. 

 

 

Here is my configuration file.

 

# Core ModSecurity Rule Set ver.2.1.1

# Copyright (C) 2006-2011 Trustwave All rights reserved.

#

# The OWASP 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.1.1"

 

 

#

# 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 DetectionOnly

 

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,deny,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=0"

 

 

#

# -=[ 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"

 

 

#

# -=[ HTTP Policy Settings ]=-

#

# 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 applic

ation/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/ .o

ld/ .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/'"

 

#

# -=[ Brute Force Protection ]=-

#

# If you are using the Brute Force Protection rule set, then uncomment the
following

# lines and set the following variables:

# - Protected URLs: resources to protect (e.g. login pages) - set to your
login page

# - Burst Time Slice Interval: time interval window to monitor for bursts

# - Request Threshold: request # threshold to trigger a burst

# - Block Period: temporary block timeout

#

#SecAction "phase:1,t:none,nolog,pass, \

#setvar:'tx.brute_force_protected_urls=/login.jsp /partner_login.php', \

#setvar:'tx.brute_force_burst_time_slice=60', \

#setvar:'tx.brute_force_counter_threshold=10', \

#setvar:'tx.brute_force_block_timeout=300'"

 

 

#

# -=[ DoS Protection ]=-

#

# If you are using the DoS Protection rule set, then uncomment the following

# lines and set the following variables:

# - Burst Time Slice Interval: time interval window to monitor for bursts

# - Request Threshold: request # threshold to trigger a burst

# - Block Period: temporary block timeout

#

#SecAction "phase:1,t:none,nolog,pass, \

#setvar:'tx.dos_burst_time_slice=60', \

#setvar:'tx.dos_counter_threshold=100', \

#setvar:'tx.dos_block_timeout=600'"

 

 

#

# -=[ 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"

 

#

# -=[ Global and IP Collections ]=-

#

# 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.

#

SecRule REQUEST_HEADERS:User-Agent "^(.*)$"
"phase:1,t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_hash=%{matched_va
r}"

SecAction
"phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}_%
{tx.ua_hash}"

 

 

 

 

cid:[email protected]
Abdellah Tantan
Systems Engineer / Application Developer
cid:[email protected]  phone: 712.388.2132 ext. 1001
cid:[email protected]   <mailto:[email protected]>
[email protected]
25 Main Place, Suite 400 Council Bluffs, IA 51503-0790
<http://www.paydq.com/> 
www.paydq.com

 

<<image001.jpg>>

<<image002.jpg>>

_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

Reply via email to