관리-도구

편집 파일: crs-setup.conf

# ------------------------------------------------------------------------ # OWASP ModSecurity Core Rule Set ver.3.0.2 # Copyright (c) 2006-2016 Trustwave and contributors. All rights reserved. # # The OWASP ModSecurity Core Rule Set is distributed under # Apache Software License (ASL) version 2 # Please see the enclosed LICENSE file for full details. # ------------------------------------------------------------------------ # # -- [[ Introduction ]] -------------------------------------------------------- # # The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack # detection rules that provide a base level of protection for any web # application. They are written for the open source, cross-platform # ModSecurity Web Application Firewall. # # See also: # https://modsecurity.org/crs/ # https://github.com/SpiderLabs/owasp-modsecurity-crs # https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project # # # -- [[ System Requirements ]] ------------------------------------------------- # # CRS requires ModSecurity version 2.8.0 or above. # We recommend to always use the newest ModSecurity version. # # The configuration directives/settings in this file are used to control # the OWASP ModSecurity CRS. These settings do **NOT** configure the main # ModSecurity settings (modsecurity.conf) such as SecRuleEngine, # SecRequestBodyAccess, SecAuditEngine, SecDebugLog, and XML processing. # # The CRS assumes that modsecurity.conf has been loaded. If you don't have this # file, you can get it from: # https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended # # The order of file inclusion in your webserver configuration should always be: # 1. modsecurity.conf # 2. crs-setup.conf (this file) # 3. rules/*.conf (the CRS rule files) # # Please refer to the INSTALL file for detailed installation instructions. # # # -- [[ Mode of Operation: Anomaly Scoring vs. Self-Contained ]] --------------- # # The CRS can run in two modes: # # -- [[ Anomaly Scoring Mode (default) ]] -- # In CRS3, anomaly mode is the default and recommended mode, since it gives the # most accurate log information and offers the most flexibility in setting your # blocking policies. It is also called "collaborative detection mode". # In this mode, each matching rule increases an 'anomaly score'. # At the conclusion of the inbound rules, and again at the conclusion of the # outbound rules, the anomaly score is checked, and the blocking evaluation # rules apply a disruptive action, by default returning an error 403. # # -- [[ Self-Contained Mode ]] -- # In this mode, rules apply an action instantly. This was the CRS2 default. # It can lower resource usage, at the cost of less flexibility in blocking policy # and less informative audit logs (only the first detected threat is logged). # Rules inherit the disruptive action that you specify (i.e. deny, drop, etc). # The first rule that matches will execute this action. In most cases this will # cause evaluation to stop after the first rule has matched, similar to how many # IDSs function. # # -- [[ Alert Logging Control ]] -- # In the mode configuration, you must also adjust the desired logging options. # There are three common options for dealing with logging. By default CRS enables # logging to the webserver error log (or Event viewer) plus detailed logging to # the ModSecurity audit log (configured under SecAuditLog in modsecurity.conf). # # - To log to both error log and ModSecurity audit log file, use: "log,auditlog" # - To log *only* to the ModSecurity audit log file, use: "nolog,auditlog" # - To log *only* to the error log file, use: "log,noauditlog" # # Examples for the various modes follow. # You must leave one of the following options enabled. # Note that you must specify the same line for phase:1 and phase:2. # # Default: Anomaly Scoring mode, log to error log, log to ModSecurity audit log # - By default, offending requests are blocked with an error 403 response. # - To change the disruptive action, see RESPONSE-999-EXCEPTIONS.conf.example # and review section 'Changing the Disruptive Action for Anomaly Mode'. # - In Apache, you can use ErrorDocument to show a friendly error page or # perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html # SecDefaultAction "phase:1,log,auditlog,pass" SecDefaultAction "phase:2,log,auditlog,pass" # Example: Anomaly Scoring mode, log only to ModSecurity audit log # - By default, offending requests are blocked with an error 403 response. # - To change the disruptive action, see RESPONSE-999-EXCEPTIONS.conf.example # and review section 'Changing the Disruptive Action for Anomaly Mode'. # - In Apache, you can use ErrorDocument to show a friendly error page or # perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html # # SecDefaultAction "phase:1,nolog,auditlog,pass" # SecDefaultAction "phase:2,nolog,auditlog,pass" # Example: Self-contained mode, return error 403 on blocking # - In this configuration the default disruptive action becomes 'deny'. After a # rule triggers, it will stop processing the request and return an error 403. # - You can also use a different error status, such as 404, 406, et cetera. # - In Apache, you can use ErrorDocument to show a friendly error page or # perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html # # SecDefaultAction "phase:1,log,auditlog,deny,status:403" # SecDefaultAction "phase:2,log,auditlog,deny,status:403" # Example: Self-contained mode, redirect back to homepage on blocking # - In this configuration the 'tag' action includes the Host header data in the # log. This helps to identify which virtual host triggered the rule (if any). # - Note that this might cause redirect loops in some situations; for example # if a Cookie or User-Agent header is blocked, it will also be blocked when # the client subsequently tries to access the homepage. You can also redirect # to another custom URL. # SecDefaultAction "phase:1,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'" # SecDefaultAction "phase:2,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'" # # -- [[ Paranoia Level Initialization ]] --------------------------------------- # # The Paranoia Level (PL) setting allows you to choose the desired level # of rule checks. # # With each paranoia level increase, the CRS enables additional rules # giving you a higher level of security. However, higher paranoia levels # also increase the possibility of blocking some legitimate traffic due to # false alarms (also named false positives or FPs). If you use higher # paranoia levels, it is likely that you will need to add some exclusion # rules for certain requests and applications receiving complex input. # # - A paranoia level of 1 is default. In this level, most core rules # are enabled. PL1 is advised for beginners, installations # covering many different sites and applications, and for setups # with standard security requirements. # At PL1 you should face FPs rarely. If you encounter FPs, please # open an issue on the CRS GitHub site and don't forget to attach your # complete Audit Log record for the request with the issue. # - Paranoia level 2 includes many extra rules, for instance enabling # many regexp-based SQL and XSS injection protections, and adding # extra keywords checked for code injections. PL2 is advised # for moderate to experienced users desiring more complete coverage # and for installations with elevated security requirements. # PL2 comes with some FPs which you need to handle. # - Paranoia level 3 enables more rules and keyword lists, and tweaks # limits on special characters used. PL3 is aimed at users experienced # at the handling of FPs and at installations with a high security # requirement. # - Paranoia level 4 further restricts special characters. # The highest level is advised for experienced users protecting # installations with very high security requirements. Running PL4 will # likely produce a very high number of FPs which have to be # treated before the site can go productive. # # Rules in paranoia level 2 or higher will log their PL to the audit log; # example: [tag "paranoia-level/2"]. This allows you to deduct from the # audit log how the WAF behavior is affected by paranoia level. # # Uncomment this rule to change the default: # SecAction \ "id:900000,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.paranoia_level=4" # # -- [[ Anomaly Mode Severity Levels ]] ---------------------------------------- # # Each rule in the CRS has an associated severity level. # These are the default scoring points for each severity level. # These settings will be used to increment the anomaly score if a rule matches. # You may adjust these points to your liking, but this is usually not needed. # # - CRITICAL severity: Anomaly Score of 5. # Mostly generated by the application attack rules (93x and 94x files). # - ERROR severity: Anomaly Score of 4. # Generated mostly from outbound leakage rules (95x files). # - WARNING severity: Anomaly Score of 3. # Generated mostly by malicious client rules (91x files). # - NOTICE severity: Anomaly Score of 2. # Generated mostly by the protocol rules (92x files). # # In anomaly mode, these scores are cumulative. # So it's possible for a request to hit multiple rules. # # (Note: In this file, we use 'phase:1' to set CRS configuration variables. # In general, 'phase:request' is used. However, we want to make absolutely sure # that all configuration variables are set before the CRS rules are processed.) # #SecAction \ # "id:900100,\ # phase:1,\ # nolog,\ # pass,\ # 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" # # -- [[ Anomaly Mode Blocking Threshold Levels ]] ------------------------------ # # Here, you can specify at which cumulative anomaly score an inbound request, # or outbound response, gets blocked. # # Most detected inbound threats will give a critical score of 5. # Smaller violations, like violations of protocol/standards, carry lower scores. # # [ At default value ] # If you keep the blocking thresholds at the defaults, the CRS will work # similarly to previous CRS versions: a single critical rule match will cause # the request to be blocked and logged. # # [ Using higher values ] # If you want to make the CRS less sensitive, you can increase the blocking # thresholds, for instance to 7 (which would require multiple rule matches # before blocking) or 10 (which would require at least two critical alerts - or # a combination of many lesser alerts), or even higher. However, increasing the # thresholds might cause some attacks to bypass the CRS rules or your policies. # # [ New deployment strategy: Starting high and decreasing ] # It is a common practice to start a fresh CRS installation with elevated # anomaly scoring thresholds (>100) and then lower the limits as your # confidence in the setup grows. You may also look into the Sampling # Percentage section below for a different strategy to ease into a new # CRS installation. # # [ Anomaly Threshold / Paranoia Level Quadrant ] # # High Anomaly Limit | High Anomaly Limit # Low Paranoia Level | High Paranoia Level # -> Fresh Site | -> Experimental Site # ------------------------------------------------------ # Low Anomaly Limit | Low Anomaly Limit # Low Paranoia Level | High Paranoia Level # -> Standard Site | -> High Security Site # # Uncomment this rule to change the defaults: # #SecAction \ # "id:900110,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.inbound_anomaly_score_threshold=5,\ # setvar:tx.outbound_anomaly_score_threshold=4" # # -- [[ Application Specific Rule Exclusions ]] ---------------------------------------- # # Some well-known applications may undertake actions that appear to be # malicious. This includes actions such as allowing HTML or Javascript within # parameters. In such cases the CRS aims to prevent false positives by allowing # administrators to enable prebuilt, application specific exclusions on an # application by application basis. # These application specific exclusions are distinct from the rules that would # be placed in the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS configuration file as # they are prebuilt for specific applications. The 'REQUEST-900' file is # designed for users to add their own custom exclusions. Note, using these # application specific exclusions may loosen restrictions of the CRS, # especially if used with an application they weren't designed for. As a result # they should be applied with care. # To use this functionality you must specify a supported application. To do so # uncomment rule 900130. In addition to uncommenting the rule you will need to # specify which application(s) you'd like to enable exclusions for. Only a # (very) limited set of applications are currently supported, please use the # filenames prefixed with 'REQUEST-903' to guide you in your selection. # Such filenames use the following convention: # REQUEST-903.9XXX-{APPNAME}-EXCLUSIONS-RULES.conf # # It is recommended if you run multiple web applications on your site to limit # the effects of the exclusion to only the path where the excluded webapp # resides using a rule similar to the following example: # SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:crs_exclusions_wordpress=1 # # Modify and uncomment this rule to select which application: # SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_drupal=1,\ setvar:tx.crs_exclusions_wordpress=1" # # -- [[ HTTP Policy Settings ]] ------------------------------------------------ # # This section defines your policies for the HTTP protocol, such as: # - allowed HTTP versions, HTTP methods, allowed request Content-Types # - forbidden file extensions (e.g. .bak, .sql) and request headers (e.g. Proxy) # # These variables are used in the following rule files: # - REQUEST-911-METHOD-ENFORCEMENT.conf # - REQUEST-912-DOS-PROTECTION.conf # - REQUEST-920-PROTOCOL-ENFORCEMENT.conf # HTTP methods that a client is allowed to use. # Default: GET HEAD POST OPTIONS # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK # MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK # Uncomment this rule to change the default. #SecAction \ # "id:900200,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.allowed_methods=GET HEAD POST OPTIONS'" # Content-Types that a client is allowed to send in a request. # Default: application/x-www-form-urlencoded|multipart/form-data|text/xml|\ # application/xml|application/soap+xml|application/x-amf|application/json|\ # application/octet-stream|text/plain # Uncomment this rule to change the default. #SecAction \ # "id:900220,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'" # Allowed HTTP versions. # Default: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 # Example for legacy clients: HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 # Note that some web server versions use 'HTTP/2', some 'HTTP/2.0', so # we include both version strings by default. # Uncomment this rule to change the default. #SecAction \ # "id:900230,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'" # Forbidden file extensions. # Guards against unintended exposure of development/configuration files. # Default: .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/ # Example: .bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .sql/ # Uncomment this rule to change the default. #SecAction \ # "id:900240,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # 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/'" # Forbidden request headers. # Header names should be lowercase, enclosed by /slashes/ as delimiters. # Blocking Proxy header prevents 'httpoxy' vulnerability: https://httpoxy.org # Default: /proxy/ /lock-token/ /content-range/ /translate/ /if/ # Uncomment this rule to change the default. #SecAction \ # "id:900250,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.restricted_headers=/proxy/ /lock-token/ /content-range/ /translate/ /if/'" # File extensions considered static files. # Extensions include the dot, lowercase, enclosed by /slashes/ as delimiters. # Used in DoS protection rule. See section "Anti-Automation / DoS Protection". # Default: /.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/ # Uncomment this rule to change the default. #SecAction \ # "id:900260,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.static_extensions=/.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/'" # # -- [[ HTTP Argument/Upload Limits ]] ----------------------------------------- # # Here you can define optional limits on HTTP get/post parameters and uploads. # This can help to prevent application specific DoS attacks. # # These values are checked in REQUEST-920-PROTOCOL-ENFORCEMENT.conf. # Beware of blocking legitimate traffic when enabling these limits. # # Block request if number of arguments is too high # Default: unlimited # Example: 255 # Uncomment this rule to set a limit. #SecAction \ # "id:900300,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.max_num_args=255" # Block request if the length of any argument name is too high # Default: unlimited # Example: 100 # Uncomment this rule to set a limit. #SecAction \ # "id:900310,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.arg_name_length=100" # Block request if the length of any argument value is too high # Default: unlimited # Example: 400 # Uncomment this rule to set a limit. #SecAction \ # "id:900320,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.arg_length=400" # Block request if the total length of all combined arguments is too high # Default: unlimited # Example: 64000 # Uncomment this rule to set a limit. #SecAction \ # "id:900330,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.total_arg_length=64000" # Block request if the file size of any individual uploaded file is too high # Default: unlimited # Example: 1048576 # Uncomment this rule to set a limit. #SecAction \ # "id:900340,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.max_file_size=1048576" # Block request if the total size of all combined uploaded files is too high # Default: unlimited # Example: 1048576 # Uncomment this rule to set a limit. #SecAction \ # "id:900350,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.combined_file_sizes=1048576" # # -- [[ Easing In / Sampling Percentage ]] ------------------------------------- # # Adding the Core Rule Set to an existing productive site can lead to false # positives, unexpected performance issues and other undesired side effects. # # It can be beneficial to test the water first by enabling the CRS for a # limited number of requests only and then, when you have solved the issues (if # any) and you have confidence in the setup, to raise the ratio of requests # being sent into the ruleset. # # Adjust the percentage of requests that are funnelled into the Core Rules by # setting TX.sampling_percentage below. The default is 100, meaning that every # request gets checked by the CRS. The selection of requests, which are going # to be checked, is based on a pseudo random number generated by ModSecurity. # # If a request is allowed to pass without being checked by the CRS, there is no # entry in the audit log (for performance reasons), but an error log entry is # written. If you want to disable the error log entry, then issue the # following directive somewhere after the inclusion of the CRS # (E.g., RESPONSE-999-EXCEPTIONS.conf). # # SecRuleUpdateActionById 901150 "nolog" # # ATTENTION: If this TX.sampling_percentage is below 100, then some of the # requests will bypass the Core Rules completely and you lose the ability to # protect your service with ModSecurity. # # Uncomment this rule to enable this feature: # #SecAction "id:900400,\ # phase:1,\ # pass,\ # nolog,\ # setvar:tx.sampling_percentage=100" # # -- [[ Project Honey Pot HTTP Blacklist ]] ------------------------------------ # # Optionally, you can check the client IP address against the Project Honey Pot # HTTPBL (dnsbl.httpbl.org). In order to use this, you need to register to get a # free API key. Set it here with SecHttpBlKey. # # Project Honeypot returns multiple different malicious IP types. # You may specify which you want to block by enabling or disabling them below. # # Ref: https://www.projecthoneypot.org/httpbl.php # Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecHttpBlKey # # Uncomment these rules to use this feature: # #SecHttpBlKey XXXXXXXXXXXXXXXXX #SecAction "id:900500,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.block_search_ip=1,\ # setvar:tx.block_suspicious_ip=1,\ # setvar:tx.block_harvester_ip=1,\ # setvar:tx.block_spammer_ip=1" # # -- [[ GeoIP Database ]] ------------------------------------------------------ # # There are some rulesets that inspect geolocation data of the client IP address # (geoLookup). The CRS uses geoLookup to implement optional country blocking. # # To use geolocation, we make use of the MaxMind GeoIP database. # This database is not included with the CRS and must be downloaded. # You should also update the database regularly, for instance every month. # The CRS contains a tool to download it to util/geo-location/GeoIP.dat: # util/upgrade.py --geoip # # This product includes GeoLite data created by MaxMind, available from: # http://www.maxmind.com. # # 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 # # Uncomment this rule to use this feature: # #SecGeoLookupDB util/geo-location/GeoIP.dat # # -=[ Block Countries ]=- # # Rules in the IP Reputation file can check the client against a list of high # risk country codes. These countries have to be defined in the variable # tx.high_risk_country_codes via their ISO 3166 two-letter country code: # https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements # # If you are sure that you are not getting any legitimate requests from a given # country, then you can disable all access from that country via this variable. # The rule performing the test has the rule id 910100. # # This rule requires SecGeoLookupDB to be enabled and the GeoIP database to be # downloaded (see the section "GeoIP Database" above.) # # By default, the list is empty. A list used by some sites was the following: # setvar:'tx.high_risk_country_codes=UA ID YU LT EG RO BG TR RU PK MY CN'" # # Uncomment this rule to use this feature: # #SecAction \ # "id:900600,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.high_risk_country_codes='" # # -- [[ Anti-Automation / DoS Protection ]] ------------------------------------ # # Optional DoS protection against clients making requests too quickly. # # When a client is making more than 100 requests (excluding static files) within # 60 seconds, this is considered a 'burst'. After two bursts, the client is # blocked for 600 seconds. # # Requests to static files are not counted towards DoS; they are listed in the # 'tx.static_extensions' setting, which you can change in this file (see # section "HTTP Policy Settings"). # # For a detailed description, see rule file REQUEST-912-DOS-PROTECTION.conf. # # Uncomment this rule to use this feature: # #SecAction \ # "id:900700,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:'tx.dos_burst_time_slice=60',\ # setvar:'tx.dos_counter_threshold=100',\ # setvar:'tx.dos_block_timeout=600'" # # -- [[ Check UTF-8 encoding ]] ------------------------------------------------ # # The CRS can optionally check request contents for invalid UTF-8 encoding. # 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 rule to use this feature: # #SecAction \ # "id:900950,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.crs_validate_utf8_encoding=1" # # -- [[ Blocking Based on IP Reputation ]] ------------------------------------ # # Blocking based on reputation is permanent in the CRS. Unlike other rules, # which look at the indvidual request, the blocking of IPs is based on # a persistent record in the IP collection, which remains active for a # certain amount of time. # # There are two ways an individual client can become flagged for blocking: # - External information (RBL, GeoIP, etc.) # - Internal information (Core Rules) # # The record in the IP collection carries a flag, which tags requests from # individual clients with a flag named IP.reput_block_flag. # But the flag alone is not enough to have a client blocked. There is also # a global switch named tx.do_reput_block. This is off by default. If you set # it to 1 (=On), requests from clients with the IP.reput_block_flag will # be blocked for a certain duration. # # Variables # ip.reput_block_flag Blocking flag for the IP collection record # ip.reput_block_reason Reason (= rule message) that caused to blocking flag # tx.do_reput_block Switch deciding if we really block based on flag # tx.reput_block_duration Setting to define the duration of a block # # It may be important to know, that all the other core rules are skipped for # requests, when it is clear that they carry the blocking flag in question. # # Uncomment this rule to use this feature: # #SecAction \ # "id:900960,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.do_reput_block=1" # # Uncomment this rule to change the blocking time: # Default: 300 (5 minutes) # #SecAction \ # "id:900970,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.reput_block_duration=300" # # -- [[ Collection timeout ]] -------------------------------------------------- # # Set the SecCollectionTimeout directive from the ModSecurity default (1 hour) # to a lower setting which is appropriate to most sites. # This increases performance by cleaning out stale collection (block) entries. # # This value should be greater than or equal to: # tx.reput_block_duration (see section "Blocking Based on IP Reputation") and # tx.dos_block_timeout (see section "Anti-Automation / DoS Protection"). # # Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecCollectionTimeout # Please keep this directive uncommented. # Default: 600 (10 minutes) SecCollectionTimeout 600 # # -- [[ Debug Mode ]] ---------------------------------------------------------- # # To enable rule development and debugging, CRS has an optional debug mode # that does not block a request, but instead sends detection information # back to the HTTP client. # # This functionality is currently only supported with the Apache web server. # The Apache mod_headers module is required. # # In debug mode, the webserver inserts "X-WAF-Events" / "X-WAF-Score" # response headers whenever a debug client makes a request. Example: # # # curl -v 'http://192.168.1.100/?foo=../etc/passwd' # X-WAF-Events: TX:930110-OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL-REQUEST_URI, # TX:930120-OWASP_CRS/WEB_ATTACK/FILE_INJECTION-ARGS:foo, # TX:932160-OWASP_CRS/WEB_ATTACK/RCE-ARGS:foo # X-WAF-Score: Total=15; sqli=0; xss=0; rfi=0; lfi=10; rce=5; php=0; http=0; ses=0 # # To enable debug mode, include the RESPONSE-981-DEBUG.conf file. # This file resides in a separate folder, as it is not compatible with # nginx and IIS. # # You must specify the source IP address/network where you will be running the # tests from. The source IP will BYPASS all CRS blocking, and will be sent the # response headers as specified above. Be careful to only list your private # IP addresses/networks here. # # Tip: for regression testing of CRS or your own ModSecurity rules, you may # be interested in using the OWASP CRS regression testing suite instead. # View the file util/regression-tests/README for more information. # # Uncomment these rules, filling in your CRS path and the source IP address, # to enable debug mode: # #Include /path/to/crs/util/debug/RESPONSE-981-DEBUG.conf #SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \ # "id:900980,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # ctl:ruleEngine=DetectionOnly,\ # setvar:tx.crs_debug_mode=1" # # -- [[ End of setup ]] -------------------------------------------------------- # # The CRS checks the tx.crs_setup_version variable to ensure that the setup # has been loaded. If you are not planning to use this setup template, # you must manually set the tx.crs_setup_version variable before including # the CRS rules/* files. # # The variable is a numerical representation of the CRS version number. # E.g., v3.0.0 is represented as 300. # SecAction \ "id:900990,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_setup_version=302"