ModSecurity et OWASP sur CentOS 6 et Apache 2

• Installation
• Utilisation de ModSecurity
• Modification d'un ensemble de règles / désactivation d'un ID de règle

ModSecurity est un pare-feu de couche d'application Web conçu pour fonctionner avec IIS, Apache2 et Nginx. Il s'agit d'un logiciel libre et open source publié sous la licence Apache 2.0. ModSecurity aide à sécuriser votre serveur Web en surveillant et en analysant le trafic de votre site Web. Il le fait en temps réel pour détecter et bloquer les attaques de la plupart des exploits connus à l'aide d'expressions régulières. À lui seul, ModSecurity offre une protection limitée et s'appuie sur des ensembles de règles pour maximiser la protection.

L'Open Web Application Security Project (OWASP) Core Rule Set (CRS) est un ensemble de règles de détection d'attaque génériques qui fournissent un niveau de protection de base pour toute application Web. L'ensemble de règles est gratuit, open-source et actuellement sponsorisé par Spider Labs.

OWASP CRS fournit:

• Protection HTTP - détection des violations du protocole HTTP et d'une politique d'utilisation définie localement.
• Recherches de listes noires en temps réel - utilise la réputation IP de tiers.
• Protection contre le déni de service HTTP - défense contre les inondations HTTP et les attaques HTTP DoS lentes.
• Protection contre les attaques Web courantes - détection des attaques de sécurité des applications Web courantes.
• Détection d'automatisation - Détection des robots, robots d'exploration, scanners et autres activités malveillantes de surface.
• Intégration avec AV Scanning pour le téléchargement de fichiers - détecte les fichiers malveillants téléchargés via l'application Web.
• Suivi des données sensibles - Suit l'utilisation des cartes de crédit et bloque les fuites.
• Trojan Protection - Détecte les chevaux de Troie.
• Identification des défauts d'application - alertes sur les erreurs de configuration des applications.
• Détection et masquage des erreurs - Déguisement des messages d'erreur envoyés par le serveur.

Installation

Ce guide vous montre comment installer l'ensemble de règles ModSecurity et OWASP sur CentOS 6 exécutant Apache 2.

Tout d'abord, vous devez vous assurer que votre système est à jour.

 yum -y update

Si vous n'avez pas installé Apache 2, installez-le maintenant.

 yum -y install httpd

Vous devez maintenant installer certaines dépendances pour que ModSecurity fonctionne. Selon la configuration de votre serveur, certains ou tous ces packages peuvent déjà être installés. Yum installera les packages que vous n'avez pas et vous informera si l'un des packages est déjà installé.

 yum -y install httpd-devel git gcc make libxml2 pcre-devel libxml2-devel curl-devel

Modifiez le répertoire et téléchargez le code source sur le site Web de ModSecuity. La version stable actuelle est 2.8.

 cd /opt/
 wget https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz

Extrayez le package et accédez à son répertoire.

 tar xzfv modsecurity-2.8.0.tar.gz 
 cd modsecurity-2.8.0

Configurez et compilez le code source.

 ./configure
 make
 make install

Copiez la configuration ModSecurity par défaut et le fichier de mappage Unicode dans le répertoire Apache.

 cp modsecurity.conf-recommended /etc/httpd/conf.d/modsecurity.conf
 cp unicode.mapping /etc/httpd/conf.d/

Configurez Apache pour utiliser ModSecurity. Vous pouvez procéder de deux manières.

 echo LoadModule security2_module modules/mod_security2.so >> /etc/httpd/conf/httpd.conf

... ou utilisez un éditeur de texte comme nano:

 nano /etc/httpd/conf/httpd.conf

Au bas de ce fichier, sur une ligne distincte, ajoutez ceci:

 LoadModule security2_module modules/mod_security2.so

Vous pouvez maintenant démarrer Apache et le configurer pour démarrer au démarrage.

 service httpd start
 chkconfig httpd on

Si vous aviez installé Apache avant d'utiliser ce guide, il vous suffit de le redémarrer.

 service httpd restart

Vous pouvez maintenant télécharger le jeu de règles de base OWASP.

 cd /etc/httpd
 git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

Configurez maintenant l'ensemble de règles OWASP.

 cd modsecurity-crs
 cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_config.conf

