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 "nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}"

SecArgumentsLimit#

Descripción: Configura el número máximo de ARGS que se aceptarán para su procesamiento.

Sintaxis: SecArgumentsLimit [LIMIT]

Por defecto: 1000

Los argumentos que excedan el límite no serán incluidos. Con el procesamiento de cuerpo JSON, no hay nada que hacer cuando se excede el límite. 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(?!04))

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

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; aún no implementado.
• 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

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"

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.

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)

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.

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:'960008',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

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

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.

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.

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.

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

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.

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.

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.

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

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)

SecRuleRemoveByID#

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

Sintaxis: SecRuleRemoveById ...[ID OR RANGE]

SecRuleRemoveByMsg#

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

Sintaxis: SecRuleRemoveByMsg MESSAGE

Normalmente, usaría SecRuleRemoveById para eliminar reglas, pero ocasionalmente puede ser más fácil deshabilitar una o más reglas con SecRuleRemoveByMsg. La coincidencia es por igualdad de cadena sensible a mayúsculas.

Ejemplo:

SecRuleRemoveByMsg "Directory Listing"

SecRuleRemoveByTag#

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

Sintaxis: SecRuleRemoveByTag [TAG]

Normalmente, usaría SecRuleRemoveById para eliminar reglas, pero ocasionalmente puede ser más fácil deshabilitar un grupo completo de reglas con SecRuleRemoveByTag. La coincidencia es por igualdad de cadena sensible a mayúsculas.

Ejemplo:

SecRuleRemoveByTag attack-dos

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"

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.

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 tiene una lista de etiquetas compatibles https://coreruleset.org/docs/rules/metadata/