Affinage section ModSecurity
This commit is contained in:
whirigoyen
parent
9137b8f05b
commit
304b07cb54
|
|
@ -1114,9 +1114,11 @@ Voir <https://wiki.evolix.org/HowtoFail2Ban#apache-nginx>
|
|||
|
||||
L'utilisation du moteur [ModSecurity](http://www.modsecurity.org) permet de bloquer certaines requêtes HTTP (injections SQL, attaques XSS connues, etc.) au niveau d'Apache. On l'installe avec le [OWASP ModSecurity Core Rule Set](https://coreruleset.org/) (CRS) qui est un ensemble de règles couvrant un large spectre d'attaques possibles. Elles sont définit dans le dossier `/usr/share/modsecurity-crs/rules/`
|
||||
|
||||
Faisant office de Pare-feu applicatif, le contenu des demandes clients ET les réponses serveurs sont analysés à la recherche de signes d'attaques pouvant générer de faux-positifs. Il faudra par la suite ajuster les réglages en fonction du niveau de sécurité que l'on veut appliquer à l'application.
|
||||
Faisant office de pare-feu applicatif, le contenu des demandes clients ET les réponses serveurs sont analysés à la recherche de signes d'attaques pouvant générer de faux-positifs. Il faudra par la suite ajuster les réglages en fonction du niveau de sécurité que l'on veut appliquer à l'application.
|
||||
|
||||
Il y aura besoin de ces deux paquets:
|
||||
#### Intégration de ModSecurity dans Apache
|
||||
|
||||
Installer les deux paquets suivants :
|
||||
|
||||
~~~
|
||||
# apt install libapache2-mod-security2 modsecurity-crs
|
||||
|
|
@ -1193,30 +1195,28 @@ SecRuleRemoveById "920000"
|
|||
SecRuleRemoveById "930000"
|
||||
|
||||
</IfModule>
|
||||
|
||||
~~~
|
||||
|
||||
À propos [des directives Apache](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x))
|
||||
[Documentation de référence sur les directives Apache de ModSecurity](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x))
|
||||
|
||||
Nous désactivons le log d'audit par défaut, puisque l’information enregistrée dans le log d'erreur Apache est suffisante pour connaître la raison d'un bloquage. Par contre, il est utile de le réactiver (avec `SecAuditEngine RelevantOnly`) lorsque
|
||||
vous faites un audit des règles applicables a un serveur ou lors de la rédaction de nouvelles règles. Dans ce cas, il existe des [outils](https://github.com/Apache-Labor/labor/blob/master/bin/.apache-modsec.alias)
|
||||
Nous désactivons le log d'audit par défaut, puisque l’information enregistrée dans le log d'erreur Apache est suffisante pour connaître la raison d'un bloquage. Par contre, il est utile de le réactiver (avec `SecAuditEngine RelevantOnly`) lorsque vous faites un audit des règles applicables a un serveur ou lors de la rédaction de nouvelles règles. Dans ce cas, il existe des [outils](https://github.com/Apache-Labor/labor/blob/master/bin/.apache-modsec.alias)
|
||||
pour faciliter l’obtention de statistiques du audit log.
|
||||
|
||||
On peut ajuster certains paramètres de ModSecurity Core Rule Set en personalisant le fichier `/etc/modsecurity/crs/crs-setup.conf`.
|
||||
C'est notamment ici qu'il faudra ajuster si on utilise d'autres méthodes HTTP (comme PATCH, PUT, DELETE...) qui sont bloquées par défaut.
|
||||
|
||||
On pourra désactiver modsecurity dans des vhosts ou sur des dossiers en particulier en jouant avec la directive `SecRuleEngine Off`.
|
||||
Ceci peut être utile en cas de problèmes, mais il est toujours mieux de faire un léger audit afin d’identifier les règles problématiques et les désactiver avec `SecRuleRemoveById XXXX`, comme nous le faisont avec les règles 910*.
|
||||
#### Ajustement des règles de ModSecurity
|
||||
|
||||
~~~
|
||||
<Directory "/home/monsite/www/wp-admin">
|
||||
<IfModule security2_module>
|
||||
SecRuleEngine Off
|
||||
</IfModule>
|
||||
</Directory>
|
||||
~~~
|
||||
Les paramètres du Core Rule Set de ModSecurity peuvent être personalisées dans `/etc/modsecurity/crs/crs-setup.conf`.
|
||||
|
||||
Le ModSecurity Core Rule Set contient des règles spécifiques pour traité les faux positifs lié à l'utilisation de certaines applications web tel que wordpress. Celles-ci sont désactivé par défaut et peuvent être activé en définissant certaines variables de modsecurity. Un exemple est présent dans le dépot git de ModSecurity Core Rule Set:
|
||||
C'est notamment là qu'on peut autoriser les méthodes HTTP bloquées par défaut, comme PATCH, PUT, DELETE...
|
||||
|
||||
|
||||
#### Affinage des règles pour les applications web type Wordpress
|
||||
|
||||
Le ModSecurity Core Rule Set contient des règles spécifiques pour traiter les faux positifs lié à l'utilisation de certaines applications web tel que Wordpress.
|
||||
|
||||
Celles-ci sont désactivées par défaut et peuvent être activées en définissant certaines variables de ModSecurity.
|
||||
|
||||
Un exemple est présent dans le [dépot GitHub Core Rule Set](https://github.com/coreruleset/coreruleset) :
|
||||
|
||||
~~~
|
||||
#SecAction \
|
||||
|
|
@ -1238,6 +1238,10 @@ Le ModSecurity Core Rule Set contient des règles spécifiques pour traité les
|
|||
|
||||
#### Désactiver des règles au cas par cas
|
||||
|
||||
En général, plutôt que de les désactiver, on préfère régler plus finement le règles définies dans le Core Rules Set (CRS) dans `/etc/modsecurity/crs/crs-setup.conf`.
|
||||
|
||||
Si après cela, certaines règles posent toujours des problèmes, on peut les désactiver au cas par cas.
|
||||
|
||||
Pour trouver dans un log toutes les règles qui se sont déclenchées ainsi que leur fréquence :
|
||||
|
||||
~~~
|
||||
|
|
@ -1250,15 +1254,33 @@ Pour trouver dans un log toutes les règles qui se sont déclenchées ainsi que
|
|||
300 980130
|
||||
~~~
|
||||
|
||||
On peut ensuite les désactiver au cas par cas dans un vhost ou dans un conf.d d'Apache :
|
||||
On peut ensuite les désactiver au cas par cas dans un vhost ou dans un `conf.d` d'Apache :
|
||||
|
||||
~~~
|
||||
<IfModule mod_security2.c>
|
||||
|
||||
SecRuleRemoveById "980130"
|
||||
...
|
||||
</IfModule>
|
||||
~~~
|
||||
|
||||
|
||||
#### Désactiver ModSecurity pour un vhost ou un répertoire
|
||||
|
||||
On évite de désactiver complètement ModSecurity.
|
||||
|
||||
Si l'affinage des règles et leur désactivation au cas par cas ne suffit pas, on peut désactiver ModSecurity spécifiquement pour un vhost ou un répertoire avec la directive `SecRuleEngine Off`.
|
||||
|
||||
Ceci peut être utile en cas de problèmes, mais on préfère identifier les règles problématiques dans les logs et les désactiver au cas par cas avec `SecRuleRemoveById XXXXXX`, comme nous le faisons avec les règles `910XXX`.
|
||||
|
||||
~~~
|
||||
<Directory "/home/monsite/www/wp-admin">
|
||||
<IfModule security2_module>
|
||||
SecRuleEngine Off
|
||||
</IfModule>
|
||||
</Directory>
|
||||
~~~
|
||||
|
||||
|
||||
## Awstats
|
||||
|
||||
[AWStats](http://www.awstats.org/) est un outil pour générer des
|
||||
|
|
|
|||
Loading…
Reference in a new issue