Règles pare-feu Cloudflare pour débutants : 5 règles gratuites pour filtrer 80 % du trafic malveillant (modèles inclus)

Introduction

Les logs du serveur débordent de requêtes de scan — des milliers d’accès malveillants par jour. Cloudflare gratuit sans aucune règle pare-feu, c’est partir à découvert. Copier-coller des tutoriels en ligne, et rien ne marche : la priorité des règles était inversée.

Les expressions comme (ip.src.country eq "CN") font mal à la tête, mais après quelques jours de tests, 5 règles gratuites suffisent vraiment. Bien configurées, elles filtrent plus de 80 % des requêtes malveillantes sans toucher aux utilisateurs légitimes. Ce guide couvre ces 5 règles : principe, priorités, 30 minutes de configuration.

Chapitre 1 : Pourquoi 5 règles gratuites suffisent

Beaucoup voient « 5 règles personnalisées » sur l’offre gratuite Cloudflare et pensent : « Ce n’est pas assez. » Pro en a 20 — faut-il upgrader ?

Attendez la fin de l’explication.

La plupart du trafic malveillant vient de quelques sources : scanners en datacenter, IP à score de menace élevé, User-Agent anormaux. D’après la communauté Cloudflare, 5 règles bien placées bloquent plus de 80 % des attaques.

C’est la loi 80/20.

En plus des 5 règles personnalisées, l’offre gratuite inclut le Cloudflare Free Managed Ruleset (jeu de règles managées gratuit), activé par défaut, contre des failles comme Shellshock ou Log4J. Jeu managé + 5 règles : suffisant pour un site PME.

Les 15 règles Pro servent surtout à affiner : sous-domaines multiples, stratégies par API. Site simple : 5 règles couvrent l’essentiel.

À condition de les utiliser correctement. Mauvaise priorité : 10 règles ne servent à rien.

Chapitre 2 : Le secret de la priorité des règles

C’est le piège le plus fréquent. Au début, j’avais aussi inversé l’ordre — aucune règle ne s’appliquait.

Les règles pare-feu Cloudflare s’exécutent de haut en bas, comme une chaîne de contrôle. Règle 1, puis 2, etc. Dès qu’une règle correspond, l’action s’applique (Allow, Block, Challenge…) et l’évaluation s’arrête (sauf Allow, qui continue).

Image : le gardien à l’entrée :

1. Reconnaître : proches → laisser entrer (liste blanche)
2. Vérifier : inconnus → contrôle d’identité (challenge)
3. Refuser : suspects → refus (block)

Inverser l’ordre (bloquer avant vérifier) : les visiteurs légitimes n’entrent plus.

Erreur classique : bloquer par pays avant la liste blanche. UptimeRobot à l’étranger, première règle « bloquer tout IP hors Chine » : monitoring coupé, panne invisible.

Bonne pratique : liste blanche toujours en première position. Trafic connu (crawlers, monitoring, vos IP), puis durcissement.

Point souvent oublié : ordre des actions. Même priorité de règle :

• Allow (autoriser) > Skip (ignorer) > Challenge (défi) > Block (bloquer) > Log (journaliser)

Allow l’emporte sur Block si les deux correspondent — d’où la liste blanche en tête.

Chapitre 3 : Les 5 règles d’or

Voici les 5 règles par priorité décroissante, prêtes à copier.

Règle 1 (priorité maximale) : Liste blanche — protéger vos alliés

Rôle : laisser passer le trafic légitime connu, éviter les faux positifs.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Cas d’usage :

• Crawlers (Google, Bing, Baidu…)
• Monitoring (UptimeRobot, StatusCake…)
• IP bureau, domicile

Expression :

(cf.client.bot) or (ip.src in {1.2.3.4 5.6.7.8})

Action : Allow

Notes :

• cf.client.bot : crawlers vérifiés par Cloudflare (Google, Bing…)
• Remplacez {1.2.3.4 5.6.7.8} par vos IP, séparées par des espaces
• Sans liste IP : (cf.client.bot)

Règle 2 : Challenge ASN datacenter — trafic hébergé en salle

