Configuring ModSecurity

Continuing Web Application Firewall (ModSecurity) in action

1.1 The concept of regular expressions

Regular Expression is a mini programming language designed to search for pattern matching.
Comment. Apache 1.x and Apache 2.x use various regular expression tools. In Apache 2.x, regular expression processing is compatible with Perl. In Apache 1.x, regular expression processing is compatible with POSIX.
Regular expressions use special characters. We present a brief semantics of some of them in Table 1.1.

Table 1.1 - Semantics of special characters used in regular expressions.

1.2 Configuration

Configuration directives ModSecurity are directly added to the configuration file (usually httpd.conf). If it is not known in advance whether this module is included, the directives should be enclosed in a tag. This will allow Apache to ignore the configuration directives when the module is not active.

Since Apache allows configuration data to be located in more than one file, it is possible to group configuration directives into one file (for example, modsecurity.conf) and include it in httpd.conf using the Include directive.
Include conf / modsecurity.conf
')

1.3 Enabling Filtering

By default, filtering is turned off. In order for the module to start analyzing requests, you should add the SecRuleEngine On configuration file.
The syntax of this command is shown below.
SecRuleEngine On | Off | DetectionOnly
Possible parameter values:
On - analyze each request;
Off - do nothing;
DetectionOnly - analyze each request, but do not take any active actions (such as blocking the request).

1.4 Scanning the contents of the request body

Scanning the contents of the request body is disabled by default. To scan the contents of requests, you must specify:
SeqRequestBodyAccess On
Syntax: SeqRequestBodyAccess On | Off

1.5 List of default actions

Whenever a request matches a rule, one or more actions are performed. Each filter can have its own actions, but you can define many default actions for all filters. If you wish, you can always specify an action for each rule.
For example, logging each rule for which a match is made is configured as follows, and the request is rejected with status code 404:
SecDefaultAction "phase: 2, deny, log, status: 404"
The syntax of this command is: SecDefaultAction. Default values ​​are "phase: 2, log, auditlog, pass"
The SecDefaultAction directive has only one parameter — a comma-separated list of actions. Actions will be performed for each filter for which compliance is performed, with the exception of rules that have their own lists of actions.
Comment. If a non-fatal default list of actions is specified (a list that does not cause a situation in which the request can be rejected, for example, log, pass), then such a list of actions will be ignored during the initialization phase. The initialization phase is intended to obtain information about the request. Allowing non-fatal actions will result in some parts of the request being skipped. Since this information is required for internal processing, such actions cannot be resolved. If ModSecurity is to be performed in the “detect-only” mode, it is necessary to disable all implicit validations (validation of the URL representation, validation of the Unicode representation, validation of the cookie format) [1].
Comment. Actions on metadata (id, rev, msg, severity) and actions that control the sequence of rules (skip / skipAfter, chain) cannot appear in the SecFilterDefaultAction directive.

1.6 Rules

When filtering is enabled, each incoming request is analyzed before it is sent to its destination. The analysis begins with a series of built-in checks designed to check the validity of the request format. These checks can be controlled using configuration directives. At the second stage, the request passes through a series of user-defined filters, for which the request is checked. Whenever a match exists, actions defined in the rules are performed.
The development team led by Ivan Ristik focuses on improving the ModSecurity code, leaving the creation of rules to users, so the original configuration file has only a few rules. There are several subprojects (for example, OWASP ModSecurity Core Rule), the purpose of which is to create and test rules. To use them, you need to download and connect the required rules file in the ModSecurity configuration file with the Include directive. Some of the rules require editing, in addition, you should consider the features of rexec and PCRE, so the rules created for Apache 2.x may not work correctly with the first version of the server. In addition, there are special scripts that transform the rules of intrusion detection systems and security scanners into rules for ModSecurity. For example, the snort2modsec.pl script, which converts IDS Snort rules into ModSecurity rules and the nessus2modsec.pl script, designed to convert the NASL Nessus / GNessUs security scanner rules. Basic filtering rules protect the Web server from a wide range of attacks, but they cannot be considered absolute protection for a specific Web application.

1.7 Easy filtering