Ensuite, vous devez ajouter l'ensemble de règles à la configuration Apache. Encore une fois, nous pouvons le faire de deux manières.

 echo Include modsecurity-crs/modsecurity_crs_10_config.conf >> /etc/httpd/conf/httpd.conf
 echo Include modsecurity-crs/base_rules/*.conf >> /etc/httpd/conf/httpd.conf

... ou avec un éditeur de texte:

 nano /etc/httpd/conf/httpd.conf

Au bas du fichier, sur des lignes distinctes, ajoutez ceci:

 Include modsecurity-crs/modsecurity_crs_10_config.conf
 Include modsecurity-crs/base_rules/*.conf

Redémarrez maintenant Apache.

 service httpd restart

Enfin, supprimez les fichiers d'installation.

 yum erase /opt/modsecurity-2.8.0
 yum erase /opt/modsecurity-2.8.0.tar.gz

Utilisation de ModSecurity

Par défaut, ModSecurity s'exécute en mode détection uniquement, ce qui signifie qu'il enregistrera toutes les violations de règles mais ne prendra aucune mesure. Ceci est recommandé pour les nouvelles installations afin que vous puissiez regarder les événements générés dans le journal des erreurs Apache. Après avoir examiné le journal, vous pouvez décider si une modification de l'ensemble de règles ou la désactivation de la règle (voir ci-dessous) doit être effectuée avant de passer en mode de protection.

Pour afficher le journal des erreurs Apache:

 cat /var/log/httpd/error_log

La ligne ModSecurity du journal des erreurs Apache est divisée en neuf éléments. Chaque élément fournit des informations sur la raison pour laquelle l'événement a été déclenché.

• La première partie indique quel fichier de règles a déclenché cet événement.
• La deuxième partie indique sur quelle ligne du fichier de règles la règle démarre.
• Le troisième élément vous indique quelle règle a été déclenchée.
• Le quatrième élément vous indique la révision de la règle.
• Le cinquième élément contient des données spéciales à des fins de débogage.
• Le sixième élément définit la gravité de journalisation de cette gravité d'événement.
• La septième section décrit quelle action s'est produite et dans quelle phase elle s'est produite.

Notez que certains éléments peuvent être absents selon la configuration de votre serveur.

Pour faire passer ModSecurity en mode de protection, ouvrez le fichier conf dans un éditeur de texte:

 nano /etc/httpd/conf.d/modsecurity.conf

... et changez:

 SecRuleEngine DetectionOnly

à:

 SecRuleEngine On

Si vous rencontrez des blocs lorsque ModSecurity est en cours d'exécution, vous devez identifier la règle dans le journal des erreurs HTTP. La commande "tail" vous permet de regarder les logs en temps réel:

 tail -f /var/log/httpd/error_log

Répétez l'action qui a provoqué le blocage tout en regardant le journal.

Modification d'un ensemble de règles / désactivation d'un ID de règle

La modification d'un ensemble de règles dépasse le cadre de ce didacticiel.

Pour désactiver une règle spécifique, vous identifiez l'ID de règle qui se trouve dans le troisième élément (par exemple [id = 200000]), puis le désactivez dans le fichier de configuration Apache:

 nano /etc/httpd/conf/httpd.conf

... en ajoutant ce qui suit au bas du fichier avec l'ID de règle:

<IfModule mod_security2.c>
SecRuleRemoveById 200000
</IfModule>

Si vous trouvez que ModSecurity bloque toutes les actions sur vos sites Web, alors "Core Rule Set" est probablement en mode "Self-Contained". Vous devez changer cela en "Détection collaborative", qui détecte et bloque uniquement les anomalies. Dans le même temps, vous pouvez consulter les options "autonomes" et les modifier si vous le souhaitez.

 nano /etc/httpd/modsecurity-crs/modsecurity_crs_10_config.conf

Remplacez «détection» par «autonome».

Vous pouvez également configurer ModSecurity pour autoriser votre IP via le pare-feu d'application Web (WAF) sans vous connecter:

 SecRule REMOTE_ADDR "@ipMatch xxx.xxx.xxx.xxx" phase:1,nolog,allow,ctl:ruleEngine=Off

... ou avec enregistrement:

 SecRule REMOTE_ADDR "@ipMatch xxx.xxx.xxx.xxx" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly