Qu'est-ce que la protection contre le déni de service (DoS) ?

Qu'est-ce que la protection contre le déni de service (DoS) ?

La protection DoS est l'ensemble des mesures qui maintiennent un service accessible pendant que quelqu'un tente d'épuiser sa bande passante, ses connexions ou sa puissance de calcul. Elle combine filtrage en bordure de réseau, limites de débit, cache, configuration durcie et plan de réponse. L'objectif n'est pas d'empêcher la tentative, ce qui est impossible, mais de continuer à servir les utilisateurs légitimes pendant qu'elle se produit.

Comment fonctionne une attaque DoS

Une attaque par déni de service inonde une cible de trafic ou de requêtes pour que les utilisateurs légitimes ne puissent plus entrer. L'agence américaine CISA la décrit comme une situation où des utilisateurs légitimes ne peuvent plus accéder à des systèmes d'information, à des appareils ou à d'autres ressources réseau. Avec une seule source, c'est une attaque DoS ; quand de nombreuses machines, souvent un botnet d'appareils détournés, attaquent ensemble, c'est une attaque par déni de service distribué (DDoS). La forme distribuée est plus puissante et plus difficile à remonter jusqu'à sa source.

Les trois endroits que vise une attaque

• La bande passante. Les inondations volumétriques, comme une inondation UDP, saturent le lien et plus rien ne passe.
• L'état des connexions. Une inondation SYN ouvre des connexions TCP à moitié établies jusqu'à ce que le serveur n'ait plus de place pour les vraies. La RFC 4987 énumère les parades, dont les SYN cookies, et ce que coûte chacune.
• Le travail applicatif. Des requêtes d'apparence normale mais coûteuses, comme une recherche ou une connexion, peuvent épuiser le processeur ou la base de données avec peu de bande passante. Voir les attaques DDoS au niveau applicatif.

Comment la protection DoS s'organise en couches

• Réseau de bordure ou service de nettoyage du trafic. Un CDN ou un service de protection DoS repère le trafic anormal et le filtre avant qu'il n'atteigne votre serveur d'origine. C'est la première recommandation de la CISA.
• Pare-feu et limites de débit. Rejetez le trafic que vous n'attendez jamais et plafonnez les requêtes par client, plus strictement sur les points d'accès coûteux. Fixez les seuils d'après l'usage mesuré, car de nombreux utilisateurs peuvent partager une même adresse IP.
• Cache. Chaque réponse servie depuis la bordure est un travail que l'origine n'a pas à faire.
• Surface d'attaque réduite. Gardez l'adresse de l'origine privée, fermez les ports inutilisés et appliquez les correctifs.
• Capacité de réserve et alertes. L'autoscaling fait gagner du temps, mais il fait aussi grimper la facture. Associez-le à des alertes et à des plafonds de dépense.
• Un plan de réponse. Décidez qui confirme une attaque, qui appelle le fournisseur ou le FAI et qui informe les clients. La CISA avertit aussi qu'une attaque peut servir de diversion pendant qu'autre chose se passe sur votre réseau.

Pour le guide complet, lisez comment arrêter les attaques DDoS.

Exemple : un point de connexion sous pression

La page de connexion d'un SaaS se met à expirer. La bande passante est normale, mais la base de données est saturée et les logs montrent des milliers de tentatives de connexion par minute depuis de nombreuses adresses. La réponse est en couches : une limite de débit sur le chemin de connexion, un défi pour les clients qui la dépassent, des pages statiques en cache qui ne coûtent presque rien et une alerte sur le débit de requêtes par chemin, pour repérer la prochaine vague en quelques minutes plutôt qu'après les plaintes des clients.

Erreurs fréquentes

• Ne protéger que l'origine. Un serveur ou un lien peut être saturé, la bordure doit donc passer en premier.
• Aucune référence du trafic normal. Sans les débits habituels, impossible de distinguer une attaque d'une promotion ou d'une publication virale. La RFC 4732 souligne que les afflux légitimes peuvent ressembler à une attaque.
• Des limites qui bloquent de vrais utilisateurs. Des blocages ou listes noires trop agressifs peuvent provoquer la panne eux-mêmes.
• Chercher de l'aide en pleine attaque. Souscrire chez un fournisseur pendant un incident prend du temps. Ayez contrats, accès DNS et contacts prêts.
• N'y voir qu'un problème réseau. Les requêtes qui ressemblent à celles d'utilisateurs normaux traversent sans peine les filtres réseau.

Protection DoS, tests de charge et supervision

LoadFocus n'est pas un produit de protection DoS ni de sécurité, et il ne simule pas d'attaques. Il peut en revanche montrer quel trafic légitime votre propre système supporte avant de ralentir ou de tomber. Les tests de charge envoient des requêtes HTTP vers votre propre site ou API depuis des régions cloud : vous voyez où la latence grimpe, si vos limites répondent bien par un 429 et si l'autoscaling réagit à temps. Commencez par load testing vs stress testing et causes du rate limiting des API (en anglais).

Ne testez que des systèmes qui vous appartiennent ou pour lesquels vous avez une autorisation écrite, et prévenez votre CDN ou fournisseur cloud avant toute exécution à fort volume. Ensuite, la supervision d'API avec alertes sur les erreurs et le temps de réponse est souvent le premier signal externe qu'un problème survient ; les vérifications gratuites s'exécutent toutes les 5 minutes.

Questions fréquentes sur la protection DoS

Quelle différence entre protection DoS et DDoS ?

Les défenses se recoupent. Un DoS issu d'une seule source peut souvent être stoppé par une règle de pare-feu ou une limite de débit ; un DDoS vient de milliers de sources et exige un réseau de bordure ou un service de nettoyage plus dimensionné que l'attaque.

Peut-on empêcher totalement les attaques DoS ?

Non. La CISA rappelle qu'il n'existe aucun moyen d'éviter complètement de devenir une cible. On réduit l'impact et on rétablit plus vite le service.

Comment savoir si je subis une attaque DoS ?

Les signes typiques sont un site lent ou inaccessible, une hausse des requêtes ou des erreurs et un trafic venu de sources inhabituelles. Cela peut aussi venir d'une panne technique ou d'un pic légitime : vérifiez les logs de trafic et interrogez votre équipe réseau ou votre FAI.

Un CDN protège-t-il contre les attaques DoS ?

Il absorbe en bordure une bonne part du trafic volumétrique et du contenu en cache. Les inondations au niveau applicatif demandent en plus des règles de pare-feu et des limites adaptées à votre trafic.

Un test de charge peut-il remplacer la protection DoS ?

Non. Un test de charge montre comment votre propre système se comporte sous un fort trafic légitime. Il n'arrête aucune attaque et ne remplace pas la protection en bordure.