The simplest form of filtering is as follows:
SecRule SecRule is a directive used to create rules in ModSecurity.
For each simple filter, ModSecurity searches for operators in variables and performs the actions specified in the actions.
Variables locates the search string. A regular expression, IP address, name, identifiers, including CGI variables can be used here.
Server variables are accessed through keywords, for example, REQUEST_LINE, REQUEST_PROTOCOL, REQUEST_METHOD, etc.
Access to variables from the query is carried out through keywords, for example, QUERY_STRING, as well as to an array of ARGS variables.
The variable parameter can consist of a set of identifiers separated by a vertical bar.

The list of variables available for use when writing rules.


The names of most of them describe themselves. (for acquaintance with others refer to the documentation).
For filtering, you can specify the inverse of some variable. For example:
SecRule «ARGS | ! ARG_param »All arguments will be searched, except for the named parameter.
Operators define the methods and data of the comparison. By default, if other operators are not defined, the @rx operator is used. This means that the string following the statement will be interpreted as a regular expression. This string will be searched in the corresponding variable.

1.8 Actions

There are several types of actions.
The primary action decides whether to continue processing the request or not. There can be only one primary action. If several primary actions are specified in the parameter, the last action will be executed. The primary actions are deny, pass and redirect.
Secondary actions will be performed if the request matches the filter, regardless of the decision made by the primary actions. There may be any number of secondary actions. For example, exec is one of the secondary actions.
Flow actions can change the sequence of rules, forcing them to switch to another rule or skipping one or more rules. The flow actions are chain and skipAfter.
Parameters are not actions, but a way of attaching parameters to filters. Some of these parameters can be used in real actions. For example, status adds a response code to the primary action deny.
Let us consider in more detail the syntax of actions in table 1.2.

Table 1.2 - Actions performed when a query matches

1.9 Phases and Rules Implementation

It is important to understand on which phase the ModSecurity applies the rules. This will be convenient for you when creating new rules and will allow you to avoid situations in which actions were unexpectedly blocked or, on the contrary, allowed, while your expectations were opposite.
The operation logic of ModSecurity divides requests into 5 phases:
1. REQUEST_HEADERS (phase 1);
2. REQUEST_BODY (phase 2);
3. RESPONSE_HEADERS (phase 3);
4. RESPONSE_BODY (phase 4);
5. LOGGING (phase 5).
The rules are executed sequentially in each phase, which means that ModSecurity first evaluates all the rules in phase 1 (“request headers”), then resumes at phase 2 - 5 (if the rules do not force to stop processing the request).

1.10 Normalization Functions

ModSecurity provides support for multiple normalization functions. These transformations are done before any rules begin to apply. Normalization functions are useful for a variety of purposes. These functions allow you to detect and prevent many types of attacks, such as cross-site scripting, injection of JavaScript code, regardless of their location.
The documentation for ModSecurity 2.x describes the following normalization functions:


The names of most of them describe themselves. (for acquaintance with others refer to the documentation). By default ModSecurity 2.x for the incoming stream performs the functions lowercase, replaceNulls and compressWhitespace. If you need other actions, you can customize them using the new “t” action. As before, to set a list of default actions for all rules, you can use SecDefaultAction, for example:
SecDefaultAction log, auditlog, deny, status: 403, phase: 2, t: lowercase, t: replaceNulls, t: compressWhitespace
This example is taken from the standard configuration. You can also set actions for each rule separately, either by specifying them completely, or by adding or removing them from the standard configuration. Here is an example where the compressWhitespace action has been removed and replaceComments has been added:
SecRule t: -compressWhitespace, t: replaceComments
To completely remove all normalizing functions, simply add the special word: none.
SecRule t: none, t: normalisePathWin
And if the built-in normalization functions are not enough for you, then in this case you can use the new API, which allows you to add new normalization functions without changing the source code [4].

1.11 Scan the contents of the response body

