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