Les attaques par déni de service non distribuées peuvent être contrées en identifiant l'adresse IP de la machine émettant les attaques et en la bannissant au niveau du pare-feu ou du serveur. Les paquets IP provenant de la machine hostile sont dès lors rejetés sans être traités empêchant que le service du serveur ne soit saturé et ne se retrouve donc hors-ligne.
Les attaques par déni de service distribuées sont plus difficiles à contrer. Le principe même de l'attaque par déni de service distribuée est de diminuer les possibilités de stopper l'attaque. Celle-ci émanant de nombreuses machines hostiles aux adresses différentes bloquer les adresses IP limite l'attaque mais ne l'arrête pas. Thomas Longstaff de l'université de Carnegie Mellon explique à ce sujet que : « En réalité, la prévention doit plus porter sur le renforcement du niveau de sécurité des machines connectées au réseau [pour éviter qu'une machine puisse être compromise] que sur la protection des machines cibles [les serveurs Web] ».
Une architecture répartie, composée de plusieurs serveurs offrant le même service gérés de sorte que chaque client ne soit pris en charge que par l'un d'entre eux, permet de répartir les points d'accès aux services et offre, en situation d'attaque, un mode dégradé (ralentissement) souvent acceptable.
Selon les attaques il est également possible de mettre un serveur tampon qui filtre et nettoie le trafic. Ce serveur, « cleaning center » permet en cas d'attaques de faire en sorte que les requêtes malveillantes ne touchent pas le serveur visé.
L'utilisation de SYN cookies est également une solution envisageable pour éviter les attaques de type SYN flood, mais cette approche ne permet pas d'éviter la saturation de la bande passante du réseau.
Compte tenu des performances actuelles des serveurs et de la généralisation des techniques de répartition de charge et de haute disponibilité, il est quasiment impossible de provoquer un déni de service simple comme décrit dans le chapitre précédent. Il est donc souvent nécessaire de trouver un moyen d’appliquer un effet multiplicateur à l’attaque initiale.
Le principe est d’utiliser plusieurs sources (daemons) pour l’attaque et des maîtres (masters) qui les contrôlent.
Le pirate utilise des maîtres pour contrôler plus facilement les sources. En effet, il a besoin de se connecter (en TCP) aux maîtres pour configurer et préparer l’attaque. Les maîtres se contentent d’envoyer des commandes aux sources en UDP. S’il n’y avait pas les maîtres, le pirate serait obligé de se connecter à chaque source. La source de l’attaque serait détectée plus facilement et sa mise en place beaucoup plus longue. Chaque daemon et master discutent en échangeant des messages spécifiques selon l’outil utilisé. Ces communications peuvent même être cryptées et/ou authentifiées. Pour installer les daemons et les masters, le pirate utilise des failles connues (buffer overflow sur des services RPC, FTP ou autres).
L’attaque en elle-même est un SYN Flooding, UDP Flooding ou autre Smurf Attack. Le résultat d’un déni de service est donc de rendre un réseau inaccessible.
Les outils de DDoS (Distributed Denial of Service) les plus connus sont :
Logiciel | Types d'attaques |
---|---|
Trinoo | UDP flooding |
Tribe Flood Network (TFN) et TFN2k | UDP/TCP/TCP SYN flooding, Smurf |
Stacheldraht | UDP/TCP/TCP SYN flooding, Smurf |
Schaft | UDP/TCP/ICMP flooding |
MStreamT | CP ACK flooding |
L’inconvénient dans ce cas est la nécessité de travailler en deux temps :
A la deuxième étape le paquet de commande peut être bloqué par un outil de détection ou de filtrage. Par conséquent l’évolution consiste à automatiser le lancement des commandes dès la corruption des systèmes relais. Cette technique a été implémentée par CodeRed dont l’objectif était de faire connecter les serveurs corrompus au site Web de la maison blanche à une date précise... Dans le même ordre d’idées les DDoS basés sur les canaux IRC comme canaux de communication. L’objectif est ici non plus d’établir une connexion directe entre le maitre et les zombies, mais d’utiliser un serveur IRC (ou plutôt un canal) comme relais. Cette méthode, initiée en Juillet et Aout 2001 par Knight et Kaiten, présente de nombreux avantages.