Elgato_dark/bunkerweb
1
0
Fork 0
mirror of https://github.com/bunkerity/bunkerweb synced 2026-05-24 09:28:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

chore: remove documentation and GitHub workflows for coreruleset v3 and v4

Browse source
This commit is contained in:
Théophile Diot 2024-11-20 11:12:00 +01:00
parent 774c1a697e
commit e8fd630c1c
No known key found for this signature in database
GPG key ID: FA995104A0BA376A
27 changed files with 2 additions and 2596 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
src/common/core/modsecurity/files/coreruleset-v3/.github/ISSUE_TEMPLATE/01_false-positive.md vendored
View file

@ -1,34 +0,0 @@
---
name: 'False positive'
about: Report a false positive (incorrect blocking)
title: ''
labels: 'False Positive'
assignees: ''
---
### Description
<!-- Please provide a copy of the audit log entry. You can usually -->
<!-- find this at /var/log/modsec_audit.log. -->
<!-- Include any relevant CVEs or research links. -->
### Audit Logs / Triggered Rule Numbers
<!-- Everything you can provide about a blocked request/response -->
<!-- or, at least, a list of triggered CRS rule numbers. -->
### Your Environment
<!-- Include as many relevant details about the environment you -->
<!-- experienced the bug in: -->
* CRS version (e.g., v3.2.0):
* Paranoia level setting:
* ModSecurity version (e.g., 2.9.3):
* Web Server and version (e.g., apache 2.4.41):
* Operating System and version:
### Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

33
src/common/core/modsecurity/files/coreruleset-v3/.github/ISSUE_TEMPLATE/02_false-negative.md vendored
View file

@ -1,33 +0,0 @@
---
name: 'False negative'
about: Report a false negative (incorrect bypass)
title: ''
labels: 'False Negative - Evasion'
assignees: ''
---
### Description
<!-- Please provide the payload you are sending. For complex payloads -->
<!-- with headers, please include a curl command. -->
<!-- Include any relevant CVEs or research links. -->
<!-- If the bypass works in paranoia level 4, please consider sending -->
<!-- us an email instead. See -->
<!-- https://github.com/SpiderLabs/owasp-modsecurity-crs/security/policy -->
<!-- for details. -->
### Your Environment
<!-- Include as many relevant details about the environment you -->
<!-- experienced the bug in: -->
* CRS version (e.g., v3.2.0):
* Paranoia level setting:
* ModSecurity version (e.g., 2.9.3):
* Web Server and version (e.g., apache 2.4.41):
* Operating System and version:
### Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

39
src/common/core/modsecurity/files/coreruleset-v3/.github/ISSUE_TEMPLATE/03_bug-report.md vendored
View file

@ -1,39 +0,0 @@
---
name: '🐞 Bug report'
about: Create a report to help us improve
title: ''
labels: 'Bug'
assignees: ''
---
### Describe the bug
<!-- A clear and concise description of what the bug is. -->
### Steps to reproduce
<!-- Include steps that will help us recreate the issue. -->
### Expected behaviour
<!-- A clear and concise description of what you expected to happen. -->
### Actual behaviour
<!-- A clear and concise description of what actually happened. -->
<!-- If applicable, add screenshots to help explain your problem. -->
### Additional context
<!-- Add any other context about the problem here. -->
### Your Environment
<!-- Include as many relevant details about the environment you -->
<!-- experienced the bug in: -->
* CRS version (e.g., v3.2.0):
* Paranoia level setting:
* ModSecurity version (e.g., 2.9.3):
* Web Server and version (e.g., apache 2.4.41):
* Operating System and version:

28
src/common/core/modsecurity/files/coreruleset-v3/.github/ISSUE_TEMPLATE/04_feature.md vendored
View file

@ -1,28 +0,0 @@
---
name: '🚀 Feature request'
about: Suggest an idea for this project
title: ''
labels: 'Feature Request'
assignees: ''
---
### Motivation
<!-- A clear and concise description of what the motivation for the -->
<!-- new feature is, and what problem it is solving. -->
### Proposed solution
<!-- A clear and concise description of the feature you would like -->
<!-- to add, and how it solves the motivating problem. -->
### Alternatives
<!-- A clear and concise description of any alternative solutions -->
<!-- or features you've considered, and why you're proposed solution is -->
<!-- better. -->
### Additional context
<!-- Add any other context or screenshots about the feature request -->
<!-- here. -->

8
src/common/core/modsecurity/files/coreruleset-v3/.github/ISSUE_TEMPLATE/config.yml vendored
View file

@ -1,8 +0,0 @@
blank_issues_enabled: false
contact_links:
- name: Help and support
url: https://security.stackexchange.com/questions/tagged/owasp-crs
about: For help and support please go here.
- name: OWASP Core Rule Set mailing list
url: https://groups.google.com/a/owasp.org/forum/#!forum/modsecurity-core-rule-set-project
about: Ask general usage questions and participate in discussions on the CRS.

37
src/common/core/modsecurity/files/coreruleset-v3/.github/workflows/lint.yaml vendored
View file

