Pare-feu applicatif (ModSecurity)

Afin de détecter et de prévenir des attaques contre des applications Web, le pare-feu applicatif (ModSecurity) vérifie toutes les requêtes de votre serveur Web et les réponses associées du serveur conformément à son jeu de règles. Si la vérification réussit, la requête HTTP est transmise au contenu du site Web. Si la vérification échoue, les actions prédéfinies sont exécutées.

ModSecurity est un module pour Apache. C'est pourquoi il ne peut vérifier que les requêtes HTTP qui atteignent Apache. Apache est utilisé avec un autre serveur Web :  Nginx. Si vous activez l'option Gérer PHP avec Nginx du serveur Web Nginx pour le contenu dynamique de votre site Web, le pare-feu applicatif ne sera pas en mesure de traiter les requêtes HTTP, car elles n'atteignent jamais Apache. Pour le contenu statique, si l'option Traiter les fichiers statiques directement avec Nginx est activée, les requêtes HTTP n'atteindront pas Apache et ModSecurity ne les vérifiera pas.

Remarque : pour utiliser le pare-feu applicatif, les administrateurs qui mettent à niveau depuis Plesk 11.5 doivent obtenir une nouvelle clé de licence pour Plesk 12 auprès d'Odin ou d'un revendeur.

Pour activer le pare-feu applicatif :

1. Allez sous  Outils & Paramètres  >  Pare-feu applicatif (ModSecurity)  (dans le groupe  Sécurité) . Le composant ModSecurity a bien été installé sur votre serveur.

   
   

2. Définissez le mode pare-feu applicatif sur On ou Détection uniquement. Toutes les requêtes HTTP entrantes et les réponses associées seront vérifiées selon un jeu de règles. Si la vérification réussit, la requête HTTP sera transmise au contenu du site Web. Si la vérification échoue, l'évènement est consigné dans le fichier de log. En mode Détection uniquement, aucune autre action n'est exécutée. En mode On, la réponse HTTP est fournie avec un code d'erreur.

   Remarque : les modes du pare-feu applicatif peuvent être définis au niveau du serveur et des domaines. Toutefois, le mode niveau de domaine ne peut pas être plus élevé que le mode défini pour le serveur. Par exemple, si le pare-feu applicatif fonctionne en mode Détection uniquement au niveau du serveur, alors vous ne le définir sur On pour les domaines. Seuls les modes Off et Détection uniquement sont affichés.

3. Sélectionnez le jeu de règles qui sera vérifié par le moteur du pare-feu applicatif pour chaque requête HTTP entrante ou chargez un jeu de règles personnalisé. Vous pouvez choisir parmi les jeux de règles suivants :
   • OWASP ModSecurity Core Rule Set (CRS). Le CRS fournit une protection générique face aux vulnérabilités souvent détectées dans les applications Web. Ce jeu de règles est fourni gratuitement. Il s'agit d'un jeu de règles reconnu comme très restrictif. Il est nécessaire de l'ajuster pour des fins de production. Lorsque ce jeu de règles est sélectionné, WordPress ne fonctionne pas complètement ; la messagerie Web et le partage des fichiers ne fonctionnent pas non plus. À la place, vous pouvez utiliser les jeux de règles Atomic ou Comodo.
   • Jeu de règles Atomic ModSecurity. Ce jeu de règles inclut les versions les plus récentes avec toutes les améliorations au niveau des performances, des fonctions de sécurité et les correctifs publiés par Atomicorp GotRoot au quotidien. Il s'agit d'un jeu de règles payant entièrement pris en charge et recommandé à des fins de production. Pour activer ce jeu de règles dans Plesk, enregistrez-vous sur le site Atomic. Indiquez le nom d'utilisateur et le mot de passe pour ce site.

     Attention : si vous sélectionnez le jeu de règles Atomic, suivez la procédure ci-après pour vérifier que ModSecurity fonctionne correctement :

     Exécutez la commande aum -u sur le serveur. Le pack Plesk modsecurity sera remplacé par celui du répertoire Atomic. Exécutez les commandes suivantes :

     • plesk sbin modsecurity_ctl --disable
     • plesk sbin modsecurity_ctl –enable
     • service httpd restart
   • Jeu de règles Comodo ModSecurity. Ce système simple à utiliser de contrôle du trafic basé sur des règles personnalisables protège vos applications basées sur le Web et prévient les techniques de hack émergentes. Pour cela, il s'appuie sur une base de données de règles mise à jour fréquemment. Ce jeu de règles est fourni gratuitement. Pour activer ce jeu de règles dans Plesk, enregistrez-vous sur le site Comodo. Indiquez le nom d'utilisateur et le mot de passe pour ce site.
4. Afin de mettre à jour le jeu de règle sélectionné, cochez la case Mettre à jour le jeu de règles et choisissez la période de mise à jour.
5. Sélectionnez un jeu de paramètres prédéfinis ou indiquez vos directives ModSecurity personnalisées. Vous pouvez sélectionner les jeux de paramètres prédéfinis suivants :
   • Rapide : analyse de l'URI de requête HTTP et d'une partie des en-têtes. Ce mode est celui qui consomme le moins de CPU.
   • Intermédiaire : analyse de l'URI de requête HTTP, des en-têtes et des données POST de la requête. Ce mode est un bon compromis entre les qualités et les performances.
   • Complet : l'intégralité des en-têtes de la requête HTTP, les données POST de la requête et le contenu du corps de la réponse seront analysés. Ce mode est celui qui consomme le plus de ressources CPU. Il est toutefois recommandé pour les sites qui requièrent des mesures de sécurité spécifiques. Par exemple, les boutiques en ligne qui acceptent des paiements par carte.

     Remarque : pour des performances optimales, le pare-feu applicatif requiert un serveur DNS local avec la mise en cache des requêtes activée. Sinon, vos sites Web risquent de ralentir pendant que le pare-feu applicatif est activé.

ModSecurity utilise deux emplacements pour ses fichiers de log :

• Le log d'audit ModSecurity (sous /var/log/httpd/modsec_audit.log) est très détaillé et utilisé par l'ensemble du serveur Plesk. Tout événement détecté par ModSecurity génère une entrée dans le fichier du log d'audit. Pour consulter le log d'audit ModSecurity, allez sous  Outils & Paramètres  > Pare-feu applicatif (ModSecurity) et cliquez sur le lien Logs d'archive dans la section Log d'audit ModSecurity. Sur cette page, vous pouvez consulter et télécharger les fichiers de log ModSecurity et voir leurs dates de modification.
• Le log d'erreurs Apache pour un domaine (sous /var/www/vhosts/DOMAIN.TLD/logs/error_log) contient seulement de courtes informations sur les erreurs de sites Web. Vous pouvez voir le log d'erreur d'un site Web particulier dans le Panneau Client sous Sites Web & Domaines > <nom_de_domaine> > Logs > sélectionnez uniquement Erreur Apache et Erreur Nginx à la place de Tous les logs à droite.

Lorsque vous passez le mode pare-feu applicatif de On à Off ou à Détection uniquement, un site Web risque de cesser de fonctionner normalement. Dans le log d'erreurs du site Web, vous pouvez trouver des codes d'erreurs du type 403, 404 ou 500. Ces erreurs disparaissent lorsque vous passez le pare-feu applicatif en mode Détection uniquement ou Off. Dans ce cas, analysez le log d'audit ModSecurity pour découvrir ce qui se passe. Vous pouvez désactiver les règles de sécurité trop restrictives ou ajuster le site Web.

Pour déterminer pourquoi une requête HTTP ne peut pas être terminée pour un site Web et désactiver la règle de sécurité :

1. Allez sous  Outils & Paramètres  > Pare-feu applicatif (ModSecurity).
2. Cliquez sur le lien vers le fichier de log ModSecurity ci-dessous. Ouvrez le log d'audit dans une nouvelle fenêtre de navigateur.
3. Utilisez la recherche (Ctrl + F dans la plupart des navigateurs) pour trouver les événements du site Web (le nom de domaine) qui ont généré des problèmes. Par exemple : votre_domaine.tld. Le navigateur met en surbrillance les entrées telles que HOST: your_domain.tld. Dans les trois lignes au-dessus de l'entrée sélectionnée, cherchez une chaîne du type --eece5138-B--. Les 8 caractères entre les tirets (ici "eece5138") correspondent à l'ID de l'événement déclenché par la requête HTTP.
4. Recherchez d'autres entrées avec le même ID d'évènement. Repérez une entrée avec la lettre H après l'ID de l'événement (ici "eece5138-H--"). Cette entrée contient l'ID et la description de la règle de sécurité déclenchée lors de la vérification de la requête HTTP. L'ID de la règle de sécurité est un nombre entier commençant par 3 entre guillemets avec le préfixe id entre crochets. Par exemple : [id "340003"].
5. Trouvez un ID de règle de sécurité dans l'événement avec la sous-chaîne [id "3.
6. Allez sous  Outils & Paramètres  > Pare-feu applicatif (ModSecurity).
7. Dans la section Règles de sécurité, sélectionnez la règle de sécurité à l'aide de son ID (par exemple 340003), de l'étiquette correspondante (par exemple CVE-2011-4898) ou d'une expression régulière (par exemple XSS) et cliquez sur OK.

Astuces pratiques si vous avez installé ModSecurity sur le serveur avant de mettre à niveau vers Plesk 12 :

• Plesk installe son propre pack ModSecurity. Toutefois, pendant la vérification préalable à la mise à niveau, le Programme d'installation de Plesk vous demandera si vous acceptez l'installation de Plesk ModSecurity sur votre installation existante.
• Votre configuration ModSecurity reste telle quelle. Toutefois, il y a de nombreuses configurations et distributions pour ModSecurity, c'est pourquoi il est si difficile de prédire comment les nouvelles et anciennes configurations risquent d'entrer en conflit. Pour éviter les problèmes, enregistrez votre configuration existante et désinstallez ModSecurity avant de procéder à la mise à niveau vers Plesk 12 (ou avant d'installer ModSecurity sur PlesK).