Le déni de service

1. Le déni de service, qu'est-ce que c'est ?

Une attaque par déni de service, ou DoS attack (Denial of Service attack), est un moyen pour un attaquant de rendre indisponible un service. Cela empêche les utilisateurs d'accéder à leurs outils ou même simplement à leur site préféré, pouvant créer des retombées économiques importantes pour l'entreprise ciblée. En effet, on peut noter la première grande attaque de déni de service en février 2000 qui a touché Yahoo!, rendant son site inaccessible pendant trois heures, et ayant eu un coût estimé à près de 500 000 dollars.

On comprend alors très vite que ce type d'attaque peut être dévastateur pour des entreprises, même pour de très grands groupes, qui perdraient alors de nombreux revenus et clients si une indisponibilité de leurs services venait à perdurer.

2. Le déni de service, comment ça marche ?

Il existe plusieurs façons de réaliser une attaque par déni de service. De manière générale, l'objectif est de remplir la mémoire de la machine ciblée jusqu'à ce qu'elle plante ou encore de congestionner le réseau pour saturer la bande passante.

L'attaque SYN Flood

Cette attaque repose sur un principe simple : le fonctionnement même du protocole TCP. En effet, lors de l'établissement d'une liaison TCP entre deux machines, un handshake est effectué. Ce handshake se déroule comme suit :

On peut observer que ce handshake, ou three way handshake, se déroule d'abord par l'envoi d'un flag SYN, suivi d'une réponse SYN-ACK puis d'une réponse finale ACK du client pour confirmer la connexion. Or, c'est là que tout se joue. En effet, si l'on débute une connexion en envoyant un flag SYN au serveur, celui-ci va répondre SYN-ACK et garder en mémoire qu'il attend une réponse du client, ce qu'il n'obtiendra jamais.

Évidemment, il existe un timeout qui fera sauter cette connexion entrante si elle ne se termine pas au bout d'un certain temps. Cependant, en envoyant plus de requêtes SYN que le serveur n'est capable de gérer, on surcharge sa mémoire et le serveur plante sous l'inondation de messages SYN, d'où son nom SYN Flood.

Aussi, pour réaliser cette attaque, il est nécessaire d'envoyer des paquets depuis différentes IP, car le serveur ne peut réaliser qu'une seule connexion par IP. Pour ce faire, il est possible d'utiliser de l'IP spoofing, c'est-à-dire de changer l'IP source du paquet envoyé par une autre IP, ce qui n'est pas dérangeant pour l'attaquant vu qu'il ne souhaite de toute façon pas établir de connexion avec le serveur.

De plus, pour maintenir un haut débit d'envoi au serveur ciblé, il est possible de réaliser une attaque DDoS - pour Distributed Denial of Service - grâce à la prise en main de machines vulnérables exposées sur internet. Ces machines compromises forment ainsi un botnet et permettent à l'attaquant d'obtenir un débit important d'envoi de SYN à la machine ciblée, ce qui la fait planter.

Attaque par UDP Flooding

L'UDP Flooding utilise une technique différente de celle du SYN Flooding. En effet, cette attaque utilise le protocole UDP et non plus TCP, ce qui implique que les échanges avec la cible s'effectuent sans connexion. Cela implique aussi qu'en plus d'une surcharge de mémoire, une surcharge du réseau est aussi effectuée.

Pour réaliser cette attaque, un attaquant fait communiquer deux machines entre elles grâce aux services chargen (port 19) et echo (port 7). Le service chargen permet de générer des données, tandis que le service echo permet de réémettre les données reçues. L'attaquant n'a plus qu'à envoyer des paquets UDP sur le port 19 à l'une des machines en réalisant de l'IP spoofing avec l'IP de la deuxième machine et son port echo (port 7). Ainsi, la machine 1 va générer des paquets puis les envoyer à la machine 2, qui va les renvoyer à la machine 1, qui va encore générer des paquets pour les envoyer à la machine 2, etc. Cela crée une boucle infinie qui surcharge le réseau ainsi que les ressources des machines et qui ne s'arrêtera que lorsque le réseau sera neutralisé ou lorsqu'une des machines plantera suite à l'attaque.

3. Le déni de service, comment s'en protéger ?

Comme expliqué auparavant, une attaque par déni de service peut être simple, provenant d'une seule machine, ou distribuée, provenant d'un botnet. La protection contre chacune de ces attaques peut varier, avec des solutions plus performantes que d'autres. Il faut cependant comprendre que la protection contre ce type d'attaques est difficile mais que certaines petites actions peuvent déjà apporter une protection minimales aux machines.

Le filtrage d'adresses IP, bonne idée?

La première idée qui peut nous venir en tête serait de bannir les IP qui envoient des paquets pour surcharger les machines et le réseau. Cependant, comme vu précédemment, réaliser de l'IP spoofing est très facile pour un attaquant et bannir des IP aléatoires ne règle malheureusement pas le problème.

Les SYN Cookies

Une seconde idée serait d'activer les SYN Cookies. Ces derniers sont des numéros de séquences initiales (ISN) particuliers qui permettent de se protéger en partie des attaques par SYN Flooding. En effet, ces SYN Cookies permettent au serveur d'arrêter les différentes connexions en cours de handshake lorsqu'une certaine limite est atteinte. Lors de cet arrêt, le serveur envoie un paquet SYN-ACK au client ; si ce dernier répond avec un ACK, la connexion semi-ouverte sera reconstruite et la communication avec le client sera autorisée. Ces SYN Cookies ne s'activent que lorsque la machine reçoit trop de connexions semi-ouvertes.