@ -1,37 +0,0 @@
---
name: Lint
on: [push, pull_request]
jobs:
check-syntax:
runs-on: ubuntu-latest
strategy:
fail-fast: true
# check why is failing and change afterwards
steps:
- name: Checkout repo
uses: actions/checkout@v2
- name: Lint Yaml
uses: ibiqlik/action-yamllint@v3
with:
format: github
file_or_dir: tests/regression/tests
config_file: .yamllint.yml
- name: Linelint
uses: fernandrone/linelint@master
id: linelint
- name: Set up Python 3
uses: actions/setup-python@v2
with:
python-version: 3.7
- name: "Check CRS syntax"
run: |
pip install --upgrade setuptools
pip install secrules-parsing
secrules-parser -c --output-type github -f rules/*.conf

19
src/common/core/modsecurity/files/coreruleset-v3/.github/workflows/stale.yml vendored
View file

@ -1,19 +0,0 @@
name: Mark stale issues
on:
schedule:
- cron: "0 0 * * *"
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v1
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
stale-issue-message: 'This issue has been open 120 days with no activity. Remove the stale label or comment, or this will be closed in 14 days'
stale-issue-label: 'Stale issue'
days-before-stale: 120
days-before-close: 14

58
src/common/core/modsecurity/files/coreruleset-v3/.github/workflows/test.yml vendored
View file

@ -1,58 +0,0 @@
---
name: Regression Tests
on:
push:
paths:
- 'rules/**'
- 'tests/**'
- '.github/**'
pull_request:
paths:
- 'rules/**'
- 'tests/**'
- '.github/**'
jobs:
regression:
runs-on: ubuntu-latest
strategy:
matrix:
modsec_version: [modsec2-apache]
steps:
- name: "Checkout repo"
uses: actions/checkout@v4
- name: "Install dependencies"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GO_FTW_VERSION: '0.4.6'
run: |
gh release download -R coreruleset/go-ftw v${GO_FTW_VERSION} -p "ftw_${GO_FTW_VERSION}_linux_amd64.tar.gz" -O - | tar -xzvf - ftw
- name: "Run tests for ${{ matrix.modsec_version }}"
env:
FTW_LOGFILE: './tests/logs/${{ matrix.modsec_version }}/error.log'
run: |
mkdir -p "tests/logs/${{ matrix.modsec_version }}"
docker compose -f ./tests/docker-compose.yml up -d "${{ matrix.modsec_version }}"
docker compose -f ./tests/docker-compose.yml logs
[ $(docker inspect ${{ matrix.modsec_version }} --format='{{.State.Running}}') = 'true' ]
./ftw check -d tests/regression/tests
./ftw run -d tests/regression/tests --show-failures-only
- name: "Change permissions if failed"
if: failure()
run: |
# we want to get the audit log, so change permissions (file is only for root on docker)
sudo chmod 644 tests/logs/${{ matrix.modsec_version }}/modsec_audit.log
- uses: actions/upload-artifact@v4
if: failure()
with:
name: waf-logs
path: tests/logs/${{ matrix.modsec_version }}
- name: Clean docker-compose
run: |
docker compose -f ./tests/docker-compose.yml down -t 0

877
src/common/core/modsecurity/files/coreruleset-v3/crs-setup.conf.example vendored
View file

@ -1,877 +0,0 @@
# ------------------------------------------------------------------------
# OWASP ModSecurity Core Rule Set ver.3.3.7
# Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved.
# Copyright (c) 2021-2024 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.
# ------------------------------------------------------------------------
#
# -- [[ 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://coreruleset.org/
# 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. It is bundled with
# ModSecurity. If you don't have it, you can get it from:
# 2.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v2/master/modsecurity.conf-recommended
# 3.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/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-EXCLUSION-RULES-AFTER-CRS.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-EXCLUSION-RULES-AFTER-CRS.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 that will add to your anomaly scores.
#
# 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.
#
# All rules 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.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.
#
# Uncomment this rule to change the default:
#
#SecAction \
# "id:900000,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.paranoia_level=1"
# It is possible to execute rules from a higher paranoia level but not include
# them in the anomaly scoring. This allows you to take a well-tuned system on
# paranoia level 1 and add rules from paranoia level 2 without having to fear
# the new rules would lead to false positives that raise your score above the
# threshold.
# This optional feature is enabled by uncommenting the following rule and
# setting the tx.executing_paranoia_level.
# Technically, rules up to the level defined in tx.executing_paranoia_level
# will be executed, but only the rules up to tx.paranoia_level affect the
# anomaly scores.
# By default, tx.executing_paranoia_level is set to tx.paranoia_level.
# tx.executing_paranoia_level must not be lower than tx.paranoia_level.
#
# Please notice that setting tx.executing_paranoia_level to a higher paranoia
# level results in a performance impact that is equally high as setting
# tx.paranoia_level to said level.
#
#SecAction \
# "id:900001,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.executing_paranoia_level=1"
#
# -- [[ Enforce Body Processor URLENCODED ]] -----------------------------------
#
# ModSecurity selects the body processor based on the Content-Type request
# header. But clients are not always setting the Content-Type header for their
# request body payloads. This will leave ModSecurity with limited vision into
# the payload. The variable tx.enforce_bodyproc_urlencoded lets you force the
# URLENCODED body processor in these situations. This is off by default, as it
# implies a change of the behaviour of ModSecurity beyond CRS (the body
# processor applies to all rules, not only CRS) and because it may lead to
# false positives already on paranoia level 1. However, enabling this variable
# closes a possible bypass of CRS so it should be considered.
#
# Uncomment this rule to change the default:
#
#SecAction \
# "id:900010,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.enforce_bodyproc_urlencoded=1"
#
# -- [[ 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:tx.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_cpanel=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=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/json|
#
# Please note, that the rule where CRS uses this variable (920420) evaluates it with operator
# `@within`, which is case sensitive, but uses t:lowercase. You must add your whole custom
# Content-Type with lowercase.
#
# Bypass Warning: some applications may not rely on the content-type request header in order
# to parse the request body. This could make an attacker able to send malicious URLENCODED/JSON/XML
# payloads without being detected by the WAF. Allowing request content-type that doesn't activate any
# body processor (for example: "text/plain", "application/x-amf", "application/octet-stream", etc..)
# could lead to a WAF bypass. For example, a malicious JSON payload submitted with a "text/plain"
# content type may still be interpreted as JSON by a backend application but would not trigger the
# JSON body parser at the WAF, leading to a bypass.
#
# When additional JSON content types are legitimately used in a deployment,
# e.g. application/cloudevents+json, it is extremely important to ensure that a
# rule exists to enable the engine's JSON body processor for these additional
# JSON content types. Failure to do so can lead to a request body bypass. The
# default JSON rule in modsecurity.conf-recommended (200001) will only activate
# the JSON body processor for the specific content type application/json. The
# optional modsecurity.conf-recommended rule 200006 can be used to enable the
# JSON body processor for a wide variety of JSON content types.
#
# To prevent blocking request with not allowed content-type by default, you can create an exclusion
# rule that removes rule 920420. For example:
# SecRule REQUEST_HEADERS:Content-Type "@rx ^text/plain" \
# "id:1234,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# ctl:ruleRemoveById=920420,\
# chain"
# SecRule REQUEST_URI "@rx ^/foo/bar" "t:none"
#
# 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/json|'"
# 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/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/
# Example: .bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .rdb/ .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/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/'"
# Forbidden request headers.
# Header names should be lowercase, enclosed by /slashes/ as delimiters.
# Default: /accept-charset/ /content-encoding/ /proxy/ /lock-token/ /content-range/ /if/
#
# Note: Accept-Charset is a deprecated header that should not be used by clients and
# ignored by servers. It can be used for a response WAF bypass, by asking for a charset
# that the WAF cannot decode.
# Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset
#
# Note: Content-Encoding is used to list any encodings that have been applied to the
# original payload. It is only used for compression, which isn't supported by CRS by
# default since it blocks newlines and null bytes inside the request body. Most
# compression algorithms require at least null bytes per RFC. Blocking it shouldn't
# break anything and increases security since ModSecurity is incapable of properly
# scanning compressed request bodies.
#
# Note: Blocking Proxy header prevents 'httpoxy' vulnerability: https://httpoxy.org
#
# Uncomment this rule to change the default.
#SecAction \
# "id:900250,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:'tx.restricted_headers=/accept-charset/ /content-encoding/ /proxy/ /lock-token/ /content-range/ /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/'"
# Content-Types charsets that a client is allowed to send in a request.
# Default: utf-8|iso-8859-1|iso-8859-15|windows-1252
# Uncomment this rule to change the default.
# Use "|" to separate multiple charsets like in the rule defining
# tx.allowed_request_content_type.
#SecAction \
# "id:900280,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:'tx.allowed_request_content_type_charset=utf-8|iso-8859-1|iso-8859-15|windows-1252'"
#
# -- [[ 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-EXCLUSION-RULES-AFTER-CRS.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.
#
# There are two formats for the GeoIP database. ModSecurity v2 uses GeoLite (.dat files),
# and ModSecurity v3 uses GeoLite2 (.mmdb files).
#
# If you use ModSecurity 3, MaxMind provides a binary for updating GeoLite2 files,
# see https://github.com/maxmind/geoipupdate.
#
# Download the package for your OS, and read https://dev.maxmind.com/geoip/geoipupdate/
# for configuration options.
#
# Warning: GeoLite (not GeoLite2) databases are considered legacy, and not being updated anymore.
# See https://support.maxmind.com/geolite-legacy-discontinuation-notice/ for more info.
#
# Therefore, if you use ModSecurity v2, you need to regenerate updated .dat files
# from CSV files first.
#
# You can achieve this using https://github.com/sherpya/geolite2legacy
# Pick the zip files from maxmind site:
# https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip
#
# Follow the guidelines for installing the tool and run:
# ./geolite2legacy.py -i GeoLite2-Country-CSV.zip \
# -f geoname2fips.csv -o /usr/share/GeoliteCountry.dat
#
# Update the database regularly, see Step 3 of the configuration link above.
#
# By default, when you execute `sudo geoipupdate` on Linux, files from the free database
# will be downloaded to `/usr/share/GeoIP` (both v1 and v2).
#
# Then choose from:
# - `GeoLite2-Country.mmdb` (if you are using ModSecurity v3)
# - `GeoLiteCountry.dat` (if you are using ModSecurity v2)
#
# 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 only one of the next rules here to use this feature.
# Choose the one depending on the ModSecurity version you are using, and change the path accordingly:
#
# For ModSecurity v3:
#SecGeoLookupDB /usr/share/GeoIP/GeoLite2-Country.mmdb
# For ModSecurity v2 (points to the converted one):
#SecGeoLookupDB /usr/share/GeoIP/GeoLiteCountry.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 individual 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
#
# -- [[ 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,\
pass,\
t:none,\
nolog,\
setvar:tx.crs_setup_version=337"

8
src/common/core/modsecurity/files/coreruleset-v3/docs/README vendored
View file

@ -1,8 +0,0 @@
Welcome to the OWASP Core Rule Set (CRS) documentation.
The OWASP CRS documentation is generated as a Sphinx project and is stored in a separate Github repository. While the documentation is available as part of the CRS project it is provided in the form of a git-submodule. Using a git-submodule allow us to update the documentation without making changes to the main rule repository.
You can download the documentation using git:
$ git submodule init
$ git submodule update
Alternatively, the latest version of the documentation is available at https://www.modsecurity.org/CRS/Documentation/

1
src/common/core/modsecurity/files/coreruleset-v4/.github/FUNDING.yml vendored
View file

@ -1 +0,0 @@
custom: https://coreruleset.org/donate

71
src/common/core/modsecurity/files/coreruleset-v4/.github/ISSUE_TEMPLATE/01_false-positive.md vendored
View file

@ -1,71 +0,0 @@
---
name: 'False positive'
about: Report a false positive (blocking of benign traffic)
title: ''
labels: ':heavy_plus_sign: False Positive'
assignees: ''
---
<!--
Please do not open issues for help and support running ModSecurity or the
OWASP Core Rule Set. Instead, use one of the following channels to reach
our project:
* https://security.stackexchange.com/questions/tagged/owasp-crs
* https://twitter.com/coreruleset
* https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
* https://owasp.org/slack/invite (-> Channel #coreruleset)
-->
### Description
<!--
We want to be able to understand and to reproduce your problem. Please describe
it here in detail.
It is safest if you assume we know nothing about your service or software.
-->
### How to reproduce the misbehavior (-> curl call)
<!--
It is easiest for us, if you submit a curl request that triggers your problem.
If you can not do this, then please skip this section but be sure to fill out
the next one in detail.
Please test your curl call against the CRS Sandbox before submitting.
https://coreruleset.org/docs/development/sandbox/
-->
### Logs
<!--
Feel free to skip this section if you provided a curl call above.
Ideally, you provide a full audit log of the request, relevant infos out of
the error log or at least a screenshot where we can see the payload so we
can reproduce the behavior.
Usually, you find the logs at a location like /var/log/modsec_audit.log.
When using a CDN or cloud server, the naming of the logs and their location
depends on the provider. Please refer to their documentation.
If you cannot submit neither curl call nor log files nor a payload to reproduce
the behavior, there is litterally nothing we can do for you. Please help us to
get access to the information we need to help you.
-->
### Your Environment
<!-- Please provide all relevant information about your environment. -->
* CRS version (e.g., v3.3.4):
* Paranoia level setting (e.g. PL1) :
* ModSecurity version (e.g., 2.9.6):
* Web Server and version or cloud provider / CDN (e.g., Apache httpd 2.4.54):
* Operating System and version:
### Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

71
src/common/core/modsecurity/files/coreruleset-v4/.github/ISSUE_TEMPLATE/02_false-negative.md vendored
View file

@ -1,71 +0,0 @@
---
name: 'False negative'
about: Report a false negative (ignoring of malicious traffic)
title: ''
labels: ':heavy_minus_sign: False Negative - Evasion'
assignees: ''
---
<!--
Please do not open issues for help and support running ModSecurity or the
OWASP Core Rule Set. Instead, use one of the following channels to reach
our project:
* https://security.stackexchange.com/questions/tagged/owasp-crs
* https://twitter.com/coreruleset
* https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
* https://owasp.org/slack/invite (-> Channel #coreruleset)
-->
### Description
<!--
We want to be able to understand and to reproduce your problem. Please describe
it here in detail.
It is safest if you assume we know nothing about your service or software.
-->
### How to reproduce the misbehavior (-> curl call)
<!--
It is easiest for us, if you submit a curl request that triggers your problem.
If you can not do this, then please skip this section but be sure to fill out
the next one in detail.
Please test your curl call against the CRS Sandbox before submitting.
https://coreruleset.org/docs/development/sandbox/
-->
### Logs
<!--
Feel free to skip this section if you provided a curl call above.
Ideally, you provide a full audit log of the request, relevant infos out of
the error log or at least a screenshot where we can see the payload so we
can reproduce the behavior.
Usually, you find the logs at a location like /var/log/modsec_audit.log.
When using a CDN or cloud server, the naming of the logs and their location
depends on the provider. Please refer to their documentation.
If you cannot submit neither curl call nor log files nor a payload to reproduce
the behavior, there is litterally nothing we can do for you. Please help us to
get access to the information we need to help you.
-->
### Your Environment
<!-- Please provide all relevant information about your environment. -->
* CRS version (e.g., v3.3.4):
* Paranoia level setting (e.g. PL1) :
* ModSecurity version (e.g., 2.9.6):
* Web Server and version or cloud provider / CDN (e.g., Apache httpd 2.4.54):
* Operating System and version:
### Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

39
src/common/core/modsecurity/files/coreruleset-v4/.github/ISSUE_TEMPLATE/03_bug-report.md vendored
View file

@ -1,39 +0,0 @@
---
name: '🐞 Bug report'
about: Create a report to help us improve
title: ''
labels: ':bug: bug'
assignees: ''
---
### Describe the bug
<!-- A clear and concise description of what the bug is. -->
### Steps to reproduce
<!-- Include steps that will help us recreate the issue. -->
### Expected behaviour
<!-- A clear and concise description of what you expected to happen. -->
### Actual behaviour
<!-- A clear and concise description of what actually happened. -->
<!-- If applicable, add screenshots to help explain your problem. -->
### Additional context
<!-- Add any other context about the problem here. -->
### Your Environment
<!-- Include as many relevant details about the environment you -->
<!-- experienced the bug in: -->
* CRS version (e.g., v3.2.0):
* Paranoia level setting:
* ModSecurity version (e.g., 2.9.3):
* Web Server and version (e.g., apache 2.4.41):
* Operating System and version:

34
src/common/core/modsecurity/files/coreruleset-v4/.github/ISSUE_TEMPLATE/04_feature.md vendored
View file

@ -1,34 +0,0 @@
---
name: '🚀 Feature request'
about: Suggest an idea for this project
title: ''
labels: ':+1: Feature Request'
assignees: ''
---
<!--
For help and support please go here:
- https://security.stackexchange.com/questions/tagged/owasp-crs
Ask general usage questions and participate in discussions on the CRS:
- https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
-->
### Motivation
<!-- A clear and concise description of what the motivation for the -->
<!-- new feature is, and what problem it is solving. -->
### Proposed solution
<!-- A clear and concise description of the feature you would like -->
<!-- to add, and how it solves the motivating problem. -->
### Alternatives
<!-- A clear and concise description of any alternative solutions -->
<!-- or features you've considered, and why you're proposed solution is -->
<!-- better. -->
### Additional context
<!-- Add any other context or screenshots about the feature request -->
<!-- here. -->

8
src/common/core/modsecurity/files/coreruleset-v4/.github/ISSUE_TEMPLATE/config.yml vendored
View file

@ -1,8 +0,0 @@
blank_issues_enabled: false
contact_links:
- name: Help and support
url: https://security.stackexchange.com/questions/tagged/owasp-crs
about: For help and support please go here.
- name: OWASP Core Rule Set mailing list
url: https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
about: Ask general usage questions and participate in discussions on the CRS.

30
src/common/core/modsecurity/files/coreruleset-v4/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md vendored
View file

@ -1,30 +0,0 @@
## Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
<!-- Github Tip: adding the text 'Fixes #<issue>' or 'Closes #<issue>' will automatically close the mentioned issue. -->
## PR Checklist
<!-- _Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code._ -->
- [ ] I have read the [CONTRIBUTING](https://github.com/coreruleset/coreruleset/blob/v4.0/dev/CONTRIBUTING.md) doc
- [ ] I have added positive tests proving my fix/feature works as intended.
- [ ] I have added negative tests that prove my fix/feature considers common cases that might end in false positives
- [ ] In case you changed a regular expression, you are not adding a ReDOS for pcre. You can check this using [regexploit](https://github.com/doyensec/regexploit)
- [ ] My test use the `comment` field to write the expected behavior
- [ ] I have added documentation for the rule or change (when appropriate)
## Further comments
<!-- If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc... If there are no additional comments, you may remove this section. -->
## For the reviewer
<!-- Don't remove this part. Reviewers will use it as guidance for the review process. -->
- [ ] Positive and negative tests were added
- [ ] Tests cover the intended fix/feature properly
- [ ] No usage of dangerous constructs like `ctl:requestBodyAccess=Off` were used in the rule
- [ ] In case a regular expression was changed, [there is no ReDOS](https://github.com/coreruleset/coreruleset/wiki/Testing-for-Regular-Expresion-DoS)
- [ ] Documentation is clear for the rule/change

28
src/common/core/modsecurity/files/coreruleset-v4/.github/release.yml vendored
View file

@ -1,28 +0,0 @@
# .github/release.yml
changelog:
exclude:
labels:
- ignore-for-release
- release:ignore
authors:
- octocat
- changelog-pr-bot
categories:
- title: ⭐ Important changes
labels:
- release:important
- title: Breaking Changes 🛠
labels:
- Semver-Major
- breaking-change
- release:breaking
- title: 🆕 New features and detections 🎉
labels:
- Semver-Minor
- enhancement
- release:new-detection
- release:new-feature
- title: 🧰 Other Changes
labels:
- "*"

19
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/check-pr-dependencies.yaml vendored
View file

@ -1,19 +0,0 @@
name: Check PR dependencies
on:
pull_request_target:
types:
- opened
- reopened
- edited
- synchronize
jobs:
check_dependencies:
runs-on: ubuntu-latest
name: Check Dependencies
permissions:
pull-requests: read # Reason: To check PRs for dependencies.
steps:
- uses: gregsdennis/dependencies-action@main
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

23
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/check-pr-title.yaml vendored
View file

@ -1,23 +0,0 @@
name: Check PR title
# default token permissions: none
permissions: {}
on:
pull_request_target:
types:
- opened
- reopened
- edited
- synchronize
jobs:
main:
name: Validate PR title
runs-on: ubuntu-latest
permissions:
pull-requests: read
steps:
- uses: amannn/action-semantic-pull-request@e9fabac35e210fea40ca5b14c0da95a099eff26f # v5.4.0
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

123
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/lint.yaml vendored
View file

@ -1,123 +0,0 @@
name: Lint
on:
push:
branches:
- main
- v3.3/dev
- v3.3/master
pull_request:
branches:
- main
- v3.3/dev
- v3.3/master
merge_group:
# Pin versions to not disrupt test pipelines
env:
CRS_TOOLCHAIN_VERSION: '2.1.0'
SECRULES_PARSING_VERSION: '0.2.9'
jobs:
check-syntax:
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.2
with:
# required for version detection using `git describe`
fetch-depth: 50
- name: Lint Yaml
uses: ibiqlik/action-yamllint@2576378a8e339169678f9939646ee3ee325e845c # v3.1.1
with:
format: github
file_or_dir: tests/regression/tests
config_file: .yamllint.yml
- name: Set up Python 3
uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # v5.0.0
with:
python-version: 3.x
- uses: pre-commit/action@2c7b3805fd2a0fd8c1884dcaebf91fc102a13ecd # v3.0.1
- name: "Check CRS syntax"
run: |
pip install -U setuptools
pip install secrules-parsing==${{ env.SECRULES_PARSING_VERSION }}
secrules-parser -c --output-type github -f rules/*.conf
- name: Fetch upstream tags for version detection in next step
run: |
git remote add upstream https://github.com/coreruleset/coreruleset
git fetch --tags upstream
git fetch upstream main
echo ${{ github.base_ref }}
if [ -n "${{ github.base_ref }}" ]; then
git fetch upstream "${{ github.base_ref }}"
fi
- name: "Check CRS formatting"
run: |
pip install -U setuptools
pip install -r ./util/crs-rules-check/requirements.txt
# Use the target branch to look up the latest tag, e.g., `v3.3/master`, fall back
# to main branch.
# The version is either a tag, if the current commit is tagged, or a string of the form
# v<major>.<minor>.<patch>-<nr of commits>-g<hash>.
# In the former case we simply use that as the version, in the latter we construct
# v<major>.<minor + 1>.<patch>-dev.
if [ -z "${{ github.base_ref }}" ]; then
# e.g., force push
version="$(git describe --tags --match "v*.*.*")"
else
version="$(git describe --tags --match "v*.*.*" "upstream/${{ github.base_ref }}")"
fi
version="$(cut -dv -f2 <<<"${version}")"
echo "Detected version ${version}"
if grep -q -- "-g" <<<"${version}"; then
prefix="$(cut -d. -f1 <<<"${version}")"
minor="$(cut -d. -f2 <<<"${version}")"
suffix="$(cut -d. -f3 <<<"${version}")"
version="${prefix}.$((minor + 1)).${suffix}"
release_ref="${{ github.head_ref }}"
if [[ "${release_ref}" =~ ^release/v ]]
then
version="${release_ref/release\/v/}"
else
version="${version/-*-g*/}-dev"
fi
fi
echo "Required version for check: ${version}"
./util/crs-rules-check/rules-check.py \
--output=github \
-r crs-setup.conf.example \
-r rules/*.conf \
-t util/APPROVED_TAGS \
"-v ${version}"
- name: "Find rules without test"
run: |
pip install -U setuptools
pip install -r ./util/find-rules-without-test/requirements.txt
./util/find-rules-without-test/find-rules-without-test.py --output=github .
- name: "Install crs-toolchain ${{ env.CRS_TOOLCHAIN_VERSION }}"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release download -R coreruleset/crs-toolchain "v${{ env.CRS_TOOLCHAIN_VERSION }}" \
-p "crs-toolchain_${{ env.CRS_TOOLCHAIN_VERSION }}_linux_amd64.tar.gz" -O - | tar -xzvf - crs-toolchain
- name: "Check that all assembly files are properly formatted"
run: |
./crs-toolchain regex format -aco github
- name: "Check that all rules are up to date"
run: |
./crs-toolchain regex compare -ao github
- name: "Check that all tests are properly numbered"
run: |
./crs-toolchain util renumber-tests -cao github

73
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/nightly.yml vendored
View file

@ -1,73 +0,0 @@
name: Nightly Release
on:
schedule:
- cron: '0 2 * * *' # run at 2 AM UTC
jobs:
nightly:
name: Nightly Release
runs-on: ubuntu-latest
steps:
- name: Check GH API rate limits
run: |
gh api -i repos/coreruleset/coreruleset/releases/latest | grep -i "x-ratelimit"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: "Checkout repo"
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.2
- name: Delete previous nightly release
run: |
gh release delete --repo coreruleset/coreruleset --cleanup-tag --yes nightly
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Create nightly release
run: |
notes=$(cat <<"EOF"
Nightly releases are snapshots of the development activity on the Core Rule Set project that may include new features and bug fixes scheduled for upcoming releases. These releases are made available to make it easier for users to test their existing configurations against the Core Rule Set code base for potential issues or to experiment with new features, with a chance to provide feedback on ways to improve the changes before being released.
As these releases are snapshots of the latest code, you may encounter an issue compared to the latest stable release so users are encouraged to run nightly releases in a non production environment. If you encounter an issue, please check our issue tracker to see if the issue has already been reported; if a report hasn't been made, please report it so we can review the issue and make any needed fixes.
EOF
)
gh release create \
--repo coreruleset/coreruleset \
--latest \
--prerelease \
--draft=false \
--title "Latest Nightly" \
--notes "${notes}" \
nightly
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Publish draft if necessary
run: |
echo "A race condition in the GH API can cause a release published for a previously existing tag to be published as draft."
echo "Wait for 30 seconds for the API to catch up to the actual state, then check that the release has been properly published."
echo "If the release is still a draft, publish it."
sleep 30
if gh release list --repo coreruleset/coreruleset --exclude-drafts | grep --quiet nightly; then
echo "Nightly release was created properly"
exit 0
fi
echo "Nightly release was created as draft. Publishing now."
gh release edit \
--repo coreruleset/coreruleset \
--latest \
--prerelease \
--draft=false \
nightly
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Check GH API rate limits
run: |
gh api -i repos/coreruleset/coreruleset/releases/latest | grep -i "x-ratelimit"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

20
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/stale.yml vendored
View file

@ -1,20 +0,0 @@
name: Mark stale issues
on:
schedule:
- cron: "0 0 * * *"
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e # v9.0.0
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
stale-issue-message: 'This issue has been open 30 days waiting for feedback. Remove the stale label or comment, or this will be closed in 14 days'
stale-issue-label: 'Stale issue'
days-before-stale: 30
days-before-close: 14
only-issue-labels: ':hourglass_flowing_sand: awaiting feedback'

78
src/common/core/modsecurity/files/coreruleset-v4/.github/workflows/test.yml vendored
View file

@ -1,78 +0,0 @@
name: Regression Tests
on:
push:
branches:
- main
- v3.3/dev
- v3.3/master
paths:
- 'rules/**'
- 'tests/**'
- '.github/**'
pull_request:
branches:
- main
- v3.3/dev
- v3.3/master
paths:
- 'rules/**'
- 'tests/**'
- 'util/**'
- '.github/**'
merge_group:
# Pin tool versions to prevent problems
env:
GO_FTW_VERSION: '1.0.3'
jobs:
regression:
runs-on: ubuntu-latest
strategy:
matrix:
modsec_version: [modsec2-apache, modsec3-nginx]
steps:
- name: "Checkout repo"
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.2
- name: "Install dependencies"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release download -R coreruleset/go-ftw "v${{ env.GO_FTW_VERSION }}" \
-p "ftw_${{ env.GO_FTW_VERSION }}_linux_amd64.tar.gz" -O - | tar -xzvf - ftw
- name: "Run tests for ${{ matrix.modsec_version }}"
run: |
mkdir -p "tests/logs/${{ matrix.modsec_version }}/{nginx,apache2}"
docker compose -f ./tests/docker-compose.yml up -d "${{ matrix.modsec_version }}"
docker compose -f ./tests/docker-compose.yml logs
if ! [ "$(docker inspect ${{ matrix.modsec_version }} --format='{{.State.Running}}')" = "true" ]; then
echo "Web server failed to start. Aborting."
exit 1
fi
./ftw check -d tests/regression/tests
./ftw run \
-d tests/regression/tests \
--log-file "tests/logs/${{ matrix.modsec_version }}/error.log" \
--overrides tests/regression/${{ matrix.modsec_version == 'modsec2-apache' && 'httpd' || 'nginx' }}-overrides.yaml \
--show-failures-only
- name: "Change permissions of artifacts for upload"
if: failure()
run: |
# Files created from the container will belong to root
sudo chmod -R a+r tests/logs
- uses: actions/upload-artifact@5d5d22a31266ced268874388b861e4b58bb5c2f3 # v4.3.1
if: failure()
with:
name: waf-logs-${{ matrix.modsec_version }}
path: tests/logs/${{ matrix.modsec_version }}
- name: Clean docker-compose
run: |
docker compose -f ./tests/docker-compose.yml stop "${{ matrix.modsec_version }}"
docker compose -f ./tests/docker-compose.yml down

826
src/common/core/modsecurity/files/coreruleset-v4/crs-setup.conf.example vendored
View file

@ -1,826 +0,0 @@
# ------------------------------------------------------------------------
# OWASP CRS ver.4.8.0
# Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved.
# Copyright (c) 2021-2024 CRS project. All rights reserved.
#
# The OWASP CRS is distributed under
# Apache Software License (ASL) version 2
# Please see the enclosed LICENSE file for full details.
# ------------------------------------------------------------------------
#
# -- [[ Introduction ]] --------------------------------------------------------
#
# The OWASP 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://coreruleset.org/
# https://github.com/coreruleset/coreruleset
# https://owasp.org/www-project-modsecurity-core-rule-set/
#
#
# -- [[ 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. It is bundled with
# ModSecurity. If you don't have it, you can get it from:
# 2.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v2/master/modsecurity.conf-recommended
# 3.x: https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/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-EXCLUSION-RULES-AFTER-CRS.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-EXCLUSION-RULES-AFTER-CRS.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 that will add to your anomaly scores.
#
# 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.
#
# All rules 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.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.
#
# Uncomment this rule to change the default:
#
#SecAction \
# "id:900000,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.blocking_paranoia_level=1"
# It is possible to execute rules from a higher paranoia level but not include
# them in the anomaly scoring. This allows you to take a well-tuned system on
# paranoia level 1 and add rules from paranoia level 2 without having to fear
# the new rules would lead to false positives that raise your score above the
# threshold.
# This optional feature is enabled by uncommenting the following rule and
# setting the tx.detection_paranoia_level.
# Technically, rules up to the level defined in tx.detection_paranoia_level
# will be executed, but only the rules up to tx.blocking_paranoia_level affect the
# anomaly scores.
# By default, tx.detection_paranoia_level is set to tx.blocking_paranoia_level.
# tx.detection_paranoia_level must not be lower than tx.blocking_paranoia_level.
#
# Please notice that setting tx.detection_paranoia_level to a higher paranoia
# level results in a performance impact that is equally high as setting
# tx.blocking_paranoia_level to said level.
#
#SecAction \
# "id:900001,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.detection_paranoia_level=1"
#
# -- [[ Enforce Body Processor URLENCODED ]] -----------------------------------
#
# ModSecurity selects the body processor based on the Content-Type request
# header. But clients are not always setting the Content-Type header for their
# request body payloads. This will leave ModSecurity with limited vision into
# the payload. The variable tx.enforce_bodyproc_urlencoded lets you force the
# URLENCODED body processor in these situations. This is off by default, as it
# implies a change of the behaviour of ModSecurity beyond CRS (the body
# processor applies to all rules, not only CRS) and because it may lead to
# false positives already on paranoia level 1. However, enabling this variable
# closes a possible bypass of CRS so it should be considered.
#
# Uncomment this rule to change the default:
#
#SecAction \
# "id:900010,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.enforce_bodyproc_urlencoded=1"
#
# -- [[ Anomaly Scoring 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.inbound_anomaly_score_threshold=5,\
# setvar:tx.outbound_anomaly_score_threshold=4"
#
# -- [[ Application Specific Rule Exclusions ]] --------------------------------
#
# CRS 3.x contained exclusion packages to tweak the CRS for use with common
# web applications, lowering the number of false positives.
#
# In CRS 4, these are no longer part of the CRS itself, but they are available
# as "CRS plugins". Some plugins improve support for web applications, and others
# may bring new functionality. Plugins are not installed by default, but can be
# downloaded from the plugin registry:
# https://github.com/coreruleset/plugin-registry
#
# For detailed information about using and installing plugins, please see:
# https://coreruleset.org/docs/concepts/plugins/
#
# -- [[ Anomaly Score Reporting Level ]] ---------------------------------------
#
# When a request is blocked due to the anomaly score meeting or exceeding the
# anomaly threshold then the blocking rule will also report the anomaly score.
# This applies to the separate inbound and outbound anomaly scores.
#
# In phase 5, there are additional rules that can perform additional reporting
# of anomaly scores with a verbosity that depends on the reporting level defined
# below.
#
# By setting the reporting level you control whether you want additional
# reporting beyond the blocking rule or not and, if yes, which requests should
# be covered. The higher the reporting level, the more verbose the reporting is.
#
# There are 6 reporting levels:
#
# 0 - Reporting disabled
# 1 - Reporting for requests with a blocking anomaly score >= a threshold
# 2 - Reporting for requests with a detection anomaly score >= a threshold
# 3 - Reporting for requests with a blocking anomaly score greater than 0
# 4 - Reporting for requests with a detection anomaly score greater than 0
# 5 - Reporting for all requests
#
# Note: Reporting levels 1 and 2 make it possible to differentiate between
# requests that are blocked and requests that are *not* blocked but would have
# been blocked if the blocking PL was equal to detection PL. This may be useful
# for certain FP tuning methodologies, for example moving to a higher PL.
#
# A value of 5 can be useful on platforms where you are interested in logging
# non-scoring requests, yet it is not possible to report this information in
# the request/access log. This applies to Nginx, for example.
#
#SecAction \
# "id:900115,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.reporting_level=4"
#
# -- [[ Early Anomaly Scoring Mode Blocking ]] ------------------------------
#
# The anomaly scores for the request and the responses are generally summed up
# and evaluated at the end of phase:2 and at the end of phase:4 respectively.
# However, it is possible to enable an early evaluation of these anomaly scores
# at the end of phase:1 and at the end of phase:3.
#
# If a request (or a response) hits the anomaly threshold in this early
# evaluation, then blocking happens immediately (if blocking is enabled) and
# the phase 2 (and phase 4 respectively) will no longer be executed.
#
# Enable the rule 900120 that sets the variable tx.early_blocking to 1 in order
# to enable early blocking. The variable tx.early_blocking is set to 0 by
# default. Early blocking is thus disabled by default.
#
# Please note that early blocking will hide potential alerts from you. This
# means that a payload that would appear in an alert in phase 2 (or phase 4)
# does not get evaluated if the request is being blocked early. So when you
# disabled early blocking again at some point in the future, then new alerts
# from phase 2 might pop up.
#SecAction \
# "id:900120,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.early_blocking=1"
#
# -- [[ Initialize Default Collections ]] -----------------------------------
#
# CRS provides a centralized option to initialize and populate collections
# meant to be used by plugins (E.g.DoS protection plugin).
# By default, Global and IP collections (see rule 901320),
# being not used by core rules, are not initialized.
#
# Uncomment this rule to change the default:
#
#SecAction \
# "id:900130,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.enable_default_collections=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-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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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/json|
#
# Please note, that the rule where CRS uses this variable (920420) evaluates it with operator
# `@within`, which is case sensitive, but uses t:lowercase. You must add your whole custom
# Content-Type with lowercase.
#
# Bypass Warning: some applications may not rely on the content-type request header in order
# to parse the request body. This could make an attacker able to send malicious URLENCODED/JSON/XML
# payloads without being detected by the WAF. Allowing request content-type that doesn't activate any
# body processor (for example: "text/plain", "application/x-amf", "application/octet-stream", etc..)
# could lead to a WAF bypass. For example, a malicious JSON payload submitted with a "text/plain"
# content type may still be interpreted as JSON by a backend application but would not trigger the
# JSON body parser at the WAF, leading to a bypass.
#
# When additional JSON content types are legitimately used in a deployment,
# e.g. application/cloudevents+json, it is extremely important to ensure that a
# rule exists to enable the engine's JSON body processor for these additional
# JSON content types. Failure to do so can lead to a request body bypass. The
# default JSON rule in modsecurity.conf-recommended (200001) will only activate
# the JSON body processor for the specific content type application/json. The
# optional modsecurity.conf-recommended rule 200006 can be used to enable the
# JSON body processor for a wide variety of JSON content types.
#
# To prevent blocking request with not allowed content-type by default, you can create an exclusion
# rule that removes rule 920420. For example:
#SecRule REQUEST_HEADERS:Content-Type "@rx ^text/plain" \
# "id:1234,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ctl:ruleRemoveById=920420,\
# ver:'OWASP_CRS/4.8.0',\
# chain"
# SecRule REQUEST_URI "@rx ^/foo/bar" \
# "t:none"
#
# Uncomment this rule to change the default.
#
#SecAction \
# "id:900220,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |text/xml| |application/xml| |application/soap+xml| |application/json|'"
# Allowed HTTP versions.
# Default: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 HTTP/3 HTTP/3.0
# Example for legacy clients: HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 HTTP/3 HTTP/3.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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0 HTTP/3 HTTP/3.0'"
# Forbidden file extensions.
# Guards against unintended exposure of development/configuration files.
# Default: .asa/ .asax/ .ascx/ .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/ .pem/ .pol/ .printer/ .pwd/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/
# Example: .bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .rdb/ .sql/
# Note that .axd was removed due to false positives (see PR 1925).
#
# To additionally guard against configuration/install archive files from being
# accidentally exposed, common archive file extensions can be added to the
# restricted extensions list. An example list of common archive file extensions
# is presented below:
# .7z/ .br/ .bz/ .bz2/ .cab/ .cpio/ .gz/ .img/ .iso/ .jar/ .rar/ .tar/ .tbz2/ .tgz/ .txz/ .xz/ .zip/ .zst/
# (Source: https://en.wikipedia.org/wiki/List_of_archive_formats)
#
# Uncomment this rule to change the default.
#SecAction \
# "id:900240,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .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/ .pem/ .pol/ .printer/ .pwd/ .rdb/ .resources/ .resx/ .sql/ .swp/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/'"
# Restricted request headers.
# The HTTP request headers that CRS restricts are split into two categories:
# basic (always forbidden) and extended (may be forbidden). All header names
# should be lowercase and enclosed by /slashes/ as delimiters.
#
# [ Basic ]
# Includes deprecated headers and headers with known security risks. Always
# forbidden.
# Default: /content-encoding/ /proxy/ /lock-token/ /content-range/ /if/ /x-http-method-override/ /x-http-method/ /x-method-override/
#
# /content-encoding/
# Used to list any encodings that have been applied to the original payload.
# Only used for compression, which isn't supported by CRS by default since CRS
# blocks newlines and null bytes inside the request body. Most compression
# algorithms require at least null bytes per RFC. Blocking Content-Encoding
# shouldn't break anything and increases security since WAF engines, including
# ModSecurity, are typically incapable of properly scanning compressed request
# bodies.
#
# /proxy/
# Blocking this prevents the 'httpoxy' vulnerability: https://httpoxy.org
#
# /lock-token/
#
# /content-range/
#
# /if/
#
# /x-http-method-override/
# /x-http-method/
# /x-method-override/
# Blocking these headers prevents method override attacks, as described here:
# https://www.sidechannel.blog/en/http-method-override-what-it-is-and-how-a-pentester-can-use-it
#
# Uncomment this rule to change the default.
#SecAction \
# "id:900250,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.restricted_headers_basic=/content-encoding/ /proxy/ /lock-token/ /content-range/ /if/ /x-http-method-override/ /x-http-method/ /x-method-override/'"
#
# [ Extended ]
# Includes deprecated headers that are still in use (so false positives are
# possible) and headers with possible security risks. Forbidden at a higher
# paranoia level.
# Default: /accept-charset/
#
# /accept-charset/
# Deprecated header that should not be used by clients and should be ignored
# by servers. Can be used for a response WAF bypass by asking for a charset
# that the WAF cannot decode. Considered to be a good indicator of suspicious
# behavior but produces too many false positives to be forbidden by default.
# References:
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Charset
# https://github.com/coreruleset/coreruleset/issues/3140
#
# Uncomment this rule to change the default.
#SecAction \
# "id:900255,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.restricted_headers_extended=/accept-charset/'"
# Content-Types charsets that a client is allowed to send in a request.
# The content-types are enclosed by |pipes| as delimiters to guarantee exact matches.
# Default: |utf-8| |iso-8859-1| |iso-8859-15| |windows-1252|
# Uncomment this rule to change the default.
#SecAction \
# "id:900280,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:'tx.allowed_request_content_type_charset=|utf-8| |iso-8859-1| |iso-8859-15| |windows-1252|'"
#
# -- [[ 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
# Note that a hard limit by the engine may also apply here (SecArgumentsLimit).
# This would override this soft limit.
# Uncomment this rule to set a limit.
#SecAction \
# "id:900300,\
# phase:1,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.combined_file_sizes=1048576"
#
# -- [[ Easing In / Sampling Percentage ]] -------------------------------------
#
# Adding the CRS 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-EXCLUSION-RULES-AFTER-CRS.conf).
#
#SecRuleUpdateActionById 901450 "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,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.sampling_percentage=100"
#
# -- [[ 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,\
# pass,\
# t:none,\
# nolog,\
# tag:'OWASP_CRS',\
# ver:'OWASP_CRS/4.8.0',\
# setvar:tx.crs_validate_utf8_encoding=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,\
pass,\
t:none,\
nolog,\
tag:'OWASP_CRS',\
ver:'OWASP_CRS/4.8.0',\
setvar:tx.crs_setup_version=480"

9
src/common/core/modsecurity/files/coreruleset-v4/docs/README.md vendored
View file

@ -1,9 +0,0 @@
# Welcome to the OWASP CRS documentation.
The latest version of the documentation can be read at:
https://coreruleset.org/docs/
Documentation is generated by Hugo and is stored
in a separate Github repository:
https://github.com/coreruleset/documentation/

4
src/common/core/modsecurity/misc/versions.json
View file

@ -5,14 +5,14 @@
"name": "Coreruleset v3.3.7",
"url": "https://github.com/coreruleset/coreruleset.git",
"commit": "daedded8fe6f132e7db8875f9dd0b02850215b74",
"post_install": "rm -rf files/coreruleset-v3/tests && cp files/coreruleset-v3/crs-setup.conf.example files/crs-setup-v3.conf"
"post_install": "rm -rf files/coreruleset-v3/tests files/coreruleset-v3/.github files/coreruleset-v3/docs && mv files/coreruleset-v3/crs-setup.conf.example files/crs-setup-v3.conf"
},
{
"id": "coreruleset-v4",
"name": "Coreruleset v4.8.0",
"url": "https://github.com/coreruleset/coreruleset.git",
"commit": "3dc7e0dbc971a6622ecc273a34c7febc14145b1c",
"post_install": "rm -rf files/coreruleset-v4/tests && cp files/coreruleset-v4/crs-setup.conf.example files/crs-setup-v4.conf"
"post_install": "rm -rf files/coreruleset-v4/tests files/coreruleset-v4/.github files/coreruleset-v4/docs && mv files/coreruleset-v4/crs-setup.conf.example files/crs-setup-v4.conf"
}
]
}