Directives :: WGE

SecRuleEngine

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the operating mode of the rule engine. Syntax: SecRuleEngine On|Off|DetectionOnly Default: Off Options: On: Enable the rule engine, execute all rules and apply disruptive actions Off: Disable the rule engine, no rules are executed DetectionOnly: Detection-only mode, execute rules but do not apply disruptive actions Case Sensitive: Yes Example: SecRuleEngine On

SecRequestBodyAccess

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure whether the WAF is allowed to access request body content. Syntax: SecRequestBodyAccess On|Off Default: Off Case Sensitive: Yes This directive must be enabled to inspect data transmitted in the request body (such as POST parameters). Request buffering is also essential for reliable blocking. Options: On: Buffer and inspect the request body Off: Do not buffer the request body This directive does not actually affect whether WGE buffers the request body, because WGE cannot control the buffering action itself - it can only passively receive the request body from the server. For this directive to take effect, related logic needs to be added in the server.

SecRequestBodyLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum acceptable request body size in bytes. Syntax: SecRequestBodyLimit LIMIT Default: 134217728 (128MB) Case Sensitive: Yes Implemented: No Requests exceeding this limit will be rejected with a 413 (Request Entity Too Large) status code. The hard upper limit is 1 GB. Example: SecRequestBodyLimit 134217728

SecRequestBodyNoFilesLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum request body size in bytes for requests without file uploads. Syntax: SecRequestBodyNoFilesLimit LIMIT Default: 1048576 (1MB) Case Sensitive: Yes Implemented: No Example: SecRequestBodyNoFilesLimit 131072

SecRequestBodyLimitAction

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure how to handle requests when the body exceeds the SecRequestBodyLimit. Syntax: SecRequestBodyLimitAction Reject|ProcessPartial Default: ProcessPartial Options: Reject: Reject requests that exceed the limit ProcessPartial: Only inspect the portion of the request body that fits within the limit, pass through the rest Case Sensitive: Yes Implemented: No This means that even if the request body size exceeds the SecRequestBodyLimit setting, it will not affect rule execution or WGE’s internal state.

SecRequestBodyJsonDepthLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum parsing depth for JSON objects. Syntax: SecRequestBodyJsonDepthLimit DEPTH Default: 0 (unlimited) Case Sensitive: Yes Implemented: No When parsing JSON objects, if the nesting level exceeds the configured depth limit, parsing will terminate and set a REQBODY_ERROR error. Example: SecRequestBodyJsonDepthLimit 512

SecResponseBodyAccess

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure whether the WAF is allowed to access response body content. Syntax: SecResponseBodyAccess On|Off Default: Off Case Sensitive: Yes Implemented: No Example: SecResponseBodyAccess On

SecResponseBodyMimeType

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure which response body MIME types should be inspected. Syntax: SecResponseBodyMimeType MIME_TYPE1 MIME_TYPE2 ... Case Sensitive: Yes Implemented: No If you need this functionality, you can use content-type and skip/skipafter to control whether rules are executed for specific MIME types. Alternatively, you can read the configuration parsed by WGE in the server and use it to determine whether to pass the body. When this directive appears multiple times, the final parsed result is a merge of all directives.

SecResponseBodyLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum response body buffer size in bytes. Syntax: SecResponseBodyLimit LIMIT Default: 524288 (512KB) Case Sensitive: Yes Implemented: No Example: SecResponseBodyLimit 524288

SecArgumentsLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum number of acceptable parameters. Syntax: SecArgumentsLimit LIMIT Case Sensitive: Yes Implemented: No When using this setting, it is recommended to combine it with rules that detect the same integer value and reject requests when the limit is reached. For example: If a matching rule is not configured, an attacker may evade detection by placing attack payloads in parameters beyond the limit. Example: SecArgumentsLimit 1000

SecArgumentSeparator

Mon, 01 Jan 0001 00:00:00 +0000

Description: Specify the parameter separator character used for application/x-www-form-urlencoded content. Syntax: SecArgumentSeparator CHARACTER Default: & Case Sensitive: Yes Implemented: No This directive is required when the backend web application uses a non-standard parameter separator. Some applications use semicolons as separators. Do not change the default setting unless you confirm that the application you are protecting requires a different separator. If this directive is not correctly configured for each web application, parameters will not be parsed correctly, significantly reducing rule matching effectiveness.

SecPcreMatchLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum number of PCRE regular expression matches to prevent ReDoS attacks. Syntax: SecPcreMatchLimit LIMIT Default: 0 Case Sensitive: Yes Since WGE currently uses re2 as the default regex matching library, PCRE is only used as a fallback when re2 fails to compile the regex, so this configuration has minimal impact. Example: SecPcreMatchLimit 3000

SecPcreMatchLimitRecursion

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the PCRE regular expression recursion depth limit. Syntax: SecPcreMatchLimitRecursion LIMIT Default: 1000 Case Sensitive: Yes Implemented: No Example: SecPcreMatchLimitRecursion 1000

SecTmpDir

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the temporary file storage directory. Syntax: SecTmpDir PATH Case Sensitive: Yes Implemented: No This directory is used to store temporary files during request body processing, especially when the request body size exceeds the SecRequestBodyInMemoryLimit setting. The WAF will write the excess portion to this directory. The directory must have write permissions for the user running the WAF process. Example: SecTmpDir /tmp/

SecDataDir

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the persistent data storage directory. Syntax: SecDataDir PATH Case Sensitive: Yes Implemented: No This directory is used to store persistent data such as IP reputation records, session data, user tracking data, etc. The WAF uses this directory to save collection data that needs to persist across requests (initialized through the initcol action). The directory must have write permissions for the user running the WAF process. Example: SecDataDir /var/lib/wge/

SecUnicodeMapFile

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the Unicode mapping file path and code page. Syntax: SecUnicodeMapFile PATH CODEPAGE Case Sensitive: Yes Implemented: No This directive defines the Unicode mapping file path used by the urlDecodeUni transformation function. The code page parameter specifies the target character encoding (e.g., 20127 represents US-ASCII). When processing URLs that use non-ASCII encoding, this configuration ensures correct character conversion. Example: SecUnicodeMapFile unicode.mapping 20127

SecDebugLog

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the debug log file path. Syntax: SecDebugLog PATH Case Sensitive: Yes Implemented: No The debug log records detailed runtime information from the WAF rule engine and is very useful for rule debugging and troubleshooting. The verbosity level of the debug log is controlled by SecDebugLogLevel. It is recommended to enable debug logging in production environments only when troubleshooting issues. Example: SecDebugLog /var/log/wge_debug.log

SecDebugLogLevel

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the verbosity level of the debug log. Syntax: SecDebugLogLevel LEVEL Default: 0 Options: 0: No logging 1: Errors only 2: Warnings 3: Notices 4: Detailed information 5: Debug information 9: Most verbose Case Sensitive: Yes Implemented: No Keeping debug logging always enabled in production environments is generally not recommended. Even when troubleshooting specific issues, be aware that using level 4 or higher will significantly impact performance. Debug log level value range:

SecStatusEngine

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the status engine for collecting and reporting runtime statistics. Syntax: SecStatusEngine On|Off Default: Off Case Sensitive: Yes Implemented: No When enabled, the status engine collects WAF runtime statistics including the number of requests processed, rule matches, blocks, and more. This information helps monitor WAF performance and security posture. Example: SecStatusEngine On

SecCookieFormat

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the cookie parsing format version. Syntax: SecCookieFormat VERSION Default: 0 Options: 0: Use Netscape cookie format (version 0) 1: Use RFC 2109 cookie format (version 1) Case Sensitive: Yes Implemented: No Example: SecCookieFormat 0

SecCollectionTimeout

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the expiration time (seconds) for persistent collections. Syntax: SecCollectionTimeout SECONDS Default: 3600 Case Sensitive: Yes Implemented: No Persistent collections (such as IP, SESSION, USER, etc.) are used to track data across requests. This directive defines the lifetime of collection records. After this time, collection records will be automatically cleaned up. Setting this value appropriately can balance security tracking needs and storage space usage. Example: SecCollectionTimeout 3600

SecRequestBodyInMemoryLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum size of request body buffered in memory; content exceeding this limit will be written to a temporary file. Syntax: SecRequestBodyInMemoryLimit LIMIT Case Sensitive: Yes Implemented: No This directive controls how much request body data the WAF keeps in memory. When the request body size exceeds this limit, the excess portion will be written to the temporary directory specified by SecTmpDir. Setting this value appropriately balances memory usage and I/O performance.

