Rechercher

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Creating ModSecurity rules

download PDF

ModSecurity primarily functions based on custom user-defined rules. These rules determine the types of security checks that ModSecurity performs.

4.1. ModSecurity rules in the Apache request cycle

You can apply rules to any of the five ModSecurity processing phases of the Apache request cycle:

Request headers
Apply a ModSecurity rule to this phase by specifying a REQUEST_HEADERS variable in the rule syntax.
Request body
Apply a ModSecurity rule to this phase by specifying a REQUEST_BODY variable in the rule syntax.
Response headers
Apply a ModSecurity rule to this phase by specifying a RESPONSE_HEADERS variable in the rule syntax.
Response body
Apply a ModSecurity rule to this phase by specifying a RESPONSE_BODY variable in the rule syntax.
Logging
Apply a ModSecurity rule to this phase by specifying a LOGGING variable in the rule syntax.

4.2. Structure of ModSecurity rules

A ModSecurity rule typically consists of four main parts:

  • A configuration directive
  • One or more variables
  • One or more operators
  • One or more actions

4.3. ModSecurity configuration directives

A ModSecurity rule starts with a configuration directive. The configuration directives for ModSecurity are similar to the Apache HTTP Server directives. You can use most ModSecurity directives within the various Apache scope directives. However, you may only use some ModSecurity directives once in the main configuration file.

You must store these rules and the core rule files outside of the httpd.conf file. You can use Apache Include directives to call these rules. This facilitates the upgrade and migration of the rules.

4.4. Example of a simple ModSecurity rule

You can define the following simple ModSecurity rule, for example, to check if the URI portion of a request equals a specific lowercase value:

SecRule REQUEST_URI "@streq /index.php" "id:1,phase:1,t:lowercase,deny"

The preceding ModSecurity rule consists of the following compoonents:

SecRule

A configuration directive that creates a rule to analyze the specified variables by using the specified operator

Note

Most ModSecurity rules use this configuration directive.

REQUEST_URI
A variable that holds the full request URL including the query string data
"@streq /index.php"
An operator where @streq checks for string values that are equal to /index.php
"id:1,phase:1,t:lowercase,deny"

Actions or transformations that the rule performs

Note

The rule performs the lowercase action first before the rule implements the preceding operator instruction.

Based on the preceding example, during phase 1 of the Apache request cycle, the rule obtains the URI portion of the HTTP request and transforms the value to lowercase. The rule then checks if the transformed value equals /index.php. If the value does equal /index.php, ModSecurity denies the request and does not process any further rules.

4.5. Example of a complex ModSecurity rule

You can define the following complex ModSecurity rule, for example, to check if a request has changed history:

SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS "history.pushstate|history.replacestate" "phase:4,deny,log,msg:'history-based attacks detected'"

The preceding ModSecurity rule consists of the following components:

SecRule

A configuration directive that creates a rule to analyze the specified variables by using the specified operator

Note

Most ModSecurity rules use this configuration directive.

`REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS_NAMES|REQUEST_HEADERS `
A pipe-separated list of variables that define different parts of the request that the rule checks
"history.pushstate|history.replacestate"
A pipe-separated pair of operators that check for the JavaScript history.pushstate() and history.replacestate() methods
"phase:4,deny,log,msg:'history-based attacks detected'"
Actions or transformations that the rule performs if the specified operator values are found

Based on the preceding example, during phase 4 of the Apache request cycle, the rule checks different parts of the request cycle for history.pushstate() and history.replacestate() methods. If the rule finds these methods in the request URL string, request body, request header names, or request headers, the rule performs the following actions:

  • deny

    Stops the rule processing and intercepts the transaction

  • log

    Logs a successful match of the rule to the Apache error log file and the ModSecurity audit log

  • msg

    Outputs a message defined as history-based attacks detected with the log

4.6. Additional resources (or Next steps)

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.