Directivas

Include#

Descripción: Incluye y evalúa un archivo o un patrón de archivos.

Sintaxis: Include [PATH_TO_CONF_FILES]

Include carga un archivo o una lista de archivos del sistema de archivos utilizando la sintaxis Glob de golang.

Ejemplo:

Include /path/coreruleset/rules/*.conf

Citando la documentación de Glob:

La sintaxis de los patrones es la misma que en Match. El patrón puede describir nombres jerárquicos como /usr/*/bin/ed (asumiendo que el separador es ‘/’). Glob ignora los errores del sistema de archivos, como errores de E/S al leer directorios. El único error posible devuelto es ErrBadPattern, cuando el patrón está mal formado.

SecAction#

Descripción: Procesa incondicionalmente la lista de acciones que recibe como primer y único parámetro.

Sintaxis: SecAction "action1,action2,action3,..."

Esta directiva se utiliza comúnmente para establecer variables e inicializar colecciones persistentes usando la acción initcol. La sintaxis del parámetro es idéntica a la del tercer parámetro de SecRule.

Ejemplo:

SecAction "id:100,nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}"

SecArgumentsLimit#

Descripción: Configura el número máximo de argumentos que Coraza conserva de cada origen.

Sintaxis: SecArgumentsLimit [LIMIT]

Por defecto: 1000

La query string (ARGS_GET), la ruta (ARGS_PATH) y los cuerpos de solicitud urlencoded o JSON (ARGS_POST) se cuentan por separado; los cuerpos de respuesta JSON (RESPONSE_ARGS) usan el mismo límite. Los argumentos que superan el límite se descartan y ARGUMENTS_LIMIT_REACHED se establece en 1, de modo que una regla pueda rechazar la solicitud (véanse las reglas 200004 y 200005 en coraza.conf-recommended). El valor debe ser mayor que 0.

Ejemplo:

SecArgumentsLimit 1000

SecAuditEngine#

Descripción: Configura el motor de registro de auditoría.

Sintaxis: SecAuditEngine RelevantOnly

Por defecto: Off

La directiva SecAuditEngine se utiliza para configurar el motor de auditoría, que registra transacciones completas.

Los valores posibles para el motor de registro de auditoría son los siguientes:

• On: registrar todas las transacciones
• Off: no registrar ninguna transacción
• RelevantOnly: registrar únicamente las transacciones que hayan generado una advertencia o un error, o que tengan un código de estado que se considere relevante (según lo determinado por la directiva SecAuditLogRelevantStatus)

Nota: Si necesita cambiar la configuración del motor de registro de auditoría por transacción (por ejemplo, en respuesta a ciertos datos de la transacción), utilice la acción ctl.

El siguiente ejemplo muestra cómo se utiliza SecAuditEngine:

SecAuditEngine RelevantOnly
SecAuditLog logs/audit/audit.log
SecAuditLogParts ABCFHZ
SecAuditLogType concurrent
SecAuditLogStorageDir logs/audit
SecAuditLogRelevantStatus ^(?:5|4(?:0[0-35-9]|[1-9][0-9]))

SecAuditLog#

Descripción: Define la ruta al archivo principal de registro de auditoría (formato de registro en serie) o al archivo de índice de registro concurrente (formato de registro concurrente).

Sintaxis: SecAuditLog [ABSOLUTE_PATH_TO_LOG_FILE]

Ejemplo:

SecAuditLog "/path/to/audit.log"

Nota: Este archivo de registro de auditoría se abre al iniciar el servidor, cuando el servidor normalmente aún se ejecuta como root. No debería permitir que usuarios sin privilegios de root tengan permisos de escritura en este archivo ni en el directorio correspondiente.

SecAuditLogDirMode#

Descripción: Configura el modo (permisos) de los directorios creados para los registros de auditoría concurrentes, utilizando un valor de modo octal como parámetro (como se usa en chmod).

Sintaxis: SecAuditLogDirMode octal_mode|"default"

Por defecto: 0600

El modo predeterminado para los nuevos directorios de registro de auditoría (0600) solo concede acceso de lectura/escritura al propietario.

Ejemplo:

SecAuditLogDirMode 02750

SecAuditLogFileMode#

Descripción: Configura el modo (permisos) de los archivos creados para los registros de auditoría concurrentes utilizando un modo octal (como se usa en chmod). Consulte SecAuditLogDirMode para controlar el modo de los directorios de registro de auditoría creados.

Sintaxis: SecAuditLogFileMode octal_mode|"default"

Por defecto: 0600

Ejemplo:

SecAuditLogFileMode 00640

SecAuditLogFormat#

