mirror of
https://github.com/owasp-modsecurity/ModSecurity.git
synced 2025-08-14 05:45:59 +03:00
Make rules/README UNIX style EOL.
Merge another branch/2.1.x change.
This commit is contained in:
brectanus
parent
d55e023bf7
commit
6569c444d8
@ -60,7 +60,7 @@ int perform_interception(modsec_rec *msr) {
|
||||
|
||||
/* Check for an initial request */
|
||||
|
||||
if (is_initial_req == 0) {
|
||||
if (is_initial_req != 1) {
|
||||
if (msr->r->main != NULL) {
|
||||
intreq_text = "Sub-Request: ";
|
||||
}
|
||||
@ -95,7 +95,7 @@ int perform_interception(modsec_rec *msr) {
|
||||
* if a nolog action was used or this is not the initial request
|
||||
* to hide the message.
|
||||
*/
|
||||
log_level = ((actionset->log != 1) || (is_initial_req == 0)) ? 4 : 1;
|
||||
log_level = ((actionset->log != 1) || (is_initial_req != 1)) ? 4 : 1;
|
||||
|
||||
/* Pause the request first (if configured and the initial request). */
|
||||
if (actionset->intercept_pause && (is_initial_req == 1)) {
|
||||
|
||||
356
rules/README
356
rules/README
@ -1,179 +1,177 @@
|
||||
|
||||
|
||||
ModSecurity Core Rule Set
|
||||
==============================
|
||||
|
||||
(c) 2006 Breach Secuiry Inc.
|
||||
|
||||
The ModSecurity Core Rule Set is provided to you under the terms and
|
||||
conditions of GPL version 2
|
||||
|
||||
This directory contains the files for Core ModSecurity Rule Set
|
||||
The rules are compatible with ModSecurity 2.1 (as of version 1.3.2)
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Using ModSecurity requires rules. In order to enable users to take full
|
||||
advantage of ModSecurity immediately, Breach Security Inc. is providing a free
|
||||
Core rule set. Unlike intrusion detection and prevention systems which
|
||||
rely on signature specific to known vulnerabilities, the Core Rule Set
|
||||
provides generic protection from unknown vulnerabilities often found in web
|
||||
application that are in most cases custom coded.
|
||||
|
||||
Keep in mind that a predefined rule set is only part of the work required to
|
||||
protect your web site. We strongly urge you to consult Ivan Ristic's book,
|
||||
"Apache Security" in order to harden your Apache web server. You may also
|
||||
consider writing custom rules for providing a positive security envelope to
|
||||
your application or critical parts of it. Breach Security can provide you with
|
||||
training and professional services to assist you in doing that. The Core
|
||||
Rule Set is heavily commented to allow it to be used as a step-by-step
|
||||
deployment guide for ModSecurity.
|
||||
|
||||
For more information refer to the Core Rule Set page at
|
||||
http://www.modsecurity.org/
|
||||
|
||||
|
||||
Core Rule Set Structure & Usage
|
||||
------------------------------------
|
||||
|
||||
To activate the rules for your web server installation:
|
||||
|
||||
1) You may want to edit and customize modsecurity_crs_10_config.conf.
|
||||
Additionally you may want to edit modsecurity_crs_30_http_policy.conf
|
||||
which enforces an application specific HTTP protocol usage.
|
||||
|
||||
2) Add the following line to your httpd.conf (assuming
|
||||
you've placed the rule files into conf/modsecurity/):
|
||||
|
||||
Include conf/modsecurity/*.conf
|
||||
|
||||
3) Restart web server.
|
||||
|
||||
4) Make sure your web sites are still running fine.
|
||||
|
||||
5) Simulate an attack against the web server. Then check
|
||||
the attack was correctly logged in the Apache error log,
|
||||
ModSecurity debug log (if you enabled it) and ModSecurity
|
||||
audit log (if you enabled it).
|
||||
|
||||
6) If you configured your audit log entries to be transported
|
||||
to ModSecurity Console in real time, check the alert was
|
||||
correctly recorded there too.
|
||||
|
||||
About Regular Expressions
|
||||
-------------------------
|
||||
|
||||
One of the advantages of the Core Rule Set, being a set of text files is your
|
||||
ability to modify it. However you will find that the regular expressions used
|
||||
are very complex.
|
||||
|
||||
Since regular expressions are much more efficient if assembled into a single
|
||||
expression and optimized, a generation script takes a list of patterns that
|
||||
are required for a rule and optimize them into a most efficient regular
|
||||
expression.
|
||||
|
||||
We plan to release the optimization script shortly to allow much easier editing
|
||||
of regular expressions.
|
||||
|
||||
|
||||
Core Rule Set Content
|
||||
--------------------------
|
||||
|
||||
In order to provide generic web applications protection, the Core Rule Set
|
||||
uses the following techniques:
|
||||
|
||||
1. HTTP protection - detecting violations of the HTTP protocol and a locally
|
||||
defined usage policy.
|
||||
|
||||
2. Common Web Attacks Protection - detecting common web application security
|
||||
attack.
|
||||
|
||||
3. Automation detection - Detecting bots, crawlers, scanners and other surface
|
||||
malicious activity.
|
||||
|
||||
4. Trojan Protection - Detecting access to Trojans horses.
|
||||
|
||||
5. Errors Hiding - Disguising error messages sent by the server
|
||||
|
||||
In addition the rule set also hints at the power of ModSecurity beyond
|
||||
providing security by reporting access from the major search engines to your
|
||||
site.
|
||||
|
||||
|
||||
HTTP Protection - This first line of protection ensures that all abnormal HTTP
|
||||
requests are detected. This line of defense eliminates a large number of
|
||||
automated and non targeted attacks as well as protects the web server itself.
|
||||
Common Web Attacks Protection Rules on the second level address the common web
|
||||
application security attack methods. These are the issues that can appear in
|
||||
any web application. Some of the issues addressed are:
|
||||
|
||||
- SQL Injection
|
||||
- Cross-Site Scripting (XSS)
|
||||
- OS Command execution
|
||||
- Remote code inclusion
|
||||
- LDAP Injection
|
||||
- SSI Injection
|
||||
- Information leak
|
||||
- Buffer overflows
|
||||
- File disclosure
|
||||
|
||||
Automation Detection - Automated clients are both a security risk and a
|
||||
commercial risk. Automated crawlers collect information from your site, consume
|
||||
bandwidth and might also search for vulnerabilities on the web site. Automation
|
||||
detection is especially useful for generic detection of comments spam.
|
||||
|
||||
|
||||
Trojan Protection - ModSecurity Core Rule Set detects access to back doors
|
||||
installed on a web server. This feature is very important in a hosting
|
||||
environment when some of this backdoors may be uploaded in a legitimate way and
|
||||
used maliciously. In addition the Core Rule Set includes a hook for adding
|
||||
an Anti-Virus program such as ClamAV for checking file uploads.
|
||||
|
||||
Errors Hiding - If all fails, the Core Rule Set will detect errors sent by
|
||||
the web server. Detecting and blocking errors prevents attackers from
|
||||
collecting reconnaissance information about the web application and also server
|
||||
as a last line of defense in case an attack was not detected eariler.
|
||||
|
||||
|
||||
Few Word of Caution
|
||||
-------------------
|
||||
|
||||
As with every new technology, using the ModSecurity Core Rule Set requires some caution:
|
||||
|
||||
- Every Rule Set can have false positive in new environments and any new
|
||||
installation should initially use the log only Rule Set version or if no such
|
||||
version is available, set ModSecurity to Detection only using the SecRuleEngine
|
||||
DetectionOnly command.
|
||||
|
||||
After running ModSecurity in a detection only mode for a while review the evens
|
||||
generated and decide if any modification to the rule set should be made before
|
||||
moving to protection mode.
|
||||
|
||||
- Freely available wide spread signatures have their down side as attackers may
|
||||
examine them and find ways to bypass them. Especially note that the automation
|
||||
detection signatures are relatively easy to evade and should not be viewed as a
|
||||
security mechanism but only as a "nuisance reduction" mechanism.
|
||||
|
||||
|
||||
Road Map
|
||||
--------
|
||||
|
||||
This rule set is both young and old. Breach Security has a long experience with
|
||||
rules and signatures for application security protection and the Core Rule
|
||||
Set is based on this experience. On the other hand, this is a first cut of a
|
||||
ModSecurity rule set so your feedback and remarks, either directly or through
|
||||
the ModSecurity mailing list would be greatly appreciated.
|
||||
|
||||
Going forward we plan to:
|
||||
|
||||
- Utilize ModSecurity 2.0 support for events correlation to detect denial of
|
||||
service attacks, brute force attacks and attack reconnaissance
|
||||
|
||||
- Add a framework for validating SOAP requests.
|
||||
|
||||
- Add signatures for key known vulnerabilities.
|
||||
|
||||
Anything else you would want?
|
||||
|
||||
ModSecurity Core Rule Set
|
||||
==============================
|
||||
|
||||
(c) 2006 Breach Secuiry Inc.
|
||||
|
||||
The ModSecurity Core Rule Set is provided to you under the terms and
|
||||
conditions of GPL version 2
|
||||
|
||||
This directory contains the files for Core ModSecurity Rule Set
|
||||
The rules are compatible with ModSecurity 2.1 (as of version 1.3.2)
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Using ModSecurity requires rules. In order to enable users to take full
|
||||
advantage of ModSecurity immediately, Breach Security Inc. is providing a free
|
||||
Core rule set. Unlike intrusion detection and prevention systems which
|
||||
rely on signature specific to known vulnerabilities, the Core Rule Set
|
||||
provides generic protection from unknown vulnerabilities often found in web
|
||||
application that are in most cases custom coded.
|
||||
|
||||
Keep in mind that a predefined rule set is only part of the work required to
|
||||
protect your web site. We strongly urge you to consult Ivan Ristic's book,
|
||||
"Apache Security" in order to harden your Apache web server. You may also
|
||||
consider writing custom rules for providing a positive security envelope to
|
||||
your application or critical parts of it. Breach Security can provide you with
|
||||
training and professional services to assist you in doing that. The Core
|
||||
Rule Set is heavily commented to allow it to be used as a step-by-step
|
||||
deployment guide for ModSecurity.
|
||||
|
||||
For more information refer to the Core Rule Set page at
|
||||
http://www.modsecurity.org/
|
||||
|
||||
|
||||
Core Rule Set Structure & Usage
|
||||
------------------------------------
|
||||
|
||||
To activate the rules for your web server installation:
|
||||
|
||||
1) You may want to edit and customize modsecurity_crs_10_config.conf.
|
||||
Additionally you may want to edit modsecurity_crs_30_http_policy.conf
|
||||
which enforces an application specific HTTP protocol usage.
|
||||
|
||||
2) Add the following line to your httpd.conf (assuming
|
||||
you've placed the rule files into conf/modsecurity/):
|
||||
|
||||
Include conf/modsecurity/*.conf
|
||||
|
||||
3) Restart web server.
|
||||
|
||||
4) Make sure your web sites are still running fine.
|
||||
|
||||
5) Simulate an attack against the web server. Then check
|
||||
the attack was correctly logged in the Apache error log,
|
||||
ModSecurity debug log (if you enabled it) and ModSecurity
|
||||
audit log (if you enabled it).
|
||||
|
||||
6) If you configured your audit log entries to be transported
|
||||
to ModSecurity Console in real time, check the alert was
|
||||
correctly recorded there too.
|
||||
|
||||
About Regular Expressions
|
||||
-------------------------
|
||||
|
||||
One of the advantages of the Core Rule Set, being a set of text files is your
|
||||
ability to modify it. However you will find that the regular expressions used
|
||||
are very complex.
|
||||
|
||||
Since regular expressions are much more efficient if assembled into a single
|
||||
expression and optimized, a generation script takes a list of patterns that
|
||||
are required for a rule and optimize them into a most efficient regular
|
||||
expression.
|
||||
|
||||
We plan to release the optimization script shortly to allow much easier editing
|
||||
of regular expressions.
|
||||
|
||||
|
||||
Core Rule Set Content
|
||||
--------------------------
|
||||
|
||||
In order to provide generic web applications protection, the Core Rule Set
|
||||
uses the following techniques:
|
||||
|
||||
1. HTTP protection - detecting violations of the HTTP protocol and a locally
|
||||
defined usage policy.
|
||||
|
||||
2. Common Web Attacks Protection - detecting common web application security
|
||||
attack.
|
||||
|
||||
3. Automation detection - Detecting bots, crawlers, scanners and other surface
|
||||
malicious activity.
|
||||
|
||||
4. Trojan Protection - Detecting access to Trojans horses.
|
||||
|
||||
5. Errors Hiding - Disguising error messages sent by the server
|
||||
|
||||
In addition the rule set also hints at the power of ModSecurity beyond
|
||||
providing security by reporting access from the major search engines to your
|
||||
site.
|
||||
|
||||
|
||||
HTTP Protection - This first line of protection ensures that all abnormal HTTP
|
||||
requests are detected. This line of defense eliminates a large number of
|
||||
automated and non targeted attacks as well as protects the web server itself.
|
||||
Common Web Attacks Protection Rules on the second level address the common web
|
||||
application security attack methods. These are the issues that can appear in
|
||||
any web application. Some of the issues addressed are:
|
||||
|
||||
- SQL Injection
|
||||
- Cross-Site Scripting (XSS)
|
||||
- OS Command execution
|
||||
- Remote code inclusion
|
||||
- LDAP Injection
|
||||
- SSI Injection
|
||||
- Information leak
|
||||
- Buffer overflows
|
||||
- File disclosure
|
||||
|
||||
Automation Detection - Automated clients are both a security risk and a
|
||||
commercial risk. Automated crawlers collect information from your site, consume
|
||||
bandwidth and might also search for vulnerabilities on the web site. Automation
|
||||
detection is especially useful for generic detection of comments spam.
|
||||
|
||||
|
||||
Trojan Protection - ModSecurity Core Rule Set detects access to back doors
|
||||
installed on a web server. This feature is very important in a hosting
|
||||
environment when some of this backdoors may be uploaded in a legitimate way and
|
||||
used maliciously. In addition the Core Rule Set includes a hook for adding
|
||||
an Anti-Virus program such as ClamAV for checking file uploads.
|
||||
|
||||
Errors Hiding - If all fails, the Core Rule Set will detect errors sent by
|
||||
the web server. Detecting and blocking errors prevents attackers from
|
||||
collecting reconnaissance information about the web application and also server
|
||||
as a last line of defense in case an attack was not detected eariler.
|
||||
|
||||
|
||||
Few Word of Caution
|
||||
-------------------
|
||||
|
||||
As with every new technology, using the ModSecurity Core Rule Set requires some caution:
|
||||
|
||||
- Every Rule Set can have false positive in new environments and any new
|
||||
installation should initially use the log only Rule Set version or if no such
|
||||
version is available, set ModSecurity to Detection only using the SecRuleEngine
|
||||
DetectionOnly command.
|
||||
|
||||
After running ModSecurity in a detection only mode for a while review the evens
|
||||
generated and decide if any modification to the rule set should be made before
|
||||
moving to protection mode.
|
||||
|
||||
- Freely available wide spread signatures have their down side as attackers may
|
||||
examine them and find ways to bypass them. Especially note that the automation
|
||||
detection signatures are relatively easy to evade and should not be viewed as a
|
||||
security mechanism but only as a "nuisance reduction" mechanism.
|
||||
|
||||
|
||||
Road Map
|
||||
--------
|
||||
|
||||
This rule set is both young and old. Breach Security has a long experience with
|
||||
rules and signatures for application security protection and the Core Rule
|
||||
Set is based on this experience. On the other hand, this is a first cut of a
|
||||
ModSecurity rule set so your feedback and remarks, either directly or through
|
||||
the ModSecurity mailing list would be greatly appreciated.
|
||||
|
||||
Going forward we plan to:
|
||||
|
||||
- Utilize ModSecurity 2.0 support for events correlation to detect denial of
|
||||
service attacks, brute force attacks and attack reconnaissance
|
||||
|
||||
- Add a framework for validating SOAP requests.
|
||||
|
||||
- Add signatures for key known vulnerabilities.
|
||||
|
||||
Anything else you would want?
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user