Modsecurity : Limiter les faux positifs

La mise en place de services de sécurité sur un serveur web est primordiale. Nous avons l’habitude d’installer deux services pour protéger nos pages web : modsecurity et fail2ban. Les deux sont complémentaires, le premier va scanner les requêtes à la recherche de tentatives malveillantes puis les bloquer. Le second va scanner les fichiers de logs des différents services (dont les logs de modsecurity) et bannir les adresses IP faisant trop souvent des tentatives considérées comme malveillantes.

Nous passerons l’installation de ses services, sachez qu’ils sont disponibles sur la plupart des repositories linux, de même que leur

configuration globale pour nous concentrer sur la mise en place de « listes blanches ». En effet, ces services très puissants ont tendance à bloquer certaines requêtes non malveillantes pour remédier à cela voici quelques pistes.

SecRuleEngine

La première chose à faire est de déterminer les pages nécessitant une protection et celles n’en requérant aucune. C’est ce deuxième type sur lequel nous allons nous concentrer dans cette partie. Sur ce type de page on désactive complètement mod_security ce qui permet de ne pas avoir à désactiver plusieurs règles de sécurité. Par exemple, dans le cadre de l’utilisation d’un CMS il est évident que la partie administration peut être retirée de la surveillance de modsecurity puisqu’elle demande une authentification et seul vous pourrez vous y connecter. De plus cette page d’authentification doit rester quant à elle sous surveillance.

Pour illustrer notre propos, voici deux exemples :

WordPress. Ce CMS à une interface d’administration avec une URL unique, il est donc très simple de sortir l’URL des règles de mod_security. Lorsque le module est installé vous avez sûrement un chemin de ce genre …/modsecurity-crs/activated-rules. Dans ce chemin créez un nouveau fichier de règles modsecurity-whitelist.conf et ajoutez-y la ligne suivante :

<LocationMatch "/wp-admin">
SecRuleEngine Off
</LocationMatch>

Drupal. Pour Drupal, c’est la même chose. On crée un fichier de whitelist et on y ajoute la ligne suivante :

<LocationMatch "/admin">
SecRuleEngine Off
</LocationMatch>

SecRuleRemoveById

Maintenant qu’on a retiré le plus gros des faux positifs. Il faut trier sur le volet chaque situations pouvant encore générer des bannissements abusifs. Pour cela, il faut supprimer les règles inappropriées de modsecurity sur les pages concernées, en testant et vérifiant toutes les fonctionnalités pour ne pas renvoyer des erreurs 403 non justifiées.

Lors de vos tests, si vous tombez sur une erreur 403 de ce type, en vérifiant les fichiers de logs, vous trouverez les ID et les pages concernés.

Le procédé à suivre est le suivant :

  1. Tester toutes les pages du site jusqu’à tomber sur une erreur 403,
  2. Il faut ensuite analyser les logs d’apache. Voir la commande :
    # tail /var/log/httpd/error_log
  3. Dans la ligne de log on récupère les informations suivantes :
    [id "960017"] [uri "/mon-url"]
    [id "960053"] [uri "/mon-url"]
  4. Puis dans le fichier modsecurity-whitelist.conf, on ajoute ces lignes :
    <LocationMatch "/mon-url">
    SecRuleRemoveById 960017 960053
    </LocationMatch>

On répète le procédé pour chaque erreur 403 que renvoie modsecurity.

Conclusion

À présent, vous devriez avoir éliminé un grand nombre de faux positifs sur les dispositifs de sécurité fail2ban et modsecurity. Cela devrait rendre la navigation plus agréable à tous vos utilisateurs. Notre dernier conseil est de penser à vérifier régulièrement les erreurs qui remontent dans le fichier de logs /var/log/httpd/error_log.