Protection contre les attaques DDoS
SSG dispose d’une fonctionnalité de protection contre les cybermenaces externes, telles que les attaques DDoS comme l’inondation TCP SYN. Ces attaques visent à épuiser les ressources du serveur, le rendant inaccessible aux utilisateurs légitimes. Elles exploitent un mécanisme d’établissement de connexion TCP connu sous le nom de poignée de main à trois voies/triple.
Comment fonctionne l’attaque TCP SYN flood ?
Tout d’abord, examinons le mécanisme de connexion TCP :
- SYN (Synchronisation) : Le client envoie un segment SYN au serveur, demandant l’établissement d’une connexion.
- SYN-ACK (Synchronize-Acknowledge) : Le serveur répond au client par un segment SYN-ACK, accusant réception du SYN et demandant un accusé de réception au client.
- ACK (Accusé de réception) : Le client envoie un segment ACK au serveur pour accuser réception du SYN-ACK et la connexion est considérée comme établie.
Dans une attaque DDoS par inondation TCP SYN, l’attaquant envoie de multiples requêtes SYN au serveur cible en utilisant un réseau composé d’un grand nombre d’appareils infectés (des PC et serveurs aux appareils IoT et consoles de jeu), également connu sous le nom de réseau de zombies (botnet). Lorsqu’il utilise un botnet, l’attaquant n’a pas besoin de masquer les adresses IP de chaque appareil sur le réseau.
Le serveur répond à chaque demande par un segment SYN-ACK et attend une confirmation ACK de la part du client. Si aucun accusé de réception n’est reçu, le serveur maintient la connexion ouverte pendant un certain temps (généralement quelques secondes) jusqu’à l’expiration du délai d’attente. Le nombre de connexions simultanées étant limité, le serveur remplit rapidement son pool de connexions, ce qui le rend inaccessible aux utilisateurs légitimes.
Protection contre les attaques TCP SYN flood DDoS basée sur SSG : une étude de cas pratique
Le système de protection contre les attaques DDoS par inondation TCP SYN basé sur SSG est largement utilisé par les centres de données et les fournisseurs de cloud. Examinons comment ce système a été organisé dans l’un des plus grands centres de données russes.
Pour tester le complexe SSG, la configuration suivante a été organisée sur le banc d’essai :
- RTR1 (routeur Juniper MX204) – utilisé comme ASBR (routeur frontière de système autonome).
- RTR2 (routeur Juniper MX204) – utilisé comme routeur d’accès
- MPLS est configuré entre RTR1 and RTR2
- Client-1 (routeur Mikrotik RB951Ui 2HnD) – émule un hôte sur Internet et agit comme une source de connexions légitimes.
- Client-2 (CRS305-1G-4S+IN router) – émule un client dans le réseau du centre de données et agit en tant que récepteur du trafic légitime et illégitime (victime).
- Client-1 and Client-2 sont connectés aux routeurs par l’intermédiaire de commutateurs (non représentés dans les diagrammes pour des raisons de simplicité).
- L’interface RTR1 à laquelle Client-1 est connecté est considérée comme une interface Uplink
- Les règles suivantes sont configurées sur RTR1 :
- flowspec redirect-to-next-hop – une règle pour rediriger le trafic aller vers la victime à travers l’interface d’entrée du filtre.flowspec redirect-to-routing-instance – règle pour rediriger le trafic retour de la victime à travers l’interface de sortie du filtre.
- flowspec redirect-to-routing-instance – règle permettant de rediriger le trafic de retour de la victime via l’interface de sortie du filtre.
- Le complexe de protection DDoS de VAS Experts SSG est utilisé pour le nettoyage du trafic, fonctionnant en mode L2.
Mise en place du réseau en l’absence d’attaques actives :
La mise en place du réseau en l’absence d’attaques actives
Au moment où l’attaque commence, un trafic légitime est échangé entre Client-1 et Client-2.
Le schéma du flux de trafic au moment du démarrage de l’attaque:
Après le lancement d’une attaque TCP SYN par l’auteur (hôte malveillant) avec différentes adresses sources usurpées, le trafic, légitime et malveillant, passe directement par le routeur pour atteindre la victime en l’espace de 20 à 25 secondes.
Lorsque le trafic d’attaque dépasse les seuils fixés pour le débit binaire ou le débit de paquets, après environ 20 à 25 secondes, le trafic légitime et malveillant passe directement par le routeur vers la victime, une règle de redirection vers le prochain saut (soit manuellement, soit annoncée par l’automatisation et le BGP) apparaît sur l’ASBR du RTR1, redirigeant le trafic à travers l’interface RTR1 vers le SSG.
Schéma de passage du trafic en mode protection:
Si l’attaque s’arrête ou si son intensité diminue en dessous des valeurs seuils, la règle flowspec est supprimée (manuellement ou par des moyens automatisés) et le trafic cesse de passer par le filtre.
Résultats du test
L’image réelle montre une redirection réussie de tout le trafic, légitime et malveillant, destiné au client victime. En même temps, tout le trafic d’attaque malveillante TCP SYN flood jusqu’à 360 Mbps a été bloqué avec succès.
Les services protégés légitimes entre le client et la victime ont fonctionné correctement, tant dans les tests synthétiques que dans le trafic réel du produit. Au moment où le trafic a été transféré vers le filtre, les services avec des connexions déjà établies ont continué à fonctionner de manière stable.
Lorsque le trafic a été retiré du dispositif, les sessions TCP liées aux ressources protégées qui ont été établies par son intermédiaire pendant l’attaque ont été interrompues. En revanche, les sessions établies par l’intermédiaire du filtre mais non liées aux ports protégés n’ont pas été interrompues.
Surveillance de l’activité virale basée sur QoE Analytics et Kaspersky Lab
Flux de données sur les menaces de Kaspersky et module d’analyse du trafic de la qualité de l’expérience (QoE) de SSG. de SSG ont été combinés pour créer une solution très efficace d’analyse et de lutte contre les cybermenaces.
Kaspersky Threat Data Feeds est une base de données structurée, constamment mise à jour et volumineuse de divers types de cybermenaces telles que les attaques DDoS, les sites de phishing, les réseaux de botnets, le spam et d’autres influences malveillantes. La base de données contient 16 types de flux, dont sept principaux sont traités par le SCAT :
- URL malveillante
- Hameçonnage URL
- Botnet C&C
- Botnet mobile
- Réputation IP
- Ransomware URL
- Données URL de l’IdO
À l’aide de robots propriétaires, de pièges à spam et de systèmes de surveillance des botnets, Kaspersky Threat Data Feeds teste, analyse et collecte des données sur toutes les cybermenaces actuellement connues en une seule référence.
Pour mettre en œuvre une solution collaborative, une copie synchronisée de la base de données sur les menaces est hébergée sur un serveur contenant des statistiques sur le comportement des utilisateurs. Les statistiques de comportement des utilisateurs sur le SCAT sont ensuite comparées à la base de données des menaces, ce qui permet de tirer des conclusions sur les menaces potentielles au sein du réseau du centre de données.
Avantages de l’intégration de Kaspersky et des experts SVA
- Identification des utilisateurs ayant une activité virale.
- Détection des botnets à un stade précoce.
- Détermination du degré d’infection du réseau.
- Créer une liste des menaces identifiées et des utilisateurs infectés pour l’administrateur du réseau.
Une fois le réseau infecté, l’administrateur réseau peut résoudre rapidement et efficacement les problèmes avec SCAT :
- Restreindre ou bloquer les utilisateurs à l’aide de politiques sur les périphériques du réseau.
- Téléchargement des données sur les utilisateurs infectés pour traitement par les spécialistes de l’assistance technique.
Ainsi, l’intégration des flux de données sur les menaces de Kaspersky et de la plateforme SSG de VAS Experts est un outil puissant pour surveiller et contrer les cybermenaces dans les réseaux de centres de données. Grâce à une synchronisation approfondie des données sur les cybermenaces avec les statistiques comportementales des utilisateurs, ce système offre un niveau de protection élevé en identifiant rapidement les menaces potentielles telles que l’activité virale et les réseaux de zombies à des stades précoces. Cela permet aux administrateurs de réseau de répondre aux incidents en temps voulu, de minimiser les risques et d’empêcher la propagation de logiciels malveillants au sein du réseau. La mise en œuvre de cette solution contribue donc à améliorer la sécurité des réseaux d’entreprise et à réduire les risques associés aux cyberattaques.
Surveillance de l’état du réseau avec module d’analyse de la qualité de l’expérience
La surveillance de l’état du réseau permet de détecter, par exemple, des problèmes de disponibilité du service pour les utilisateurs tels que des dysfonctionnements ou des surcharges des aplinks en amont, ainsi qu’un fonctionnement lent ou une indisponibilité des services sans expertise en ligne particulière.
Examinons un cas réel d’application du module d’analyse de la qualité de l’expérience par l’un des plus grands centres de données pour surveiller l’état de son propre réseau et optimiser l’acheminement du trafic.
Description de la connexion QoE
Le trafic de l’infrastructure virtuelle du client a été dirigé à travers le miroir vers le port BareMetal du serveur avec SSG. La tâche de SSG consistait à collecter des statistiques sur le protocole NetFlow v10, en utilisant des champs personnalisés comprenant les informations RTT et Retransmit pour les sessions TCP. Les statistiques collectées ont été introduites dans une machine virtuelle où le module de collecte de statistiques QoE Stor a été déployé.
Résultats du test
Vérification de la correspondance entre la part de retransmission et les pertes configurées manuellement sur l’hôte.
Pour le test, un hôte a été utilisé sur lequel Linux TC a été utilisé pour définir des paramètres qui écartent artificiellement 30 % du trafic entrant sur l’interface. À l’issue du test, l’analyse de la qualité de l’expérience a montré 30 % de retransmissions et les valeurs RTT correspondantes.
Améliorer la connectivité des hôtes en réacheminant le trafic
L’un des hôtes subissait des retransmissions sur une session TCP. À 13h00, la route du trafic sortant pour le préfixe problématique a été modifiée, ce qui a entraîné la disparition des retransmissions et une diminution du RTT. Ces mesures ont également été confirmées par les statistiques obtenues à partir de la qualité de l’environnement.
Les illustrations ci-dessous montrent clairement les changements apportés à l’itinéraire du trafic.
Avant
After
Ainsi, la fonctionnalité du module QoE permet d’identifier les goulets d’étranglement du réseau et peut être utilisée pour la surveillance afin d’identifier et de traiter de manière proactive les zones problématiques en temps opportun. Grâce à l’API, il est possible d’intégrer le SSG dans un système de surveillance existant afin de contrôler les moments de dégradation de la connectivité dans le réseau.