ModSecurity supports outbound filtering for Apache 2. By default, it is disabled. To use outbound filtering, use the directive
SecResponseBodyAccess On
Syntax: SecResponseBodyAccess On | Off
If scanning the contents of the response body is enabled, this allows the response body to be analyzed according to the rules using the RESPONSE_BODY argument.
It should be noted that although it is possible to mix the output and input filters, they are not executed simultaneously. Input filters are executed before the Apache request is processed, while the output filters are executed after Apache has completed processing the request.
The skipAfter and chain actions do not work with output filters.
Output filtering is used only for output in plain-text and HTML. Applying regular expressions to binary data (for example, to images) will heavily load the server. By default, ModSecurity scans the output in responses that do not specify a Content Type or Content Type is text / plan or text / html. This can be changed using the SecResponseBodyMimeType directive:
SecResponseBodyMimeType (null) text / html text / plain
Syntax: SecResponseBodyMimeType In this configuration, ModSecurity will apply output filters to plain-text files, HTML files and files whose MIME type is not specified.
When using buffering, ModSecurity keeps the entire page in memory, regardless of page size.
Outgoing monitoring is a useful feature under certain circumstances. It should ensure that it can not be circumvented. If the attacker has full control over the processing of the request, he can bypass the outgoing monitoring in two ways.
• Use Content-Type that is not viewable. For performance reasons, it is not possible to view all content types.
• Some way to transcode the output. Even the simplest transcoding can fool monitoring.

1.12 Implicit validation check

Implicit validation of the request (if configured) is performed only at the beginning of the processing of the request. This check consists of checks for the query string and headers.
Comment. Unicode validation check does not apply to the contents of the Referer header as part of the initial implicit validation request. This is done because this header often contains information about other Web sites, and their coding is usually different from the coding used on the protected Web site.

1.13 Filter Inheritance

Filters defined in parent directories are usually inherited in nested Apache contexts. This behavior is acceptable (and required) in most cases, but not always. Sometimes it is necessary to weaken the checks for some part of the site. Using the SecRuleInheritance Off directive, you can specify ModSecurity to ignore the parent filters, thereby starting the rules again. This directive only affects the rules. The configuration is always inherited from the parent context, but it can be overridden using the appropriate configuration directives.
Comment. By default, configuration and rules inheritance is always performed. If the context is below the one in which inheritance is allowed, you should explicitly prohibit inheritance again when necessary.

1.14 Cookies

ModSecurity provides full support for cookies. By default, cookies are processed as version 0 format. However, version 1 cookies (as defined in RFC 2109) are also supported. In order to enable support for cookie version 1, you need to use the following directive:
SecCookieFormat 1
The syntax of this command is: SecCookieFormat 0 | 1

1.15 ModSecurity interaction with packet filter

In some cases, after finding a particular dangerous attack or series of attacks, you may want to prevent further attacks from a particular source. This can be done by modifying the firewall so that it rejects all traffic coming from a specific IP address [3].
This method can be very dangerous, as its result can be a DoS attack. For example, an attacker can use a proxy to launch attacks. Rejecting all requests from the proxy server can be very dangerous, since it will also affect all legitimate users.
Since most proxies send information describing the source client, you can try to determine the real IP address. Consider the following scenario.
The attacker wants to get direct access to the application, but tries to act as a proxy, indicating a random (or valid) IP address as the real IP address of the source. If we start rejecting requests based on this received information, the attacker can simply change the IP address and continue the attack. As a result, access for legitimate users may be denied, while the attacker may continue to search for vulnerabilities in the application.
Therefore, this method can be used only when access to the application through a proxy is not allowed or access is only allowed through those proxies that are trusted.
If, however, there is a need to deny requests based on IP addresses, you must use a script that will be executed when the query matches the filter. The script must extract the attacker's IP address from environment variables and then call a packet filter to deny access from this IP address.

1.16 Special Features

File upload support
ModSecurity has the ability to intercept files that are loaded using POST requests and multipart / form-data encoding or using PUT requests.
ModSecurity always uploads files to a temporary directory. This can be changed using the SecUploadDir directive:
SecUploadDir / tmp
To store files, it is better to use a directory to which only users of the Web server are allowed. Otherwise, other server users can also access files uploaded through the web server.

Store downloaded files
It is possible to upload files via a web server. To do this, simply add the following line to the configuration
SecUploadKeepFiles On
The directory in which files are stored is determined using the directive SecUploadDir.