SecResponseBodyMimeTypesClear

Mon, 01 Jan 0001 00:00:00 +0000

Description: Clear all response body MIME type configurations. Syntax: SecResponseBodyMimeTypesClear Case Sensitive: Yes This directive clears all MIME types previously configured through SecResponseBodyMimeType, allowing you to redefine which response types need to be buffered from scratch. Typically used to override inherited configurations. Example: SecResponseBodyMimeTypesClear SecResponseBodyMimeType text/html text/plain

SecResponseBodyLimitAction

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure how to handle responses when the body exceeds the SecResponseBodyLimit. Syntax: SecResponseBodyLimitAction Reject|ProcessPartial Default: ProcessPartial Options: Reject: Reject responses that exceed the limit ProcessPartial: Only inspect the portion of the response body that fits within the limit, pass through the rest Case Sensitive: Yes Implemented: No Example: SecResponseBodyLimitAction ProcessPartial

SecXmlExternalEntity

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure whether XML external entity processing is allowed. Syntax: SecXmlExternalEntity On|Off Default: Off Case Sensitive: Yes Implemented: No Example: SecXmlExternalEntity Off

SecGeoLookupDb

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the geolocation database file path for the @geoLookup operator. Syntax: SecGeoLookupDb PATH Case Sensitive: Yes Implemented: No Example: SecGeoLookupDb /usr/share/GeoIP/GeoLite2-Country.mmdb

SecHttpBlKey

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the HTTP Blacklist (Project Honeypot) API key for @rbl usage. Syntax: SecHttpBlKey API_KEY Case Sensitive: Yes Implemented: No Example: SecHttpBlKey abcdefghijkl

SecRemoteRules

Mon, 01 Jan 0001 00:00:00 +0000

Description: Load rule configuration from a remote HTTPS server. Case Sensitive: Yes Implemented: No This directive allows dynamically loading rules from a remote server, facilitating centralized management and updates of security policies. The KEY parameter is used for authentication, allowing the target server to provide differentiated rule sets for different clients. Example: SecRemoteRules some-key https://example.com/rules.conf

SecRemoteRulesFailAction

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure how to handle remote rule loading failures. Case Sensitive: Yes Implemented: No Example: SecRemoteRulesFailAction Warn

SecWebAppId

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the web application identifier to distinguish between different applications. Syntax: SecWebAppId NAME Case Sensitive: Yes Implemented: No Example: SecWebAppId "MyWebApp"

SecComponentSignature

Mon, 01 Jan 0001 00:00:00 +0000

Description: Add component signature information to the log. Syntax: SecComponentSignature "SIGNATURE" Case Sensitive: Yes Implemented: No This directive is used to identify the presence of important rule sets. The complete signature will be recorded in the transaction audit log. Example: SecComponentSignature "OWASP_CRS/3.3.2"

SecTmpSaveUploadedFiles

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure whether to save uploaded files to the temporary directory. Syntax: SecTmpSaveUploadedFiles On|Off Default: Off Case Sensitive: Yes Implemented: No When enabled, files uploaded via multipart/form-data will be saved to the temporary directory specified by SecTmpDir. This allows rules to use the @inspectFile operator for deep inspection of uploaded files (such as virus scanning). Example: SecTmpSaveUploadedFiles On

SecUploadDir

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the storage directory for file uploads. Syntax: SecUploadDir PATH Case Sensitive: Yes Implemented: No This directory must be on the same filesystem as the temporary directory defined by SecTmpDir. This directive should be used in conjunction with SecUploadKeepFiles. This directive is not implemented in WGE and cannot be used. Example: SecUploadDir /var/lib/wge/upload/

SecUploadFileLimit

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the maximum number of files allowed to be uploaded in a single request. Syntax: SecUploadFileLimit INT Default: 0 Case Sensitive: Yes When the number of uploaded files exceeds the configured value, the error flag MULTIPART_FILE_LIMIT_EXCEEDED will be set. This error value, along with other multipart/form-data format errors, is included in the variable MULTIPART_STRICT_ERROR. Example: SecUploadFileLimit 10

SecUploadFileMode

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the permission mode for uploaded files (octal). Syntax: SecUploadFileMode MODE Case Sensitive: Yes Implemented: No This directive is not implemented in WGE and cannot be used. Example: SecUploadFileMode 0640

