C’est quoi les OWASP Top 10, Core Rule Set (CRS) et ModSecurity ?

réparer Windows 11

Requête envoyée au site
        ↓
ModSecurity l'inspecte
        ↓
Les règles OWASP CRS sont appliquées
        ↓
Comportement normal ou suspect ?
        ↓
La requête continue ou peut être bloquée

C’est un point important. Vous pouvez parfaitement avoir le module ModSecurity installé sur votre serveur sans bénéficier de la protection que vous imaginez. Il faut que le moteur soit actif, que les règles soient chargées, que les parties importantes des requêtes soient inspectées et que les règles puissent déclencher des actions.

ModSecurity possède trois états principaux pour SecRuleEngine :

Off
DetectionOnly
On

En mode DetectionOnly, les règles sont exécutées mais les actions de blocage ne sont pas appliquées. Le moteur peut détecter quelque chose et le journaliser sans empêcher la requête de continuer. Et c’est d’ailleurs ce que je recommande pour quelqu’un qui commence tout juste avec ModSecurity et les CRS car vous allez voir que c’est très puissant et que ça peut vous bloquer vous-même (ça m’est arrivé, les CRS ont bloqué mon éditeur WordPress et je ne pouvais même plus modifier ou actualiser un article). Et cela nous amène à l’un des points les plus importants lorsque l’on utilise CRS.

Pourquoi ne pas simplement activer les CRS en blocage ?

Parce que CRS est volontairement général. Il doit pouvoir être utilisé devant énormément d’applications différentes sans connaître à l’avance leur fonctionnement. WordPress, Nextcloud, une API maison ou une boutique en ligne ne communiquent pas de la même manière.

Certaines applications envoient aussi des données qui, sorties de leur contexte, peuvent ressembler à une attaque. C’est ce que l’on appelle un faux positif. Un WAF ne comprend pas une page comme un humain, il voit surtout une URL, des cookies, des en-têtes HTTP , le corps d’une requête et des chaînes de caractères.

Impossible de rechercher PowerShell sur mon site WordPress

Sur Assistouest.fr, j’ai publier un article informatique contenant une commande PowerShell. Pour moi, c’est simplement du contenu destiné à expliquer une manipulation Windows. Mais une partie de cette commande ressemble à quelque chose qu’un attaquant enverrait pour tenter d’exécuter du code sur Windows Server. Le pare-feu ne sait pas forcément que je suis en train de rédiger un article. Il voit surtout la chaîne de caractères.

Les faux positifs que j’ai rencontrés sur mon serveur

Sur mon infrastructure, j’ai rencontré différents cas de faux positifs avec ModSecurity et CRS.

Parmi eux certaines requêtes Nextcloud utilisant WebDAV, des contenus WordPress parlant de PowerShell ou de Base64 et certains cookies Cloudflare comme cf_clearance.

La règle a souvent détecté quelque chose qui ressemblait à ce qu’elle cherchait. Le problème est simplement que, dans ce contexte précis, la requête était légitime. Et c’est là que les logs deviennent indispensables pour configurer parfaitement les CRS et ModSecurity.

Un 403 ne suffit pas pour comprendre ce qu’il s’est passé

Lorsque ModSecurity bloque une requête, le navigateur voit passer un 403 Forbidden (accès interdit), ce code indique qu’une requête a été refusée. Sur mon infrastructure, lorsqu’un comportement m’étonne, je ne commence pas par désactiver la règle.

Je commence par chercher pourquoi elle s’est déclenchée. Et l’inverse est également vrai. Une absence de 403 ne signifie pas que ModSecurity n’a rien détecté.

Une règle peut s’être déclenchée sans que la requête soit bloquée.

Cela peut arriver si le moteur fonctionne en DetectionOnly, mais aussi si le niveau de suspicion total n’est pas suffisant pour atteindre le seuil de blocage.

Le score d’anomalie où plusieurs petits signaux peuvent déclencher une règle

OWASP CRS utilise un score d’anomalie pondéré. Lorsqu’une règle correspond à quelque chose de suspect, elle peut ajouter des points à la transaction. Toutes les détections n’ont pas la même importance. La configuration officielle utilise par défaut des scores différents selon la gravité des règles, puis compare le total à un seuil de blocage.

Prenons volontairement un exemple simplifié. Une première règle détecte un élément un peu suspect :

+ 3 points

Une deuxième règle trouve autre chose de suspect :

+ 2 points

Le score total devient 5. Si le seuil de blocage est fixé à 5, la requête peut alors être rejetée.

Les Paranoia Levels pour détecter davantage et bloquer sans sommation (ou pas)

CRS possède également plusieurs Paranoia Levels (PL). Le niveau 1 est le niveau par défaut.

Lorsque l’on monte de niveau, davantage de règles sont activées et les contrôles deviennent progressivement plus stricts. Cela peut améliorer la détection de certains comportements.

