Skip to content

Commit

Permalink
Merge pull request #109 from coreruleset/update-modsec-url
Browse files Browse the repository at this point in the history
chore: update modsec url
  • Loading branch information
fzipi authored Feb 12, 2024
2 parents 3d19754 + e101790 commit dba04a5
Show file tree
Hide file tree
Showing 6 changed files with 18 additions and 18 deletions.
2 changes: 1 addition & 1 deletion content/concepts/anomaly_scoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -192,7 +192,7 @@ Early blocking makes this possible by inserting **two additional rounds of block
1. Make a **blocking decision** using the *outbound* anomaly score threshold

{{% notice info %}}
More information about processing phases can be found in the [processing phases section](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#processing-phases) of the ModSecurity Reference Manual.
More information about processing phases can be found in the [processing phases section](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#processing-phases) of the ModSecurity Reference Manual.
{{% /notice %}}

{{% notice warning %}}
Expand Down
14 changes: 7 additions & 7 deletions content/concepts/false_positives_tuning.md
Original file line number Diff line number Diff line change
Expand Up @@ -328,7 +328,7 @@ SecRule REQUEST_URI "@beginsWith /webapp/login.html" \
{{% notice tip %}}
It's possible to write a conditional rule exclusion that tests something other than just the request URI. Conditions can be built which test, for example, the source IP address, HTTP request method, HTTP headers, and even the day of the week.

Multiple conditions can also be chained together to create a logical AND by using ModSecurity's [chain](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) action. This allows for creating powerful rule logic like "for transactions that are from source IP address 10.0.0.1 AND that are for location '/login.html', exclude the query string parameter 'user_id' from rule 920280". Extremely granular and specific rule exclusions can be written, in this way.
Multiple conditions can also be chained together to create a logical AND by using ModSecurity's [chain](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) action. This allows for creating powerful rule logic like "for transactions that are from source IP address 10.0.0.1 AND that are for location '/login.html', exclude the query string parameter 'user_id' from rule 920280". Extremely granular and specific rule exclusions can be written, in this way.
{{% /notice %}}

#### Rule Exclusion Packages
Expand Down Expand Up @@ -366,12 +366,12 @@ The CRS project is always looking to work with other communities and individuals

A popular tutorial titled [Handling False Positives with the OWASP ModSecurity Core Rule Set](https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/) by Christian Folini walks through a full CRS tuning process, with examples.

Detailed reference of each of the rule exclusion mechanisms outlined above can be found in the [ModSecurity Reference Manual](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)):
Detailed reference of each of the rule exclusion mechanisms outlined above can be found in the [ModSecurity Reference Manual](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)):