SecUploadKeepFiles

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure whether to keep uploaded files after request processing is complete. Syntax: SecUploadKeepFiles On|Off Default: Off Options: On: Keep all uploaded files Off: Do not keep uploaded files Case Sensitive: Yes Implemented: No This directive requires that the storage directory has been defined via SecUploadDir. Example: SecUploadKeepFiles RelevantOnly

SecRule

Mon, 01 Jan 0001 00:00:00 +0000

Description: Define a security rule. Syntax: SecRule VARIABLES "OPERATOR" "ACTIONS" Case Sensitive: Yes SecRule is the most important directive in SecLang, used to define rules for detecting and responding to security threats. A rule consists of three parts: Variables (VARIABLES): Specify the data sources to inspect, such as ARGS for query parameters Operator (OPERATOR): Define the matching conditions, including regex matching, comparison, etc. Actions (ACTIONS): Contains configuration actions like phase and id, transformation functions, and post-match actions like setvar The execution logic of a SecRule: obtain the data to be matched from the variables (VARIABLES), process the data through transformation functions for encoding/decoding operations (such as t:urlDecode for URL decoding), perform the specified matching operation on the decoded data, execute post-match actions (such as setvar) after a successful match, and if there are chained rules, continue executing them.

SecAction

Mon, 01 Jan 0001 00:00:00 +0000

Description: Unconditionally execute the specified actions. Syntax: SecAction "ACTIONS" SecAction is used to unconditionally execute a set of actions, commonly used for setting variables, initializing collections, etc. Case Sensitive: Yes SecAction unconditionally processes the specified action list, and its parameter syntax is identical to the third parameter of SecRule. This directive is commonly used for setting variables and initializing persistent collections through the initcol action. Because there are no variable and operator parameters, SecAction’s actions will be executed unconditionally during each processing.

SecDefaultAction

Mon, 01 Jan 0001 00:00:00 +0000

Description: Define the default action list for a specific phase. Syntax: SecDefaultAction "ACTIONS" Case Sensitive: Yes SecDefaultAction sets a series of actions that will be inherited by all rules in the same phase. Therefore, SecDefaultAction must contain a phase. If there are multiple SecDefaultAction directives in the same phase, the later one will replace the earlier one. SecDefaultAction mainly affects three aspects: Transformation functions: Transformation functions in SecDefaultAction will be executed by all rules in the same phase, and executed before their own transformation functions, unless the rule has t:none; Disruptive actions: Rules using block will determine whether to block based on whether the DefaultAction in the same phase has disruptive actions (such as allow, deny); Post-match actions: Actions like setvar, ctl, etc. - when rules in the same phase match successfully, they will first execute DefaultAction and then execute their own actions. Example:

SecRuleRemoveById

Mon, 01 Jan 0001 00:00:00 +0000

Description: Remove rules by ID. Syntax: SecRuleRemoveById [ID|ID_RANGE] ... Case Sensitive: Yes This directive supports multiple parameters, each of which can be a rule ID or range. Note: SecRuleRemoveById should be loaded last; it will not take effect if it appears before the rules it intends to disable. Example: # Remove a single rule SecRuleRemoveById 1001 # Remove multiple rules SecRuleRemoveById 1001 1002 1003 # Remove a range of rules SecRuleRemoveById 1001-1100

SecRuleRemoveByMsg

Mon, 01 Jan 0001 00:00:00 +0000

Description: Remove rules by msg content. Syntax: SecRuleRemoveByMsg "STRING" Case Sensitive: Yes Typically SecRuleRemoveById is used to remove rules, but this directive supports removing rules by matching the rule’s msg action. Matching uses case-sensitive exact string matching. Like SecRuleRemoveById, it can only disable rules that appear before it. Example: SecRuleRemoveByMsg "SQL Injection Attack"

SecRuleRemoveByTag

Mon, 01 Jan 0001 00:00:00 +0000

Description: Remove rules by tag. Syntax: SecRuleRemoveByTag "STRING" Case Sensitive: Yes Typically SecRuleRemoveById is used to remove rules, but sometimes it is more convenient to disable a group of rules using SecRuleRemoveByTag. Matching is case-sensitive. Like SecRuleRemoveById, it can only disable rules that appear before it. Example: SecRuleRemoveByTag "attack-sqli"