Descripción: Selecciona el formato de salida de los registros de auditoría. El formato puede ser el formato nativo de registros de auditoría, JSON u OCSF (Open CyberSecurity Schema Framework).

Sintaxis: SecAuditLogFormat JSON|JsonLegacy|Native|OCSF

Por defecto: Native

Ejemplo:

SecAuditLogFormat JSON

SecAuditLogParts#

Descripción: Define qué partes de cada transacción se registrarán en el registro de auditoría. A cada parte se le asigna una letra; cuando una letra aparece en la lista, la parte equivalente será registrada. Consulte a continuación la lista de todas las partes.

Sintaxis: SecAuditLogParts [PARTLETTERS]

Por defecto: ABCFHZ

Ejemplo:

SecAuditLogParts ABCFHZ

Partes disponibles del registro de auditoría:

• A: Cabecera del registro de auditoría (obligatoria).
• B: Cabeceras de la solicitud.
• C: Cuerpo de la solicitud (presente solo si el cuerpo de la solicitud existe y Coraza está configurado para interceptarlo. Esto requiere que SecRequestBodyAccess esté establecido en on).
• D: Reservado para cabeceras de respuesta intermedias; aún no implementado.
• E: Cuerpo de respuesta intermedio (presente solo si Coraza está configurado para interceptar cuerpos de respuesta y si el motor de registro de auditoría está configurado para registrarlo. La interceptación de cuerpos de respuesta requiere que SecResponseBodyAccess esté habilitado). El cuerpo de respuesta intermedio es el mismo que el cuerpo de respuesta real, a menos que Coraza intercepte el cuerpo de respuesta intermedio, en cuyo caso el cuerpo de respuesta real contendrá el mensaje de error.
• F: Cabeceras de respuesta finales.
• G: Reservado para el cuerpo de respuesta real; aún no implementado.
• H: Pie del registro de auditoría.
• I: Esta parte es un reemplazo de la parte C. Registrará los mismos datos que C en todos los casos, excepto cuando se utilice la codificación multipart/form-data. En este caso, registrará un cuerpo ficticio application/x-www-form-urlencoded que contiene la información sobre los parámetros pero no sobre los archivos. Esto es útil si no desea tener archivos (a menudo grandes) almacenados en sus registros de auditoría; aún no implementado.
• J: Esta parte contiene información sobre los archivos subidos usando la codificación multipart/form-data. Disponible desde Coraza v3.7.0.
• K: Esta parte contiene una lista completa de cada regla que coincidió (una por línea) en el orden en que coincidieron. Las reglas están completamente cualificadas y por tanto mostrarán las acciones heredadas y los operadores por defecto.
• Z: Límite final, indica el fin de la entrada (obligatorio).

SecAuditLogRelevantStatus#

Descripción: Configura qué código de estado de respuesta se considerará relevante a efectos del registro de auditoría.

Sintaxis: SecAuditLogRelevantStatus [REGEX]

El propósito principal de esta directiva es permitirle configurar el registro de auditoría solo para las transacciones que tengan un código de estado que coincida con la expresión regular proporcionada.

Ejemplo:

SecAuditLogRelevantStatus "^(?:5|40[1235])"

Este ejemplo registraría todos los códigos de estado de nivel 5xx y 4xx, excepto los 404. Aunque se podría lograr el mismo efecto con una regla en la fase 5, SecAuditLogRelevantStatus es a veces mejor, porque continúa funcionando incluso cuando SecRuleEngine está deshabilitado.

Nota: Requiere que SecAuditEngine esté establecido en RelevantOnly. Adicionalmente, la acción auditlog está presente por defecto en las reglas, lo que hará que el motor omita SecAuditLogRelevantStatus y envíe las coincidencias de reglas al registro de auditoría independientemente del estado. Debe especificar noauditlog en las reglas manualmente o establecerlo en SecDefaultAction.

SecAuditLogStorageDir#

Descripción: Configura el directorio donde se almacenan las entradas de registro de auditoría concurrentes.

Sintaxis: SecAuditLogStorageDir [PATH_TO_LOG_DIR]

Esta directiva es necesaria solo cuando se utiliza el registro de auditoría concurrente. Asegúrese de especificar una ubicación del sistema de archivos con espacio en disco adecuado.

Ejemplo:

SecAuditLogStorageDir /tmp/auditlogs/

SecAuditLogType#

Descripción: Configura el tipo de mecanismo de registro de auditoría a utilizar.

Sintaxis: SecAuditLogType Serial|Concurrent|HTTPS|Syslog

Los valores posibles son:

• Serial: Las entradas del registro de auditoría se almacenarán en un solo archivo, especificado por SecAuditLog. Esto es conveniente para uso ocasional, pero puede ralentizar el servidor, porque solo se puede escribir una entrada de registro de auditoría en el archivo a la vez.
• Concurrent: Se utiliza un archivo por transacción para el registro de auditoría. Este enfoque es más escalable cuando se requiere un registro intensivo (múltiples transacciones pueden registrarse en paralelo).
• HTTPS: Las entradas del registro de auditoría se enviarán a la URL de destino, especificada por SecAuditLog.
• Syslog: Las entradas del registro de auditoría se enviarán al servidor syslog, especificado por SecAuditLog en uno de los formatos: “ADDRESS:PORT” (TCP), “udp://ADDRESS:PORT”, o “unixgram:///var/run/syslog”.

Ejemplo:

SecAuditLogType Serial

SecCollectionTimeout#

Descripción: Establecería el tiempo, en segundos, durante el que se conservan los registros de las colecciones persistentes.

Sintaxis: SecCollectionTimeout [SECONDS]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecCollectionTimeout 600

SecComponentSignature#

Descripción: Añade la firma de un componente a la firma de Coraza.

Sintaxis: SecComponentSignature "COMPONENT_NAME/X.Y.Z (COMMENT)"

Añade la firma de un componente a la firma de Coraza.

Ejemplo:

SecComponentSignature "OWASP_CRS/4.18.0"

SecConnEngine#

Descripción: Habilitaría el seguimiento por conexión.

Sintaxis: SecConnEngine On|Off|DetectOnly

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecConnEngine Off

SecConnReadStateLimit#

Descripción: Limitaría el número de conexiones en estado de lectura por dirección IP.

Sintaxis: SecConnReadStateLimit [NUMBER]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecConnReadStateLimit 50

SecConnWriteStateLimit#

Descripción: Limitaría el número de conexiones en estado de escritura por dirección IP.

Sintaxis: SecConnWriteStateLimit [NUMBER]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecConnWriteStateLimit 50

SecDataDir#

Descripción: Establece el directorio donde se almacenan los datos de las colecciones persistentes.

Sintaxis: SecDataDir /path/to/dir

Ejemplo:

SecDataDir /tmp/coraza/data

SecDataset#

Descripción: Define un dataset con nombre, declarado en línea, al que pueden hacer referencia operadores como @pmFromDataset e @ipMatchFromDataset. Los registros se indican en un bloque delimitado por acentos graves (backticks), uno por línea.

Sintaxis: SecDataset NAME `\n...\n`

Ejemplo:

SecDataset test `
123
456
`

SecDebugLog#

Descripción: Ruta al archivo de registro de depuración de Coraza.

Sintaxis: SecDebugLog [ABSOLUTE_PATH_TO_DEBUG_LOG]

Los registros se escribirán en este archivo. Asegúrese de que el usuario del proceso tenga acceso de escritura al directorio.

Ejemplo:

SecDebugLog /var/log/coraza/debug.log

SecDebugLogLevel#

Descripción: Configura el nivel de detalle de los datos del registro de depuración.

Sintaxis: SecDebugLogLevel [LOG_LEVEL]

Por defecto: 3

Dependiendo de la implementación, los errores en el rango de 1 a 2 podrían registrarse directamente en el registro de errores del conector. Por ejemplo, los registros de nivel 1 (error) se escribirán en los registros de errores del servidor caddy. Los valores posibles para el nivel de registro de depuración son:

• 0: Sin registro (menos detallado)
• 1: Error
• 2: Advertencia
• 3: Información
• 4-8: Depuración
• 9: Traza (más detallado)

Los niveles fuera del rango 0-9 se establecerán por defecto en el nivel 3 (Información)

Ejemplo:

SecDebugLogLevel 3

SecDefaultAction#

Descripción: Define la lista de acciones por defecto, que será heredada por las reglas en el mismo contexto de configuración.

Sintaxis: SecDefaultAction "phase:2,log,auditlog,deny,status:403,tag:'SLA 24/7'"

Por defecto: phase:2,log,auditlog,pass

Cada regla que siga a una directiva SecDefaultAction previa en el mismo contexto de configuración heredará su configuración, a menos que se utilicen acciones más específicas.

Conjuntos de reglas como OWASP Core Ruleset usan esto para definir modos de operación:

• Puede establecer la acción disruptiva por defecto en block para las fases 1 y 2 y puede forzar que una regla de fase 3 sea disruptiva si la puntuación de amenaza es alta.
• Puede establecer la acción disruptiva por defecto en deny y cada regla de riesgo interrumpirá la conexión.

Importante: Cada directiva SecDefaultAction debe especificar una acción disruptiva y una fase de procesamiento y no puede contener acciones de metadatos.

Ejemplo:

SecDefaultAction "phase:2,log,auditlog,pass"

SecGsbLookupDb#

Descripción: Establecería la ruta a la base de datos de Google Safe Browsing que utiliza @gsbLookup.

Sintaxis: SecGsbLookupDb /path/to/db

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecGsbLookupDb /path/to/GsbMalware.dat

SecHTTPBlKey#

Descripción: Establecería la clave de API que utiliza el operador @rbl para las consultas a Project Honey Pot.

Sintaxis: SecHttpBlKey "KEY"

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHttpBlKey "my_api_key"

SecHashEngine#

Descripción: Habilitaría el motor de hashing de responses, que se utiliza para firmar enlaces y campos de formulario.

Sintaxis: SecHashEngine On|Off

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHashEngine On

SecHashKey#

Descripción: Establecería la clave que utiliza el motor de hashing de responses.

Sintaxis: SecHashKey [KEY] [KeyOnly|SessionID|RemoteIP]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHashKey "my_secret_key" KeyOnly

SecHashMethodPm#

Descripción: Seleccionaría, por coincidencia de frases, qué elementos de la response firma el motor de hashing.

Sintaxis: SecHashMethodPm TYPE PHRASES

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHashMethodPm HashHref "example.com"

SecHashMethodRx#

Descripción: Seleccionaría, mediante una expresión regular, qué elementos de la response firma el motor de hashing.

Sintaxis: SecHashMethodRx TYPE REGEX

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHashMethodRx HashHref "^/admin"

SecHashParam#

Descripción: Establecería el nombre del parámetro que transporta el hash añadido por el motor de hashing de responses.

Sintaxis: SecHashParam "NAME"

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto.

Ejemplo:

SecHashParam "hmac"

SecIgnoreRuleCompilationErrors#

Descripción: Continúa la carga de un conjunto de reglas cuando una regla no compila, en lugar de abortar. Al habilitarla se registra una advertencia: una regla defectuosa que no se carga no protege nada, por lo que es una ayuda para la migración y no una opción con la que operar.

Sintaxis: SecIgnoreRuleCompilationErrors On|Off

Ejemplo:

SecIgnoreRuleCompilationErrors Off

SecMarker#

Descripción: Añade un marcador de regla fijo que puede usarse como destino en una acción skipAfter. Una directiva SecMarker esencialmente crea una regla que no hace nada y cuyo único propósito es portar el ID proporcionado.

Sintaxis: SecMarker [ID|TEXT]

El valor puede ser un número o una cadena de texto. La directiva SecMarker está disponible para permitirle elegir la mejor manera de implementar un salto. A continuación se muestra un ejemplo utilizado del Core Rule Set:

SecMarker BEGIN_HOST_CHECK

	SecRule &REQUEST_HEADERS:Host "@eq 0" \
		"id:'960008',skipAfter:END_HOST_CHECK,phase:2,rev:'2.1.1',\
		t:none,block,msg:'Request Missing a Host Header',\
		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 "^$" \
		"id:'960009',phase:2,rev:'2.1.1',t:none,block,msg:'Request Missing a Host Header',\
		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

SecPcreMatchLimit#

Descripción: Establecería el límite de coincidencias de PCRE.

Sintaxis: SecPcreMatchLimit [NUMBER]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto. Coraza evalúa las expresiones regulares con RE2, que se ejecuta en tiempo lineal y no tiene ningún límite de backtracking que configurar.

Ejemplo:

SecPcreMatchLimit 1500

SecPcreMatchLimitRecursion#

Descripción: Establecería el límite de recursión de coincidencias de PCRE.

Sintaxis: SecPcreMatchLimitRecursion [NUMBER]

Nota: Coraza acepta esta directiva por compatibilidad con las configuraciones de ModSecurity, pero no tiene ningún efecto. Coraza evalúa las expresiones regulares con RE2, que no utiliza recursión al evaluarlas.

Ejemplo:

SecPcreMatchLimitRecursion 1500

SecRemoteRules#

Descripción: Carga reglas desde una URL remota.

Sintaxis: SecRemoteRules [KEY] URL

Nota: Coraza rechaza esta directiva: la obtención de reglas a través de la red no está implementada, por lo que una configuración que la utilice falla al cargarse con un error en lugar de ignorarse.

Ejemplo:

SecRemoteRules https://example.com/rules.conf

SecRemoteRulesFailAction#

Descripción: Controla lo que ocurre cuando no se pueden obtener las reglas de una fuente remota: Abort hace fallar la carga de la configuración y Warn continúa.

Sintaxis: SecRemoteRulesFailAction Abort|Warn

Ejemplo:

SecRemoteRulesFailAction Abort

