Test DDoS

Objectifs

Test DDoS

Cette prestation simule une attaque basée principalement sur l'inondation du réseau afin de saturer les ressources associées aux services externes.

Durant ce type d'audit, divers indicateurs pourront être évalués : disponibilité des services, réactivité des équipes techniques ou encore résistance des équipements frontaux.

Les tests techniques réalisés simulent également un flux de visiteurs important lors d'un pic d'activité, le dimensionnement de l'infrastructure pourra ainsi également être évalué.

Demande d'informations

Méthodologies

La méthodologie employée pour les tests de déni de service a été élaborée par les équipes techniques de Sysdream afin de mettre à l'épreuve l'architecture cible dans des conditions les plus réelles possibles.

En amont, nous définissons avec nos clients les scénarios les plus judicieux et les plus adaptés aux cibles d'évaluation pour dresser un planning du déroulement de l'audit.

Nous bénéficions d’un partenariat avec un hébergeur de renom, ce qui nous permet de constituer un botnet (réseau de machines d’attaque) de taille conséquente et d’atteindre des débits significatifs. La constitution du réseau d’attaque représente la clé de voûte pour le bon déroulement de la prestation, c’est pourquoi nous effectuons de nombreux tests fonctionnels pour maximiser la précision de celle-ci.

Après réalisation des préparatifs techniques, une réunion d'initialisation est programmée : celle-ci permettra de valider les derniers réglages avant le lancement des tests. Pendant toute la durée de la prestation, nous maintenons un canal de communication afin de dimensionner « à chaud » les attaques déroulées et d'assurer une adaptation rapide en cas de perturbation importante.

Nos scenarios

Inondation de trafic IP et UDP

Génération de plusieurs Gbps de trafic composé de paquets IP et/ou UDP.

Inondation de paquets

Génération de centaines de kpps à quelques Mpps en variant la taille et le type de paquets.

Saturation de sessions TCP / HTTP / HTTPS (Slow Loris)

Maintien de connexions TCP, HTTP, HTTPS ouvertes afin de saturer le nombre de connexion pouvant être proposé par le service HTTP cible.

Inondation de requêtes HTTP

Génération de requêtes HTTP de façon massive et ciblée afin de saturer le service HTTP cible.

Inondation de paquets TCP SYN

Génération de paquets SYN ayant pour objectif de maintenir des connexions semi ouvertes du côté serveur.


Livrables

La livrable présente les différentes phases menées par nos équipes techniques lors des tests ainsi que résultats obtenus. Y sera notamment présente une synthèse générale, chargée de restituer une évaluation globale sur la sécurité du réseau audité. Les points névralgiques nécessitant une intervention urgente seront mis en exergue dans cette section.

Une analyse globale à destination des décideurs sera rédigée : celle-ci fera notamment une énumération des machines détectées, des services actifs ainsi que toute autre information technique associée jugée pertinente. Chaque service et chaque machine reçoit une évaluation de sécurité individuellement, ce qui permettra aux décideurs de concevoir un plan d’action de manière efficace.

La dimension technique est restituée en rappelant en tout premier lieu les différents scénarios élaborés dans le cadre de la prestation. Seront notamment identifiées la/les couche(s) visée(s) par chaque scénario.
Le déroulement de chaque scénario est restitué le plus fidèlement possible, en incluant l’horodatage ainsi que la réactivité des équipes de maintenance.
D’une manière plus générale, toute information technique permettant une meilleure compréhension des attaques et des résultats est fournie. En cas de succès d’une attaque, une ou plusieurs recommandations adaptées sont émises.

Des recommandations génériques concernant la politique de management de la sécurité informatique à adopter sont finalement délivrées.


Cas d'études

Une société de vente en ligne a récemment subi d’importantes pertes financières et pour cause : la plateforme d’achat en ligne proposée par la société n’a pas su délivrer de service à tous les clients en période de soldes. Cette dernière a en effet subi d’importants dysfonctionnements à cause d’un nombre de visiteurs supérieurs à la limite théoriquement acceptable par la couche matérielle.

La société en question a réalisé des investissements dans des équipements de résorption et a formé ses équipes techniques afin d’assurer la disponibilité des services lorsque le trafic réseau s’intensifie. Désireuse de ne pas subir de nouvelles pertes, elle fait appel à nos services afin d’évaluer la résistance de son infrastructure.

Une première discussion a lieu avec nos équipes techniques afin de préciser les cibles d’évaluation et les services associés. Nous proposons au vu des services en jeu et des contraintes de production plusieurs scénarios :

Inondation de requêtes HTTP

Après une rapide analyse du comportement de la plateforme applicative, nous constatons que celle-ci repose majoritairement sur une architecture de type REST. Cela signifie que chaque requête émise par un client contient toutes les informations relatives à sa session, augmentant de fait la bande passante consommée ainsi que la quantité de données à traiter par le serveur. Ce scénario consistera donc en l’envoi massif de requêtes HTTP de type GET/POST avec des en-têtes et/ou des corps de taille conséquente.

Inondation de requêtes HTTP aléatoires

La plateforme applicative communiquant avec le protocole HTTP, nous suggérons l’envoi de requêtes HTTP « personnalisées » et de taille conséquente. Ces dernières ne respecteront dans les faits plus les normes qui encadrent le protocole, avec notamment des en-têtes et des méthodes composées de données pseudo-aléatoires. Le but de scénario est de tester la robustesse du serveur HTTP face à des requêtes émises dans un langage qu’il n’est pas censé pouvoir traiter ou nécessitant un temps de traitement plus long.

Saturation de sessions HTTP

Ce scénario est une instance d’un type de déni de service appelé « Slow Loris ». Le principe est d’ouvrir de multiples sessions HTTP jusqu’à ce que le serveur ait atteint le maximum de sessions pouvant être gérées simultanément. Ceci est réalisé en envoyant des requêtes incomplètes et de temps à autres des en-têtes chargés de maintenir la connexion ouverte. De nombreux réseaux de zombies utilisent ce type d’attaque, car de nombreux serveurs web sont vulnérables à ce type d’attaque.

Inondation de paquets TCP SYN

Les protocoles des couches supérieures fonctionnent dans la plupart des cas sur des protocoles de transports communs comme TCP et UDP : la résistance des équipements dans ces couches est donc nécessaire au fonctionnement des applications. En l’occurrence le protocole HTTP fonctionne par-dessus TCP, nous proposons pour éprouver cette couche une attaque distribuée dite de « SYN flooding ». Celle-ci consiste en un envoi continu de paquets TCP avec un drapeau particulier (SYN) activé, causant sur le serveur l’ouverture de nombreuses demi-connexions qui ne seront pas fermées. Le but est de pousser le nombre de requêtes émises par seconde jusqu’à ce que le serveur atteigne son maximum de sessions TCP simultanées et de voir comment celui-ci gère les connexions au voisinage ou au-delà de cette limite.

Inondation de paquets aléatoires

Ce scénario est grossièrement la combinaison des précédents, dans le sens où des données aléatoire seront placées dans les couches 3 à 7 du modèle OSI.