Gecko [ georgetownmover.com ]

Name	Size	Permission	Date
REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf	7.48 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-901-INITIALIZATION.conf	13.58 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf	13.31 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf	25.28 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf	10.46 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9004-DOKUWIKI-EXCLUSION-RULES.conf	7.71 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9005-CPANEL-EXCLUSION-RULES.conf	1.9 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-903.9006-XENFORO-EXCLUSION-RULES.conf	17.97 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-905-COMMON-EXCEPTIONS.conf	1.59 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-910-IP-REPUTATION.conf	10.16 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-911-METHOD-ENFORCEMENT.conf	2.62 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-912-DOS-PROTECTION.conf	10.42 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-913-SCANNER-DETECTION.conf	6.97 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-920-PROTOCOL-ENFORCEMENT.conf	53.07 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-921-PROTOCOL-ATTACK.conf	16.41 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-922-MULTIPART-ATTACK.conf	4.38 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-930-APPLICATION-ATTACK-LFI.conf	5.89 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-931-APPLICATION-ATTACK-RFI.conf	5.62 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-932-APPLICATION-ATTACK-RCE.conf	53.59 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-933-APPLICATION-ATTACK-PHP.conf	31.93 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-934-APPLICATION-ATTACK-NODEJS.conf	3.9 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-941-APPLICATION-ATTACK-XSS.conf	39.52 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-942-APPLICATION-ATTACK-SQLI.conf	68.87 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf	5.16 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-944-APPLICATION-ATTACK-JAVA.conf	15 KB	-rw-r--r--	2023-08-02 10:15
REQUEST-949-BLOCKING-EVALUATION.conf	4.07 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-950-DATA-LEAKAGES.conf	4.67 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-951-DATA-LEAKAGES-SQL.conf	17.55 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-952-DATA-LEAKAGES-JAVA.conf	3.5 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-953-DATA-LEAKAGES-PHP.conf	4.91 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-954-DATA-LEAKAGES-IIS.conf	5.7 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-959-BLOCKING-EVALUATION.conf	4.18 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-980-CORRELATION.conf	6.71 KB	-rw-r--r--	2023-08-02 10:15
RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf	3 KB	-rw-r--r--	2023-08-02 10:15
crawlers-user-agents.data	786 B	-rw-r--r--	2023-08-02 10:15
iis-errors.data	551 B	-rw-r--r--	2023-08-02 10:15
java-classes.data	933 B	-rw-r--r--	2023-08-02 10:15
java-code-leakages.data	264 B	-rw-r--r--	2023-08-02 10:15
java-errors.data	240 B	-rw-r--r--	2023-08-02 10:15
lfi-os-files.data	30.48 KB	-rw-r--r--	2023-08-02 10:15
php-config-directives.data	5.28 KB	-rw-r--r--	2023-08-02 10:15
php-errors.data	8.99 KB	-rw-r--r--	2023-08-02 10:15
php-function-names-933150.data	683 B	-rw-r--r--	2023-08-02 10:15
php-function-names-933151.data	20.78 KB	-rw-r--r--	2023-08-02 10:15
php-variables.data	224 B	-rw-r--r--	2023-08-02 10:15
restricted-files.data	2 KB	-rw-r--r--	2023-08-02 10:15
restricted-upload.data	390 B	-rw-r--r--	2023-08-02 10:15
scanners-headers.data	216 B	-rw-r--r--	2023-08-02 10:15
scanners-urls.data	418 B	-rw-r--r--	2023-08-02 10:15
scanners-user-agents.data	4.75 KB	-rw-r--r--	2023-08-02 10:15
scripting-user-agents.data	717 B	-rw-r--r--	2023-08-02 10:15
sql-errors.data	1.85 KB	-rw-r--r--	2023-08-02 10:15
unix-shell.data	1.35 KB	-rw-r--r--	2023-08-02 10:15
windows-powershell-commands.data	3.83 KB	-rw-r--r--	2023-08-02 10:15

Rename

# ------------------------------------------------------------------------
# OWASP ModSecurity Core Rule Set ver.3.3.5
# Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved.
# Copyright (c) 2021-2023 Core Rule Set project. 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.
# ------------------------------------------------------------------------