SecRequestBodyAccess#

Descripción: Configura si los cuerpos de las solicitudes serán almacenados en búfer y procesados por Coraza.

Sintaxis: SecRequestBodyAccess On|Off

Por defecto: Off

Esta directiva es necesaria si desea inspeccionar los datos transportados en los cuerpos de las solicitudes (por ejemplo, parámetros POST). El almacenamiento en búfer de las solicitudes también es necesario para hacer posible un bloqueo fiable. Los valores posibles son:

• On: almacenar en búfer los cuerpos de las solicitudes
• Off: no almacenar en búfer los cuerpos de las solicitudes

Ejemplo:

SecRequestBodyAccess On

SecRequestBodyInMemoryLimit#

Descripción: Configura el tamaño máximo del cuerpo de la solicitud que Coraza almacenará en memoria.

Sintaxis: SecRequestBodyInMemoryLimit [LIMIT_IN_BYTES]

Por defecto: defaults to RequestBodyLimit

Cuando se procesa una solicitud multipart/form-data, una vez que se alcanza el límite de memoria, el cuerpo de la solicitud comenzará a transmitirse a un archivo temporal en disco.

Ejemplo:

SecRequestBodyInMemoryLimit 131072

SecRequestBodyJsonDepthLimit#

Descripción: Configura la profundidad máxima de recursión JSON que acepta Coraza.

Sintaxis: SecRequestBodyJsonDepthLimit [LIMIT]

Por defecto: 1024

Todo lo que supere el límite genera un REQBODY_ERROR en el body processor de JSON.

Ejemplo:

SecRequestBodyJsonDepthLimit 1024

SecRequestBodyLimit#

Descripción: Configura el tamaño máximo del cuerpo de la solicitud que Coraza aceptará para el almacenamiento en búfer.

Sintaxis: SecRequestBodyLimit [LIMIT_IN_BYTES]

Por defecto: 134217728 (128 Mib)

Depende de SecRequestBodyLimitAction

• Reject: Cualquier cosa que supere este límite será rechazada con el código de estado 413 (Request Entity Too Large).
• ProcessPartial: Se procesarán los primeros N bytes del cuerpo de la solicitud. Existe un límite estricto de 1 GiB.

Ejemplo:

SecRequestBodyLimit 134217728

SecRequestBodyLimitAction#

Descripción: Controla lo que sucede cuando se alcanza el límite del cuerpo de la solicitud, configurado con SecRequestBodyLimit.

Sintaxis: SecRequestBodyLimitAction Reject|ProcessPartial

Por defecto: Reject

Por defecto, Coraza rechazará un cuerpo de solicitud que sea más largo de lo especificado para evitar problemas de memoria insuficiente al almacenar en búfer el cuerpo de la solicitud antes de la inspección.

Nota: Cuando SecRuleEngine está establecido en DetectionOnly, esta directiva se establece en ProcessPartial para minimizar las interrupciones durante el despliegue inicial de Coraza.

Ejemplo:

SecRequestBodyLimitAction Reject

SecRequestBodyNoFilesLimit#

Descripción: Configura el tamaño máximo del cuerpo de la solicitud que Coraza aceptará para el almacenamiento en búfer, excluyendo el tamaño de los archivos transportados en la solicitud. Esta directiva es útil para reducir la susceptibilidad a ataques DoS cuando alguien envía cuerpos de solicitud de tamaños muy grandes. Las aplicaciones web que requieren la subida de archivos deben configurar SecRequestBodyLimit con un valor alto, pero como los archivos grandes se transmiten al disco, las subidas de archivos no aumentarán el consumo de memoria. Sin embargo, aún es posible que alguien aproveche un límite alto del cuerpo de la solicitud y envíe solicitudes sin archivos con cuerpos de gran tamaño. Esta directiva elimina esa brecha.

Sintaxis: SecRequestBodyNoFilesLimit 131072

Por defecto: 1048576 (1 MB)

En general, el valor por defecto no es lo suficientemente bajo. Para la mayoría de las aplicaciones, debería poder reducirlo a 128 KB o menos. Cualquier cosa que supere el límite será rechazada con el código de estado 413 (Request Entity Too Large). Existe un límite estricto de 1 GiB.

Nota: aún no implementado

Ejemplo:

SecRequestBodyNoFilesLimit 131072

SecResponseBodyAccess#

Descripción: Configura si los cuerpos de las respuestas deben ser almacenados en búfer.

Sintaxis: SecResponseBodyAccess On|Off

Por defecto: Off

Esta directiva es necesaria si planea inspeccionar las respuestas HTML e implementar el bloqueo de respuestas. Los valores posibles son:

• On: almacenar en búfer los cuerpos de las respuestas (pero solo si el tipo MIME de la respuesta coincide con la lista configurada con SecResponseBodyMimeType).
• Off: no almacenar en búfer los cuerpos de las respuestas.

Ejemplo:

SecResponseBodyAccess On

SecResponseBodyJsonDepthLimit#

Descripción: Configura la profundidad máxima de recursión JSON que acepta Coraza en los cuerpos de respuesta.

Sintaxis: SecResponseBodyJsonDepthLimit [LIMIT]

Por defecto: 1024

Todo lo que supere el límite genera un RES_BODY_ERROR en el body processor de JSON. Requiere SecResponseBodyAccess On para tener efecto.

Ejemplo:

SecResponseBodyJsonDepthLimit 1024

SecResponseBodyLimit#

Descripción: Configura el tamaño máximo del cuerpo de la respuesta que se aceptará para el almacenamiento en búfer.

Sintaxis: SecResponseBodyLimit [LIMIT_IN_BYTES]

Por defecto: 524288 (512 Kib)

Depende de SecResponseBodyLimitAction

• Reject: Cualquier cosa que supere este límite será rechazada con el código de estado 500 (Internal Server Error).
• ProcessPartial: Se procesarán los primeros N bytes del cuerpo de la respuesta. Esta configuración no afectará a las respuestas con tipos MIME que no estén seleccionados para el almacenamiento en búfer. Existe un límite estricto de 1 GiB.

Ejemplo:

SecResponseBodyLimit 524288

SecResponseBodyLimitAction#

Descripción: Controla lo que sucede cuando se alcanza el límite del cuerpo de la respuesta, configurado con SecResponseBodyLimit.

Sintaxis: SecResponseBodyLimitAction Reject|ProcessPartial

Por defecto, Coraza rechazará un cuerpo de respuesta que sea más largo de lo especificado. Sin embargo, algunos sitios web producirán respuestas muy largas, lo que dificulta establecer un límite razonable. Dichos sitios tendrían que aumentar el límite significativamente para funcionar correctamente, anulando el propósito de tener el límite en primer lugar (controlar el consumo de memoria). Con la capacidad de elegir qué sucede cuando se alcanza un límite, los administradores de sitios pueden optar por inspeccionar solo la primera parte de la respuesta, la parte que puede caber dentro del límite deseado, y dejar pasar el resto. Algunos podrían argumentar que permitir que partes de las respuestas pasen sin inspección es una debilidad. Esto es cierto en teoría, pero se aplica solo a casos en los que el atacante controla la salida (por ejemplo, puede hacerla arbitrariamente larga). En tales casos, sin embargo, no es posible prevenir la filtración de todos modos. El atacante podría comprimir, ofuscar o incluso cifrar los datos antes de enviarlos de vuelta, y por tanto eludir cualquier dispositivo de monitorización.

Nota: Cuando SecRuleEngine está establecido en DetectionOnly, esta directiva se establece en ProcessPartial para minimizar las interrupciones durante el despliegue inicial de Coraza.

Ejemplo:

SecResponseBodyLimitAction ProcessPartial

SecResponseBodyMimeType#

Descripción: Configura qué tipos MIME se considerarán para el almacenamiento en búfer del cuerpo de la respuesta.

Sintaxis: SecResponseBodyMimeType MIMETYPE MIMETYPE ...

Se pueden utilizar múltiples directivas SecResponseBodyMimeType para añadir tipos MIME. Use SecResponseBodyMimeTypesClear para borrar los tipos MIME configurados previamente y comenzar de nuevo.

Ejemplo:

SecResponseBodyMimeType text/plain text/html text/xml

SecResponseBodyMimeTypesClear#

Descripción: Borra la lista de tipos MIME considerados para el almacenamiento en búfer del cuerpo de la respuesta, permitiéndole comenzar a poblar la lista desde cero.

Sintaxis: SecResponseBodyMimeTypesClear

Ejemplo:

SecResponseBodyMimeTypesClear

SecRule#

Descripción: Crea una regla que analizará las variables seleccionadas utilizando el operador seleccionado.

Sintaxis: SecRule VARIABLES OPERATOR [ACTIONS]

Cada regla debe proporcionar una o más variables junto con el operador que debe usarse para inspeccionarlas. Si no se proporcionan acciones, se utilizará la lista por defecto. (Siempre hay una lista por defecto, incluso si no se estableció explícitamente con SecDefaultAction.) Si hay acciones especificadas en una regla, se fusionarán con la lista por defecto para formar las acciones finales que se utilizarán. (Las acciones en la regla sobrescribirán las de la lista por defecto.) Consulte SecDefaultAction para más información.

Ejemplo:

SecRule ARGS "@rx attack" "phase:1,log,deny,id:1"

SecRuleEngine#

Descripción: Configura el motor de reglas.

Sintaxis: SecRuleEngine On|Off|DetectionOnly

Por defecto: Off

Los valores posibles son:

• On: procesar reglas
• Off: no procesar reglas
• DetectionOnly: procesar reglas pero nunca ejecutar acciones disruptivas (block, deny, drop, allow, proxy y redirect)

Ejemplo:

SecRuleEngine DetectionOnly

SecRuleRemoveByID#

Descripción: Elimina las reglas coincidentes del contexto de configuración actual.

Sintaxis: SecRuleRemoveById ID|RANGE [ID|RANGE ...]

Elimina permanentemente de la configuración del WAF, al analizarla, las reglas indicadas por ID o por rango inclusivo. La eliminación se aplica a todas las transacciones. Para un control más granular al deshabilitar una regla, véase la acción ctl:ruleRemoveById, que actúa en tiempo de ejecución y por transacción.

Nota: Esta directiva opera sobre las reglas ya cargadas en el punto en que se analiza, por lo que debe aparecer DESPUÉS de cualquier directiva Include que cargue las reglas que se van a eliminar. Colocarla antes del Include no tiene efecto porque esas reglas todavía no existen en la configuración.

Ejemplo:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny"
SecRuleRemoveById 1000

SecRuleRemoveByMsg#

Descripción: Elimina las reglas coincidentes del contexto de configuración actual.

Sintaxis: SecRuleRemoveByMsg MESSAGE

Elimina permanentemente de la configuración del WAF, al analizarla, todas las reglas con el mensaje indicado. La eliminación se aplica a todas las transacciones. Para un control más granular al deshabilitar reglas, véase la acción ctl:ruleRemoveByMsg, que actúa en tiempo de ejecución y por transacción.

La coincidencia es por igualdad de cadena sensible a mayúsculas.

Nota: Esta directiva opera sobre las reglas ya cargadas en el punto en que se analiza, por lo que debe aparecer DESPUÉS de cualquier directiva que cargue las reglas que se van a eliminar. Colocarla antes no tiene efecto porque esas reglas todavía no existen en la configuración.

Ejemplo:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny,msg:'My Custom Rule Msg'"
SecRuleRemoveByMsg "My Custom Rule Msg"

SecRuleRemoveByTag#

Descripción: Elimina las reglas coincidentes del contexto de configuración actual.

Sintaxis: SecRuleRemoveByTag [TAG]

Elimina permanentemente de la configuración del WAF, al analizarla, todas las reglas que llevan la etiqueta indicada. La eliminación se aplica a todas las transacciones. Para un control más granular al deshabilitar reglas, véase la acción ctl:ruleRemoveByTag, que actúa en tiempo de ejecución y por transacción.

La coincidencia es por igualdad de cadena sensible a mayúsculas.

Nota: Esta directiva opera sobre las reglas ya cargadas en el punto en que se analiza, por lo que debe aparecer DESPUÉS de cualquier directiva que cargue las reglas que se van a eliminar. Colocarla antes no tiene efecto porque esas reglas todavía no existen en la configuración.

Ejemplo:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny,tag:my-tag"
SecRuleRemoveByTag my-tag

Nota: OWASP CRS tiene una lista de etiquetas compatibles https://coreruleset.org/docs/rules/metadata/

SecRuleUpdateActionByID#

Descripción: Actualiza la lista de acciones de la(s) regla(s) especificada(s).

Sintaxis: SecRuleUpdateActionById ID ACTIONLIST

Esta directiva sobrescribirá la lista de acciones de la regla especificada con las acciones proporcionadas en el segundo parámetro. Tiene dos limitaciones: no puede usarse para cambiar el ID o la fase de una regla. Solo se sobrescriben las acciones que pueden aparecer una sola vez. Las acciones que pueden aparecer múltiples veces en una lista se añadirán al final de la misma. El siguiente ejemplo muestra cómo se utiliza SecRuleUpdateActionById:

SecRuleUpdateActionById 12345 "deny,status:403"

El ID de la regla puede ser un ID individual o rangos de IDs. Los destinos se separan con el carácter de tubería.

SecRuleUpdateTargetByID#

Descripción: Actualiza la lista de destinos (variables) de la(s) regla(s) especificada(s).

Sintaxis: SecRuleUpdateTargetById ID TARGET1[|TARGET2|TARGET3]

Esta directiva añadirá variables a la regla especificada con los destinos proporcionados en el segundo parámetro. El ID de la regla puede ser un ID individual o rangos de IDs. Los destinos se separan con el carácter de tubería.