SecRuleUpdateActionById

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update a rule’s actions by ID. Syntax: SecRuleUpdateActionById INT|(INT ':' '-'? INT) "ACTIONS" Case Sensitive: Yes This directive will override the specified rule’s action list with the actions provided in the second parameter. There are two limitations: it cannot be used to modify the rule ID or phase; it only overrides actions that can only appear once. Actions that are allowed to appear multiple times in the list will be appended to the end.

SecRuleUpdateTargetById

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update a rule’s variable list by ID. Syntax: SecRuleUpdateTargetById ID VARIABLES Case Sensitive: Yes Updates the variables (VARIABLES) of the rule with the specified ID, allowing operations such as adding or removing variables. Note: This directive is a configuration directive, not runtime - meaning skipAfter and similar directives do not affect it. It must be loaded after the rule it updates. Example: If the rule with ID 1001 is:

SecRuleUpdateTargetByMsg

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update a rule’s variable list by message content. Syntax: SecRuleUpdateTargetByMsg "MESSAGE" VARIABLES Case Sensitive: Yes Similar to SecRuleUpdateTargetById, SecRuleUpdateTargetByMsg modifies the variables of specified rules by matching the msg. For more details, see SecRuleUpdateTargetById. Example: SecRuleUpdateTargetByMsg "SQL Injection" !ARGS:id

SecRuleUpdateTargetByTag

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update a rule’s variable list by tag. Syntax: SecRuleUpdateTargetByTag "TAG" VARIABLES Case Sensitive: Yes Similar to SecRuleUpdateTargetById, SecRuleUpdateTargetByTag modifies the variables of specified rules by matching the tag. For more details, see SecRuleUpdateTargetById. Example: SecRuleUpdateTargetByTag "attack-sqli" !ARGS:search

SecRuleScript

Mon, 01 Jan 0001 00:00:00 +0000

Description: Define rule logic using Lua scripts. Syntax: SecRuleScript LUA_PATH "ACTIONS" Case Sensitive: Yes Implemented: No This directive creates a special rule that decides whether to match by executing a Lua script. The main difference from SecRule is that there are no target and operator parameters. The script can access any variables from the WAF context and use Lua operators for testing. All Lua scripts are compiled and cached in memory at configuration load time; if you need to reload scripts, you must reload the entire configuration.

SecAuditEngine

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the audit logging engine. Syntax: SecAuditEngine On|Off|RelevantOnly Default: Off Options: On: Enable audit logging for all transactions Off: Disable audit logging RelevantOnly: Only log transactions that trigger a warning/error or match the status code pattern configured via SecAuditLogRelevantStatus Case Sensitive: Yes Implemented: No Example: SecAuditEngine RelevantOnly

SecAuditLog

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the path to the primary audit log file. Syntax: SecAuditLog /path/to/audit.log Case Sensitive: Yes Implemented: No This directive defines the path to the main audit log file where the engine will write detailed information about transactions. Example: SecAuditLog /var/log/modsec_audit.log

SecAuditLog2

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the path to the secondary audit log file. Syntax: SecAuditLog2 /path/to/audit2.log Case Sensitive: Yes Implemented: No This directive defines the path to a secondary audit log file, typically used for concurrent logging or as a backup destination. Example: SecAuditLog2 /var/log/modsec_audit2.log

SecAuditLogDirMode

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the directory permission mode for concurrent audit log directories. Syntax: SecAuditLogDirMode OCTAL Default: 0600 Case Sensitive: Yes Implemented: No This directive sets the Unix permission mode for directories created when using concurrent audit logging. The value must be specified in octal format. Example: SecAuditLogDirMode 0750

SecAuditLogFormat

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the format of the audit log output. Syntax: SecAuditLogFormat Native|JSON Default: Native Options: Native: Use the traditional ModSecurity audit log format JSON: Output audit log entries in JSON format for easier parsing Case Sensitive: Yes Implemented: No Example: SecAuditLogFormat JSON

SecAuditLogFileMode

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the file permission mode for audit log files. Syntax: SecAuditLogFileMode OCTAL Default: 0600 Case Sensitive: Yes Implemented: No This directive sets the Unix permission mode for audit log files created when using concurrent audit logging. The value must be specified in octal format. Example: SecAuditLogFileMode 0640