#
# The purpose of this file is to hold LOCAL exceptions for your site.  The
# types of rules that would go into this file are one where you want to
# short-circuit inspection and allow certain transactions to pass through
# inspection or if you want to alter rules that are applied.
#
# This file is named REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example for a
# very specific reason. Files affixed with the .example extension are designed
# to contain user created/modified data. The '.example'. extension should be
# renamed to end in .conf. The advantage of this is that when OWASP CRS is
# updated, the updates will not overwrite a user generated configuration file.
#
# As a result of this design paradigm users are encouraged NOT to directly
# modify rules. Instead they should use this
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS and the
# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS file to modify OWASP rules using
# methods similar to the examples specified below.
#
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS and
# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS serve different purposes. ModSecurity
# effectively maintains two different context: startup, and per transaction.
# As a rule, directives are processed within the startup context. While they
# can affect the per transaction context they generally remain fixed during the
# execution of ModSecurity.
#
# As a result if one wanted to disable a rule at bootup the SecRuleRemoveById
# directive or one of its siblings would have to be placed AFTER the rule is
# listed, otherwise it will not have knowledge of the rules existence (since
# these rules are read in at the same time). This means that when using
# directives that effect SecRules, these exceptions should be placed AFTER all
# the existing rules. This is why RESPONSE-999-EXCLUSION-RULES-AFTER-CRS is
# designed such that it loads LAST.
#
# Conversely, ModSecurity supports several actions that can change the state of
# the underlying configuration during the per transaction context, this is when
# rules are being processed. Generally, these are accomplished by using the
# 'ctl' action. As these are part of a rule, they will be evaluated in the
# order rules are applied (by physical location, considering phases). As a
# result of this ordering a 'ctl' action should be placed with consideration to
# when it will be executed. This is particularly relevant for the 'ctl' options
# that involve modifying ID's (such as ruleRemoveById). In these cases it is
# important that such rules are placed BEFORE the rule ID they will affect.
# Unlike the setup context, by the time we process rules in the per-transaction
# context, we are already aware of all the rule ID's. It is by this logic that
# we include rules such as this BEFORE all the remaining rules.  As a result
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS is designed to load FIRST.
#
# As a general rule:
# ctl:ruleEngine            -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveById        -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveByMsg       -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveByTag       -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetById  -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetByMsg -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetByTag -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
#
# SecRuleRemoveById         -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleRemoveByMsg        -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleRemoveByTag        -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateActionById   -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetById   -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetByMsg  -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetByTag  -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
#
#
# What follows are a group of examples that show you how to perform rule
# exclusions.
#
#
# Example Exclusion Rule: Disable inspection for an authorized client
#
# This ruleset allows you to control how ModSecurity will handle traffic
# originating from Authorized Vulnerability Scanning (AVS) sources.  See
# related blog post -
# http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-authorized-scanning-traffic.html
#
# White-list ASV network block (no blocking or logging of AVS traffic) Update
# IP network block as appropriate for your AVS traffic
#
# ModSec Rule Exclusion: Disable Rule Engine for known ASV IP
# SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
#     "id:1000,\
#     phase:1,\
#     pass,\
#     nolog,\
#     ctl:ruleEngine=Off"
#
#
# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
#                         for an individual rule
#
# This rule shows how to conditionally exclude the "password"
# parameter for rule 942100 when the REQUEST_URI is /index.php
# ModSecurity Rule Exclusion: 942100 SQL Injection Detected via libinjection
#
# SecRule REQUEST_URI "@beginsWith /index.php" \
#     "id:1001,\
#     phase:1,\
#     pass,\
#     nolog,\
#     ctl:ruleRemoveTargetById=942100;ARGS:password"
#
#
# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
#                         for only certain attacks
#
# Attack rules within the CRS are tagged, with tags such as 'attack-lfi',
# 'attack-sqli', 'attack-xss', 'attack-injection-php', et cetera.
#
# ModSecurity Rule Exclusion: Disable inspection of ARGS:pwd
#                             for all rules tagged attack-sqli
# SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \
#     "id:1002,\
#     phase:2,\
#     pass,\
#     nolog,\
#     ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:pwd"
#

# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
#                         for all CRS rules
#
# This rule illustrates that we can use tagging very effectively to whitelist a
# common false positive across an entire ModSecurity instance. This can be done
# because every rule in OWASP_CRS is tagged with OWASP_CRS. This will NOT
# affect custom rules.
#
# ModSecurity Rule Exclusion: Disable inspection of ARGS:pwd
#                             for all CRS rules
# SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \
#     "id:1003,\
#     phase:2,\
#     pass,\
#     nolog,\
#     ctl:ruleRemoveTargetByTag=OWASP_CRS;ARGS:pwd"

#
# Example Exclusion Rule: Removing a range of rules
#
# This rule illustrates that we can remove a rule range via a ctl action.
# This uses the fact, that rules are grouped by topic in rule files covering
# a certain id range.
#
# ModSecurity Rule Exclusion: Disable all SQLi and XSS rules
# SecRule REQUEST_FILENAME "@beginsWith /admin" \
#     "id:1004,\
#     phase:2,\
#     pass,\
#     nolog,\
#     ctl:ruleRemoveById=941000-942999"
#
#
# The application specific rule exclusion files
# REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
# REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
# bring additional examples which can be useful then tuning a service.