ModSecurity : journalisation et débogage

Faisal MemonIngénieur logiciel

« ModSecurity vous aidera à mieux dormir la nuit, car il résout avant tout le problème de visibilité : il vous permet de voir votre trafic web. »

– Ivan Ristić, créateur de ModSecurity

Lorsque quelque chose ne fonctionne pas comme prévu, les journaux sont toujours le premier endroit où chercher. Des journaux de qualité peuvent fournir de précieuses informations pour vous aider à résoudre les problèmes auxquels vous êtes confronté. L’une des raisons pour lesquelles Ivan Ristić a créé ModSecurity à l’origine est qu’il était frustré par le manque de visibilité offert par les outils qu’il utilisait. Il n’est donc pas surprenant que ModSecurity dispose de fonctionnalités étendues de journalisation et de débogage.

ModSecurity propose deux types de journaux :

• Un journal d’audit. Pour chaque transaction bloquée, ModSecurity fournit des journaux détaillés sur la transaction et la raison de son blocage.
• Un journal de débogage. Lorsqu’il est activé, ce journal conserve des informations détaillées sur toutes les opérations effectuées par ModSecurity.

Le journal d’audit permet non seulement de comprendre pourquoi une attaque donnée a été bloquée, mais aussi d’en savoir plus sur les tendances générales en matière d’attaques. Vous pourriez être surpris par le volume de trafic généré par les bots et les scanners simplement en exposant les ports 80 et/ou 443 à Internet.

Dans cet article de blog, nous présenterons les principes de base de la journalisation et du débogage avec ModSecurity.

Journal d’audit

Le journal principal de ModSecurity est le journal d’audit, qui consigne toutes les attaques, y compris les attaques potentielles, qui se produisent. Si vous avez suivi nos instructions d’installation de ModSecurity (avec NGINX Open Source) ou de NGINX ModSecurity WAF (avec NGINX Plus), alors, par défaut, ModSecurity consignera toutes les transactions ayant déclenché un avertissement ou une erreur, ainsi que toutes celles ayant entraîné des réponses 5xx et 4xx, à l’exception de 404. (Sur un système Ubuntu 16.04 uniquement, le journal d’audit se trouve dans /var/log/modsec_audit.log.)

Le journal d’audit de ModSecurity est divisé en sections. Cela facilite son examen et permet de trouver plus rapidement les informations recherchées. Le tableau ci-dessous décrit le contenu de chaque section :

Pour chaque transaction qui déclenche une entrée dans le journal d’audit, tout ou partie des sections ci-dessus sont consignées. Vous pouvez configurer les sections à consigner.

Exemple de journal d’audit

Voici à quoi pourrait ressembler un exemple d’entrée de journal d’audit ModSecurity :

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

Bien que cela ne ressorte pas immédiatement du tableau ci-dessus, la section la plus pertinente pour savoir pourquoi une requête donnée a été bloquée est la section H, et non la section K. Dans l’exemple de journal d’audit ci-dessus, en parcourant la section H, on peut voir le message « L’en-tête Host est une adresse IP numérique » qui indique que quelqu’un a tenté d’accéder à notre site à l’aide de son adresse IP plutôt que de son nom d’hôte. Cela peut être le signe d’une analyse automatisée.

Configuration de la journalisation d’audit

Si vous avez suivi nos instructions pour installer et configurer ModSecurity, vous trouverez la configuration de la journalisation d’audit dans /etc/nginx/modsec/modsecurity.conf. Dans ce fichier, vous trouverez les trois directives suivantes, qui déterminent les informations consignées dans le journal d’audit :

SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"SecAuditLogParts ABIJDEFHZ

où

• SecAuditEngine – Contrôle les éléments à journaliser. Les options sont les suivantes :
  • Off – Désactive le journal d’audit.
  • Activé – Consigne toutes les transactions, ce qui peut être utile pour le débogage.
  • RelevantOnly – Journaliser uniquement les transactions ayant déclenché un avertissement ou une erreur, ou dont le code d’état correspond à celui défini dans la directive SecAuditLogRelevantStatus.
• SecAuditLogRelevantStatus – If SecAuditEngine est défini sur RelevantOnly, cette directive détermine alors les codes d’état de réponse HTTP qui doivent être journalisés. Elle repose sur une expression régulière. La valeur ci-dessus journalisera toutes les réponses 5xx et 4xx, à l’exception des erreurs 404.
• SecAuditLogParts – Contrôle les sections à inclure dans le journal d’accès. La suppression des sections qui ne vous intéressent pas réduit la taille du journal d’audit et facilite sa consultation.

Pour connaître les autres directives de configuration de la journalisation des audits, consultez le wiki de ModSecurity.

Journal de débogage

Lorsque le journal de débogage est activé, il fournit une mine d’informations sur toutes les opérations effectuées par ModSecurity. Pour comprendre pourquoi quelque chose ne fonctionne pas comme prévu, le journal de débogage est votre ressource de référence. Il est également très utile si vous débutez avec ModSecurity et souhaitez comprendre pourquoi il se comporte d’une certaine manière.

Exemple de journal de débogage

Le journal de débogage se présente comme suit. Il contient de nombreux détails sur les actions effectuées par ModSecurity pour chacune des transactions :

[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: deny

Le journal de débogage indique le numéro d’identification de la règle afin de faciliter les recherches. Dans cet exemple, la sortie provient de notre règle de test portant le numéro d’identification 1234.

Configuration du journal de débogage

Par défaut, le journal de débogage est désactivé, car il peut nuire aux performances. Comme pour la journalisation d’audit, le journal de débogage est configuré dans /etc/nginx/modsec/modsecurity.conf. Dans ce fichier, deux directives de configuration sont commentées. Pour activer la journalisation de débogage, décommentez-les et modifiez-les comme suit :

SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9

où

• SecDebugLog – Spécifie le chemin d’accès au fichier journal de débogage.
• SecDebugLogLevel – 0–9 indique la quantité d’informations à consigner, 9 étant le niveau le plus élevé. Si vous effectuez un dépannage, définir cette valeur sur 9 est le plus utile.

Conclusion

Dans cet article de blog, nous avons expliqué comment commencer à utiliser les nombreuses fonctionnalités de journalisation de ModSecurity. ModSecurity propose à la fois des journaux d’audit, qui contiennent des informations sur toutes les transactions bloquées, et un journal de débogage pour vous aider davantage si vous rencontrez des difficultés lors de son utilisation.

ModSecurity 3.0 est disponible à la fois pour NGINX Open Source et sous la forme du NGINX ModSecurity WAF pour NGINX Plus. Le NGINX ModSecurity WAF est un module dynamique précompilé, maintenu et entièrement pris en charge par NGINX, Inc. Essayez-le gratuitement pendant 30 jours.

[Note de la rédaction – La commercialisation de NGINX ModSecurity WAF a officiellement pris fin le 1er avril 2022, et sa fin de vie prendra effet le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF passe en fin de vie<.htmla> sur notre blog.]

À propos de l’auteur

Faisal MemonIngénieur logiciel

Autres articles de Faisal Memon