We misunderstood what the init rules did in modsecurity

Since they do not write to files they do not need to be removed
(doing so actually breaks modsecurity)
This commit is contained in:
Patrick Marchand 2018-11-07 11:00:46 -05:00
parent 251cf34ae9
commit 3fd16e25e6

View file

@ -814,8 +814,8 @@ Voir <https://wiki.evolix.org/HowtoFail2Ban#apache-nginx>
L'utilisation de [ModSecurity](http://www.modsecurity.org) permet
d'interdire certaines requêtes (attaques XSS connues, etc.) au
niveau d'Apache. On l'installe généralement avec le [OWASP ModSecurity
Core Rule Set](https://coreruleset.org/) (CRS)
niveau d'Apache. On l'installe généralement avec le
[OWASP ModSecurity Core Rule Set](https://coreruleset.org/) (CRS)
~~~
# apt install libapache2-mod-security2 modsecurity-crs
@ -856,10 +856,8 @@ Nous faisons une configuration minimale via
Include /usr/share/modsecurity-crs/owasp-crs.load
# Removed because it does not play well with apache-itk
SecRuleRemoveById "901000-901999"
# Removed because IP reputation based blocking is hard to predict
# and reason about
# Can be removed when modsecurity 2.9.3 hits debian
# See https://github.com/SpiderLabs/ModSecurity/issues/712
SecRuleRemoveById "910000-910999"
@ -884,7 +882,7 @@ 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 didentifier les règles problématiques
et les désactiver avec `SecRuleRemoveById XXXX`, comme nous le
faisont avec les règles 901* et 910*.
faisont avec les règles 910*.
~~~
<Directory "/home/monsite/www/wp-admin">