Ejemplo:

SecRuleUpdateTargetById 7 "!REQUEST_HEADERS:/xyz/"

SecRuleUpdateTargetByTag#

Descripción: Actualiza la lista de destinos (variables) de la(s) regla(s) especificada(s) por etiqueta.

Sintaxis: SecRuleUpdateTargetByTag TAG TARGET1[|TARGET2|TARGET3]

Como alternativa a SecRuleUpdateTargetById, esta directiva añadirá variables a la regla especificada con los destinos proporcionados en el segundo parámetro. Puede ser útil para actualizar un grupo completo de reglas. La coincidencia es por igualdad de cadena sensible a mayúsculas. Esta directiva añadirá variables a la regla especificada con los destinos proporcionados en el segundo parámetro. El ID de la regla puede ser un ID individual o rangos de IDs. Los destinos se separan con el carácter de tubería.

Nota: OWASP CRS proporciona una lista de etiquetas compatibles.

Ejemplo:

SecRuleUpdateTargetByTag "attack-sqli" "!ARGS:query"

SecRxPreFilter#

Descripción: Habilita o deshabilita el prefiltrado para el operador @rx.

Sintaxis: SecRxPreFilter On|Off

Por defecto: Off

Cuando está habilitado, Coraza analiza cada patrón de expresión regular al cargar las reglas para extraer las subcadenas literales obligatorias y calcular la longitud mínima de coincidencia. Al procesar cada request, estas comprobaciones rápidas se ejecutan antes que la expresión regular completa, lo que permite al motor omitirla por completo cuando una entrada claramente no puede coincidir.

Advertencia: Esta es una funcionalidad experimental.

Ejemplo:

SecRxPreFilter On

SecSensorID#

Descripción: Establece un identificador para esta instancia de Coraza, útil cuando varios sensores escriben en un registro compartido.

Sintaxis: SecSensorID "ID"

Ejemplo:

SecSensorID "sensor-01"

SecServerSignature#

Descripción: Establece la firma de servidor que comunica Coraza. Si el valor va entre comillas, estas se eliminan.

Sintaxis: SecServerSignature "SIGNATURE"

Ejemplo:

SecServerSignature "Apache/2.2.15"

SecUploadDir#

Descripción: Configura el directorio donde se almacenan los ficheros subidos.

Sintaxis: SecUploadDir /path/to/dir

Por defecto: ""

Esta directiva es obligatoria cuando se habilita SecUploadKeepFiles.

Ejemplo:

SecUploadDir /tmp/coraza/uploads

SecUploadFileLimit#

Descripción: Establece el número máximo de ficheros subidos que se gestionan por request. El valor se analiza, pero todavía no se aplica; véase corazawaf/coraza#1686 para la discusión al respecto.

Sintaxis: SecUploadFileLimit [NUMBER]

Ejemplo:

SecUploadFileLimit 10

SecUploadFileMode#

Descripción: Establece el modo de fichero que se aplica a los ficheros almacenados por SecUploadDir. El valor se interpreta como octal.

Sintaxis: SecUploadFileMode OCTAL_MODE

Ejemplo:

SecUploadFileMode 0600

SecUploadKeepFiles#

Descripción: Configura si los ficheros interceptados se conservan una vez procesada la transacción.

Sintaxis: SecUploadKeepFiles On|RelevantOnly|Off

Por defecto: Off

La directiva SecUploadKeepFiles se utiliza para configurar si los ficheros interceptados se conservan en disco una vez procesada la transacción. Esta directiva requiere que se haya definido el directorio de almacenamiento (mediante SecUploadDir).

Los valores posibles son:

• On: conservar todos los ficheros subidos.
• Off: no conservar los ficheros subidos.
• RelevantOnly: conservar solo los ficheros subidos que hayan coincidido con al menos una regla que se registraría (excluyendo las reglas con la acción nolog).

Ejemplo:

SecUploadKeepFiles RelevantOnly

SecWebAppID#

Descripción: Establece un identificador para la aplicación web protegida. El valor queda disponible para las reglas y los registros de auditoría.

Sintaxis: SecWebAppID "NAME"

Ejemplo:

SecWebAppID "my_application"

Unsupported#

Descripción: Manejador compartido para las directivas de ModSecurity que Coraza analiza y descarta, de modo que las configuraciones existentes sigan cargándose.

Sintaxis: SecTmpDir /path/to/dir

Nota: Este manejador respalda SecArgumentSeparator, SecCookieFormat, SecRuleUpdateTargetByMsg, SecRuleScript, SecRulePerfTime, SecUnicodeMap y SecTmpDir. Todas se aceptan y se ignoran.

Ejemplo:

SecTmpDir /tmp