Hiding server identification
One of the technologies that allows attackers to be confused is the change in the identification of the Web server. Web servers typically send their identification on each HTTP response in the Server header.
To change the identity of the Web server, you can find its name (for example, “Apache”) in the source code, replace it and recompile the server. The same result can be obtained using the SecServerSignature directive:
SecServerSignature "Microsoft-IIS / 5.0"
SecServerSignature "Apache / 2.2.4 (Fedora)"
It should be noted that, although this procedure works quite well, qualified attackers (and tools) can use other technologies to obtain the “fingerprint” of the Web server. For example, the default files, the error message, the sequence of headers in the response, the way the server responds to certain requests, and the like - all this can give the correct identification.
Chroot support
Standard approach
ModSecurity includes support for Apache file system isolation or chroot. After the chroot operation is completed, the application cannot access outside the specified directory.
Unfortunately, it is not always easy to do. The problem is that applications usually require shared libraries and various other files to function correctly.
ModSecurity approach
A special directive has been added to ModSecurity that allows you to successfully chroot.
SecChrootDir / chroot / apache
In addition to simplicity, this approach has other advantages. Unlike the execution of an external chroot, when running chroot ModSecurity it is not required that there are additional files in the specified directory. A chroot call is made after the Web server is initialized, but before performing a fork. As a result, all shared libraries are already loaded, all modules of the Web server are initialized and log files are open. In the specified directory must be only data.
Nevertheless, there are several cases when additional files should be placed in this directory. This is necessary if execution of CGI scripts or other systems is required.

1.17 Solving Common Security Problems

ModSecurity features can be used to identify and prevent the most common security issues. In more detail, protection against attacks on Web applications is discussed in the specialized literature [4, 5]. Consider some of them.

1.17.1 Navigating the Directory

If some script should have access to the file system, then you should pay attention to some metacharacters and constructs. For example, a combination of ../ characters in the path means moving one level up in the directory. Such a sequence of characters should not occur in requests and should be prohibited using the following filter:
SecRule REQUEST_URI "... /" "t: urlDecode, deny"

1.17.2 Normalization of the path

Filters do not apply to the original request data — first they are normalized. This is done because an attacker can use various techniques to hide a certain sequence of characters to avoid attack detection. ModSecurity can automatically apply the following transformations:
converts to Windows in /;
lowers /./ to /;
lowers // to /;
decodes URL characters.
Two functions are used to normalize the path: normalizePath and normalisePathWin.
This rule demonstrates the ability of ModSecurity to normalize the path.
SecRule REQUEST_URI "pass, t: - normalisePathWin„

1.17.3 Prevent null byte attacks

Attacks of null byte are trying to deceive software written in C / C ++, forcing him to believe that the line ends earlier than it actually is. This type of attack is usually prevented by the normalize function removeNulls and replaceNulls. If you do not filter out null byte, then this may affect subsequent filtering. Possible syntax of the null byte filtering command:
SecDefaultAction “phase: 2, deny, log, status: 403, t: removeNulls»
SecRule ARGS: data "pass, t: -removeNulls"

1.18 Event Logging

If your server is being attacked, it is very important to get a picture of what the attacker is trying to do. Does he use a pre-packaged script to try to log in to your server? Or is someone trying to hack your server using SQL injection through a foreign proxy server?
Viewing ModSecurity audit logs on a regular basis is important to have information about what actions they are trying to take against your server. In some cases, based on this data, you can discover new vulnerabilities of your server and take necessary measures to protect against these actions.
Standard Apache audit logs can not give more information about events than the time and date of the request, its type (Post or Get). ModSecurity enters audit logs that allow the server to log much more detailed information about the requests addressed to your server. Using audit logs, you can get information about the headers and body of the request, as well as information about the headers and body of the answer and all the rules that apply to the request.

1.18.1 Enable the event logging mechanism

Event logging is disabled by default. You can enable the event logging mechanism by placing the SecAuditEngine directive in the ModSecurity configuration file. Here are the possible values ​​for the SecAuditEngine directive.
1) SecAuditEngine On
Enables event logging for all operations.
2) SecAuditEngine Off
Turns off event logging.
3) SecAuditEngine RelevantOnly
Includes logging of only events that match the rule or that have a status code that matches the regular expression generated via the SecAuditLogRelevantStatus directive.
In most cases, it is best to use the SecAuditEngine RelevantOnly directive to register transactions that are actually considered relevant (i.e., those that comply with the ModSecurity rules and have the corresponding HTTP status code). Using the directive SecAuditEngine On allows you to record all operations, but it will consume a lot of disk space and load the server.
The SecAuditLogRelevantStatus directive takes as its parameter a regular expression that is matched against the HTTP response code for the operation. So for registering operations that produce an HTTP error (status code 400-599), you can use the following:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^ [1]

