ModSecurity : Journalisation et débogage

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

Lorsque quelque chose ne fonctionne pas comme prévu, les journaux sont toujours le premier endroit à consulter. De bons journaux peuvent fournir des informations précieuses 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é des outils qu’il utilisait. Il n’est donc pas surprenant que ModSecurity dispose de capacités de journalisation et de débogage étendues.

ModSecurity a 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 pour laquelle elle a été bloquée.
• Un journal de débogage. Lorsqu'il est activé, ce journal conserve des informations détaillées sur tout ce que fait ModSecurity.

Le journal d'audit est utile non seulement pour comprendre pourquoi une attaque individuelle a été bloquée, mais également pour en savoir plus sur les modèles d'attaque globaux. Vous pourriez être surpris par la quantité de trafic de robots et de scanners que vous obtenez simplement en exposant les ports 80 et/ou 443 à Internet.

Dans cet article de blog, nous décrirons les bases de la journalisation et du débogage avec ModSecurity.

Journal d'audit

Le journal principal de ModSecurity est le journal d'audit, qui enregistre toutes les attaques, y compris les attaques potentielles, qui se produisent. Si vous avez suivi nos instructions d'installation pour ModSecurity (avec NGINX Open Source ) ou le WAF NGINX ModSecurity (avec NGINX Plus ), alors par défaut, ModSecurity enregistrera toutes les transactions qui ont déclenché un avertissement ou une erreur, ainsi que toutes les transactions qui ont abouti à des réponses 5xx et 4xx , à l'exception de404 . (Pour un système Ubuntu 16.04 uniquement, le journal d'audit se trouve dans /var/log/modsec_audit.log .)

Le journal d’audit ModSecurity est partitionné en sections. Cela facilite l’analyse du journal et la recherche des informations que vous recherchez. Le tableau ci-dessous décrit le contenu de chaque section :

Chaque transaction qui déclenche une entrée de journal d'audit aura une ou toutes les sections ci-dessus enregistrées. Vous pouvez configurer les sections qui sont enregistrées.

Exemple de journal d'audit

Un exemple d’entrée de journal d’audit ModSecurity pourrait ressembler à ceci :

---ICmPEb5c---A--[04/10/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
Hôte : 54.183.57.254
Agent utilisateur : Mozilla/5.0 zgrab/0.x
Accepter-Encodage : gzip

---ICmPEb5c---D--

---ICmPEb5c---F--
HTTP/1.1 200
Serveur : nginx/1.13.4
Date : Mercredi 4 octobre 2017 21:45:15 GMT
Content-Type: text/html
Connexion: keep-alive

---ICmPEb5c---H--
ModSecurity: Avertissement. Correspondance entre "Opérateur `Rx' avec le paramètre `^[d.:]+$' et la variable `REQUEST_HEADERS:Host' (valeur : `54.183.57.254') [fichier "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [ligne "733"] [id "920350"] [rev "2"] [msg "L'en-tête de l'hôte est une adresse IP numérique"] [données "54.183.57.254"] [s
gravité "4"] [ver "OWASP_CRS/3.0.0"] [maturité "9"] [précision "9"] [balise "application-multi"] [balise "language-multi"] [balise "platform-multi"] [balise "attack-prot
ocol"] [balise "OWASP_CRS/VIOLATION_PROTOCOLE/HÔTE_IP"] [balise "WASCTC/WASC-21"] [balise "OWASP_TOP_10/A7"] [balise "PCI/6.5.10"] [ref "o0,13v21,13"]

---ICmPEb5c---I--

---ICmPEb5c---J--

---ICmPEb5c---Z--

Bien que cela ne soit pas immédiatement apparent dans le tableau ci-dessus, la meilleure section pour trouver des informations sur la raison pour laquelle une demande particulière a été bloquée est la section H, et non la section K. À partir de l'exemple de journal d'audit ci-dessus, si nous parcourons la section H, nous pouvons voir le message « L'en-tête de l'hôte est une adresse IP numérique » qui indique que quelqu'un a essayé d'accéder à notre site par adresse IP plutôt que par nom d'hôte. Cela peut indiquer la présence d'un scanner.

Configuration de la journalisation d'audit

Si vous avez suivi nos instructions pour l'installation et la configuration de ModSecurity, vous trouverez la configuration de la journalisation d'audit dans /etc/nginx/modsec/modsecurity.conf . Dans ce fichier, vous verrez les trois directives suivantes qui contrôlent ce qui est mis dans le journal d’audit :

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

où

• SecAuditEngine – Contrôle ce qui doit être enregistré. Les options sont :

  • Désactivé – Désactiver le journal d’audit.
  • Activé – Enregistrer toutes les transactions, ce qui peut être utile lors du débogage.
  • RelevantOnly – Enregistrez uniquement les transactions qui ont déclenché un avertissement/une erreur ou dont le code d'état correspond à celui de la directive SecAuditLogRelevantStatus .

• SecAuditLogRelevantStatus – Si SecAuditEngine est défini sur RelevantOnly , cette directive contrôle les codes d’état de réponse HTTP qui doivent être enregistrés. Il est basé sur des expressions régulières. La valeur ci-dessus enregistrera toutes les réponses 5xx et 4xx , à l'exclusion404 p.

• SecAuditLogParts – Contrôle les sections qui doivent être incluses 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 son analyse.

Pour des directives de configuration de journalisation d’audit supplémentaires, reportez-vous au wiki ModSecurity .

Journal de débogage

Lorsque le journal de débogage est activé, il fournit une multitude d'informations sur tout ce que fait ModSecurity. Pour résoudre les problèmes liés au fonctionnement d'un élément comme prévu, le journal de débogage est votre ressource de référence. C’est également idéal si vous débutez avec ModSecurity et que vous souhaitez observer pourquoi il fait les choses d’une certaine manière.

Exemple de journal de débogage

Le journal de débogage ressemble à ce qui suit. Il contient de nombreux détails sur les actions que ModSecurity entreprend pour toutes les transactions :

[4] (Règle : 1234) Exécution de l'opérateur « Contient » avec le paramètre « test » par rapport à ARGS : testparam.[9] Valeur cible : « test » (Variable : ARGS : testparam)
[9] Variables correspondantes mises à jour.
[4] Action [indépendante] (non perturbatrice) en cours d'exécution : log
[9] Enregistrement de la transaction dans les journaux
[4] La règle a renvoyé 1.
[9] (SecDefaultAction) Action en cours d'exécution : log
[9] Enregistrement de la transaction dans les journaux
[9] (SecDefaultAction) Action en cours d'exécution : auditlog
[4] (SecDefaultAction) action ignorée : pass (la règle contient une action perturbatrice)
[4] Action en cours d'exécution (non perturbatrice) : auditlog
[4] Action en cours d'exécution (perturbatrice) : deny

Le journal de débogage répertorie le numéro d'ID de règle pour une recherche facile. Dans cet exemple, la sortie provient de notre règle de test avec le numéro d'ID 1234.

Configuration du journal de débogage

Par défaut, le journal de débogage est désactivé, car il peut affecter négativement les performances. Tout comme avec la journalisation d'audit, le journal de débogage est configuré dans /etc/nginx/modsec/modsecurity.conf . Dans ce fichier, il y a deux directives de configuration qui sont commentées. Pour activer la journalisation de débogage, supprimez-les du commentaire et remplacez-les par ce qui suit :

SecDebugLog /var/log/modsec_debug.logSecDebugLogNiveau 9

où

• SecDebugLog – Spécifie le chemin d’accès au fichier journal de débogage.
• SecDebugLogLevel –0 –9 indique la quantité d'informations à enregistrer, avec9 étant le plus. Si vous effectuez un dépannage, définissez cette valeur sur9 est le plus utile.

Conclusion

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

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

[ Éditeur – NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]