ModSecurity: Registro y depuración

“ ModSecurity te ayudará a dormir mejor por la noche porque, sobre todo, resuelve el problema de visibilidad: te permite ver tu tráfico web ” .

Cuando algo no funciona como se espera, los registros son siempre el primer lugar donde buscar. Los buenos registros pueden brindar información valiosa para ayudarlo a solucionar los problemas que enfrenta. Una de las razones por las que Ivan Ristić creó originalmente ModSecurity es que estaba frustrado por la falta de visibilidad en las herramientas que estaba usando. No es de sorprender, entonces, que ModSecurity tenga amplias capacidades de registro y depuración.

ModSecurity tiene dos tipos de registros:

• Un registro de auditoría. Para cada transacción que se bloquea, ModSecurity proporciona registros detallados sobre la transacción y por qué se bloqueó.
• Un registro de depuración. Cuando está activado, este registro guarda información detallada sobre todo lo que hace ModSecurity.

El registro de auditoría es útil para saber no sólo por qué se bloqueó un ataque individual, sino también para obtener más información sobre los patrones de ataque generales. Te sorprendería la cantidad de tráfico de bots y escáneres que obtienes simplemente al exponer los puertos 80 y/o 443 a Internet.

En esta publicación de blog, describiremos los conceptos básicos del registro y la depuración con ModSecurity.

Registro de auditoría

El registro principal de ModSecurity es el registro de auditoría, que registra todos los ataques, incluidos los ataques potenciales, que ocurren. Si ha seguido nuestras instrucciones de instalación para ModSecurity (con NGINX Open Source ) o NGINX ModSecurity WAF (con NGINX Plus ), entonces, de manera predeterminada, ModSecurity registrará todas las transacciones que activaron una advertencia o un error, así como todas las transacciones que resultaron en respuestas 5xx y 4xx , excepto404 . (Sólo para un sistema Ubuntu 16.04, el registro de auditoría está en /var/log/modsec_audit.log ).

El registro de auditoría de ModSecurity está dividido en secciones. Esto hace que sea más fácil escanear el registro y encontrar la información que estás buscando. La siguiente tabla describe lo que contiene cada sección:

Cada transacción que activa una entrada en el registro de auditoría tendrá registrada alguna o todas las secciones anteriores. Puede configurar qué secciones se registran.

Ejemplo de registro de auditoría

Un ejemplo de entrada del registro de auditoría de ModSecurity podría verse así:

