Acciones

Las acciones se definen como parte de un SecRule o como parámetro para SecAction o SecDefaultAction. Una regla puede tener ninguna o varias acciones, que deben estar separadas por una coma.

Las acciones pueden categorizarse según cómo afectan al procesamiento general:

Acciones disruptivas - Hacen que Coraza realice algo. En muchos casos, ese algo significa bloquear la transacción, pero no en todos. Por ejemplo, la acción allow se clasifica como una acción disruptiva, pero hace lo opuesto al bloqueo. Solo puede haber una acción disruptiva por regla (si hay múltiples acciones disruptivas presentes o heredadas, solo la última tendrá efecto), o cadena de reglas (en una cadena, una acción disruptiva solo puede aparecer en la primera regla).
Las acciones disruptivas NO se ejecutarán si SecRuleEngine está establecido en DetectionOnly. Si está creando reglas de excepción/lista de permitidos que utilizan la acción allow, también debería añadir la acción ctl:ruleEngine=On para ejecutar la acción.
Acciones no disruptivas - Realizan algo, pero ese algo no afecta ni puede afectar al flujo de procesamiento de reglas. Establecer una variable o cambiar su valor es un ejemplo de una acción no disruptiva. Las acciones no disruptivas pueden aparecer en cualquier regla, incluida cada regla perteneciente a una cadena.
Acciones de flujo - Estas acciones afectan al flujo de las reglas (por ejemplo skip o skipAfter).
Acciones de metadatos - Se utilizan para proporcionar más información sobre las reglas. Los ejemplos incluyen id, rev, severity y msg.
Acciones de datos - No son realmente acciones, sino meros contenedores que almacenan datos utilizados por otras acciones. Por ejemplo, la acción status contiene el estado que se utilizará para el bloqueo (si este tiene lugar).

allow

Descripción: Detiene el procesamiento de reglas en caso de coincidencia exitosa y permite que la transacción continúe. allow afectará a toda la transacción, deteniendo el procesamiento de la fase actual y saltando también todas las demás fases aparte de la fase de registro. (La fase de registro es especial; está diseñada para ejecutarse siempre.) El motor dejará de procesar la fase actual, y las demás fases continuarán. El motor dejará de procesar la fase actual, y la siguiente fase a procesar será la fase types.PhaseResponseHeaders.

Grupo de acción: Disruptiva

Ejemplo:

# 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

Descripción: Marca la transacción para su registro en el registro de auditoría.

Grupo de acción: No disruptiva

Ejemplo:

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

block

Descripción: Ejecuta la acción disruptiva definida por el SecDefaultAction anterior. Esta acción es un marcador de posición para que los autores de reglas soliciten una acción de bloqueo, pero sin especificar cómo debe realizarse el bloqueo. La idea es que tales decisiones se dejan mejor a los usuarios de las reglas, así como permitir a los usuarios anular el bloqueo según sus necesidades. En futuras versiones de Coraza, se añadirá más control y funcionalidad para definir “cómo” bloquear.

Grupo de acción: Disruptiva

Ejemplo:

# 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

Descripción: > Esta acción se está forzando actualmente; podría reutilizarse en el futuro. Cuando se utiliza junto con el operador de expresión regular @rx, capture crea una copia de la expresión regular y la coloca en la colección de variables de transacción. Se copiarán hasta 10 capturas en una coincidencia de patrón exitosa, cada una con un nombre que consiste en un dígito del 0 al 9. La variable TX.0 siempre contiene el área completa que la expresión regular ha coincidido. Todas las demás variables contienen los valores capturados, en el orden en que aparecen los paréntesis de captura en la expresión regular.

Grupo de acción: No disruptiva

Ejemplo:

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

chain

Descripción: Crea una cadena de reglas - encadena la regla actual con la regla que le sigue inmediatamente. Nótese que las cadenas de reglas simulan la condición AND. Las acciones disruptivas especificadas en la primera parte de la regla encadenada solo se activarán si todas las comprobaciones de variables devuelven resultados positivos. Si una de las reglas encadenadas es negativa, toda la cadena de reglas no coincidirá.

acciones disruptivas
fases de ejecución
acciones de metadatos (id, rev, msg, tag, severity, logdata)
skip
skipAfter
SecAction
SecRule
SecRuleScript
Una acción que afecte al flujo de las reglas (es decir, las acciones disruptivas, skip y skipAfter) solo puede usarse en el inicio de la cadena. Se ejecutarán únicamente si toda la cadena coincide.
Las reglas no disruptivas pueden usarse en cualquier regla; se ejecutarán si la regla que las contiene coincide y no solo cuando toda la cadena coincide.
Las acciones de metadatos (por ejemplo, id, rev, msg) solo pueden usarse en el inicio de la cadena.

Grupo de acción: Flujo

Ejemplo:

# 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

Descripción: Cambia la configuración de Coraza de forma transitoria, por transacción. Cualquier cambio realizado con esta acción afectará únicamente a la transacción en la que se ejecuta la acción. La configuración por defecto, así como las demás transacciones que se ejecuten en paralelo, no se verán afectadas.

auditEngine
auditLogParts
debugLogLevel
forceRequestBodyVariable
requestBodyAccess
requestBodyLimit
requestBodyProcessor
responseBodyAccess
responseBodyLimit
ruleEngine
ruleRemoveById
ruleRemoveByMsg
ruleRemoveByTag
ruleRemoveTargetById
ruleRemoveTargetByMsg
ruleRemoveTargetByTag
hashEngine (No soportado en Coraza (TBI))
hashEnforcement (No soportado en Coraza (TBI))

Con las opciones ruleRemoveTargetById, ruleRemoveTargetByMsg y ruleRemoveTargetByTag, los usuarios no necesitan usar el carácter ! antes de la lista de destinos.
La opción ruleRemoveById se activa en tiempo de ejecución y debe especificarse antes de la regla que está deshabilitando.
La opción requestBodyProcessor le permite configurar el procesador del cuerpo de la solicitud. Por defecto, Coraza utilizará los procesadores URLENCODED y MULTIPART para procesar cuerpos application/x-www-form-urlencoded y multipart/form-data respectivamente. JSON y XML, pero nunca se usan implícitamente. En su lugar, debe indicar a Coraza que los use colocando algunas reglas en la fase de procesamiento REQUEST_HEADERS. Después de que el cuerpo de la solicitud se procese como XML, podrá usar las funcionalidades relacionadas con XML para inspeccionarlo. Los procesadores del cuerpo de la solicitud no interrumpirán una transacción si ocurre un error durante el análisis. En su lugar, establecerán las variables REQBODY_PROCESSOR_ERROR y REQBODY_PROCESSOR_ERROR_MSG. Estas variables deben inspeccionarse en la fase REQUEST_BODY y tomar las acciones apropiadas.
La opción forceRequestBodyVariable le permite configurar la variable REQUEST_BODY para que se establezca cuando no hay un procesador del cuerpo de la solicitud configurado. Esto permite la inspección de cuerpos de solicitud de tipos desconocidos.

Grupo de acción: No disruptiva

Ejemplo:

# Parse requests with Content-Type "text/xml" as XML
SecRule REQUEST_CONTENT_TYPE ^text/xml "nolog,pass,id:106,phase:1,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

Descripción: Detiene el procesamiento de reglas e intercepta la transacción. Si no se utiliza la acción status, la acción deny establece por defecto el estado 403.

Grupo de acción: Disruptiva

Ejemplo:

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

drop

Descripción: > Esta acción depende de cada implementación; se instruye al servidor para que cierre la conexión. Inicia un cierre inmediato de la conexión TCP enviando un paquete FIN. Esta acción es extremadamente útil al responder a ataques de fuerza bruta y de denegación de servicio, en los que puede querer minimizar el ancho de banda de red y los datos devueltos al cliente. core_output_filter: writing data to the network

Grupo de acción: Disruptiva

Ejemplo:

# 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

Descripción: Ejecuta un script/binario externo proporcionado como parámetro. La acción exec se ejecuta independientemente de cualquier acción disruptiva especificada. Los scripts externos siempre se llamarán sin parámetros. Parte de la información de la transacción se colocará en variables de entorno. Todas las variables de entorno CGI habituales estarán presentes. Debe tener en cuenta que bifurcar un proceso multihilo resulta en que todos los hilos se replican en el nuevo proceso. La bifurcación puede por tanto incurrir en una mayor sobrecarga en un despliegue multihilo.

El script que ejecute debe escribir algo (cualquier cosa) en stdout; si no lo hace, Coraza asumirá que el script falló y registrará el fallo.

Grupo de acción: No disruptiva

Ejemplo:

# 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

Descripción: Configura una variable de colección para que expire después del período de tiempo indicado (en segundos). Debe usar expirevar con la acción setvar para mantener el tiempo de expiración previsto. El tiempo de expiración se restablecerá si se usan de forma independiente (quizás en una directiva SecAction).

Grupo de acción: No disruptiva

Ejemplo:

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

Descripción: > Esta acción es obligatoria para todos los SecRule y SecAction, y debe ser numérica. Asigna un ID único a la regla o cadena en la que aparece.

Grupo de acción: Metadatos

Ejemplo:

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

initcol

Descripción: Inicializa una colección persistente con nombre, ya sea cargando datos del almacenamiento o creando una nueva colección en memoria. Las colecciones se cargan en memoria bajo demanda, cuando se ejecuta la acción initcol. Una colección se persistirá solo si se realizó un cambio en ella durante el procesamiento de la transacción. Consulte la sección de Almacenamiento persistente para más detalles.

Grupo de acción: No disruptiva

Ejemplo:

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

log

Descripción: Indica que una coincidencia exitosa de la regla necesita ser registrada.

Grupo de acción: No disruptiva

Ejemplo:

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

logdata

Descripción: Registra un fragmento de datos como parte del mensaje de alerta. La información de logdata aparece en los archivos de registro de error y/o auditoría. Se realiza expansión de macros, por lo que puede usar nombres de variables como %{TX.0} o %{MATCHED_VAR}. La información se escapa correctamente para su uso con el registro de datos binarios.

Grupo de acción: No disruptiva

Ejemplo:

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

maturity

Descripción: Especifica el nivel relativo de madurez de la regla en relación con el tiempo que una regla ha sido pública y la cantidad de pruebas que ha recibido. El valor es una cadena basada en una escala numérica (1-9 donde 9 es extensamente probada y 1 es una regla experimental nueva).

Grupo de acción: Metadatos

Ejemplo:

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

Descripción: Asigna un mensaje personalizado a la regla o cadena en la que aparece, y el mensaje se registrará junto con cada alerta. Nótese que la información de msg aparece en los archivos de registro de error y/o auditoría y no se envía de vuelta al cliente en las cabeceras de respuesta.

Grupo de acción: Metadatos

Ejemplo:

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

multimatch

Descripción: Realiza múltiples invocaciones del operador para cada destino, antes y después de que se realice cada transformación anti-evasión. Normalmente, las variables se inspeccionan solo una vez por regla, y solo después de que se hayan completado todas las funciones de transformación. Con multiMatch, las variables se comprueban contra el operador antes y después de cada función de transformación que modifica la entrada.

Grupo de acción: No disruptiva

Ejemplo:

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

noauditlog

Descripción: Indica que una coincidencia exitosa de la regla no debe usarse como criterio para determinar si la transacción debe registrarse en el registro de auditoría. Si SecAuditEngine está establecido en On, todas las transacciones serán registradas. Si está establecido en RelevantOnly, puede controlar el registro con la acción noauditlog. La acción noauditlog afecta solo a la regla actual. Si previene el registro de auditoría en una sola regla, una coincidencia en otra regla seguirá causando que se produzca el registro de auditoría. Si desea prevenir que se produzca el registro de auditoría, independientemente de si alguna regla coincide, use ctl:auditEngine=Off.

Grupo de acción: No disruptiva

Ejemplo:

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

nolog

Descripción: Evita que las coincidencias de reglas aparezcan tanto en los registros de error como en los de auditoría. Aunque nolog implica noauditlog, puede anular lo anterior usando nolog,auditlog.

Grupo de acción: No disruptiva

Ejemplo:

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

pass

Descripción: Continúa el procesamiento con la siguiente regla a pesar de una coincidencia exitosa.

Grupo de acción: Disruptiva

Ejemplo:

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

Descripción: Coloca la regla o cadena en una de las cinco fases de procesamiento disponibles. También puede usarse en SecDefaultAction para establecer los valores por defecto de las reglas.

2 (solicitud)
4 (respuesta)
5 (registro) Tenga en cuenta que la variable usada en la regla puede no estar disponible si especifica la fase incorrecta.

Esto podría llevar a una situación de falso negativo donde su variable y operador pueden ser correctos, pero no detecta datos maliciosos porque especificó la fase equivocada.

Grupo de acción: Metadatos

Ejemplo:

# 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

Descripción: Intercepta la transacción emitiendo una redirección externa (visible para el cliente) a la ubicación indicada. Si la acción status está presente en la misma regla y su valor puede usarse para una redirección (301, 302, 303, 307), el valor se usará para el código de estado de la redirección. De lo contrario, se usará el código de estado 302.

Grupo de acción: Disruptiva

Ejemplo:

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

rev

Descripción: Especifica la revisión de la regla. Esta acción se usa en combinación con la acción id para permitir que el mismo ID de regla se use después de cambios, y aún pueda proporcionar alguna indicación sobre los cambios en la regla.

Grupo de acción: Metadatos

Ejemplo:

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

Descripción: Crea, elimina y actualiza variables de entorno que pueden ser accedidas por la implementación.

En una regla encadenada, la acción se ejecutará cuando una regla individual coincida (no toda la cadena).

Grupo de acción: No disruptiva

Ejemplo:

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

Descripción: Crea, elimina o actualiza una variable. Los nombres de variables no distinguen entre mayúsculas y minúsculas.

Grupo de acción: No disruptiva

Ejemplo:

# 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

Descripción: Asigna una severidad a la regla en la que se utiliza. Los valores de severidad en Coraza siguen la escala numérica de syslog (donde 0 es el más severo). Se genera a partir de la correlación de datos de puntuación de anomalías donde hay un ataque entrante y una filtración saliente. Se genera a partir de la correlación donde hay un ataque entrante y un error a nivel de aplicación saliente. Puntuación de anomalía de 5. Es el nivel de severidad más alto posible sin correlación. Normalmente se genera por las reglas de ataque web (archivos de nivel 40). Error - Puntuación de anomalía de 4. Se genera principalmente a partir de reglas de filtración saliente (archivos de nivel 50). Puntuación de anomalía de 3. Se genera por las reglas de cliente malicioso (archivos de nivel 35). Puntuación de anomalía de 2. Se genera por los archivos de política de protocolo y anomalías.

6, INFO
7, DEBUG

Es posible especificar los niveles de severidad usando los valores numéricos o los valores de texto, pero siempre debería especificar los niveles de severidad usando los valores de texto, porque es difícil recordar qué representa un número. El uso de los valores numéricos está obsoleto desde la versión 2.5.0 y puede eliminarse en una de las actualizaciones principales posteriores.

Grupo de acción: Metadatos

Ejemplo:

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

skip

Descripción: Salta una o más reglas (o reglas encadenadas) en caso de coincidencia exitosa. Solo funciona dentro de la fase de procesamiento actual y no necesariamente en el orden en que aparecen las reglas en el archivo de configuración. Si coloca una regla de fase 2 después de una regla de fase 1 que usa skip, no saltará la regla de fase 2, sino que saltará la siguiente regla de fase 1 que le siga en la fase.

Grupo de acción: Flujo

Ejemplo:

# 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

Descripción: La acción skipAfter es similar a skip; salta una o más reglas (o reglas encadenadas) en caso de coincidencia exitosa, **y reanuda la ejecución de reglas con la primera regla que sigue a la regla (o marcador creado por SecMarker) con el ID proporcionado. La acción skipAfter solo funciona dentro de la fase de procesamiento actual y no necesariamente en el orden en que aparecen las reglas en el archivo de configuración.

Grupo de acción: Flujo

Ejemplo:

# 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

Descripción: Especifica el código de estado de respuesta a usar con las acciones deny y redirect. Si status no está establecido, la acción deny establece por defecto el estado 403.

Grupo de acción: Datos

Ejemplo:

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

t

Descripción: t se utiliza para especificar la cadena de transformación a usar para transformar el valor de cada variable utilizada en la regla antes de la coincidencia. Cualquier función de transformación que especifique en un SecRule se añadirá a las anteriores especificadas en SecDefaultAction. Se recomienda que siempre use t:none en sus reglas, lo cual evita que dependan de la configuración por defecto.

Grupo de acción: No disruptiva

Ejemplo:

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

tag

Descripción: Asigna una etiqueta (categoría) a una regla o cadena. La información de etiqueta aparece junto con otros metadatos de la regla. Las etiquetas permiten una categorización automatizada sencilla de eventos, y se pueden especificar múltiples etiquetas en la misma regla. Puede usar barras diagonales para crear una jerarquía de categorías (véase el ejemplo), y también admite expansión de macros.

Grupo de acción: Metadatos

Ejemplo:

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

Descripción: Especifica la versión del conjunto de reglas.

Grupo de acción: Metadatos

Ejemplo:

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}"

Previo

Sintaxis

Flujo de ejecución

Docs

OWASP Coraza

Title here

Acciones

allow

auditlog

block

capture

chain

ctl

deny

drop

exec

expirevar

id

initcol

log

logdata

maturity

msg

multimatch

noauditlog

nolog

pass

phase

redirect

rev

setenv

setvar

severity

skip

skipafter

status

t

tag

ver

Acciones

allow#

auditlog#

block#

capture#

chain#

ctl#

deny#

drop#

exec#

expirevar#

id#

initcol#

log#

logdata#

maturity#

msg#

multimatch#

noauditlog#

nolog#

pass#

phase#

redirect#

rev#

setenv#

setvar#

severity#

skip#

skipafter#

status#

t#

tag#

ver#

allow

auditlog

block

capture

chain

ctl

deny

drop

exec

expirevar

id

initcol

log

logdata

maturity

msg

multimatch

noauditlog

nolog

pass

phase

redirect

rev

setenv

setvar

severity

skip

skipafter

status

t

tag

ver