Comprendre les attaques DDoS et comment s'en protéger

Bonjour 🙂,
Nous utilisons internet tous les jours, des quantités gigantesques de données transitent sur internet, tout cela est possible grâce au réseau, en lisant ces lignes, le contenu de cet article a transité sur le réseau pour arriver jusqu'à vous.

Parfois, il est possible d'abuser de ce réseau, et de faire ce qu'on appelle des attaques DDoS (attaque par déni de service), par exemple ici, le retour d’expérience sur une très grosse attaque.

Dans cet article, on va tenter d'expliquer le plus clairement possible comment fonctionne ce type d'attaque et quelles sont les solutions pour s'en protéger.

Internet, un réseau en couche

D'abord, il y a le modèle OSI, qui découpe le réseau en 7 couches, mais, nous n'allons pas utiliser ce modèle pour nos explications, mais maintenant, il y a plus simple, il y a le modèle TCP/IP, qui regroupe les couches du modèle OSI en seulement 4 couches, pour la compréhension de tous, ce sera plus simple.

Le modèle TCP/IP

Voici les couches de ce modèle :

• Couche application

  • Rôle : Correspond aux couches Session, Présentation et Application du modèle OSI. Gère les protocoles de haut niveau et certaines applications orientées utilisateur.
  • Exemples de protocoles: HTTP, FTP, SMTP, DNS, SNMP.
  • Exemples d'application serveur: Apache (HTTP), Nginx (HTTP), Postfix (SMTP), Bind9 (DNS).

• Couche transport

  • Rôle : Fourniture de services de communication entre les machines. Assure le contrôle de flux et la correction des erreurs.
  • Exemples de protocoles: TCP pour la communication orientée connexion (quand il est nécessaire au préalable de "créer" la connexion avant d'envoyer des données) et UDP pour la communication sans connexion (on envoie directement les données).

• Couche internet (ou couche réseau)

  • Rôle : Détermination du chemin optimal pour transmettre les paquets de données. Adressage, logique et fragmentation des paquets.
  • Exemples de protocoles: IP, ICMP, IGMP, OSPF, BGP.

• Couche accès au réseau (ou liaison et physique)

  • Rôle : Transmission des trames de données sur le réseau via différents médiums.
  • Exemple : Ethernet, Wi-Fi.

Gardez bien ces couches en têtes, cela nous sera utile pour la suite...

Les attaques sur la couche transport et la couche réseau

Je mets ces couches ensemble, car globalement les principes de bases de ces attaques sont les mêmes.
Que ce soit une attaque avec ICMP (couche réseau) ou une attaque avec UDP (couche transport), le principe est toujours le même, envoyer tout un tas de données inutile a une machine cible afin de saturer sa bande passante et qu'elle ne soit plus accessible aux autres, et il est possible de faire en sorte que l'attaque vienne de plusieurs machines, c'est une "attaque distribuée".

Spécificité de l'attaque ICMP

L'ICMP, c'est plus communément appelé le "ping", c'est un protocole qui permet de tester la connexion entre deux machines, donc, une machine envoie une requête et l'autre lui envoie une réponse pour dire "je suis là", donc, cela sature la bande passante dans les deux sens.

Le propriétaire de la machine cible peut par exemple mitiger cette attaque en désactivant la réponse au « ping », ce qui fait que cette machine ne sera pas saturée sur la bande passante sortante, mais uniquement entrante, après, cela ne règle pas le problème, mais la réponse étant une spécificité de l'ICMP, il est intéressant de le noter

Spécificité de l'attaque avec UDP

L'UDP est très violent, et ce pour plusieurs raisons :

• UDP est un protocole qui ne nécessite pas d'établir de connexion au préalable, donc, il est possible d'envoyer des données sans avoir besoin de créer une connexion avec la cible, peu importe que la cible le veuille ou non, elle devrait forcément traiter ces données inutiles, elle ne peut pas dire "non".

• L'amplification : Du fait du design d'UDP, il n'y a pas de vérification de la source, cela veut dire que l'on peut parfaitement créer un « paquet de données » avec comme adresse IP de réponse l'adresse IP de la cible, et donc, la cible va recevoir des données qu'elle n'a pas demandées

  Cas concret :
  Un attaquant disposant de beaucoup de bande passante utilise le protocole applicatif DNS, il utilise un ou plusieurs serveurs pour demander une information bien lourde à un serveur DNS, mais dans sa demande, il dit répond à "Adresse IP de la cible".
  Imaginons que sa demande initiale soit d'une taille de 10 kilo-octets octets, et que la réponse, soit de 100 kilo-octets, il aura alors multiplié sa bande passante par 10.
  Maintenant, en prenant en compte du multiplicateur, il suffit d'envoyer des millions de requêtes DNS à des serveurs DNS vulnérables (qui n'ont pas de "rate limiting") et ce sera ces serveurs DNS qui satureront la cible de données inutile.

Comment se protéger de ces attaques ? (UDP et ICMP)