Rôle : validation humaine pour le trafic venant de datacenters.

Cas d’usage :

Scanners et outils de crawl tournent souvent sur VPS ou cloud ; les utilisateurs réels accèdent rarement depuis une IP datacenter. Un challenge suffit à bloquer les bots.

Expression :

(ip.geoip.asnum in {13335 15169 16509 14618 45090})

Action : Managed Challenge

Table ASN (datacenters courants) :

Adaptez la liste à votre site. Évitez Block direct — risque pour utilisateurs VPN. Managed Challenge : humains passent, bots restent bloqués.

Règle 3 : Score de menace + filtrage IP à risque

Rôle : bloquer les IP à haut risque via la threat intelligence Cloudflare.

Cas d’usage :

Cloudflare note chaque IP (0-100). Score élevé = plus dangereux. > 10 : possible spam ; > 40 : comportement suspect ; > 50 : block recommandé.

Expression :

(cf.threat_score gt 10)

Action : Challenge (10-40) ou Block (> 50)

Seuils recommandés :

Astuce :

Segmentation en deux règles :

• Règle 3A : (cf.threat_score gt 10 and cf.threat_score le 50) → Challenge
• Règle 3B : (cf.threat_score gt 50) → Block

Cela consomme 2 règles. Si le quota manque : gt 10 + Challenge, observer une semaine.

Règle 4 : Blocage User-Agent anormaux

Rôle : filtrer UA vides, crawlers malveillants, outils automatisés.

Cas d’usage :

Un navigateur envoie un User-Agent (« je suis Chrome »). UA vide ou python-requests, curl : probablement un script, pas un humain.

Expression :

(http.user_agent eq "") or (http.user_agent contains "python-requests") or (http.user_agent contains "curl") or (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "MJ12bot")

Action : Block

UA malveillants courants :

• python-requests — script Python
• curl — ligne de commande
• sqlmap — injection SQL
• nikto — scanner de vulnérabilités
• MJ12bot — crawler Majestic SEO (ignore robots.txt)
• masscan — scan de ports
• ZmEu — scanner

Attention :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Ne pas bloquer Mozilla, Chrome, Safari
• Mode Log une semaine pour inventorier les UA anormaux
• API publique : exclure l’UA de votre client API

Règle 5 : Protection des chemins sensibles

Rôle : protéger admin, API sensibles, fichiers de config.

Cas d’usage :

WordPress : /wp-admin, /wp-login.php — cibles favorites. .env, .git : fuite = catastrophe.

Expression :

