Actions

The action of a rule defines how to handle HTTP requests that have matched one or more rule conditions.

Actions are defined as part of a SecRule or as parameter for SecAction or SecDefaultAction. A rule can have no or several actions which need to be separated by a comma.

Actions can be categorized by how they affect overall processing:

  • Disruptive actions - Cause Coraza to do something. In many cases something means block transaction, but not in all. For example, the allow action is classified as a disruptive action, but it does the opposite of blocking. There can only be one disruptive action per rule (if there are multiple disruptive actions present, or inherited, only the last one will take effect), or rule chain (in a chain, a disruptive action can only appear in the first rule).
  • Non-disruptive actions - Do something, but that something does not and cannot affect the rule processing flow. Setting a variable, or changing its value is an example of a non-disruptive action. Non-disruptive action can appear in any rule, including each rule belonging to a chain.
  • Flow actions - These actions affect the rule flow (for example skip or skipAfter).
  • Meta-data actions - used to provide more information about rules. Examples include id, rev, severity and msg.
  • Data actions - Not really actions, these are mere containers that hold data used by other actions. For example, the status action holds the status that will be used for blocking (if it takes place).

allow

Description: Stops rule processing on a successful match and allows a transaction to be proceed.allow will affect the entire transaction. stopping processing of the current phase but also skipping over all other phases apart from the logging phase. (The logging phase is special; it is designed to be always execute.)the engine will stop processing the current phase, and the other phases will continue.engine will stop processing the current phase, and the next phase to be processed will be phase types.PhaseResponseHeaders.

Action Group: Disruptive

Example:

# Allow unrestricted access from 192.168.1.100
SecRule REMOTE_ADDR "^192\.168\.1\.100$" phase:1,id:95,nolog,allow
# Do not process request but process response
SecAction phase:1,allow:request,id:96
# Do not process transaction (request and response).
SecAction phase:1,allow,id:97
# If you want to allow a response through, put a rule in phase RESPONSE_HEADERS and use allow
SecAction phase:3,allow,id:98

auditlog

Description: Marks the transaction for logging in the audit log.

Action Group: Non-disruptive

Example:

# The action is explicit if the log is specified.
SecRule REMOTE_ADDR "^192\.168\.1\.100$" "auditlog,phase:1,id:100,allow"

block

Description: Performs the disruptive action defined by the previous SecDefaultAction. This action is a placeholder to be used by rule writers to request a blocking action, but without specifying how the blocking is to be done. The idea is that such decisions are best left to rule users, as well as to allow users, to override blocking for their demands. In future versions of Coraza, more control and functionality will be added to define “how” to block.

Action Group: Disruptive

Example:

# Specify how blocking is to be done
SecDefaultAction "phase:2,deny,id:101,status:403,log,auditlog"
# Detect attacks where we want to block
SecRule ARGS "@rx attack1" "phase:2,block,id:102"
# Detect attacks where we want only to warn
SecRule ARGS "@rx attack2" "phase:2,pass,id:103"
# It is possible to use the `SecRuleUpdateActionById` directive to override how a rule handles blocking.
# 1. If a rule has blocking hard-coded, and you want it to use the policy you determine.
# 2. If a rule was written to `block`, but you want it to warn only.
# 3. If a rule was written to only `warn`, but you want it to block.
# The following example demonstrates the first case,
# Specify how blocking is to be done
SecDefaultAction "phase:2,deny,status:403,log,auditlog,id:104"
# Detect attacks and block
SecRule ARGS "@rx attack1" "phase:2,id:1,deny"
# Change how rule ID 1 blocks
SecRuleUpdateActionById 1 "block"

capture

Description: > This action is being forced by now, it might be reused in the future. When used together with the regular expression operator @rx, capture creates a copy of the regular expression and places them into the transaction variable collection. Up to 10 captures will be copied on a successful pattern match, each with a name consisting of a digit from 0 to 9. The TX.0 variable always contains the entire area that the regular expression matched. All the other variables contain the captured values, in the order in which the capturing parentheses appear in the regular expression.

Action Group: Non-disruptive

Example:

SecRule REQUEST_BODY "^username=(\w{25,})" phase:2,capture,t:none,chain,id:105
SecRule TX:1 "(?:(?:a(dmin|nonymous)))"

chain

Description: Creating a rule chain - chains the current rule with the rule that immediately follows it. Noted that rule chains simulate AND condition. The disruptive actions specified in the first portion of the chained rule will be triggered only if all of the variable checks return positive hits. If one of the chained rule is negative, the entire rule chain will fail to match.

  • disruptive actions
  • execution phases
  • metadata actions (id, rev, msg, tag, severity, logdata)
  • skip
  • skipAfter
  • SecAction
  • SecRule
  • SecRuleScript
  • An action which affects the rule flow (i.e., the disruptive actions, skip and skipAfter) can be used only in the chain starter. They will be executed only if the entire chain matches.
  • Non-disruptive rules can be used in any rule; they will be executed if the rule that contains them matches and not only when the entire chain matches.
  • The metadata actions (e.g., id, rev, msg) can be used only in the chain starter.

Action Group: Flow

Example:

# Refuse to accept POST requests that do not contain a Content-Length header.
# Noted that the rule should be preceded by a rule that verifies only valid request methods are used.
	SecRule REQUEST_METHOD "^POST$" "phase:1,chain,t:none,id:105"
		SecRule &REQUEST_HEADERS:Content-Length "@eq 0" "t:none"

ctl

Description: Change Coraza configuration on transient, per-transaction basis. Any changes made using this action will affect only the transaction in which the action is executed. The default configuration, as well as the other transactions running in parallel, will be unaffected.

  • auditEngine
  • auditLogParts
  • debugLogLevel
  • forceRequestBodyVariable
  • requestBodyAccess
  • requestBodyLimit
  • requestBodyProcessor
  • responseBodyAccess
  • responseBodyLimit
  • ruleEngine
  • ruleRemoveById
  • ruleRemoveByMsg
  • ruleRemoveByTag
  • ruleRemoveTargetById
  • ruleRemoveTargetByMsg
  • ruleRemoveTargetByTag
  • hashEngine (Not Supported in Coraza (TBI))
  • hashEnforcement (Not supported in Coraza (TBI))
  1. Option ruleRemoveTargetById, ruleRemoveTargetByMsg, and ruleRemoveTargetByTag, users don’t need to use the char ! before the target list.
  2. Option ruleRemoveById is triggered at run time and should be specified before the rule in which it is disabling.
  3. Option requestBodyProcessor allows you to configure the request body processor. By default, Coraza will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body respectively.JSON and XML, but they are never used implicitly. Instead, you must tell Coraza to use it by placing a few rules in the REQUEST_HEADERS processing phase. After the request body is processed as XML, you will be able to use the XML-related features to inspect it. Request body processors will not interrupt a transaction if an error occurs during parsing. Instead, they will set the variables REQBODY_PROCESSOR_ERROR and REQBODY_PROCESSOR_ERROR_MSG. These variables should be inspected in the REQUEST_BODY phase and an appropriate action taken.
  4. Option forceRequestBodyVariable“ allows you to configure the REQUEST_BODY` variable to be set when there is no request body processor configured. This allows for inspection of request bodies of unknown types.

Action Group: Non-disruptive

Example:

# Parse requests with Content-Type "text/xml" as XML
SecRule REQUEST_CONTENT_TYPE ^text/xml "nolog,pass,id:106,ctl:requestBodyProcessor=XML"
# white-list the user parameter for rule #981260 when the REQUEST_URI is /index.php
		SecRule REQUEST_URI "@beginsWith /index.php" "phase:1,t:none,pass,\
	 	nolog,ctl:ruleRemoveTargetById=981260;ARGS:user"

deny

Description: Stops rule processing and intercepts transaction. If status action is not used, deny action defaults to status 403.

Action Group: Disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "nikto" "log,deny,id:107,msg:'Nikto Scanners Identified'"

drop

Description: > This action depends on each implementation, the server is instructed to drop the connection. Initiates an immediate close of the TCP connection by sending a FIN packet. This action is extremely useful when responding to both Brute Force and Denial of Service attacks, which you may want to minimize the network bandwidth and the data returned to the client.core_output_filter: writing data to the network`

Action Group: Disruptive

Example:

# The following example initiates an IP collection for tracking Basic Authentication attempts.
# If the client exceed the threshold of more than 25 attempts in 2 minutes, it will `DROP` the subsequent connections.
SecAction phase:1,id:109,initcol:ip=%{REMOTE_ADDR},nolog
SecRule ARGS:login "!^$" "nolog,phase:1,id:110,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=25/120"
SecRule IP:AUTH_ATTEMPT "@gt 25" "log,drop,phase:1,id:111,msg:'Possible Brute Force Attack'"

exec

Description: Executes an external script/binary supplied as parameter. The exec action is executed independently from any disruptive actions specified. External scripts will always be called with no parameters. Some transaction information will be placed in environment variables. All the usual CGI environment variables will be there. You should be aware that forking a threaded process results in all threads being replicated in the new process. Forking can therefore incur larger overhead in a multithreaded deployment.

The script you execute must write something (anything) to stdout, if it doesn’t, Coraza will assume that the script failed, and will record the failure.

Action Group: Non-disruptive

Example:

# Run external program on rule match
SecRule REQUEST_URI "^/cgi-bin/script\.pl" "phase:2,id:112,t:none,t:lowercase,t:normalizePath,block,\ exec:/usr/local/apache/bin/test.sh"
# Run Lua script on rule match
SecRule ARGS:p attack "phase:2,id:113,block,exec:/usr/local/apache/conf/exec.lua"

expirevar

Description: Configures a collection variable to expire after the given time period (in seconds). You should use the expirevar with setvar action to keep the intended expiration time. The expire time will be reset if they are used on their own (perhaps in a SecAction directive).

Action Group: Non-disruptive

Example:

	SecRule REQUEST_COOKIES:JSESSIONID "!^$" "nolog,phase:1,id:114,pass,setsid:%{REQUEST_COOKIES:JSESSIONID}"
	SecRule REQUEST_URI "^/cgi-bin/script\.pl" "phase:2,id:115,t:none,t:lowercase,t:normalizePath,log,allow,\
		setvar:session.suspicious=1,expirevar:session.suspicious=3600,phase:1"

id

Description: > This action is mandatory for all SecRule and SecAction, and it must be numeric. Assigns a unique ID to the rule or chain in which it appears.

Action Group: Metadata

Example:

SecRule &REQUEST_HEADERS:Host "@eq 0" "log,id:60008,severity:2,msg:'Request Missing a Host Header'"

initcol

Description: Initializes a named persistent collection, either by loading data from storage or by creating a new collection in memory. Collections are loaded into memory on-demand, when the initcol action is executed. A collection will be persisted only if a change was made to it in the course of transaction processing. See the Persistent Storage section for further details.

Action Group: Non-disruptive

Example:

# Initiates IP address tracking, which is best done in phase 1
SecAction "phase:1,id:116,nolog,pass,initcol:ip=%{REMOTE_ADDR}"

log

Description: Indicates that a successful match of the rule needs to be logged.

Action Group: Non-disruptive

Example:

# log matches from the error log file to the Coraza audit log.
SecAction "phase:1,id:117,pass,initcol:ip=%{REMOTE_ADDR},log"

logdata

Description: Logs a data fragment as part of the alert message. The logdata information appears in the error and/or audit log files. Macro expansion is performed, so you may use variable names such as %{TX.0} or %{MATCHED_VAR}. The information is properly escaped for use with logging of binary data.

Action Group: Non-disruptive

Example:

SecRule ARGS:p "@rx <script>" "phase:2,id:118,log,pass,logdata:%{MATCHED_VAR}"

maturity

Description: Specifies the relative maturity level of the rule related to the length of time a rule has been public and the amount of testing it has received. The value is a string based on a numeric scale (1-9 where 9 is extensively tested and 1 is a brand new experimental rule).

Action Group: Metadata

Example:

	SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
		"phase:2,ver:'CRS/2.2.4,accuracy:'9',maturity:'9',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'% \
	 	{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

msg

Description: Assigns a custom message to the rule or chain in which it appears, and the message will be logged along with every alert. Noted that the msg information appears in the error and/or audit log files and is not sent back to the client in response headers.

Action Group: Metadata

Example:

SecRule &REQUEST_HEADERS:Host "@eq 0" "log,id:60008,severity:2,msg:'Request Missing a Host Header'"

multimatch

Description: Perform multiple operator invocations for every target, before and after every anti-evasion transformation is performed. Normally, variables are inspected only once per rule, and only after all transformation functions have been completed. With multiMatch, variables are checked against the operator before and after every transformation function that changes the input.

Action Group: Non-disruptive

Example:

SecRule ARGS "attack" "phase1,log,deny,id:119,t:removeNulls,t:lowercase,multiMatch"

noauditlog

Description: Indicates that a successful match of the rule should not be used as criteria to determine whether the transaction should be logged to the audit log. If the SecAuditEngine is set to On, all of the transactions will be logged. If it is set to RelevantOnly, you can control the logging with the noauditlog action. Action noauditlog affects only on the current rule. If you prevent audit logging in one rule only, a match in another rule will still cause audit logging to take place. If you want to prevent audit logging from taking place, regardless of whether any rule matches, use ctl:auditEngine=Off.

Action Group: Non-disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "@streq Test" "allow,noauditlog,id:120"

nolog

Description: Prevents rule matches from appearing in both error and audit logs. Although nolog implies noauditlog, you can override the former by using nolog,auditlog.

Action Group: Non-disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "@streq Test" "allow,nolog,id:121"

pass

Description: Continues processing with the next rule in spite of a successful match.

Action Group: Disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "@streq Test" "log,pass,id:122"
# When using pass with a SecRule with multiple targets,
# all variables will be inspected and all non-disruptive actions trigger for every match.
# In the following example, the TX.test variable will be incremented once for every request parameter
# Set TX.test to zero
SecAction "phase:2,nolog,pass,setvar:TX.test=0,id:123"
# Increment TX.test for every request parameter
SecRule ARGS "test" "phase:2,log,pass,setvar:TX.test=+1,id:124"

phase

Description: Places the rule or chain into one of five available processing phases. It can also be used in SecDefaultAction to establish the rule defaults.

  • 2 (request)
  • 4 (response)
  • 5 (logging)Keep in mind that the variable used in the rule may not be available if specifying the incorrect phase.

This could lead to a false negative situation where your variable and operator may be correct, but it misses malicious data because you specified the wrong phase.

Action Group: Metadata

Example:

# Initialize IP address tracking in phase 1
SecAction phase:1,nolog,pass,id:126,initcol:IP=%{REMOTE_ADDR}
# Example of using phase alias
SecRule REQUEST_HEADERS:User-Agent "Test" "phase:request,log,deny,id:127"

redirect

Description: Intercepts transaction by issuing an external (client-visible) redirection to the given location. If the status action is presented on the same rule, and its value can be used for a redirection301, 302, 303, 307) the value will be used for the redirection status code. Otherwise, status code 302 will be used.

Action Group: Disruptive

Example:

SecRule REQUEST_HEADERS:User-Agent "@streq Test" "phase:1,id:130,log,redirect:http://www.example.com/failed.html"

rev

Description: Specifies the rule revision. This action is used in combination with action id to allow the same rule ID to be used after changes, and it can still provide some indication about the rule changes.

Action Group: Metadata

Example:

	SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(?:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))" \
		"phase:2,rev:'2.1.3',capture,t:none,t:normalizePath,t:lowercase,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950907',tag:'WEB_ATTACK/COMMAND_INJECTION',tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.command_injection_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"

setenv

Description: Creates, removes, and updates environment variables that can be accessed by the implementation.

In a trained rule, the action will be executed when an individual rule matches (not the entire chain).

Action Group: Non-disruptive

Example:

SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "phase:3,t:none,pass,id:139,nolog,setvar:tx.sessionid=%{matched_var}"Missing HttpOnly Cookie Flag.'"
# In Apache
Header set Set-Cookie "%{httponly_cookie}e; HTTPOnly" env=httponly_cookie

setvar

Description: Creates, removes, or updates a variable. Variable names are case-insensitive.

Action Group: Non-disruptive

Example:

# Create a variable and set its value to 1 (usually used for setting flags)
`setvar:TX.score`
# Create a variable and initialize it at the same time,
`setvar:TX.score=10`
# Remove a variable, prefix the name with an exclamation mark
`setvar:!TX.score`
# Increase or decrease variable value, use + and - characters in front of a numerical value
`setvar:TX.score=+5`
	SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bsys\.user_catalog\b" \
		"phase:2,rev:'2.1.3',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E, \
		block,msg:'Blind SQL Injection Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1', \
		tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score}, \
		setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
# When using in a chain, the action will be executed when an individual rule matches instead of the entire chain match.
	SecRule REQUEST_FILENAME "@contains /test.php" "chain,id:7,phase:1,t:none,nolog,setvar:tx.auth_attempt=+1"
		SecRule ARGS_POST:action "@streq login" "t:none"
# Increment every time that test.php is visited (regardless of the parameters submitted).
# If the desired goal is to set the variable only if the entire rule matches,
# it should be included in the last rule of the chain.
	SecRule REQUEST_FILENAME "@streq test.php" "chain,id:7,phase:1,t:none,nolog"
		SecRule ARGS_POST:action "@streq login" "t:none,setvar:tx.auth_attempt=+1"

severity