Mais il y a une contrepartie car plus les règles deviennent sensibles, plus vous augmentez également le risque de faux positifs. Cela ne veut donc pas dire :

PL4 = meilleure sécurité

La bonne configuration est celle que vous êtes capable d’administrer correctement.

Un PL très élevé qui oblige à désactiver ensuite des familles entières de règles peut devenir moins intéressant qu’un niveau plus raisonnable correctement réglé.

Vous devrez autoriser précisément ce qui est légitime

C’est probablement l’un des aspects les moins visibles des CRS. Lorsqu’une règle bloque une requête légitime, la solution la plus facile consiste à créer une exception et non pas à désactiver cette règle.

Imaginons qu’une règle XSS pose problème uniquement lorsqu’un champ particulier de WordPress contient du code destiné à un article technique.

Vous pouvez désactiver cette règle partout.

Le faux positif disparaît.

Mais la protection disparaît également sur tout le reste du site.

La meilleure approche consiste plutôt à dire :

Cette règle reste active partout

SAUF

Pour ce champ précis, sur cette fonctionnalité et lorsque cela est nécessaire

CRS prévoit différents mécanismes d’exclusion permettant de limiter une exception à une variable, une URL ou un contexte déterminé, sans supprimer la règle pour tout le site.

Il faut retester après chaque exclusion

Une exclusion corrige un problème. Mais si elle est trop large, elle peut également créer une faiblesse dans la protection. C’est pour cette raison que j’effectue ensuite des tests de non-régression.

Sur mon installation, j’ai utilisé des requêtes de test correspondant à plusieurs familles d’injection SQL, XSS, LFI, tentative de RCE et accès à certains fichiers sensibles comme .env.

Un WAF peut-il protéger contre une faille zero-day ?

C’est également l’un des intérêts les plus intéressants des règles générales du CRS. Une zero-day est une vulnérabilité nouvellement découverte pour laquelle il peut ne pas encore exister de correctif disponible.

Évidemment, CRS ne peut pas connaître par magie une vulnérabilité qui vient d’apparaître.

Mais il n’a pas forcément besoin de connaître le nom de la faille pour reconnaître la technique utilisée pour l’exploiter. Imaginons qu’une nouvelle vulnérabilité soit découverte dans une extension WordPress.

Personne n’a encore ajouté de règle dédiée à cette extension.

Mais si l’exploitation de la faille consiste à envoyer une injection SQL classique dans un paramètre, le CRS connaît déjà de nombreux motifs caractéristiques des injections SQL.

Il peut donc bloquer la tentative parce qu’il reconnaît la famille d’attaque, et non parce qu’il connaît cette vulnérabilité précise.

nouvelle vulnérabilité
        ↓
technique d'exploitation
        ↓
injection SQL
        ↓
règles SQL déjà présentes dans CRS
        ↓
détection

C’est aussi le principe derrière ce qu’OWASP appelle le virtual patching, une couche de sécurité intermédiaire peut empêcher certaines tentatives d’exploitation avant que le code vulnérable soit corrigé. Cela ne remplace évidemment pas une mise à jour.

Dès qu’un véritable correctif existe, la vulnérabilité doit être corrigée à sa source.

Le WAF permet quand même de réduire temporairement l’exposition et de manière plus générale la surface d’attaque.

Et toutes les attaques que le CRS ne peut pas voir ?

C’est là que l’OWASP Top 10 permet aussi de comprendre les limites d’un WAF.

Imaginons un site où /facture?id=100 affiche votre facture.

Si vous remplacez simplement 100 par 101 et que l’application vous donne la facture d’un autre client, il existe un problème de contrôle d’accès. Pourtant, votre requête HTTP peut sembler normale.

Pas de SQL suspect. Pas de JavaScript. Pas de commande système. Le problème se trouve dans la logique de l’application. Un jeu de règles génériques ne peut pas savoir que l’utilisateur connecté n’a pas le droit de consulter cette ressource.

Même chose pour une mauvaise architecture d’authentification, une erreur cryptographique et autres failles purement logiques.

ModSecurity et CRS doivent faire partie d’un ensemble

Un WAF est une couche de protection. Pas la seule. Dans mon cas, ModSecurity et CRS fonctionnent aux côtés d’autres protections placées à différents endroits de l’infrastructure.

Cloudflare peut filtrer une partie du trafic avant son arrivée sur le serveur. Un firewall peut limiter certains accès réseau. Un outil comme CrowdSec permet d’analyser les logs pour détecter certains événements et comportements présents dans les journaux de ModSecurity.

Mais leur fonctionnement est un autre sujet et aucune de ces couches ne rend inutile les autres.

Le rôle de ModSecurity et CRS est d’analyser les transactions Web selon des règles et intervenir lorsqu’elles correspondent suffisamment à des comportements considérés comme dangereux.