«ModSecurity te ayudará a dormir mejor por la noche porque, ante todo, resuelve el problema de la visibilidad: te permite ver tu tráfico web».
– Ivan Ristić, creador de ModSecurity
Cuando algo no funciona como esperas, los registros son siempre el primer lugar donde debes mirar. Unos buenos registros pueden proporcionar información valiosa para ayudarte a solucionar los problemas a los que te enfrentas. Una de las razones por las que Ivan Ristić creó originalmente ModSecurity fue su frustración ante la falta de visibilidad de las herramientas que utilizaba. Por tanto, no es de extrañar que ModSecurity cuente con amplias funciones de registro y depuración.
ModSecurity tiene dos tipos de registros:
- Un registro de auditoría. Por cada transacción bloqueada, ModSecurity proporciona registros detallados sobre la transacción y el motivo por el que se bloqueó.
- Un registro de depuración. Cuando está activado, este registro almacena información exhaustiva sobre todo lo que hace ModSecurity.
El registro de auditoría no solo resulta útil para saber por qué se bloqueó un ataque concreto, sino también para obtener más información sobre los patrones generales de ataque. Puede que le sorprenda la cantidad de tráfico de bots y escáneres que recibe por el mero hecho de exponer a Internet los puertos 80 y/o 443.
En esta entrada del 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 que se producen, incluidos los posibles ataques. Si ha seguido nuestras instrucciones de instalación de ModSecurity (con NGINX Open Source) o de NGINX ModSecurity WAF (con NGINX Plus), de forma predeterminada, ModSecurity registrará todas las transacciones que hayan activado una advertencia o un error, así como todas las transacciones que hayan dado lugar a respuestas 5xx y 4xx, excepto 404. (Solo en sistemas Ubuntu 16.04, el registro de auditoría se encuentra en /var/log/modsec_audit.log.)
El registro de auditoría de ModSecurity está dividido en secciones. Esto facilita la consulta del registro y la búsqueda de la información que necesita. En la tabla siguiente se indica qué contiene cada sección:
| Sección | Descripción |
|---|---|
| A | Cabecera del registro de auditoría (obligatoria) |
| B | Cabeceras de la solicitud |
| C | Cuerpo de la solicitud |
| D | Reservada |
| E | Cuerpo de la respuesta |
| F | Cabeceras de la respuesta |
| G | Reservada |
| H | Pie del registro de auditoría, que contiene datos adicionales |
| I | Alternativa compacta al cuerpo de la solicitud (sección C), que excluye los archivos |
| J | Información sobre los archivos subidos |
| K | Contiene una lista de todas las reglas que coincidieron con la transacción |
| Z | Delimitador final (obligatorio) |
En cada transacción que genere una entrada en el registro de auditoría, se registrarán algunas 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 tener este aspecto:
---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.1Host: 54.183.57.254User-Agent: Mozilla/5.0 zgrab/0.xAccept-Encoding: gzip---ICmPEb5c---D-----ICmPEb5c---F--HTTP/1.1 200Server: nginx/1.13.4Date: Wed, 04 Oct 2017 21:45:15 GMTContent-Type: text/htmlConnection: keep-alive---ICmPEb5c---H--ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `54.183.57.254' ) [file "/root/owasp-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "733"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "54.183.57.254"] [severity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [ref "o0,13v21,13"]---ICmPEb5c---I-----ICmPEb5c---J-----ICmPEb5c---Z--Aunque no resulte evidente a primera vista en la tabla anterior, la mejor sección para encontrar información sobre por qué se bloqueó una solicitud concreta es la sección H, no la sección K. Si revisamos la sección H del ejemplo anterior del registro de auditoría, podemos ver el mensaje "El encabezado Host es una dirección IP numérica" que indica que alguien intentó acceder a nuestro sitio mediante la dirección IP en lugar del nombre de host. Esto podría indicar que se trata de un escáner.
Configuración del registro de auditoría
Si ha seguido 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 tres directivas siguientes, que controlan qué se incluye en el registro de auditoría:
SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"SecAuditLogParts ABIJDEFHZdonde
SecAuditEngine– Controla qué se debe registrar. Las opciones son:Off– Desactiva el registro de auditoría.Activado– Registra todas las transacciones, lo que puede resultar útil para la depuración.RelevantOnly– Registra únicamente las transacciones que hayan activado una advertencia o un error, o cuyo código de estado coincida con lo especificado en la directivaSecAuditLogRelevantStatus.
SecAuditLogRelevantStatus–Si SecAuditEngineestá configurado comoRelevantOnly, esta directiva controla qué códigos de estado de respuesta HTTP deben registrarse. Se basa en expresiones regulares. El valor anterior registrará todas las respuestas5xxy4xx, excepto las404.SecAuditLogParts– Controla qué secciones deben incluirse en el registro de acceso. Eliminar las secciones que no le interesen reduce el tamaño del registro de auditoría y facilita su revisión.
Para consultar directivas de configuración adicionales del registro de auditoría, consulte la wiki de ModSecurity.
Registro de depuración
Cuando se activa el registro de depuración, este proporciona una gran cantidad de información sobre todo lo que hace ModSecurity. Si necesita solucionar problemas y averiguar por qué algo no funciona como esperaba, el registro de depuración es el recurso de referencia. También resulta muy útil si está empezando a utilizar ModSecurity y quiere observar por qué actúa de una determinada manera.
Ejemplo de registro de depuración
El registro de depuración tiene el siguiente aspecto. Incluye muchos detalles sobre las acciones que lleva a cabo ModSecurity en todas y cada una de las transacciones:
[4] (Rule: 1234) Executing operator "Contains" with param "test" against ARGS:testparam.[9] Target value: "test" (Variable: ARGS:testparam)[9] Matched vars updated.[4] Running [independent] (non-disruptive) action: log[9] Saving transaction to logs[4] Rule returned 1.[9] (SecDefaultAction) Running action: log[9] Saving transaction to logs[9] (SecDefaultAction) Running action: auditlog[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)[4] Running (non-disruptive) action: auditlog[4] Running (disruptive) action: denyEl registro de depuración muestra el número de ID de la regla para facilitar la búsqueda. En este ejemplo, la salida corresponde a nuestra regla de prueba con el número de ID 1234.
Configuración del registro de depuración
De forma predeterminada, el registro de depuración está deshabilitado, ya que puede afectar negativamente al rendimiento. Al igual que 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 comentadas. Para habilitar el registro de depuración, quite los comentarios y modifíquelas de la siguiente manera:
SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9donde
- SecDebugLog – Especifica la ruta del archivo de registro de depuración.
- SecDebugLogLevel –
0–9indica cuánta información se registra;9es el nivel máximo. Si está solucionando problemas, establecer este valor en9es lo más útil.
Conclusión
En esta entrada del blog, hemos explicado cómo empezar a utilizar las amplias funciones de registro de ModSecurity. ModSecurity dispone tanto de registros de auditoría, que contienen información sobre todas las transacciones bloqueadas, como de un registro de depuración que ofrece ayuda adicional si tiene problemas al utilizar ModSecurity.
ModSecurity 3.0 está disponible tanto para NGINX Open Source como en forma de NGINX ModSecurity WAF para NGINX Plus. NGINX ModSecurity WAF es un módulo dinámico precompilado que cuenta con el mantenimiento y el soporte integral de NGINX, Inc. Pruébelo gratis durante 30 días.
[Editor – NGINX ModSecurity WAF dejó de comercializarse oficialmente el 1 de abril de 2022 y llegará al final de su vida útil el 31 de marzo de 2024. Para obtener más información, consulte F5 NGINX ModSecurity WAF está llegando al final de su vida útil<.htmla> en nuestro blog.]
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.