Created
April 21, 2019 06:01
-
-
Save PacodiazDG/b1a9ff24e1401ae2f156479295581934 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# --------------------------------------------------------------- | |
# Core ModSecurity Rule Set ver.2.2.9 | |
# Copyright (C) 2006-2012 Trustwave All rights reserved. | |
# | |
# The OWASP ModSecurity Core Rule Set is distributed under | |
# Apache Software License (ASL) version 2 | |
# Please see the enclosed LICENCE file for full details. | |
# --------------------------------------------------------------- | |
# | |
# -- [[ Recommended Base Configuration ]] ------------------------------------------------- | |
# | |
# The configuration directives/settings in this file are used to control | |
# the OWASP ModSecurity CRS. These settings do **NOT** configure the main | |
# ModSecurity settings such as: | |
# | |
# - SecRuleEngine | |
# - SecRequestBodyAccess | |
# - SecAuditEngine | |
# - SecDebugLog | |
# | |
# You should use the modsecurity.conf-recommended file that comes with the | |
# ModSecurity source code archive. | |
# | |
# Ref: https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended | |
# | |
# | |
# -- [[ Rule Version ]] ------------------------------------------------------------------- | |
# | |
# Rule version data is added to the "Producer" line of Section H of the Audit log: | |
# | |
# - Producer: ModSecurity for Apache/2.7.0-rc1 (http://www.modsecurity.org/); OWASP_CRS/2.2.4. | |
# | |
# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecComponentSignature | |
# | |
SecComponentSignature "OWASP_CRS/2.2.9" | |
# | |
# -- [[ Modes of Operation: Self-Contained vs. Collaborative Detection ]] ----------------- | |
# | |
# 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. | |
# | |
# -- [[ Self-Contained Mode ]] -- | |
# Rules inherit the "deny" disruptive action. The first rule that matches will block. | |
# | |
# -- [[ Collaborative Detection Mode ]] -- | |
# This is a "delayed blocking" mode of operation where each matching rule will inherit | |
# the "pass" action and will only contribute to anomaly scores. Transactional blocking | |
# can be applied | |
# | |
# -- [[ Alert Logging Control ]] -- | |
# 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" | |
# | |
# Ref: http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html | |
# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecDefaultAction | |
# | |
SecDefaultAction "phase:1,deny,log" | |
SecDefaultAction "phase:2,deny,log" | |
# | |
# -- [[ Collaborative Detection 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 \ | |
"id:'900001', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.critical_anomaly_score=5, \ | |
setvar:tx.error_anomaly_score=4, \ | |
setvar:tx.warning_anomaly_score=3, \ | |
setvar:tx.notice_anomaly_score=2, \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ Collaborative Detection Scoring Initialization and 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 level (rule 900003) 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 \ | |
"id:'900002', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.anomaly_score=0, \ | |
setvar:tx.sql_injection_score=0, \ | |
setvar:tx.xss_score=0, \ | |
setvar:tx.inbound_anomaly_score=0, \ | |
setvar:tx.outbound_anomaly_score=0, \ | |
nolog, \ | |
pass" | |
SecAction \ | |
"id:'900003', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.inbound_anomaly_score_level=5, \ | |
setvar:tx.outbound_anomaly_score_level=4, \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ Collaborative Detection Blocking ]] ----------------------------------------------- | |
# | |
# This is a collaborative detection mode where each rule will increment an overall | |
# anomaly score for 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 want to use anomaly scoring mode, then uncomment this line. | |
# | |
#SecAction \ | |
"id:'900004', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.anomaly_score_blocking=on, \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ GeoIP Database ]] ----------------------------------------------------------------- | |
# | |
# There are some rulesets that need to inspect the GEO data of the REMOTE_ADDR data. | |
# | |
# You must first download the MaxMind GeoIP Lite City DB - | |
# | |
# http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz | |
# | |
# You then need to define the proper path for the SecGeoLookupDb directive | |
# | |
# Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html | |
# Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html | |
# | |
#SecGeoLookupDb /opt/modsecurity/lib/GeoLiteCity.dat | |
# | |
# -- [[ Regression Testing Mode ]] -------------------------------------------------------- | |
# | |
# If you are going to run the regression testing mode, you should uncomment the | |
# following rule. It will enable DetectionOnly mode for the SecRuleEngine and | |
# will enable Response Header tagging so that the client testing script can see | |
# which rule IDs have matched. | |
# | |
# You must specify the your source IP address where you will be running the tests | |
# from. | |
# | |
#SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \ | |
"id:'900005', \ | |
phase:1, \ | |
t:none, \ | |
ctl:ruleEngine=DetectionOnly, \ | |
setvar:tx.regression_testing=1, \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ 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 \ | |
"id:'900006', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.max_num_args=255, \ | |
nolog, \ | |
pass" | |
# | |
# -- Limit argument name length | |
#SecAction \ | |
"id:'900007', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.arg_name_length=100, \ | |
nolog, \ | |
pass" | |
# | |
# -- Limit value name length | |
#SecAction \ | |
"id:'900008', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.arg_length=400, \ | |
nolog, \ | |
pass" | |
# | |
# -- Limit arguments total length | |
#SecAction \ | |
"id:'900009', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.total_arg_length=64000, \ | |
nolog, \ | |
pass" | |
# | |
# -- Individual file size is limited | |
#SecAction \ | |
"id:'900010', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.max_file_size=1048576, \ | |
nolog, \ | |
pass" | |
# | |
# -- Combined file size is limited | |
#SecAction \ | |
"id:'900011', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.combined_file_sizes=1048576, \ | |
nolog, \ | |
pass" | |
# | |
# 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 \ | |
"id:'900012', \ | |
phase:1, \ | |
t:none, \ | |
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|application/json', \ | |
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/', \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ Content Security Policy (CSP) Settings ]] ----------------------------------------- | |
# | |
# The purpose of these settings is to send CSP response headers to | |
# Mozilla FireFox users so that you can enforce how dynamic content | |
# is used. CSP usage helps to prevent XSS attacks against your users. | |
# | |
# Reference Link: | |
# | |
# https://developer.mozilla.org/en/Security/CSP | |
# | |
# Uncomment this SecAction line if you want use CSP enforcement. | |
# You need to set the appropriate directives and settings for your site/domain and | |
# and activate the CSP file in the experimental_rules directory. | |
# | |
# Ref: http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html | |
# | |
#SecAction \ | |
"id:'900013', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.csp_report_only=1, \ | |
setvar:tx.csp_report_uri=/csp_violation_report, \ | |
setenv:'csp_policy=allow \'self\'; img-src *.yoursite.com; media-src *.yoursite.com; style-src *.yoursite.com; frame-ancestors *.yoursite.com; script-src *.yoursite.com; report-uri %{tx.csp_report_uri}', \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ 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 \ | |
"id:'900014', \ | |
phase:1, \ | |
t:none, \ | |
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', \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ 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 \ | |
"id:'900015', \ | |
phase:1, \ | |
t:none, \ | |
setvar:'tx.dos_burst_time_slice=60', \ | |
setvar:'tx.dos_counter_threshold=100', \ | |
setvar:'tx.dos_block_timeout=600', \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ 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 \ | |
"id:'900016', \ | |
phase:1, \ | |
t:none, \ | |
setvar:tx.crs_validate_utf8_encoding=1, \ | |
nolog, \ | |
pass" | |
# | |
# -- [[ Enable XML Body Parsing ]] ------------------------------------------------------- | |
# | |
# The rules in this file will trigger the XML parser upon an XML request | |
# | |
# Initiate XML Processor in case of xml content-type | |
# | |
SecRule REQUEST_HEADERS:Content-Type "text/xml" \ | |
"id:'900017', \ | |
phase:1, \ | |
t:none,t:lowercase, \ | |
nolog, \ | |
pass, \ | |
chain" | |
SecRule REQBODY_PROCESSOR "!@streq XML" \ | |
"ctl:requestBodyProcessor=XML" | |
# | |
# -- [[ 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 "^(.*)$" \ | |
"id:'900018', \ | |
phase:1, \ | |
t:none,t:sha1,t:hexEncode, \ | |
setvar:tx.ua_hash=%{matched_var}, \ | |
nolog, \ | |
pass" | |
SecRule REQUEST_HEADERS:x-forwarded-for "^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b" \ | |
"id:'900019', \ | |
phase:1, \ | |
t:none, \ | |
capture, \ | |
setvar:tx.real_ip=%{tx.1}, \ | |
nolog, \ | |
pass" | |
SecRule &TX:REAL_IP "!@eq 0" \ | |
"id:'900020', \ | |
phase:1, \ | |
t:none, \ | |
initcol:global=global, \ | |
initcol:ip=%{tx.real_ip}_%{tx.ua_hash}, \ | |
nolog, \ | |
pass" | |
SecRule &TX:REAL_IP "@eq 0" \ | |
"id:'900021', \ | |
phase:1, \ | |
t:none, \ | |
initcol:global=global, \ | |
initcol:ip=%{remote_addr}_%{tx.ua_hash}, \ | |
setvar:tx.real_ip=%{remote_addr}, \ | |
nolog, \ | |
pass" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment