Pour détecter et prévenir les 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 en fonction de son jeu de règles. Si la vérification réussit, la requête HTTP est transmise pour récupérer le contenu du site Web. Si elle échoue, les actions prédéfinies sont exécutées.

ModSecurity is supported in both Plesk for Linux and for Windows. It works as a web server (Apache, Nginx, or IIS) module.

Activation de ModSecurity

Pour activer le pare-feu applicatif :

  1. Go to Tools & Settings > Web Application Firewall (ModSecurity) (under « Security »).

    Si vous ne voyez pas ce lien, installez le composant ModSecurity dans Outils & Paramètres > Mises à jour > Ajouter/Supprimer des composants > groupe Hébergement Web.

    image 78702

  2. Définissez le mode pare-feu applicatif sur On ou sur Détection uniquement. Chaque requête HTTP entrante et la réponse associée seront vérifiées selon un jeu de règles. Si la vérification réussit, la requête HTTP est transmise au site Web pour récupérer le contenu. Si elle é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 émise avec un code d’erreur.

    Note: les modes du pare-feu applicatif peuvent être définis au niveau du serveur et des domaines. Toutefois, le mode au niveau du domaine ne peut ê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 pouvez pas le définir sur On pour les domaines. Seuls les modes Off et Détection uniquement sont disponibles.

  3. (Linux) Go to the « Settings » tab, and then in the Run rules on drop-down menu, select the desired combination of the web server and ModSecurity version:

    • Apache (ModSecurity 2.9) (recommended).

    • Nginx (ModSecurity 3.0).

      Note: Switching to Nginx (ModSecurity 3.0) may affect your existing applications. We recommend trying ModSecurity 3.0 out on a test server before switching your production environment to that version.

    If your Plesk server is running on a Microsoft Windows operating system, you will be able to select only the IIS (ModSecurity 2.9) combination and all the related settings will be present on one tab.

  4. Select an available set of rules that will be checked by the web application firewall engine for each incoming HTTP request, or upload a custom rule set. You can select the following rule sets:

    image 78703

    • Atomic Standard (free, can be upgraded to Atomic Advanced). A free starter version of the Atomic ModSecurity rules, bundled with Plesk. It contains important security features and bug fixes released on a monthly basis. For rules included in this rule set, see Atomic ModSecurity Rule Sets.

    • OWASP (free). The OWASP ModSecurity Core Rule Set (CRS) provides generic protection from unknown vulnerabilities often found in web applications. This rule set is shipped for free. It is known as a very restrictive rule set; it requires additional tuning for production use. When this rule set is selected, WordPress partly does not work, webmail and file sharing do not work either. You can use Atomic or Comodo rule sets instead.

    • (Plesk for Linux) Comodo (free). A free, simple-to-use, customizable, rules-based traffic control system that protects your web-based applications and prevents newly emerging hacking techniques with the use of a frequently updated rules database. Unlike the « Comodo (free subscription) » rule set, you do not need a subscription on the Comodo website to select « Comodo (free) ».

    • Atomic Advanced. The latest version of the rules, with all the performance enhancements, new security features and bug fixes released by Atomicorp GotRoot on a daily basis. This is a commercial rule set that is fully supported and recommended for production use. Plesk provides the Security Core Complete by Atomicorp extra feature that allows you to enable this rule set in Plesk. You can get this extra feature by the following ways:

      • Achetez le produit Advanced ModSecurity Rules by Atomicorp dans la Boutique en ligne Plesk.
      • Si vous disposez d’une licence Plesk, vous pouvez ajouter une fonction supplémentaire via l’interface Plesk Partner Central ou via Partner API (pour en savoir plus, consultez le Guide de l’utilisateur Partner Central (en anglais) ou la référence Partner API 3.0 (en anglais)).
      • Si vous disposez d’une licence Plesk mais n’avez pas accès à l’interface Partner Central de Plesk, contactez votre revendeur.

      Si vous disposez déjà d’un compte sur le site Atomic, vous pouvez indiquer votre nom d’utilisateur et votre mot de passe pour activer ce jeu de règles.

      Note: If you get this extra feature, the Plesk interface will display Atomic Advanced instead of Atomic Standard (free, can be upgraded to Atomic Advanced), and this actually means the complete Atomic Advanced ModSecurity rule set.

      Découvrez les règles comprises dans ce jeu dans la section Jeu de règles Atomic ModSecurity.

      Prudence: (Plesk for Linux) If you select the Atomic ruleset, perform the following procedure to ensure that ModSecurity works fine. Run the aum -u command on the server. The Plesk modsecurity package will be replaced by that from the Atomic repository. Then run the following commands:

      • plesk sbin modsecurity_ctl --disable
      • plesk sbin modsecurity_ctl -enable
      • service httpd restart
    • (Plesk for Linux) Comodo (free subscription). This is a simple-to-use, customizable rules-based traffic control system that protects your web-based applications and prevents newly emerging hacking techniques with the use of a frequently updated rules database. This rule set is shipped for free. To enable this rule set in Plesk, register on the Comodo site and provide your username and password from this site.

      Note: By default, Plesk does not show the « Comodo (free subscription) » rule set. To make the rule set visible in the Plesk interface, add the following lines to the panel.ini file:

      [modSecurity]
      ruleSet.comodo = 1
      
    • Custom rule set. You can upload a custom web application firewall rule set, for example, a trial package from Atomic or a free package from Comodo. Supported formats: zip, tar.gz, tgz, tar.bz2, conf.

  5. Pour mettre à jour automatiquement le jeu de règles sélectionné, cochez la case Mettre à jour le jeu de règles et choisissez la période de mise à jour.

  6. Sélectionnez un jeu de paramètres prédéfinis ou indiquez vos directives ModSecurity personnalisées. Vous pouvez choisir parmi 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 sollicitant le moins le 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 qualité/performances.

    • Complet : analyse de l’intégralité des en-têtes de la requête HTTP, des données POST de la requête et du contenu du corps de la réponse. 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 acceptant les paiements par carte.

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

      image 76906

