Ich habe gestern meinen Apache 2.2.8 mit mod-security 2.5.11 (core rule set 2.0.6) ergänzt.
So weit scheint auch alles sehr schön zu funktionieren. Leider nur ein wenig zu schön, denn mod security sperrt nun alle meine SSL-URLs.
Ich würde gerne das Debug-Log einer einzelnen Anfrage posten, das ist allerdings 400.000+ Zeilen lang. Vielleicht hilft euch schon das Audit-Log:
Trotz langer Suche kann ich mir das alles nicht erklären. Das Core Rule Set habe ich übernommen wie es ist und habe nur das Logging ergänzt. Hier meine modsecurity_crs_10_config.conf:
Ich hoffe ihr fühlt euch nicht vom Log erschlagen und könnt mir helfen!
der_linmatz
So weit scheint auch alles sehr schön zu funktionieren. Leider nur ein wenig zu schön, denn mod security sperrt nun alle meine SSL-URLs.
Ich würde gerne das Debug-Log einer einzelnen Anfrage posten, das ist allerdings 400.000+ Zeilen lang. Vielleicht hilft euch schon das Audit-Log:
Code:
--0c9bf877-A--
[10/Mar/2010:09:47:46 +0100] WixOGFOpBboAAFU5ygMAAAAD 62.213.151.127 55724 83.169.5.186 443
--0c9bf877-B--
GET / HTTP/1.1
Host: www.domainname.ltd
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
--0c9bf877-F--
HTTP/1.1 403 Forbidden
Content-Length: 394
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--0c9bf877-H--
Message: Warning. Operator GE matched 0 at TX:inbound_anomaly_score. [file "/etc/apache2/modsecurity2/base_rules/modsecurity_crs_60_correlation.conf"] [line "35"] [msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 10, SQLi=, XSS=): HTTP header is restricted by policy"]
Action: Intercepted (phase 2)
Stopwatch: 1268210866081304 9819 (522 2154 -)
Producer: ModSecurity for Apache/2.5.9 (http://www.modsecurity.org/); core ruleset/2.0.6.
Server: Apache/2.2.8 (Ubuntu) mod_ssl/2.2.8 OpenSSL/0.9.8g
--0c9bf877-Z--Trotz langer Suche kann ich mir das alles nicht erklären. Das Core Rule Set habe ich übernommen wie es ist und habe nur das Logging ergänzt. Hier meine modsecurity_crs_10_config.conf:
Code:
# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.0.6
# Copyright (C) 2006-2010 Breach Security Inc. All rights reserved.
#
# The ModSecurity Core Rule Set is distributed under GPL version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------
## -- Configuration ----------------------------------------------------------
#
# Logging
#
# Debug log
SecDebugLog logs/modsecurity/modsec_debug.log
SecDebugLogLevel 0
# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog logs/modsecurity/modsec_audit.log
SecDataDir /var/log/apache2/modsecurity
#
# Server Signatur
#
SecServerSignature "Apache/Version unknown (Debian)"
#
# Specify CRS version in the audit logs.
#
SecComponentSignature "core ruleset/2.0.6"
#
# 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}"
# You most likely already have a base ModSecurity configuration. The data
# presented in this file should work in conjunction with your configs.
# There are also some references to some directive settings that you will
# want to double check.
#
# -=[ 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"
#
# -=[ 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=20"
SecAction "phase:1,t:none,nolog,pass,setvar:tx.outbound_anomaly_score_level=15"
#
# -=[ 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 20.
# 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 15.
# Is generated mostly from outbound leakage rules (50 level files).
# - 4: Warning - Anomaly Score of 10.
# Is generated by malicious client rules (35 level files).
# - 5: Notice - Anomaly Score of 5.
# Is generated by the Protocol policy and anomaly files.
#
SecAction "phase:1,t:none,nolog,pass, \
setvar:tx.critical_anomaly_score=20, \
setvar:tx.error_anomaly_score=15, \
setvar:tx.warning_anomaly_score=10, \
setvar:tx.notice_anomaly_score=5"
#
# -=[ 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', \
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'"
#
#
# -=[ Blocking Action ]=-
# What to do when the anomaly score threshold is exceeded.
#
# The default is to log the error and let the request go through.
# This is a reasonable setting to start with because you do not
# want to reject legitimate requests with an untuned rule set.
#
# The following line's settings will be inherited by rules that
# do blocking in the 49 inbound and 59 outbound blocking files.
#
# Change to a disruptive action such as deny, drop or redirect if you
# want to block the transaction.
#
#SecDefaultAction "phase:2,pass"
SecDefaultAction "phase:2,drop"
#
# 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 OnIch hoffe ihr fühlt euch nicht vom Log erschlagen und könnt mir helfen!
der_linmatz
