Attaque DDoS probable
Le trafic ou le nombre de requêtes augmente brutalement, certaines routes sont visées de façon répétitive et plusieurs sources sollicitent le service sans comportement utilisateur cohérent.
Incident en cours
Votre site, application ou API subit une attaque DDoS ?
Nous qualifions l'attaque, réduisons le trafic malveillant et stabilisons votre infrastructure. Nous pouvons intervenir sur une configuration Cloudflare existante ou commencer directement sur le serveur avant de déployer une protection en amont si nécessaire.
Prise en charge téléphonique immédiate du lundi au vendredi, de 9 h à 18 h.
Nous répondons habituellement par e-mail en moins d'une heure pendant ces horaires.
Intervention d'urgence sur devis. Après une première qualification du périmètre, nous présentons les actions envisageables et leurs conditions avant la prise en charge.
Demande urgente
Décrivez les symptômes
Ces informations nous permettent de qualifier plus vite la situation et de préparer le rappel.
Première lecture
Attaque, panne ou pic de trafic ?
Les symptômes se ressemblent souvent. Une première qualification évite de durcir la sécurité contre de vrais visiteurs ou de traiter comme une panne ce qui relève d'une pression malveillante.
Panne technique possible
La dégradation apparaît sans hausse de trafic identifiable, après un changement, une saturation de stockage, une erreur applicative ou la défaillance d'une dépendance.
Pic légitime à confirmer
Une campagne, un événement ou une actualité peut produire une charge inhabituelle. Les parcours, les conversions et les sources restent alors compatibles avec de vrais visiteurs.
Qualification
Comprendre ce qui cède avant d'agir
Nous croisons les signaux vus en amont avec l'état du serveur, des conteneurs, du frontal web et de la base de données. L'objectif est de réduire l'attaque sans déplacer la saturation ni bloquer inutilement le trafic légitime.
- 01
Recueillir l'heure de début, les symptômes, les changements récents et les services touchés.
- 02
Comparer les événements Cloudflare, les journaux web et les métriques du serveur d'origine.
- 03
Identifier les routes ciblées, la nature du trafic et les ressources qui commencent à saturer.
- 04
Choisir des mesures réversibles, suivre leurs effets et contrôler les faux positifs.
Nous intervenons avec ou sans Cloudflare
La présence de Cloudflare accélère certaines actions, mais elle ne conditionne pas la prise en charge.
Protection existante
Cloudflare est déjà en place
Nous analysons les événements de sécurité et le comportement de l'infrastructure d'origine, puis nous adaptons les règles DDoS, le WAF, le rate limiting, les challenges et la mise en cache. La protection existante permet généralement d'intervenir plus rapidement, à condition que l'origine ne soit pas directement exposée.
Prise en charge directe
Cloudflare n'est pas encore en place
Nous commençons par stabiliser directement le serveur lorsque cela reste possible : filtrage local, limitation des requêtes, protection des chemins ciblés et réduction des traitements les plus coûteux. Si cette réponse ne suffit pas, nous pouvons mettre Cloudflare en place pendant l'incident et déplacer progressivement le trafic derrière sa protection.
Si l'adresse IP d'origine est déjà ciblée, nous étudions avec l'hébergeur la possibilité de neutraliser l'ancienne adresse et de basculer le service vers une nouvelle adresse. Nous vérifions également que cette nouvelle origine ne reste pas identifiable par le DNS, les sous-domaines, les services non protégés ou les messages envoyés par la plateforme.
Stabilisation
Protéger l'amont sans oublier le serveur et l'application
Une attaque HTTP/HTTPS peut viser un site web, une application SaaS, une API ou quelques routes particulièrement coûteuses. La mitigation combine alors filtrage et réduction des facteurs d'amplification sur l'origine.
✓
Configurer ou ajuster le WAF, le rate limiting, les challenges et les règles ciblées.
✓
Protéger les routes applicatives, API, recherches, authentifications ou pages dynamiques visées.
✓
Renforcer la mise en cache pour éviter des traitements applicatifs inutiles.
✓
Limiter localement les connexions et requêtes lorsque le serveur peut encore les traiter.
✓
Réduire la pression sur le serveur web, PHP, les conteneurs et la base de données.
✓
Superviser l'incident et adapter progressivement les mesures au trafic observé.
Protéger ou remplacer l'adresse IP d'origine
Une origine connue peut être attaquée directement et contourner le proxy. Nous recherchons les fuites possibles dans le DNS, les sous-domaines, les services accessibles en direct, les formulaires et les e-mails émis par la plateforme. Lorsque la bascule est possible, la nouvelle adresse est placée derrière la protection avant la neutralisation de l'ancienne avec l'hébergeur.
Coordonner le filtrage avec l'hébergeur
Nous intervenons sur la couche HTTP/HTTPS, l'application et les systèmes Linux. Si la liaison réseau est saturée ou si l'attaque relève d'un filtrage L3/L4 en amont, l'action doit être menée avec l'hébergeur ou l'opérateur. Nous coordonnons les éléments techniques utiles sans prétendre disposer de notre propre réseau de scrubbing.
Incident réel anonymisé
Une attaque applicative suivie pendant 15 h 30
Cette intervention passée a combiné l'analyse du trafic Cloudflare avec celle de l'origine, l'ajustement des règles de sécurité et la réduction des traitements coûteux sur le serveur. Ces chiffres décrivent ce cas précis, pas une capacité maximale ni une promesse de résultat.
Lire le retour d'expérience complet →- Durée suivie
- 15 h 30
- Requêtes mitigées
- 22,48 M
- IP distinctes observées
- ≈ 290 000
Après l'urgence, réduire le risque de récidive
La stabilisation ne doit pas laisser des règles temporaires, une origine exposée ou une application encore fragile. Nous documentons l'incident, organisons le retour à une posture normale et proposons uniquement les mesures durables justifiées par les observations.
Renfort technique après incident
Audit ciblé, optimisation, procédures, automatisation et accompagnement de votre équipe.
Exploitation et couverture durable
Supervision, maintenance, sauvegardes, traitement des incidents et astreinte selon le niveau de service.
Pour préparer la protection avant le prochain incident, consultez aussi notre analyse sur la protection anti-DDoS avec Cloudflare et un WAF piloté.
Questions fréquentes pendant une urgence DDoS
Que faire immédiatement pendant une attaque DDoS ?+
Évitez les changements non tracés, conservez les journaux disponibles et relevez l'heure de début, les services touchés et les symptômes. Contactez ensuite votre hébergeur et une équipe capable de corréler le trafic avec l'état réel du serveur.
Comment savoir s'il s'agit d'une attaque DDoS et non d'une panne ?+
Il faut comparer le trafic, les événements de sécurité, les journaux web et les métriques système. Une hausse brutale ou des routes répétitivement ciblées orientent vers une attaque, mais une panne ou un pic légitime peuvent produire des symptômes proches.
Pouvez-vous intervenir si Cloudflare n'est pas encore installé ?+
Oui. Nous commençons par stabiliser le serveur lorsque cela reste possible, puis nous pouvons placer le trafic derrière Cloudflare si une protection en amont devient nécessaire.
L'intervention est-elle plus rapide lorsque Cloudflare est déjà en place ?+
Une configuration existante permet généralement d'agir plus vite sur les règles et le trafic, à condition que l'adresse IP d'origine ne soit pas directement exposée et que les accès nécessaires soient disponibles.
Que faire si l'adresse IP réelle du serveur est déjà connue ?+
Nous vérifions si l'attaque contourne la protection et coordonnons avec l'hébergeur le filtrage ou la neutralisation de l'ancienne adresse. Une nouvelle origine doit ensuite rester masquée.
Peut-on changer l'adresse IP d'origine pendant l'attaque ?+
Oui, si l'architecture et l'hébergeur le permettent. La bascule doit être préparée pour limiter l'interruption et accompagnée d'une vérification du DNS, des sous-domaines et des services qui pourraient révéler la nouvelle adresse.
Qu'est-ce qu'un null route ?+
Un null route consiste à demander au réseau d'abandonner le trafic destiné à une adresse IP. Il peut protéger le reste de l'infrastructure, mais rend aussi le service associé inaccessible tant que cette mesure reste active.
Pouvez-vous protéger une API ou une application SaaS ?+
Oui. L'intervention peut cibler les endpoints, les méthodes, l'authentification, les clients techniques et les limites propres à une API ou à une application SaaS, sans appliquer une règle uniforme à tout le trafic.
Cloudflare suffit-il à arrêter toutes les attaques DDoS ?+
Non. Cloudflare apporte une protection importante en amont, mais il faut aussi masquer l'origine, adapter les règles, surveiller les faux positifs et corriger les traitements applicatifs qui amplifient la charge.
Quels accès faut-il fournir pour commencer l'analyse ?+
Selon le contexte, nous demandons des accès limités à Cloudflare, aux journaux, à la supervision et au serveur concerné. Le périmètre et les modalités sont définis lors de la première qualification.
Combien coûte une intervention DDoS urgente ?+
L'intervention est réalisée sur devis. Après une première qualification, nous présentons les actions envisageables, leur périmètre et leurs conditions avant la prise en charge.
Que se passe-t-il après la stabilisation du service ?+
Nous documentons l'incident, retirons ou adaptons les mesures temporaires et proposons les corrections durables utiles : protection de l'origine, supervision, procédures, optimisation ou couverture d'exploitation.
Votre service est attaqué maintenant ?
Appelez-nous pour une première qualification ou transmettez les informations techniques par le formulaire urgent. Cloudflare n'a pas besoin d'être déjà installé.
Intervention d'urgence sur devis, après qualification du périmètre et présentation des conditions de prise en charge.