1.18.2 Registration Format

There are two types of control registration formats that can be used: serial (serial) and parallel (concurrent). Sequential registration registers all control events in a single file, parallel event registration places registration data for each request into a separate file. The type of registration format is formed through the directive SecAuditLogType. There are advantages to each registration format. With parallel logging, system log files are placed in separate logs corresponding to the time of event logging. Using a parallel logging format, we need to form a directory where ModSecurity will create separate log files. This is done using the SecAuditLogStorageDir directive.
With a parallel event logging format, ModSecurity creates a specific directory structure in which separate audit log files are placed. The directory structure is as follows.
/ logs / data /
| - 20090331
| | - 20090331-1530
| | | - 20090331-153030-Cei44F5MziQAAFKTAIcAAAAA
| | | - 20090331-153030-Cei5115MziQAAFKUAM0AAAAB
| | | - 20090331-153030-CgEmHV5MziQAAFKVAS0AAAAC
| | | - 20090331-153054-C1JA815MziQAAFKoBfIAAAAV
| | `- 20090331-153054-C1JIqV5MziQAAFKVAS4AAAAC
| | - 20090331-1531
| | | - 20090331-153100-C6skpV5MziQAAFKUAM4AAAAB
| | | - 20090331-153105-C @ gA6F5MziQAAFKgBD0AAAAN
| | | - 20090331-153109-DBTxLV5MziQAAFKhBKAAAAAO
| | `- 20090331-153118-DLyqv15MziQAAFKeA8AAAAAL
| | - 20090331-1532
| - 20090401
| | - 20090401-0208
| | | - 20090401-020802-8H1Ox15MziQAAFPGEv4AAAAI
| | | - 20090401-020802-8esmr15MziQAAF0tGXAAAAAD
| | | - 20090401-020805-8RWbIF5MziQAAFNbCN8AAAAy
...
ModSecurity produces a new directory for each day (for example, the magazine named 20090331 contains audit log files produced on March 31st, 2009). Each of these logs contains separate subdirectories with event logs made at a specific time (for example, the log named 20090331-1530 contains all audit log files for queries made at 3:30 in the afternoon of March 31st).

1.18.3 SecAuditLogParts

SecAuditLogParts , . , 1.3.
: SecAuditLogParts <>
: SecAuditLog ABCFHZ

1.3 – SecAuditLogParts

1.18.4

