Un blog associatif tombe. Pas de concurrent, pas de données bancaires. L'administrateur reçoit un email : « 0,5 BTC et ça s'arrête ». Le VPS à six euros par mois sature en bande passante ; l'hébergeur coupe le serveur pour protéger le réseau. Le petit site était une cible — parce qu'il était facile, pas parce qu'il était riche.
Une attaque par déni de service distribué noie un service sous un trafic inutile. Les petits sites croient être invisibles. Ils le sont moins qu'ils ne le pensent : adresse IP connue, stack WordPress standard, absence de marge de sécurité.
Pourquoi un petit site se retrouve visé
| Motif | Mécanisme |
|---|---|
| Extorsion | Email plus flood jusqu'au paiement |
| Conflit personnel | Forum, politique, gaming |
| Collatéral | Même plage IP qu'une autre cible |
| Scan botnet | Exploit puis flood de test |
| Concurrence locale | Rare mais documenté |
Être petit ne immunise pas. Ça réduit parfois l'intérêt — pas la probabilité d'un scan automatisé.
Où la fragilité se cache
Un VPS d'entrée de gamme offre souvent cent mégabits par seconde ou moins, avec un noyau sensible aux floods SYN. Sur le mutualisé, un voisin attaqué ralentit tout le monde ; l'adresse IP partagée peut être blacklistée — voir notre enquête sur les IP partagées. Sans CDN, l'origine est exposée directement. Une API lourde — une route de recherche coûteuse — amplifie les attaques de couche 7. Des formulaires sans captcha ajoutent spam et charge.
Défense proportionnée pour un budget modeste
Placez un CDN ou proxy devant l'origine — Cloudflare, ou l'anti-DDoS réseau de l'hébergeur (VAC OVHcloud, etc.). Configurez le rate limiting via nginx, règles CDN ou fail2ban modeste. Appliquez un cache agressif sur le statique pour que l'origine respire — voir CDN premier usage. Désactivez XML-RPC WordPress si inutile. Mettez en place un monitoring : trafic anormal, pic de 502, bande passante. Préparez un plan incident : qui bascule le proxy, qui contacte l'hébergeur.
La protection enterprise n'est pas requise pour la plupart des petits sites ; éviter l'exposition de l'origine l'est.
Signaux d'alerte avant la saturation
Un trafic HTTP multiplié par dix en dix minutes sans campagne marketing. Pic de requêtes sur une seule URL (/xmlrpc.php, /wp-login.php). Bande passante sortante plate à 100 % sur le panel hébergeur. Emails d'extorsion reçus la veille. Ces signaux précèdent souvent la coupure brutale par l'hébergeur pour protéger le réseau mutualisé — mieux vaut activer le proxy avant la coupure que négocier une remise en service d'urgence. Documentez aussi qui a accès au panel CDN et qui peut basculer le mode « under attack » — en pleine attaque, chercher les identifiants perds des minutes précieuses.
Pendant l'attaque : ordre utile
Confirmez d'abord qu'il s'agit bien d'une attaque DDoS et non d'un pic légitime (soldes, contenu viral). Activez le proxy orange ou le CDN si disponible. Passez en mode challenge ou « under attack » temporairement. Alertez l'hébergeur — une mitigation réseau est parfois possible. Ne redémarrez pas en boucle sans diagnostic. Documentez les journaux ; déposez plainte en cas d'extorsion.
Le sommet : payer ne garantit rien
Les petits sites sous-estiment surtout le coût indirect : réputation, référencement en panne, support client submergé — pas seulement la facture d'infrastructure.
Décider et avancer sans angle mort
Masquez l'origine via CDN dès le départ, pas après la première attaque. Lisez le SLA anti-DDoS de l'hébergeur avant signature. Configurez rate limiting et cache sur les routes coûteuses. Préparez les contacts incident (hébergeur, CDN, responsable technique). Comparez les offres via l'annuaire et notre guide WAF site web.
Questions fréquentes
Pourquoi attaquer un petit site sans valeur ?
Les motifs varient : vendetta, rançon, diversion, cible opportuniste, test de botnet. La taille du site importe moins que sa vulnérabilité.
Mon hébergeur mutualisé protège-t-il des DDoS ?
Souvent une mitigation basique existe, mais un voisin saturé peut vous impacter. Lisez le SLA et les exclusions.
Cloudflare gratuit suffit-il ?
Souvent oui pour le volumétrique ; les attaques de couche 7 sophistiquées exigent parfois un plan payant.
Que faire pendant l'attaque ?
Activez le proxy CDN, limitez le débit, contactez l'hébergeur, documentez. Ne payez pas de rançon sans stratégie juridique.
Un petit site peut être une cible DDoS parce qu'il est atteignable — pas parce qu'il est important. Réduisez l'exposition avant d'en devenir la preuve.