Description: Assigns severity to the rule in which it is used. Severity values in Coraza follows the numeric scale of syslog (where 0 is the most severe).is generated from correlation of anomaly scoring data where there is an inbound attack and an outbound leakage.is generated from correlation where there is an inbound attack and an outbound application level error.Anomaly Score of 5. Is the highest severity level possible without correlation. It is normally generated by the web attack rules (40 level files).Error - Anomaly Score of 4. Is generated mostly from outbound leakage rules (50 level files).Anomaly Score of 3. Is generated by malicious client rules (35 level files).Anomaly Score of 2. Is generated by the Protocol policy and anomaly files.

  • 6, INFO
  • 7, DEBUG

It is possible to specify severity levels using either the numerical values or the text values, but you should always specify severity levels using the text values, because it is difficult to remember what a number stands for. The use of the numerical values is deprecated as of version 2.5.0 and may be removed in one of the subsequent major updates.

Action Group: Metadata

Example:

SecRule REQUEST_METHOD "^PUT$" "id:340002,rev:1,severity:CRITICAL,msg:'Restricted HTTP function'"

skip

Description: Skips one or more rules (or chained rules) on successful match. It only within the current processing phase and not necessarily in the order in which the rules appear in the configuration file. If you place a phase 2 rule after a phase 1 rule that uses skip, it will not skip over the phase 2 rule, it will skip over the next phase 1 rule that follows it in the phase.

Action Group: Flow

Example:

# Require Accept header, but not from access from the localhost
SecRule REMOTE_ADDR "^127\.0\.0\.1$" "phase:1,skip:1,id:141"
# This rule will be skipped over when REMOTE_ADDR is 127.0.0.1
SecRule &REQUEST_HEADERS:Accept "@eq 0" "phase:1,id:142,deny,msg:'Request Missing an Accept Header'"

skipafter

Description: Action skipAfter is similar to skip, it skip one or more rules (or chained rules) on a successful match, **and resuming rule execution with the first rule that follows the rule (or marker created by SecMarker) with the provided ID)). The skipAfter action works only within the current processing phase and not necessarily the order in which the rules appear in the configuration file.

Action Group: Flow

Example:

# Require Accept header, but not from access from the localhost
SecRule REMOTE_ADDR "^127\.0\.0\.1$" "phase:1,id:143,skipAfter:IGNORE_LOCALHOST"
# This rule will be skipped over when REMOTE_ADDR is 127.0.0.1
SecRule &REQUEST_HEADERS:Accept "@eq 0" "phase:1,deny,id:144,msg:'Request Missing an Accept Header'"
SecMarker IGNORE_LOCALHOST
# another Example from the OWASP CRS
SecMarker BEGIN_HOST_CHECK
	SecRule &REQUEST_HEADERS:Host "@eq 0" \
		"skipAfter:END_HOST_CHECK,phase:2,rev:'2.1.3',t:none,block,msg:'Request Missing a Host Header',id:'960008',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21', \
		tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score}, \
		setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
	SecRule REQUEST_HEADERS:Host "^$" \
		"phase:2,rev:'2.1.3',t:none,block,msg:'Request Missing a Host Header',id:'960008',tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7', \
		tag:'PCI/6.5.10',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score}, \
		setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
SecMarker END_HOST_CHECK

status

Description: Specifies the response status code to use with actions deny and redirect. If status is not set, deny action defaults to status 403.

Action Group: Data

Example:

# Deny status 403
SecDefaultAction "phase:1,log,deny,id:145,status:403"

t

Description: t is used to specify the transformation pipeline to use to transform the value of each variable used in the rule before matching. Any transformation functions that you specify in a SecRule will be added to the previous ones specified in SecDefaultAction. It is recommended that you always use t:none in your rules, which prevents them depending on the default configuration.

Action Group: Non-disruptive

Example:

SecRule ARGS "(asfunction|javascript|vbscript|data|mocha|livescript):" "id:146,t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace"

tag

Description: Assigns a tag (category) to a rule or a chain. The tag information appears along with other rule metadata. Tags allow easy automated categorization of events, and multiple tags can be specified on the same rule. You can use forward slashes to create a hierarchy of categories (see example), and it also support Macro Expansions.

Action Group: Metadata

Example:

	SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
	 	"phase:2,rev:'2.1.3',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'% \
		{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

ver

Description: Specifies the rule set version.

Action Group: Metadata

Example:

	SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
	 	"phase:2,ver:'CRS/2.2.4,capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'% \
		{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"
Edit this page on
← Syntax
Execution flow →