Activation des SYN Cookies

Sur Linux

Pour activer les SYN Cookies sur le kernel il faut faire : sysctl -w net.ipv4.tcp_syncookies=1

Pour activer les SYN Cookies à chaque redémarrage il faut éditer le fichier /etc/sysctl.conf comme suit : net.ipv4.tcp_syncookies = 1

Il est aussi recommandé d'augmenter la backlog queue à 2048 : sysctl -w net.ipv4.tcp_max_syn_backlog=2048

De même, pour modifier cette option à chaque redémarrage il faut éditer le fichier /etc/sysctl.conf : net.ipv4.tcp_max_syn_backlog=2048

Sur Windows

Pour activer cette protection sur des serveurs Windows 2000 et 2003 il faut changer les clés de registre suivantes dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Par :

• SynAttackProtect à 2
• TcpMaxPortsExhausted à 5
• TcpMaxHalfOpen à 500
• TcpMaxHalfOpenRetried à 400
• TcpMaxConnectResponseRetransmissions à 2
• TcpMaxDataRetransmissions à 2
• EnablePMTUDiscovery à 0
• KeepAliveTime à 300000

Cette protection est activée par défaut à partir de Windows 2008 / 7.

Inconvénients

Les principaux inconvénients des SYN Cookies sont la perte d'informations qu'ils apportent, des coûts de calculs plus importants, l'absence de retransmission des paquets SYN-ACK ainsi que l'apparition d'une autre attaque. Cette dernière consiste pour un attaquant à inonder le serveur de requêtes SYN (SYN Flooding) pour que le serveur passe à l'utilisation des SYN Cookies, puis à inonder le serveur de paquets ACK contenant des numéros de séquence aléatoires, en espérant obtenir un SYN Cookie valide, avec une chance de (1/2)^24, ce qui nécessite un débit de 85Mb/s pour falsifier une connexion par minute. De plus, même si l'attaquant ne cherche pas à falsifier une connexion, il va accroître considérablement l'utilisation du processeur pour la validation des SYN Cookies ainsi que consommer une grosse partie de la bande passante du réseau.

Cette protection est donc efficace contre des attaques par SYN Flooding relativement petites, les attaques trop importantes feront planter la machine de toute façon à cause de la validation des SYN Cookies.

Protection contre les attaques par UDP Flooding

L'objectif de cette protection est d'éviter de devenir une victime ou un amplificateur pour l'attaque.

La première solution à mettre en place est le filtrage réseau au niveau du routeur. En effet, il faut créer des filtres pour empêcher les paquets provenant d'une IP source qui n'est pas supposée envoyer des paquets. Il est aussi possible de préciser quelles adresses IP ont le droit d'être l'adresse source d'un paquet.

Une seconde solution, sûrement la plus facile à mettre en oeuvre, est la désactivation des services UDP entre les ports 1 et 19 s'ils ne sont pas utilisés.

Sur Windows

Dans l'onglet Network Control Panel sur Windows, il faut désactiver Simple TCP Services, cela désactivera echo, chargen, ainsi que d'autres services inutilisés tels que daytime, discard et qotd.

Sur Linux

Il faut éditer le fichier inetd.conf sur Linux et commenter les services echo, chargen, ainsi que daytime, discard et qotd. Il faut ensuite redémarrer le daemon inetd et vérifier que les changements ont bien été pris en compte avec netstat.

Inconvénients

La mise en place d'un filtrage réseau peut être complexe et demande une connaissance importante de l'infrastructure à protéger.

Pour ce qui est de la désactivation des services UDP entre les ports 1 et 19 par des filtres réseau, cela peut poser des problèmes de performances au niveau du réseau. En effet, cela requiert une liste d'accès étendue et donc cela demande au routeur de regarder précisément l'IP et le port de destination du header de chaque paquet, ce qui augmente la surcharge réseau.

Conclusion

Les attaques par déni de service peuvent affecter de nombreuses entreprises, causant certes des dommages sur le court terme, mais pouvant entacher la réputation de l'entreprise touchée, tout en lui faisant perdre une partie de ses bénéfices.

Ainsi, il est important d'être préparé face à ces attaques. Bien qu'il ne semble pas possible d'entièrement contrer ces dernières sans couper directement le service attaqué (ce qui semblerait contre-productif vu que l'objectif du DoS est de couper ce service), des protections existent et permettent de limiter les risques.

Par ailleurs, à titre d'information, AlgoSecure ne procède pas à des dénis de service lors de ses pentests.

Sources :

• Analysis of the SYN Flood DoS Attack, Mitko Bogdanoski, Tomislav Shuminoski and Aleksandar Risteski, 2013 (https://www.researchgate.net/publication/237076791_Analysis_of_the_SYN_flood_DoS_attack)
• Incident Handling and Hacker Exploits, Certification Practical, version 1.5c, Tamara Bowman, Avril 2001 (https://www.giac.org/paper/gcih/206/udp-flood-denial-service/101057)