Les attaques DDoS - DDoS pour Distributed Denial of Service - visent à rendre indisponible une ressource (un site web, un service, par extension cela peut être une application) - le plus souvent - en innondant cette ressource de requêtes non désirées avec une multitude de sources et/ou vecteurs d'attaque, d'où le terme Distributed.
Une attaque DoS a pour but de rendre une ressource indisponible mais avec un unique vecteur d'attaque, on peut voir les attaques de type DDoS comme un sous-ensemble des attaques DoS avec cette particularité d'avoir plusieurs sources innondant la ressource visée.
Dans cette vulgarisation, nous ferons abstraction du medium utilisé pour passer les commandes, que ce soit le téléphone, de la capacité à recevoir des appels, ou recevoir des commandes en direct au comptoir.
Cette vulgarisation a pour but unique de permettre à un public non-technique de mettre en exergue la difficulté à se protéger contre les attaques distribuées par rapport à une attaque par innondation de type non distribuée.
Imaginons que vous possédez une pizzéria, un concurrent a recemment ouvert et fait de l'ombre à votre activité commerciale, ce soir il y a OM - PSG. Pour vous assurer un bon chiffre d'affaire, ce soir vous optez pour le côté obscur.
Afin de déstabiliser l'activité de votre concurrent, vous appelez en vous faisant passer pour un réel client, vous dites que vous louez une salle diffusant le match, et vous passez commande à votre concurrent pour 100 pizzas à une adresse postale usurpée, dans le but d'innonder l'activité de votre concurrent.
Une fois débusqué, nul doute que ce concurrent décidera de blacklister votre numéro de téléphone.
Il va de soi qu'une telle manière d'agir sera aisée à débusquer, notamment avec le risque que votre concurrent refuse simplement d'honorer cette commande qu'il jugerait douteuse, n'ayant pas l'habitude d'être prévenu au dernier moment pour ce genre de commande à grosse quantité.
On observe alors facilement la limite d'une attaque DoS (avec simple source), comme en réseau, il est simple de détecter une simple source faisant un nombre de requête statistiquement anormalement élevé, on pourra aisément automatiser le fait d'interdire temporairement ou de manière permanante l'accès à notre ressource depuis une source donnée avec le pseudo-code suivant.
Avec source la source désirant accéder à la ressource, nombre_requetes(source) le nombre de requêtes par seconde depuis source, requetes_max_par_seconde_par_source le nombre maximum de requêtes par seconde par source désiré, et enfin Interdire_Acces(source) une fonction interdisant à source l'accès à notre ressource :
Si nombre_requetes(source) > requetes_max_par_seconde_par_source Alors
Interdire_Acces(source)
Fin Si
Cet algorithme est loin d'être parfait, mais reste néanmoins performant pour se prémunir des attaques DoS basique visant à innonder une ressource de requêtes non désirées venant d'une seule et même source.
En appliquant cela à notre histoire :
Si pizza_à_commander(client) > pizza_max_par_commande_par_client Alors
ignorer(client)
Fin Si
Une fois votre numéro de téléphone blacklisté par votre concurrent, vous décidez de changer de stratégie. Vous décidez donc de faire appel à 50 amis, en échange d'une pizza gratuite ultérieurement, vous leur demandez de passer chacun une fausse commande pour 2 pizzas chez votre concurrent, en prenant soin d'évoquer une adresse postale qui n'est pas la leur.
Et voilà, vous avez décliné votre attaque DoS en attaque DDoS, au lieu d'avoir 100 pizzas/numéro de téléphone, vous passez à 2 pizzas/numéro de téléphone, avec 50 personnes différentes qui passent fausse commande de 2 pizzas chacun, il y a bien 100 pizzas commandés, mais avec cette fois-ci une réelle difficulté de détecter qu'il s'agit de fausses commandes, qui douterait de la légitimité de commander 2 pizzas ?
On voit qu'il est impossible d'appliquer le même algorithme que celui utilisé pour contrer les attaques DoS, en effet, si l'on se contente de mettre un paramètre maximum de pizzas/numéro de téléphone, on voit bien qu'avec une valeur de 2 on va également interdire des commandes légitimes.
Votre concurrent peut tout de même espérer que vous ayez demandé à vos amis d'effectuer le même type de commande tel que :
- 1 calzone
- 1 margarita
Notons que toutes les commandes se ressemblent (chaque commande est toujours composée d'une calzone & d'une margarita),
Après quelques commandes refusées aux adresses données par vos amis, votre concurrent s'est aperçu que les fausses commandes avaient toutes ce même point commun, 1 calzone et 1 margarita (on appelle cela une faible entropie du fait de la faible diversité (ici nulle) de la nature des commandes), votre concurrent a décidé de bannir toute commande composée d'1 calzone et 1 margarita, même si cela va également bloquer des commandes légitimes, on se permet des faux positifs sur ces critères, afin d'assurer une meilleure disponibilité globale.
Si chacun de vos amis commande des pizzas différentes, et même, un nombre différent de pizza, on peut également penser à une chronologie d'énoncement de pizza différente, ce qui revient donc à avoir une grande entropie, il sera alors impossible de différencier les requêtes légitimes de celles de l'attaque en question.
On pourrait proposer comme contre-mesure (durant l'attaque uniquement) de :
- ne traiter que les commandes des clients ayant déjà commandés dans le passé
- On est quasiment sûr qu'ils feront des commandes légitimes, mais les nouveaux clients ne verront pas leur commande traitée
- regarder l'annuaire inversé lors d'un appel et espérer que les numéros appelants soient présents dedans afin d'avoir un point de vérification
- Une sorte de preuve d'association adresse postale/n° de téléphone, mais cela n'est pas toujours fiable/complet (liste rouge, listes non à jour), et demande un temps de traitement plus long car il faudra aller vérifier à la main si l'on n'a pas prévu de système pouvant effectuer cette tâche automatiquement
- faire payer les commandes avant la réception, en prenant les commandes via un site web par exemple
- Le coût de l'attaque augmente fortement, cela demande à être mis en place préalablement, sans compter le fait que certains clients vont sûrement finalement ne pas commander via ce medium finalement car souhaitant payer à la réception.
Bien sûr on peut imaginer d'autres solutions encore, mais le but restait de mettre en exergue la grande difficulté de se protéger des attaques DDoS par rapport aux attaques DoS.
En réseau, il reste très difficile de se protéger contre les attaques distribuées, et les possibilités de maximiser l'entropie est grande, il est très difficile et coûteux de mettre en place des filtres et méthodes d'analyses actives (pour tenter d'identifier et donc grouper en temps réel.