Documentation AEM Tutoriels AEM Tutoriels sur AEM Foundation

Utiliser ModSecurity pour protéger votre site AEM des attaques par déni de service (DoS)

Last update: Wed May 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Rubriques :
Security

Créé pour :

Experienced
Admin
Developer

Découvrez comment activer ModSecurity pour protéger votre site des attaques par déni de service (DoS) à l’aide de l’ ensemble de règles de base (CRS) OWASP ModSecurity sur le Dispatcher de publication d’Adobe Experience Manager (AEM).

https://video.tv.adobe.com/v/3422976?quality=12&learn=on

Vue d’ensemble

La fondation Open Web Application Security Project® (OWASP). fournit le Top 10 d’OWASP présentant les dix préoccupations de sécurité les plus critiques pour les applications web.

ModSecurity est une solution open source sur plusieurs plateformes qui offre une protection contre un éventail d’attaques à l’encontre des applications web. Elle permet également la surveillance du trafic HTTP, la journalisation et l’analyse en temps réel.

OWSAP® fournit également l’ensemble de règles de base (CRS) OWASP® ModSecurity. Le CRS est un ensemble de règles de détection d’attaque génériques à utiliser avec ModSecurity. Ainsi, le CRS vise à protéger les applications web d’un grand nombre d’attaques, y compris celles du top 10 d’OWASP, avec un minimum de fausses alertes.

Ce tutoriel explique comment activer et configurer la règle CRS de Protection de déni de service pour protéger votre site contre une attaque potentielle par déni de service.

TIP

Il est important de noter que le réseau CDN géré d’AEM as a Cloud Service répond à la plupart des exigences de performances et de sécurité des clientes et clients. Cependant, ModSecurity fournit un niveau supplémentaire de sécurité et permet des règles et des configurations spécifiques aux clientes et clients.

Ajouter le CRS au module de projet Dispatcher

Téléchargez et extrayez le dernier ensemble de règles de base OWASP ModSecurity.

code language-shell

code language-shell
`# Replace the X.Y.Z with relevent version numbers. $ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/vX.Y.Z.tar.gz # For version v3.3.5 when this tutorial is published $ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz # Extract the downloaded file $ tar -xvzf coreruleset-3.3.5.tar.gz`

# Replace the X.Y.Z with relevent version numbers.
$ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/vX.Y.Z.tar.gz

# For version v3.3.5 when this tutorial is published
$ wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz

# Extract the downloaded file
$ tar -xvzf coreruleset-3.3.5.tar.gz

Créez les dossiers modsec/crs dans dispatcher/src/conf.d/ dans le code de votre projet AEM. Par exemple, dans la copie locale du projet AEM Sites WKND.

{width="200" modal="regular"}
Copiez le dossier coreruleset-X.Y.Z/rules du package de version CRS téléchargé dans le dossier dispatcher/src/conf.d/modsec/crs.
Copiez le fichier coreruleset-X.Y.Z/crs-setup.conf.example du package de version CRS téléchargé dans le dossier dispatcher/src/conf.d/modsec/crs et renommez-le crs-setup.conf.

Désactivez toutes les règles CRS copiées à partir du dispatcher/src/conf.d/modsec/crs/rules en les renommant XXXX-XXX-XXX.conf.disabled. Vous pouvez utiliser les commandes ci-dessous pour renommer tous les fichiers en même temps.

code language-shell

code language-shell
`# Go inside the newly created rules directory within the dispathcher module $ cd dispatcher/src/conf.d/modsec/crs/rules # Rename all '.conf' extension files to '.conf.disabled' $ for i in *.conf; do mv -- "$i" "$i.disabled"; done`

# Go inside the newly created rules directory within the dispathcher module
$ cd dispatcher/src/conf.d/modsec/crs/rules

# Rename all '.conf' extension files to '.conf.disabled'
$ for i in *.conf; do mv -- "$i" "$i.disabled"; done

Voir Règles CRS et fichier de configuration renommés dans le code de projet WKND.

Règles CRS désactivées dans le code de projet AEM - ModSecurity. {width="200" modal="regular"}

Activer et configurer la règle de protection de déni de service (DoS)

Pour activer et configurer la règle de protection de déni de service (DoS), procédez comme suit :

Activez la règle de protection de déni de service en renommant REQUEST-912-DOS-PROTECTION.conf.disabled en REQUEST-912-DOS-PROTECTION.conf (ou supprimez .disabled à partir de l’extension de nom de règle) au sein du dossier dispatcher/src/conf.d/modsec/crs/rules.

Configurez la règle en définissant les variables DOS_COUNTER_THRESHOLD, DOS_BURST_TIME_SLICE, DOS_BLOCK_TIMEOUT.

Créez un fichier crs-setup.custom.conf dans le dossier dispatcher/src/conf.d/modsec/crs.
Ajoutez l’extrait de code de règle ci-dessous au fichier nouvellement créé.

code language-none

code language-none
`# The Denial of Service (DoS) protection against clients making requests too quickly. # When a client is making more than 25 requests (excluding static files) within # 60 seconds, this is considered a 'burst'. After two bursts, the client is # blocked for 600 seconds. SecAction \ "id:900700,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:'tx.dos_burst_time_slice=60',\ setvar:'tx.dos_counter_threshold=25',\ setvar:'tx.dos_block_timeout=600'"`

# The Denial of Service (DoS) protection against clients making requests too quickly.
# When a client is making more than 25 requests (excluding static files) within
# 60 seconds, this is considered a 'burst'. After two bursts, the client is
# blocked for 600 seconds.
SecAction \
    "id:900700,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:'tx.dos_burst_time_slice=60',\
    setvar:'tx.dos_counter_threshold=25',\
    setvar:'tx.dos_block_timeout=600'"

Dans cet exemple de configuration de règle, DOS_COUNTER_THRESHOLD est de 25, DOS_BURST_TIME_SLICE est de 60 secondes, et le délai d’expiration de DOS_BLOCK_TIMEOUT est de 600 secondes. Cette configuration identifie que plus de deux occurrences de 25 requêtes, à l’exception des fichiers statiques, en l’espace de 60 secondes sont considérées comme une attaque par déni de service, ce qui entraîne le blocage du client ou de la cliente effectuant la requête pendant 600 secondes (ou 10 minutes).

WARNING

Pour définir les valeurs appropriées à vos besoins, collaborez avec votre équipe de sécurité web.

Initialiser le CRS

Pour initialiser le CRS, supprimer les faux positifs courants et ajouter des exceptions locales pour votre site, procédez comme suit :

Pour initialiser le CRS, supprimez .disabled du fichier REQUEST-901-INITIALIZATION. En d’autres termes, renommez le fichier REQUEST-901-INITIALIZATION.conf.disabled en REQUEST-901-INITIALIZATION.conf.
Pour supprimer les faux positifs courants tels que le ping de l’adresse IP locale (127.0.0.1), supprimez .disabled du fichier REQUEST-905-COMMON-EXCEPTIONS.

Pour ajouter des exceptions locales telles que la plateforme AEM ou des chemins spécifiques à votre site, renommez REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example en REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Ajoutez des exceptions de chemin d’accès spécifiques à la plateforme AEM au fichier nouvellement renommé.

code language-none

code language-none
######################################################## # AEM as a Cloud Service exclusions # ######################################################## # Ignoring AEM-CS Specific internal and reserved paths SecRule REQUEST_URI "@beginsWith /systemready" \ "id:1010,\ phase:1,\ pass,\ nolog,\ ctl:ruleEngine=Off" SecRule REQUEST_URI "@beginsWith /system/probes" \ "id:1011,\ phase:1,\ pass,\ nolog,\ ctl:ruleEngine=Off" SecRule REQUEST_URI "@beginsWith /gitinit-status" \ "id:1012,\ phase:1,\ pass,\ nolog,\ ctl:ruleEngine=Off" ######################################################## # ADD YOUR SITE related exclusions # ######################################################## ...

########################################################
# AEM as a Cloud Service exclusions                    #
########################################################
# Ignoring AEM-CS Specific internal and reserved paths

SecRule REQUEST_URI "@beginsWith /systemready" \
    "id:1010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

SecRule REQUEST_URI "@beginsWith /system/probes" \
    "id:1011,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

SecRule REQUEST_URI "@beginsWith /gitinit-status" \
    "id:1012,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleEngine=Off"

########################################################
# ADD YOUR SITE related exclusions                     #
########################################################
...

Supprimez également .disabled de REQUEST-910-IP-REPUTATION.conf.disabled pour la vérification des blocs de réputation d’adresse IP et REQUEST-949-BLOCKING-EVALUATION.conf.disabled pour vérifier le score d’anomalie.

TIP

Lors de la configuration sur AEM 6.5, assurez-vous de remplacer les chemins ci-dessus par des chemins AMS ou On-Prem respectifs qui vérifient l’intégrité d’AEM (également appelés chemins de pulsation).

Ajouter la configuration Apache ModSecurity

Pour activer ModSecurity (également appelé module Apache mod_security), procédez comme suit :

Créez modsecurity.conf sur dispatcher/src/conf.d/modsec/modsecurity.conf avec les configurations clés ci-dessous.

code language-none

code language-none
# Include the baseline crs setup Include conf.d/modsec/crs/crs-setup.conf # Include your customizations to crs setup if exist IncludeOptional conf.d/modsec/crs/crs-setup.custom.conf # Select all available CRS rules: #Include conf.d/modsec/crs/rules/*.conf # Or alternatively list only specific ones you want to enable e.g. Include conf.d/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf Include conf.d/modsec/crs/rules/REQUEST-901-INITIALIZATION.conf Include conf.d/modsec/crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf Include conf.d/modsec/crs/rules/REQUEST-910-IP-REPUTATION.conf Include conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf Include conf.d/modsec/crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf # Start initially with engine off, then switch to detection and observe, and when sure enable engine actions #SecRuleEngine Off #SecRuleEngine DetectionOnly SecRuleEngine On # Remember to use relative path for logs: SecDebugLog logs/httpd_mod_security_debug.log # Start with low debug level SecDebugLogLevel 0 #SecDebugLogLevel 1 # Start without auditing SecAuditEngine Off #SecAuditEngine RelevantOnly #SecAuditEngine On # Tune audit accordingly: SecAuditLogRelevantStatus "^(?:5\|4(?!04))" SecAuditLogParts ABIJDEFHZ SecAuditLogType Serial # Remember to use relative path for logs: SecAuditLog logs/httpd_mod_security_audit.log # You might still use /tmp for temporary/work files: SecTmpDir /tmp SecDataDir /tmp

# Include the baseline crs setup
Include conf.d/modsec/crs/crs-setup.conf

# Include your customizations to crs setup if exist
IncludeOptional conf.d/modsec/crs/crs-setup.custom.conf

# Select all available CRS rules:
#Include conf.d/modsec/crs/rules/*.conf

# Or alternatively list only specific ones you want to enable e.g.
Include conf.d/modsec/crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Include conf.d/modsec/crs/rules/REQUEST-901-INITIALIZATION.conf
Include conf.d/modsec/crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
Include conf.d/modsec/crs/rules/REQUEST-910-IP-REPUTATION.conf
Include conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf
Include conf.d/modsec/crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf

# Start initially with engine off, then switch to detection and observe, and when sure enable engine actions
#SecRuleEngine Off
#SecRuleEngine DetectionOnly
SecRuleEngine On

# Remember to use relative path for logs:
SecDebugLog logs/httpd_mod_security_debug.log

# Start with low debug level
SecDebugLogLevel 0
#SecDebugLogLevel 1

# Start without auditing
SecAuditEngine Off
#SecAuditEngine RelevantOnly
#SecAuditEngine On

# Tune audit accordingly:
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial

# Remember to use relative path for logs:
SecAuditLog logs/httpd_mod_security_audit.log

# You might still use /tmp for temporary/work files:
SecTmpDir /tmp
SecDataDir /tmp

Sélectionnez le .vhost souhaité à partir du module de Dispatcher de votre projet AEM dispatcher/src/conf.d/available_vhosts, par exemple, wknd.vhost, ajoutez l’entrée ci-dessous en dehors du bloc <VirtualHost>.

code language-none
`# Enable the ModSecurity and OWASP CRS <IfModule mod_security2.c> Include conf.d/modsec/modsecurity.conf </IfModule> ... <VirtualHost *:80> ServerName "publish" ... </VirtualHost>`

Toutes les configurations ModSecurity CRS et DOS-PROTECTION ci-dessus sont disponibles sur la branche tutoriel/enable-modsecurity-crs-dos-protection du projet AEM Sites WKND pour vérification.

Valider la configuration de Dispatcher

Lorsque vous utilisez AEM as a Cloud Service, avant de déployer vos modifications de la configuration du Dispatcher, il est recommandé de les valider localement à l’aide du script validate des outils de Dispatcher du SDK AEM.

# Go inside Dispatcher SDK 'bin' directory
$ cd <YOUR-AEM-SDK-DIR>/<DISPATCHER-SDK-DIR>/bin

# Validate the updated Dispatcher configurations
$ ./validate.sh <YOUR-AEM-PROJECT-CODE-DIR>/dispatcher/src

Déployer

Déployez les configurations de Dispatcher validées localement à l’aide du pipeline Niveau web ou Full stack de Cloud Manager. Vous pouvez également utiliser l’environnement de développement rapide pour accélérer le délai d’exécution.

Vérifier

Pour vérifier la protection de déni de service, dans cet exemple, envoyons plus de 50 requêtes (seuil de 25 requêtes multiplié par deux occurrences) en l’espace de 60 secondes. Toutefois, ces requêtes doivent passer par l’intégration d’AEM as a Cloud Service ou tout autre réseau CDN devant votre site web.

Une technique permettant d’assurer le passage du réseau CDN consiste à ajouter un paramètre de requête avec une nouvelle valeur aléatoire pour chaque requête de page de site.

Pour déclencher un plus grand nombre de requêtes (50 ou plus) sur une courte période (par exemple, 60 secondes), JMeter ou l’outil AB ou de référence d’Apache peuvent être utilisés.

Simuler une attaque par déni de service à l’aide du script JMeter

Pour simuler une attaque par déni de service à l’aide de JMeter, procédez comme suit :

Téléchargez Apache JMeter et installez-le localement
Exécutez-le à l’aide du script jmeter depuis le répertoire <JMETER-INSTALL-DIR>/bin.
Ouvrez l’exemple de script JMX WKND-DoS-Attack-Simulation-Test dans JMeter à l’aide du menu d’outils Ouvrir.
Mettez à jour la valeur de champ Nom du serveur ou Adresse IP dans l’échantillonage de requête HTTP Page d’accueil et Page d’aventure correspondant à l’URL de votre environnement de test AEM. Consultez d’autres détails de l’exemple de script JMeter.
Exécutez le script en appuyant sur le bouton Démarrer dans le menu d’outils. Le script envoie 50 requêtes HTTP (5 profils utilisateurs et 10 itérations de boucle) contre la Page d’accueil et la Page d’aventure du site WKND. Par conséquent, un total de 100 requêtes de fichiers non statiques qualifie l’attaque du déni de service par la configuration de règle CRD personnalisée DOS-PROTECTION.
Le listener JMeter Affichage des résultats dans le tableau affiche le statut de réponse En échec pour les numéros de requête supérieurs à 53 environ.
Le code de réponse HTTP 503 est renvoyé pour les requêtes en échec, vous pouvez afficher les détails à l’aide du listener JMeter Afficher l’arborescence des résultats.

Journaux de révision

La configuration du journal ModSecurity consigne les détails de l’incident d’attaque DoS. Pour afficher les détails, procédez comme suit :

Téléchargez et ouvrez le fichier journal httpderror du Dispatcher de l’instance de publication.

Recherchez le mot burst dans le fichier journal, pour afficher les lignes d’erreur.

code language-none

code language-none
Tue Aug 15 15:19:40.229262 2023 [security2:error] [pid 308:tid 140200050567992] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Warning. Operator GE matched 2 at IP:dos_burst_counter. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "265"] [id "912170"] [msg "Potential Denial of Service (DoS) Attack from 192.150.10.209 - # of Request Bursts: 2"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/content/wknd/us/en/adventures.html"] [unique_id "ZNuXi9ft_9sa85dovgTN5gAAANI"] ... Tue Aug 15 15:19:40.515237 2023 [security2:error] [pid 309:tid 140200051428152] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Access denied with connection close (phase 1). Operator EQ matched 0 at IP. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "120"] [id "912120"] [msg "Denial of Service (DoS) attack identified from 192.150.10.209 (1 hits since last alert)"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/us/en.html"] [unique_id "ZNuXjAN7ZtmIYHGpDEkmmwAAAQw"]

Tue Aug 15 15:19:40.229262 2023 [security2:error] [pid 308:tid 140200050567992] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Warning. Operator GE matched 2 at IP:dos_burst_counter. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "265"] [id "912170"] [msg "Potential Denial of Service (DoS) Attack from 192.150.10.209 - # of Request Bursts: 2"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/content/wknd/us/en/adventures.html"] [unique_id "ZNuXi9ft_9sa85dovgTN5gAAANI"]

...

Tue Aug 15 15:19:40.515237 2023 [security2:error] [pid 309:tid 140200051428152] [cm-p46652-e1167810-aem-publish-85df5d9954-bzvbs] [client 192.150.10.209] ModSecurity: Access denied with connection close (phase 1). Operator EQ matched 0 at IP. [file "/etc/httpd/conf.d/modsec/crs/rules/REQUEST-912-DOS-PROTECTION.conf"] [line "120"] [id "912120"] [msg "Denial of Service (DoS) attack identified from 192.150.10.209 (1 hits since last alert)"] [ver "OWASP_CRS/3.3.5"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "paranoia-level/1"] [tag "attack-dos"] [tag "OWASP_CRS"] [tag "capec/1000/210/227/469"] [hostname "publish-p46652-e1167810.adobeaemcloud.com"] [uri "/us/en.html"] [unique_id "ZNuXjAN7ZtmIYHGpDEkmmwAAAQw"]

Consultez les détails comme adresse IP du client, action, message d’erreur et détails de la requête.

Impact sur les performances de ModSecurity

L’activation de ModSecurity et des règles associées a des répercussions sur les performances. N’oubliez donc pas quelles règles sont requises, redondantes et ignorées. Associez-vous avec les personnes spécialisées chargées de votre sécurité web pour activer et personnaliser les règles CRS.

Règles supplémentaires

Ce tutoriel active et personnalise uniquement la règle CRS DOS-PROTECTION à des fins de démonstration. Il est recommandé de collaborer avec des personnes spécialisées en sécurité web pour comprendre, examiner et configurer les règles appropriées.

recommendation-more-help

c92bdb17-1e49-4e76-bcdd-89e4f85f45e6