(http.request.uri.path contains "/wp-login" or http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git") and not (ip.src in {1.2.3.4})

Action : Block ou Challenge

Notes :

• Remplacez {1.2.3.4} par votre IP pour accéder à l’admin
• Sans liste IP : supprimez and not (ip.src in {1.2.3.4}) et utilisez Challenge

Autres chemins sensibles :

• /xmlrpc.php (WordPress XML-RPC, souvent cible DDoS)
• /phpMyAdmin
• /config.php
• /.sql (sauvegarde BDD)

Adaptez à votre stack.

Flux complet des 5 règles

Requête entrante
   ↓
Règle 1 : crawler ou IP liste blanche ? → oui → autoriser
   ↓ non
Règle 2 : ASN datacenter ? → oui → challenge → passé / bloqué
   ↓ non
Règle 3 : score > 10 ? → oui → challenge / block
   ↓ non
Règle 4 : UA anormal ? → oui → block
   ↓ non
Règle 5 : chemin sensible ? → oui → block / challenge
   ↓ non
Autoriser vers l'origine

Ce flux filtre la majorité des attaques automatisées sans faux positifs massifs.

Chapitre 4 : Configuration pas à pas

Les règles seules ne suffisent pas — il faut les déployer.

Étape 1 : page pare-feu

Cloudflare Dashboard → votre domaine → Security → WAF → onglet Custom rules.

Étape 2 : première règle (liste blanche)

1. Create rule

2. Nom : Liste blanche - crawlers et monitoring

3. Expression Builder par défaut ; Edit expression pour coller le code

4. Expression :

   (cf.client.bot) or (ip.src in {1.2.3.4})

   Remplacez l’IP

5. Action : Allow

6. Deploy

Étape 3 : règles 2 à 5

Même méthode, noms, expressions et actions du chapitre 3.

Étape 4 : ordre des règles

Dans la liste, glissez l’icône à six points :

• Liste blanche en haut (priorité 1)
• ASN en second
• Score de menace en troisième
• UA anormaux en quatrième
• Chemins sensibles en cinquième

Étape 5 : tests

1. Liste blanche : votre IP → accès normal

2. UA :

   curl -A "sqlmap" https://votre-domaine.com

   Page de blocage attendue

3. Logs : Dashboard → Security → Events

Si inefficace :

• Erreur de syntaxe
• Ordre de priorité
• Action correcte

Chapitre 5 : Astuces avancées et FAQ

Les 5 règles de base bloquent déjà la majorité des attaques. Quelques optimisations utiles.

Comment juger l’efficacité

Indicateur clé : CSR (Challenge Solve Rate, taux de résolution des défis).

Formule : CSR = défis résolus / défis émis

Plus bas = mieux. CSR ~ 0 % : presque que des bots → Block possible pour économiser les ressources.

CSR élevé (> 50 %) : faux positifs possibles → ajuster les conditions.

Voir le CSR : Security → Events → règle → statistiques.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Éviter les faux positifs

1. Nouvelle règle en Log 7 jours

   • Action Log (journaliser sans bloquer)
   • Après une semaine, Challenge ou Block si OK

2. Lister vos IP et le monitoring

   • IP habituelles en règle 1
   • Plages UptimeRobot sur le site officiel

3. Ne pas Block d’emblée

   • Challenge d’abord
   • Block si CSR ~ 0 %

4. Chute anormale du trafic

   • Trafic légitime en baisse → vérifier Security Events

Attaque soudaine

Sous attaque CC ou DDoS : mode Under Attack (bouclier 5 secondes) :

Security → Settings → Security Level → I’m Under Attack

Page 5 s avec validation JS. Bots bloqués ; humains attendent 5 s. Revenir à Medium ou Low après l’attaque.

Renforcement temporaire :

• Challenge → Block
• Blocage géographique si l’attaque vient d’un pays

5 règles insuffisantes

1. Fusionner avec or

   • Règle 4 : plusieurs UA en une règle
   • Une règle par type de scénario

2. Listes IP

   • Cloudflare : milliers d’IP
   • ip.src in $blacklist
   • Une règle pour un grand volume

3. Upgrade Pro

   • 20 règles et fonctions avancées
   • Si le site est rentable

FAQ

Q : Règles inefficaces ?

A : Vérifier :

• Syntaxe (Cloudflare signale les erreurs)
• Priorité (liste blanche en haut)
• Allow ou Skip en amont

Q : Votre IP bloquée ?

A : Ajoutez-la à la règle 1 :

(cf.client.bot) or (ip.src in {votre IP})

Q : Quel seuil de score de menace ?

A :

• Conservatrice : cf.threat_score gt 30
• Équilibrée : cf.threat_score gt 10 (recommandé)
• Agressive : cf.threat_score gt 5

Commencez avec 10, une semaine d’observation, ajustez selon CSR.

Q : Googlebot bloqué ?

A : Règle 1 (liste blanche) en tête. cf.client.bot reconnaît Google, Bing, etc.

Conclusion

En résumé :

5 règles pare-feu gratuites suffisent. L’essentiel : priorité correcte :

1. Liste blanche en premier
2. Challenge ASN datacenter
3. Filtrage score de menace
4. Blocage UA anormaux
5. Protection chemins sensibles

Effet sous 30 minutes. Une semaine plus tard, Security Events montre l’impact — scanners et trafic parasite bloqués à la porte.

Configurez maintenant. Dashboard Cloudflare, modèles ci-dessus, copier-coller, ajuster les IP, 30 minutes.

Revenez voir les stats dans une semaine. Gardez cet article pour les ajustements futurs — le chapitre 5 FAQ reste utile.

Votre site mérite une meilleure protection.