, .
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4\d[^4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs/data/
SecAuditLog bin/mlogc.exe
SecAuditLog "|bin/mlogc.exe bin/mlogc.conf"

1.18.5

, , . .
--ae720000-A--
[11/Nov/2011:14:19:17 +0500] TrzolcCoCgIAAAsYBPwAAAD5 192.168.10.5 65004 192.168.10.2 80
--ae720000-B--
GET /webgoat/images/buttons/hint.jpg HTTP/1.1
Host: 192.168.10.2
Connection: keep-alive
Referer: 192.168.10.2/webgoat/attack
Authorization: Basic Z3Vlc3Q6Z3Vlc3Q=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU, ru; q = 0.8, en-US; q = 0.6, en; q = 0.4
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=CD7576D71A7DD34291918F65FD215FCD
If-None-Match: W/«563-1257685080000»
If-Modified-Since: Sun, 08 Nov 2009 12:58:00 GMT
--ae720000-F--
HTTP/1.1 304 Not Modified
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 05:00:00 GMT
ETag: W/«563-1257685080000»
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/plain
--ae720000-E--
--ae720000-H--
Message: Warning. Pattern match "^[\\d.:]+$" at REQUEST_HEADERS:Host. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf»] [line «98»] [id «960017»] [rev «2.2.2»] [msg «Host header is a numeric IP address»] [severity «CRITICAL»] [tag «PROTOCOL_VIOLATION/IP_HOST»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [tag « technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx »]
Message: Warning. Operator LT matched 5 at TX:inbound_anomaly_score. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf»] [line «33»] [id «981203»] [msg «Inbound Anomaly Score (Total Inbound Score: 2, SQLi=, XSS=): Host header is a numeric IP address»]
Apache-Handler: proxy-server
Stopwatch: 1321003157121875 31250 (- — -)
Stopwatch2: 1321003157121875 31250; combined=0, p1=0, p2=0, p3=0, p4=0, p5=0, sr=0, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.2 (http://www.modsecurity.org/); core ruleset/2.2.2.
Server: Apache/2.2.21 (Win32) proxy_html/3.1.2
--ae720000-Z--
--ae720000-A--. . SecAuditLogParts.
, , 192.168.10.5, ModSecurity, «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf — »PROTOCOL_VIOLATION/IP_HOST" «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf» «Inbound Anomaly Score (Total Inbound Score: 2, SQLi=, XSS=): Host header is a numeric IP address»]
modsec_debug.log .
11/Nov/2011:11:21:34 +0500] [192.168.10.2/sid#5e5148][rid#4aec970][/webgoat/attack][2] Warning. Found 1 byte(s) in ARGS:Screen outside range: 1-255. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_20_protocol_violations.conf»] [line «353»] [id «960901»] [rev «2.2.2»] [msg «Invalid character in request»] [severity «WARNING»] [tag «PROTOCOL_VIOLATION/EVASION»] [tag «WASCTC/WASC-28»] [tag «OWASP_TOP_10/A1»] [tag «OWASP_AppSensor/RE8»] [tag «PCI/6.5.2»] [tag « i-technica.com/whitestuff/asciichart.html »]
[11/Nov/2011:11:21:34 +0500] [192.168.10.2/sid#5e5148][rid#4aec970][/webgoat/attack][2] Warning. Pattern match "^[\\d.:]+$" at REQUEST_HEADERS:Host. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_21_protocol_anomalies.conf»] [line «98»] [id «960017»] [rev «2.2.2»] [msg «Host header is a numeric IP address»] [severity «CRITICAL»] [tag «PROTOCOL_VIOLATION/IP_HOST»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [tag « technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx »]

c Web- ErrorLog.
[Tue Nov 29 16:57:03 2011] [error] [client 192.168.10.5] ModSecurity: Warning. Pattern match "\\\\bacunetix-product\\\\b" at REQUEST_HEADERS_NAMES:Acunetix-Product. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_35_bad_robots.conf»] [line «22»] [id «990901»] [rev «2.2.2»] [msg «Request Indicates a Security Scanner Scanned the Site»] [severity «WARNING»] [tag «AUTOMATION/SECURITY_SCANNER»] [tag «WASCTC/WASC-21»] [tag «OWASP_TOP_10/A7»] [tag «PCI/6.5.10»] [hostname «192.168.10.2»] [uri "/lessons/RoleBasedAccessControl/images/"] [unique_id «TtTIj8CoCgIAAAgcQw8AAADj»]
[Tue Nov 29 16:57:03 2011] [error] [client 192.168.10.5] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file «C:/Apache2/conf/rules/base_rules/modsecurity_crs_60_correlation.conf»] [line «37»] [id «981204»] [msg «Inbound Anomaly Score Exceeded (Total Inbound Score: 5, SQLi=, XSS=): Request Indicates a Security Scanner Scanned the Site»] [hostname «192.168.10.2»] [uri "/lessons/RoleBasedAccessControl/images/"] [unique_id «TtTIj8CoCgIAAAgcQw8AAADj»]

1. Barnett, Ryan C. Preventing Web Attacks with Apache. USA: Addison-Wesley Publishing, 2006. 240 .
2. Magnus Mischel ModSecurity 2.5.Securing your Apache installation and web applications. England: Published by Packt Publishing, 2009. 280 c.
3. ModSecurity Reference Manual // www.modsecurity.org/documentation/modsecurity-apache/2.2.4/modsecurity-manual.html
4. Ryan Barnett Center for Internet Security Benchmark for Apache Web Server v2.1. USA: The Center for Internet Security (CIS), 2009. 50c.
5. Securing WebGoat Using ModSecurity. USA: OWASP Foundation, 2008. 130 c.