---ICmPEb5c---A--[04/oct/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
Host: 54.183.57.254
Agente de usuario: Mozilla/5.0 zgrab/0.x
Codificación aceptada: gzip

---ICmPEb5c---D--

---ICmPEb5c---F--
HTTP/1.1 200
Servidor: nginx/1.13.4
Fecha: Mié, 4 de oct. de 2017 21:45:15 GMT
Tipo de contenido: text/html
Conexión: keep-alive

---ICmPEb5c---H--
ModSecurity: Advertencia. Coincidencia del "Operador `Rx' con el parámetro `^[d.:]+$' con la variable `REQUEST_HEADERS:Host' (Valor: `54.183.57.254') [archivo "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [línea "733"] [id "920350"] [rev "2"] [msg "El encabezado del host es una dirección IP numérica"] [datos "54.183.57.254"] [s
everity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-prot
ocol"] [tag "OWASP_CRS/VIOLACIÓN_DE_PROTOCOLO/HOST_IP"] [etiqueta "WASCTC/WASC-21"] [etiqueta "OWASP_TOP_10/A7"] [etiqueta "PCI/6.5.10"] [ref "o0,13v21,13"]

---ICmPEb5c---I--

---ICmPEb5c---J--

---ICmPEb5c---Z--

Aunque no es inmediatamente evidente en la tabla anterior, la mejor sección para encontrar información sobre por qué se bloqueó una solicitud en particular es la sección H, no la K. En el ejemplo del registro de auditoría anterior, si revisamos la sección H, podemos ver el mensaje "El encabezado del host es una dirección IP numérica" , que indica que alguien intentó acceder a nuestro sitio por dirección IP en lugar de por nombre de host. Esto podría ser indicativo de un escáner.

Configuración del registro de auditoría

Si siguió nuestras instrucciones para instalar y configurar ModSecurity, encontrará la configuración del registro de auditoría en /etc/nginx/modsec/modsecurity.conf . En ese archivo, verá las siguientes tres directivas que controlan lo que se incluye en el registro de auditoría:

Motor de Auditoría de Seguridad Solo Relevante Estado Relevante del Registro de Auditoría de Seguridad "^(?:5|4(?!04))"
Partes del Registro de Auditoría de Seguridad ABIJDEFHZ

dónde

• SecAuditEngine : controla qué debe registrarse. Las opciones son:

  • Desactivado : deshabilita el registro de auditoría.
  • Activado : registra todas las transacciones, lo que puede resultar útil durante la depuración.
  • RelevantOnly : registra solo las transacciones que hayan activado una advertencia/error o que tengan un código de estado que coincida con el de la directiva SecAuditLogRelevantStatus .

• SecAuditLogRelevantStatus : si SecAuditEngine está configurado como RelevantOnly , esta directiva controla qué códigos de estado de respuesta HTTP se deben registrar. Se basa en expresiones regulares. El valor anterior registrará todas las respuestas 5xx y 4xx , excluyendo404 s.

• SecAuditLogParts : controla qué secciones deben incluirse en el registro de acceso. Eliminar las secciones que no le interesan reduce el tamaño del registro de auditoría y facilita su escaneo.

Para obtener directivas de configuración de registro de auditoría adicionales, consulte la wiki de ModSecurity .

Registro de depuración

Cuando el registro de depuración está activado, proporciona una gran cantidad de información sobre todo lo que hace ModSecurity. Para solucionar problemas sobre por qué algo no funciona como usted espera, el registro de depuración es su recurso ideal. También es genial si estás empezando a utilizar ModSecurity y quieres observar por qué hace las cosas de determinada manera.

Ejemplo de registro de depuración

El registro de depuración se ve así: Tiene muchos detalles sobre las acciones que ModSecurity toma para todas y cada una de las transacciones:

[4] (Regla: 1234) Ejecutando el operador "Contiene" con el parámetro "prueba" contra ARGS:testparam.[9] Valor objetivo: "prueba" (Variable: ARGS:testparam)
[9] Variables coincidentes actualizadas.
[4] Ejecutando acción [independiente] (no disruptiva): log
[9] Guardando transacción en registros
[4] La regla devolvió 1.
[9] (SecDefaultAction) Ejecutando acción: log
[9] Guardando transacción en registros
[9] (SecDefaultAction) Ejecutando acción: auditlog
[4] (SecDefaultAction) Ignorando acción: pass (la regla contiene una acción disruptiva)
[4] Ejecutando acción (no disruptiva): auditlog
[4] Ejecutando acción (disruptiva): deny

El registro de depuración enumera el número de identificación de la regla para facilitar la búsqueda. En este ejemplo, la salida es de nuestra regla de prueba con el número de identificación 1234.

Configuración del registro de depuración

De forma predeterminada, el registro de depuración está deshabilitado, ya que puede afectar negativamente el rendimiento. Al igual que con el registro de auditoría, el registro de depuración se configura en /etc/nginx/modsec/modsecurity.conf . En ese archivo, hay dos directivas de configuración que están comentadas. Para habilitar el registro de depuración, descomente estos elementos y cámbielos por lo siguiente:

SecDebugLog /var/log/modsec_debug.logSecDebugLogNivel 9

dónde

• SecDebugLog – Especifica la ruta al archivo de registro de depuración.
• Nivel de registro de depuración secundaria –0 –9 Indica cuánta información registrar, con9 siendo el más. Si está solucionando problemas, configure este valor en9 es el más útil

CONCLUSIÓN

En esta publicación de blog, cubrimos cómo comenzar a utilizar las amplias capacidades de registro dentro de ModSecurity. ModSecurity tiene registros de auditoría, que contienen información sobre todas las transacciones bloqueadas, y un registro de depuración para ayudarlo si tiene problemas al usar ModSecurity.

ModSecurity 3.0 está disponible tanto para NGINX Open Source como para NGINX ModSecurity WAF para NGINX Plus. El WAF NGINX ModSecurity es un módulo dinámico precompilado que recibe mantenimiento y soporte total de NGINX, Inc. Pruébelo gratis durante 30 días .

[ Editor – NGINX ModSecurity WAF oficialmente dejó de venderse el 1 de abril de 2022 y está en transición al fin de su vida útil a partir del 31 de marzo de 2024 . Para obtener más detalles, consulte F5 NGINX ModSecurity WAF está en transición al final de su vida útil<.htmla> en nuestro blog.]