Comment configurer Cloudflare contre les attaques DDoS d’un site ?

Question

IT Interview Practice · Accepted Answer

**Cloudflare protège au mieux un site lorsque les requêtes passent par lui et que l’application peut absorber le trafic restant.** Activer un seul réglage ne protège pas tous les chemins vers votre serveur.

Imaginez une boutique en ligne. Un attaquant peut inonder les images de produits, appeler sans cesse une recherche coûteuse ou contacter directement le serveur. Ces attaques consomment des ressources différentes : il faut plusieurs couches de protection.

## 1. Faire passer les requêtes par Cloudflare

Activez le mode proxy pour les enregistrements DNS pris en charge du site. Les visiteurs passent alors par Cloudflare avant d’atteindre l’origine, c’est-à-dire le serveur qui héberge réellement le site. Un enregistrement « DNS only » résout le nom, mais ne fait pas passer le trafic HTTP par ce chemin de protection.

```text
Browser -> Cloudflare -> Origin -> Database
```

C’est la base : le filtrage Cloudflare aide uniquement les requêtes qui le traversent. Vérifiez chaque nom d’hôte public utilisé par la boutique, notamment celui de l’API, et pas seulement le domaine principal.

## 2. Fermer l’accès direct au serveur d’origine

Si les attaquants peuvent atteindre directement l’origine, ils contournent le filtrage. Limitez les connexions web entrantes publiques aux plages IP Cloudflare appropriées et maintenez cette liste à jour. Vous pouvez aussi étudier Cloudflare Tunnel, qui établit une connexion sortante et peut supprimer le besoin de ports web entrants publics.

Gardez l’administration sur un accès protégé distinct et les bases de données hors de l’Internet public. Testez l’accès normal via Cloudflare et le rejet des accès directs. Cacher une adresse IP ne suffit pas. Consultez la [protection de l’origine](https://developers.cloudflare.com/fundamentals/security/protect-your-origin-server/).

## 3. Filtrer les attaques sans bloquer les vrais clients

Examinez la protection DDoS gérée et les contrôles disponibles dans votre offre. Ajoutez des règles WAF adaptées : ce pare-feu examine les requêtes HTTP pour détecter des motifs suspects avant de les transmettre. DDoS et WAF traitent des problèmes partiellement différents ; aucun ne garantit qu’une requête autorisée coûtera peu à l’application.

Commencez par des règles que vous pouvez expliquer, observez le trafic concerné et ajustez précisément si des clients légitimes sont bloqués. Un grand nombre de requêtes bloquées ne prouve pas à lui seul la réussite. Cloudflare décrit la [configuration et l’ajustement DDoS](https://developers.cloudflare.com/ddos-protection/get-started/).

## 4. Protéger séparément les opérations coûteuses

Une image en cache coûte généralement bien moins à l’origine qu’une recherche parcourant de nombreux enregistrements. Limitez le débit des points d’accès coûteux selon leur usage normal et la capacité du service sous-jacent.

- Pour la connexion ou l’envoi d’OTP, combinez les limites périphériques avec des limites applicatives par compte ou destination. Une seule IP peut représenter plusieurs utilisateurs réels.
- Pour la recherche ou les rapports, bornez le travail déclenché par chaque requête ; limiter seulement leur nombre peut laisser passer des requêtes dangereusement coûteuses.
- Pour les API authentifiées, considérez le client ou la clé API en plus des signaux réseau. Des attaquants distribués peuvent utiliser beaucoup d’adresses IP.

Il n’existe pas de seuil universellement sûr. Observez les pics légitimes, introduisez les limites prudemment et mesurez à la fois le soulagement du backend et les requêtes valides refusées.

## 5. Mettre en cache ce qui peut être partagé sans risque

Mettez en cache les images publiques et fichiers statiques pour servir les demandes répétées sans atteindre l’origine. Dans notre boutique, cela évite de dépenser sans cesse des ressources pour la même image de produit.

Les paniers personnels et pages de compte exigent d’autres règles : personne ne doit recevoir les données d’un autre client. Vérifiez les clés de cache et les conditions de contournement avant de mettre en cache des réponses dynamiques. Le cache réduit le travail répété, mais ne sécurise pas automatiquement la connexion ou le paiement sous forte charge.

## 6. Prévoir la sortie des mesures d’urgence

Le mode Under Attack peut présenter un défi au navigateur pendant un incident. Évaluez-le pour les routes navigateur concernées et retirez cette mesure temporaire au moment opportun. Les clients logiciels et webhooks de paiement peuvent être incapables de résoudre ce défi : leurs routes nécessitent une authentification adaptée et des contrôles ciblés.

Enfin, vérifiez que de vrais clients peuvent consulter les produits et payer, tout en surveillant la latence de l’origine, le CPU, la pression sur la base et les erreurs. Si une attaque réseau directe sature la connexion de l’origine, coordonnez une protection en amont avec l’hébergeur. L’objectif est de maintenir un service utile, sans promettre qu’aucune attaque ne pourra jamais le perturber.

1. Faire passer les requêtes par Cloudflare

2. Fermer l’accès direct au serveur d’origine

3. Filtrer les attaques sans bloquer les vrais clients

4. Protéger séparément les opérations coûteuses

5. Mettre en cache ce qui peut être partagé sans risque

6. Prévoir la sortie des mesures d’urgence

Questions connexes