Fichiers de log (Linux)

Sous Linux, ModSecurity utilise les emplacements suivants pour les logs :

  • Le log d’audit ModSecurity (dans /var/log/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 voir le log d’audit de ModSecurity, allez dans Outils & Paramètres > Pare-feu applicatif (ModSecurity) > 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’erreurs d’un site Web particulier dans le panneau Client sous Sites Web & Domaines > <nom_domaine> > Logs. Sélectionnez uniquement Erreur Apache et Erreur Nginx à la place de Tous les logs à droite.

Fichiers de log (Windows)

On Windows, ModSecurity audit logs are domain-specific and located in %plesk_dir%ModSecurity\vhosts\<domain's GUID>\logs (where %plesk_dir% is the default installation directory for Plesk).

Désactivation des règles

Lorsque vous passez le mode pare-feu applicatif de On à Off ou à Détection uniquement, cela peut arrêter un site Web. Dans le log d’erreurs du site Web, vous pouvez trouver des codes d’erreur 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 comprendre ce qu’il se passe. Vous pouvez désactiver les règles de sécurité trop restrictives ou ajuster le site Web.

Afin de déterminer pourquoi une requête HTTP ne peut aboutir pour un site Web :

  1. Consultez le fichier du log d’audit du site Web.

    Dans Plesk pour Linux, vous pouvez utiliser l’interface Plesk pour voir le log : allez dans  Outils & Paramètres > Pare-feu applicatif (ModSecurity) et cliquez sur le lien Fichier de log ModSecurity pour télécharger le log d’audit et l’ouvrir dans une nouvelle fenêtre de navigateur.

  2. Utilisez la recherche (généralement Ctrl + F) pour trouver les événements du site Web (nom de domaine) qui ont généré des problèmes. Par exemple, votre_domaine.tld. Le navigateur met en surbrillance des entrées comme HOST: votre_domaine.tld. Trois lignes au-dessus de l’entrée en surbrillance, repérez 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.

  3. 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 d’é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"].

  4. Trouvez un ID de règle de sécurité dans l’événement avec la sous-chaîne [id "3. Cet ID peut être utilisé lorsque vous désactivez des règles.

Pour désactiver une règle :

  1. Allez sous  Outils & Paramètres > Pare-feu applicatif (ModSecurity).
  2. Dans la section Désactiver les règles de sécurité, sélectionnez la règle de sécurité selon son ID (par exemple 340003), la balise correspondante (par exemple CVE-2011-4898) ou une expression régulière (par exemple XSS) et cliquez sur OK.

Remarques relatives à Nginx et ModSecurity (Linux)

Sous Linux, ModSecurity est un module pour Apache. Par conséquent, il vérifie uniquement les requêtes HTTP communiquant avec Apache. Apache peut être complété par 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 (dans les paramètres Apache & Nginx du site), 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.