Nous allons rester simples et basiques afin de ne perdre personne 🙂.

Puisque ce type d’attaques se résument simplement à saturer la connexion de la cible, il suffit que la cible ait une plus grosse capacité que l'attaquant, c'est ce que fait Cloudflare par exemple, ils ont plusieurs « datacenter » partout dans le monde et leur bande passante totale s'élève à plus de 209 Tera-bits par seconde.
Et vu que leur serveur se place entre les utilisateurs et les serveurs qui hébergent réellement l'application, il faut donc à l'attaquant autant de bande passante disponible que ce Cloudflare peut encaisser.
Cela ne vaut que si l'adresse IP du serveur qui héberge réellement l'application est bien cachée et ne fuite pas.

Le SYN flood

Cela consiste à envoyer un grand nombre de requêtes SYN à un serveur, c'est la requête qui est la première étape d'une connexion TCP, donc, le serveur va répondre avec un SYN-ACK, mais comme l'attaquant ne va pas envoyer de ACK (ce qui valide l'ouverture de connexion pour le client, cela force le serveur a garder la connexion ouverte, et donc, mobilise des ressources inutilement.
Une fois que l'ensemble des ports (les ports d'envoi et non les ports d’écoute) du serveur sont occupés, il ne peut plus fonctionner comme il le devrait.

Comment se protéger du SYN flood ?

Dans le cas de Cloudflare, encore une fois, vu qu'ils se mettent entre l'attaquant et vos serveurs, la requête de l'attaquant part dans leurs centres de données et vu le nombre de serveurs qu'ils ont, bonne chance pour tout saturer.
Et de votre côté, pour vous protéger vous pouvez configurer votre serveur pour qu'une fois que votre serveur est saturé de connexion "semi-ouverte" il écrase la plus ancienne avec une nouvelle, ainsi, l'attaquant ne peut pas bloquer complètement votre serveur.
Il y a d'autres solutions, que je ne détaillerais pas plus ici, car elles ont toutes des inconvénients, même celle que je viens de vous proposer a des inconvénients, mais c'est la « moins contraignante ».

Les attaques sur la couche application

Ici, on arrive dans quelque chose de plus sophistiqué, on ne cherche pas à saturer la bande passante ou exploiter les protocoles, l'idée ici est d'exploiter des logiciels ou la configuration de ceux-ci pour faire "tomber" un service.

PHP-FPM

Comme premier exemple, on peut prendre PHP-FPM, c'est le module PHP qui est souvent utilisé avec NGINX, son travail comme vous vous en doutez est d'interpréter le PHP (pour les non-initiés, PHP est un langage de programmation).

Dans sa config par défaut, PHP-FPM, a une limitation, au bou d'un certain nombre de requêtes, quand il n'arrive plus a traité tout cela, il va simplement s'arrêter et donc, le service proposé par le serveur va s’arrêter.

Du coup, vous l'aurez compris, dans ce cas présent, il suffit d'envoyer énormément de requêtes HTTP simples et au bout d'un moment, quand vous aurez dépassé la limite de PHP-FPM, le service tombera.

Comment se protéger des attaques au niveau applicatif ?

Dans le cas de Cloudflare, encore une fois, ils ont ce qu'il faut, vu qu'il se situe entre l'attaquant et vos serveurs, quand ils ont un doute sur la légitimité de requête, ils peuvent simplement les filtrer en présentant un « captcha » (quelque chose à faire résoudre par un humain), les attaques qui visent l'applicatif peuvent atteindre vos serveurs (contrairement aux attaques via le protocole énoncées précédemment), c'est à vous de bien configurer le "WAF" (Web Application Firewall)".

Si vous n'utilisez pas Cloudflare, vous devez faire attention à « comment sont écrites vos applications, et comment sont configurés leurs environnements », par exemple plutôt que d'envoyer chaque requête à PHP, vous pouvez mettre un proxy de cache avant votre "back-end" tel que Varnish, il ne fait que se contenter de redonner la même réponse à chaque requête et du coup est très léger.

Vous pouvez également utiliser le "rate limiting" de serveur comme NGINX, qui permet de limiter le nombre de requêtes par seconde par IP, car bon qui fait plus de 30 requêtes par seconde depuis la même adresse IP ? (hormis dans les cas spécifique)

Enfin, vous pouvez aller encore plus loin, en faisant un mix, par exemple, a la première requête d'un utilisateur, celle-ci est forcément prise en charge par le cache Varnish, et lors de la visite de la page, un cookie est généré dans son navigateur, ce cookie et la clef lui permettant d'accéder à des pages réellement générées par le black, car les scripts de DDoS classique cherchant à faire tomber un service sont généralement incapable de gérer les cookies, ce sont de simple programmer qui envoie une simple requête HTTP en chaine.

Conclusion

Cet article n'a pas la vocation à être "la référence" sur le sujet, j'ai essayé, de le rendre simple possible 😁.
Passez une très bonne semaine et à la prochaine.