Tout dépend de votre site, de votre technologie et de votre infrastructure de test. L'OWASP CRS est très bruyant par défaut et nécessite beaucoup de peaufinage. Incidemment, il y a du travail en cours et la prochaine version pourrait avoir un mode normal et un paranoïaque, pour réduire les faux positifs. Pour donner un exemple, je m'occupe d'un site de taille raisonnable avec un mélange de pages statiques et un certain nombre d'applications écrites dans une grande variété de technologies (code hérité!) Et un bon nombre de visiteurs. Heureusement j'ai eu une régression nocturne dans notre environnement de préproduction avec une bonne couverture, ce qui était mon premier port d'escale. J'ai libéré ModSecurity après quelques tests initiaux, en mode DetectionOnly et je l'ai ajusté sur un mois peut-être jusqu'à ce que j'aie résolu tous les problèmes et que je me sois senti à l'aise pour passer à prod. Ce n'était pas un mois complet de travail continu bien sûr mais 30-60 minutes sur la plupart des jours pour vérifier les nuits précédentes courir, ajuster les règles de manière appropriée et mettre en place pour la course de la nuit prochaine (cookies sacrés avec leurs ficelles aléatoires!). Ensuite, j'ai fait la même chose en production, et j'ai presque immédiatement rencontré des problèmes avec les champs de retour de texte libre comme vous l'avez fait (bien sûr, je n'ai pas vu la plupart de ces régressions). Cela a pris beaucoup de peaufinage (a dû désactiver beaucoup de règles d'injection SQL pour ces champs). J'ai aussi beaucoup de connaissances sur le nombre de bots et de scripts lancés sur notre site! La plupart étaient des tentatives d'exploitation inoffensives ou Wordpress (heureusement que je n'exécute pas Wordpress), donc pas de risque réel pour mon site, mais encore une révélation. J'ai d'abord surveillé les journaux toutes les heures (paranoïaque!), Puis tous les jours, puis toutes les semaines.
Je dirais de mémoire qu'il a fallu environ 3 mois jusqu'à ce que je sois complètement à l'aise de l'allumer complètement et de le vérifier beaucoup au cours des prochains jours. Heureusement, tout le travail dur a porté ses fruits et très peu de faux positifs. Depuis, c'est assez stable et très peu de fausses alertes - principalement dues à de mauvaises données (par exemple, email @@ example.com est entré comme adresse e-mail pour un champ qui n'a pas correctement validé les adresses e-mail) et j'ai souvent quitté ces lieux et a fixé la validation du champ à la place.
Certains des problèmes courants et des règles que j'ai dû modifier sont donnés ici: Modsecurity: Excessive false positives (notez que vous ne pouvez pas besoin ou ne voulez pas désactiver toutes ces règles dans votre site).
Nous avons Splunk installé sur nos serveurs Web (essentiellement un outil qui aspire les fichiers journaux et peut ensuite être recherché ou automatiquement d'alerte ou signaler des problèmes). Mettez donc en place quelques alertes pour savoir quand les champs de champs libres les plus gênants ont provoqué un blocage ModSecurity (y ont corrigé un ou deux faux positifs), ainsi que du volume (nous recevons donc une alerte lorsqu'un seuil est dépassé et nous pouvons voir étaient sous une attaque soutenue - arrive plusieurs fois par an) et hebdomadaires/mensuels.
Donc un bon 4-5 mois pour mettre en œuvre de bout en bout de bout en bout avec peut-être 30-40 jours-homme de travail au cours de cette période. Mais c'était un site très compliqué et je n'avais aucune expérience antérieure de ModSecurity/WAF. Du côté positif, on a beaucoup appris sur les technologies web, ModSecurity et on a été aveuglé par regexpr en ne respectant pas certaines règles! :-)
Bonne élaboration! – darpet