SecAuditLogParts

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure which parts of a transaction should be recorded in the audit log. Syntax: SecAuditLogParts PARTS Default: ABCFHZ Parts: A: Audit log header (mandatory) B: Request headers C: Request body (only if request body access is enabled and the body exists) D: Reserved for intermediary response headers E: Response body (only if response body access is enabled and the body exists) F: Final response headers G: Reserved for actual response body H: Audit log trailer (contains additional data) I: Compact request body (alternative to C, excludes files) J: Reserved for upload file information K: List of all rules that matched Z: Final boundary marker (mandatory) Case Sensitive: Yes

SecAuditLogRelevantStatus

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure which HTTP response status codes are considered relevant for audit logging. Syntax: SecAuditLogRelevantStatus REGEX Case Sensitive: Yes Implemented: No This directive defines a regular expression pattern to match HTTP response status codes. When SecAuditEngine is set to RelevantOnly, only transactions with matching response status codes will be logged. Example: SecAuditLogRelevantStatus "^(?:5|4(?!04))" This example logs all 5xx errors and 4xx errors except 404.

SecAuditLogStorageDir

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the directory for storing individual audit log files in concurrent mode. Syntax: SecAuditLogStorageDir /path/to/dir Case Sensitive: Yes Implemented: No This directive specifies the directory where individual audit log files will be stored when using concurrent audit logging (SecAuditLogType Concurrent). Each transaction will have its own file in this directory. Example: SecAuditLogStorageDir /var/log/modsec_audit

SecAuditLogType

Mon, 01 Jan 0001 00:00:00 +0000

Description: Configure the type of audit logging mechanism. Syntax: SecAuditLogType Serial|Concurrent Default: Serial Options: Serial: Write all audit log entries to a single file (specified by SecAuditLog), suitable for low-traffic environments Concurrent: Create separate files for each transaction in the directory specified by SecAuditLogStorageDir, suitable for high-traffic environments Case Sensitive: Yes Implemented: No Example: SecAuditLogType Concurrent

SecMarker

Mon, 01 Jan 0001 00:00:00 +0000

Description: Create a rule marker that can be used as a target for the skipAfter action. Syntax: SecMarker LABEL Case Sensitive: Yes SecMarker creates a fixed-position rule marker that serves as a target for the skipAfter action. When skipAfter is triggered, rule processing skips forward to the marker with the matching label. This enables conditional rule execution by allowing groups of rules to be skipped. The marker itself does not perform any action; it simply serves as a jump target.

Include

Mon, 01 Jan 0001 00:00:00 +0000

Description: Include an external configuration file into the current configuration. Syntax: Include /path/to/file.conf Case Sensitive: Yes This directive includes the contents of an external configuration file at the current position. It supports both absolute paths and relative paths (relative to the current configuration file). Wildcards can be used to include multiple files. This is commonly used to organize rule sets into separate files for easier management. Example: Include /etc/modsecurity/crs/crs-setup.conf Include /etc/modsecurity/crs/rules/*.conf

SecRuleUpdateOperatorById

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update the operator of an existing rule by its ID. Syntax: SecRuleUpdateOperatorById ID [ID...] "OPERATOR" Case Sensitive: Yes WGE Extension: This is a WGE-specific extension, not available in standard ModSecurity. This directive allows you to modify the operator of one or more existing rules by their ID. This is useful for customizing third-party rule sets (like OWASP CRS) without modifying the original rule files. The ID can be a single rule ID, a range (e.g., 100-200), or an ID with chain index (e.g., 100:1 for the first chained rule).

SecRuleUpdateOperatorByTag

Mon, 01 Jan 0001 00:00:00 +0000

Description: Update the operator of existing rules by their tag. Syntax: SecRuleUpdateOperatorByTag "TAG" "OPERATOR" Case Sensitive: Yes WGE Extension: This is a WGE-specific extension, not available in standard ModSecurity. This directive allows you to modify the operator of all rules that have a matching tag. This is useful for applying a consistent operator change across multiple related rules in a rule set. Example: # Update all SQL injection rules to use a new pattern SecRuleUpdateOperatorByTag "attack-sqli" "@rx (?i)(union|select|insert|update|delete)" # Update all XSS detection rules SecRuleUpdateOperatorByTag "attack-xss" "@rx ]*>"