- Configure-time rule exclusion mechanisms:
- [SecRuleRemoveById](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleRemoveById)
- [SecRuleRemoveByTag](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleRemoveByTag)
- [SecRuleUpdateTargetById](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleUpdateTargetById)
- [SecRuleUpdateTargetByTag](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleUpdateTargetByTag)
- [SecRuleRemoveById](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleRemoveById)
- [SecRuleRemoveByTag](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleRemoveByTag)
- [SecRuleUpdateTargetById](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleUpdateTargetById)
- [SecRuleUpdateTargetByTag](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleUpdateTargetByTag)
- Runtime rule exclusion mechanisms:
- [The ctl action](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#ctl)
- [The ctl action](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#ctl)
8 changes: 4 additions & 4 deletions content/deployment/install.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ ModSecurity is frequently pre-packaged and is available from several major Linux
- **Fedora:** Execute `dnf install mod_security` for Apache + ModSecurity v2.
- **RHEL compatible:** Install EPEL and then execute `yum install mod_security`.

For Windows, get the latest MSI package from https://github.com/SpiderLabs/ModSecurity/releases.
For Windows, get the latest MSI package from https://github.com/owasp-modsecurity/ModSecurity/releases.

{{% notice warning %}}
**Distributions might not update their ModSecurity releases frequently.**
Expand All @@ -58,8 +58,8 @@ Examples of `<web server config>/` include:

Compiling ModSecurity is easy, but slightly outside the scope of this document. For information on how to compile ModSecurity, refer to:

- the official [ModSecurity documentation](https://github.com/SpiderLabs/ModSecurity/wiki) on GitHub
- the compilation recipes for ModSecurity v3 on the [ModSecurity wiki](https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x)
- the official [ModSecurity documentation](https://github.com/owasp-modsecurity/ModSecurity/wiki) on GitHub
- the compilation recipes for ModSecurity v3 on the [ModSecurity wiki](https://github.com/owasp-modsecurity/ModSecurity/wiki/Compilation-recipes-for-v3.x)
- the netnea tutorials for [Apache](https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/) or [Nginx](https://www.netnea.com/cms/nginx-tutorial-6_embedding-modsecurity/)

{{% notice warning "Unsupported Configurations" "skull-crossbones" %}}
Expand Down Expand Up @@ -174,7 +174,7 @@ OWASP CRS contains a setup file that should be reviewed prior to completing set

At a minimum, keep in mind the following:

- CRS does not configure features such as the rule engine, audit engine, logging, etc. This task is part of the initial *engine* setup and is not a job for the rule set. For ModSecurity, if not already done, see the [recommended configuration](https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended).
- CRS does not configure features such as the rule engine, audit engine, logging, etc. This task is part of the initial *engine* setup and is not a job for the rule set. For ModSecurity, if not already done, see the [recommended configuration](https://github.com/owasp-modsecurity/ModSecurity/blob/master/modsecurity.conf-recommended).
- Decide what ModSecurity should do when it detects malicious activity, e.g., drop the packet, return a *403 Forbidden* status code, issue a redirect to a custom page, etc.
- Make sure to configure the anomaly scoring thresholds. For more information see [Anomaly]({{< ref "anomaly_scoring.md" >}} "Anomaly").
- By default, the CRS rules will consider many issues with different databases and languages. If running in a specific environment, e.g., without any SQL database services present, it is probably a good idea to limit this behavior for performance reasons.
Expand Down
4 changes: 2 additions & 2 deletions content/development/contribution_guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ chapter: false
* Adhere to an 80 character line length limit where possible.
* Add comments where possible and clearly explain any new rules.
* Comments must not appear between chained rules and should instead be placed before the start of a rule chain.
* All [chained rules](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) should be indented like so, for readability:
* All [chained rules](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#chain) should be indented like so, for readability:
```
SecRule .. .. \
"..."
Expand Down Expand Up @@ -305,7 +305,7 @@ The types of rules that are allowed at each paranoia level are as follows:

**PL 2:**

* [Chain](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#chain) usage is allowed
* [Chain](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-%28v2.x%29#chain) usage is allowed
* Confirmed matches use score critical
* Matches that cause false positives are limited to using scores notice or warning
* Low false positive rates
Expand Down
4 changes: 2 additions & 2 deletions content/operation/known_issues.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,13 +47,13 @@ chapter: false

It is advisable to upgrade an affected Apache version. If upgrading is not possible, the CRS project provides a script in the `util/join-multiline-rules` directory which converts the rules into a format that works around the bug. This script must be re-run whenever the CRS rules are modified or updated.

- As of CRS version 3.0.1, support has been added for the `application/soap+xml` MIME type by default, as specified in RFC 3902. **OF IMPORTANCE:** application/soap+xml is indicative that XML will be provided. In accordance with this, ModSecurity's XML request body processor should also be configured to support this MIME type. Within the ModSecurity project, [commit 5e4e2af](https://github.com/SpiderLabs/ModSecurity/commit/5e4e2af7a6f07854fee6ed36ef4a381d4e03960e) has been merged to support this endeavor. However, if running a modified or preexisting version of the modsecurity.conf file provided by this repository, it is a good idea to upgrade rule '200000' accordingly. The rule now appears as follows:
- As of CRS version 3.0.1, support has been added for the `application/soap+xml` MIME type by default, as specified in RFC 3902. **OF IMPORTANCE:** application/soap+xml is indicative that XML will be provided. In accordance with this, ModSecurity's XML request body processor should also be configured to support this MIME type. Within the ModSecurity project, [commit 5e4e2af](https://github.com/owasp-modsecurity/ModSecurity/commit/5e4e2af7a6f07854fee6ed36ef4a381d4e03960e) has been merged to support this endeavor. However, if running a modified or preexisting version of the modsecurity.conf file provided by this repository, it is a good idea to upgrade rule '200000' accordingly. The rule now appears as follows:

```
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \
"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
```
- **All versions of libmodsecurity3** [do not support](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v3.x)#secdisablebackendcompression) the `SecDisableBackendCompression` directive at all.
- **All versions of libmodsecurity3** [do not support](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v3.x)#secdisablebackendcompression) the `SecDisableBackendCompression` directive at all.
If Nginx is acting as a proxy and the backend supports any type of compression, if the client sends an `Accept-Encoding: gzip,deflate,...` or `TE` header, the backend will return the response in a compressed format. Because of this, the engine cannot verify the response. As a workaround, you need to override the `Accept-Encoding` and `TE` headers in the proxy:

```
Expand Down
4 changes: 2 additions & 2 deletions content/rules/creating.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ chapter: false

### The Basic Syntax

A [SecRule](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRule)
A [SecRule](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRule)
is a directive like any other understood by ModSecurity. The difference
is that this directive is way more powerful in what it is capable of
representing. Generally, a SecRule is made up of 4 parts:
Expand Down Expand Up @@ -48,7 +48,7 @@ ModSecurity directives are only evaluated at startup.
Clearly, if this was all there was to SecRules it wouldn't be very
powerful. In fact, there is a lot more. So much more that it is in fact
a full fledged language. The best place to find out about all the
possible capabilities is via the [ModSecurity Manual](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)).
possible capabilities is via the [ModSecurity Manual](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)).
The following is just a glimpse of its capabilities:

There are ~105 **variables** in 6 different categories, some examples
Expand Down

0 comments on commit dba04a5

Please sign in to comment.