L'article suivant est la première partie d'une série en 2 parties sur le dépannage des attaques DDoS, et c'est un article invité de Matt Conran de Aperçu du réseau. Dans cet article, Matt couvre les défis de l'approche manuelle du dépannage DDoS.
Une attaque DDoS (Distributed Denial of Service) est une embuscade pour aliéner les services en ligne par un trafic énorme provenant de nombreuses sources. Dans cette cyberattaque, le bourreau utilise plus d'une adresse IP unique. Alors, Lorsque nous pensons à DDoS, les principaux éléments qui nous viennent à l'esprit sont les composants de détection et d'atténuation. Après tout, c'est là que l'argent est poussé et que les nouvelles fonctionnalités sophistiquées sont introduites. Cependant, c'est toute l'efficacité de la solution de bout en bout qui arrête le DDoS à temps.
La pièce manquante du puzzle est le dépannage. Beaucoup perçoivent que mapper un réseau et le dépannage est une tâche technique ne nécessitant que les mains d'un ingénieur. Mais il y a tout un processus d'entreprise qui doit s'intégrer, menant au travail final de configuration, arrêtant ainsi le DDoS.
La procédure implique la coordination de personnes de différentes équipes et de différents horizons techniques pour mélanger et former efficacement une solution. Ce n'est pas quelque chose qui arrive automatiquement ou par hasard. Il doit être répété et contrôlé avec précision. L'un des plus gros problèmes des attaques DDoS est le manque de préparation. Le manque de préparation mène à la panique et rien ne sera réparé si cela s'installe.
Toute l'expérience technique du monde ne vous aidera que si les cultures entre les équipes fonctionnent efficacement. Et avec un événement DDoS, vous aurez certainement besoin de plusieurs équipes travaillant ensemble.
L'art de la mise en réseau a conduit à des milliers de conceptions de réseaux différentes souvent appelées flocons de neige uniques. Dans le réseau SP, il fournit souvent la même exigence de connectivité d'objectif final, telle qu'un L2VPN et L3PVPN. Cependant, le type de conception de réseau varie considérablement d'un fournisseur à l'autre.
De nombreuses conceptions sont laissées sur la tête du concepteur alors qu'elles devraient être dans un référentiel central, suivies des modifications. Le dépannage de diverses conceptions et configurations de réseau devient difficile lorsque vous êtes attaqué par DDoS avec des volumes atteignant l'échelle du téraoctet.
Le trou noir déclenché à distance (RTBH) est l'un des plus courants moyens d'atténuer une attaque. Il utilise le protocole BGP (Border Gateway Protocol) au sein du réseau et installe des règles dans le lieu de transfert pour bloquer la destination afin d'atténuer l'attaque DDoS. Il complète essentiellement l'attaque DDoS au nom de l'attaquant. RTHB a été utile dans le passé, mais l'un de ses défauts est qu'il combine à la fois le routage en mode mission et les fonctions de sécurité sur le même appareil.
Les règles de pare-feu utilisées pour bloquer une attaque sont placées dans le périphérique réseau qui joue le rôle principal d'acheminer le trafic du point A au point B. Donc, d'un point de vue technique, nous avons déjà des défis. Pour aggraver encore cela, nous devons plus que souvent combiner deux équipes pour travailler sur le même appareil, à la fois la sécurité et le réseau. D'un point de vue opérationnel, l'approche la plus courante de l'atténuation des attaques DDoS consiste à mélanger deux chapeaux techniques sur le même appareil.
Au plus fort d'une attaque DDoS, la collaboration d'équipe est essentielle et l'atténuation DDoS existante telle que RTBH peut poser des problèmes de coordination d'équipe. Pour se protéger efficacement contre les attaques DDoS, une solution ne peut jamais être vue singulièrement du seul point de vue technique. C'est l'ensemble du processus de dépannage et la collaboration des équipes qui remportent la course avec succès.
Pour une protection DDoS efficace, vous devez examiner toutes les couches de la pile du modèle d'interconnexion de systèmes ouverts (OSI). Il ne s'agit plus seulement d'une couche ; les cybercriminels utilisent plusieurs couches pour pénétrer dans un réseau. Les attaques parallèles sont souvent utilisées en combinant les deux, l'attaque volumétrique de couche 4 avec l'attaque d'application de couche 7. Donc, essentiellement, nous avons deux couches de la pile qui nécessitent un dépannage - la couche 4 et la couche 7.
Cela pourrait également impliquer potentiellement deux équipes distinctes - une équipe de mise en réseau pour la couche 4 et une équipe d'application pour la couche 7. Combinez dans quelques pare-feu et équilibreurs de charge, nous avons un bon mélange d'interaction d'équipe dispersée. Ce type de collaboration doit être rationalisé et coordonné efficacement.
L'approche manuelle de DDoS contient un certain nombre d'étapes avant d'arriver à la source du problème. Tous ces éléments peuvent devoir être effectués par des personnes, des équipes, des lieux et des moments différents. La plupart du temps, les individus impliqués ne seront pas assis les uns à côté des autres. En fonction de l'attaque et de la façon dont elle a été signalée, c'est ce qui compte. S'il s'agit d'une attaque au niveau de l'application, un administrateur peut avoir besoin d'afficher les journaux de chaque serveur en se connectant manuellement ou via un analyseur de journaux central.
Un autre administrateur peut avoir à parcourir un groupe de machines et à émettre des commandes telles que "Netstat" pour déterminer quelles connexions sont ouvertes sur ce serveur ou cette appliance. Un autre administrateur doit vérifier si la charge de la machine est élevée ou déterminer le nombre de Processus HTTP fonctionnement. Un administrateur Linux ou de pare-feu doit créer des scripts personnalisés et les exécuter sur des tables IP pour déterminer d'autres types d'informations de sécurité.
Les scripts personnalisés créés par des ingénieurs individuels sont parfaits pour l'un des travaux, mais si vous souhaitez qu'il soit automatisé entre les équipes, les choses deviennent plus délicates. La personne qui crée le script est généralement celle qui gère le script. Que se passe-t-il lorsque cette personne quitte ou s'il y a des bogues ou des modifications qui sont nécessaires ?
Le travail supplémentaire qui dépasse le domaine de cet ingénieur est regroupé dans ses opérations quotidiennes normales et sera éventuellement laissé de côté. Il est de loin préférable de stocker tous vos scripts dans une base de données gérée de manière centralisée où aucune personne n'est responsable. Les attaques DDoS évoluent rapidement. Le type de changements aléatoires requis ( TCP -> UDP ) serait une simple commande sur le serveur C2. Essayer de suivre tout cela avec des scripts personnalisés est un mauvais service pour vous et votre entreprise.
Un ingénieur plus avancé peut devoir être appelé pour examiner les en-têtes d'hôte HTTP ou les tables de session sur un équilibreur de charge pour déterminer s'il s'agit d'une attaque plus sophistiquée. Les attaques de couche 7 ne dépassent pas le nombre de paquets par seconde, nous devons donc aller plus loin que le 5 tuple standard et déterminer les problèmes intermittents.
Parfois, nous pouvons avoir besoin d'aller plus loin pour examiner le nombre de congestions, les fenêtres de congestion, TCP RTT ou d'autres fonctionnalités avancées. Sur un serveur Web, nous devrons peut-être rechercher des en-têtes spécifiques à écrire dans Null0.
Les communautés BGP sont souvent adaptées aux atténuations DDoS. La communauté BGP est définie sur une route, puis cette route est bloquée à la périphérie WAN. S'il est mal réglé, cela impliquerait beaucoup de travail manuel pour savoir où se trouve la source du problème.
L'approche manuelle du dépannage doit éventuellement être effectuée, puis toutes les informations de diagnostic doivent être regroupées d'une manière ou d'une autre en un seul endroit pour prendre une décision sur ce qu'il faut faire. Essayer de répéter ces étapes avec les mêmes personnes sans automatisation n'est pas la solution pour des opérations fluides. Il y a beaucoup d'étapes différentes qui nécessitent de nombreuses équipes différentes, combinant de nombreux chapeaux technologiques différents.
Certains de ces appareils requis pour le dépannage peuvent même se trouver sur différents réseaux avec des connexions différentes. Il se peut que vous ayez besoin de déposer un ticket de dépannage même pour accéder à l'appareil pour démarrer le dépannage. Nous avons déjà les mains liées et le DDoS est déjà en train de gagner de loin. Ce type de dépannage ne vous rend pas service, surtout quand on est déjà dans un jeu du chat et de la souris. Combiner des équipes, des casquettes techniques et des ensembles de compétences est une tâche difficile et nécessite une bonne gestion d'équipe et de projet. Au lieu de laisser la foi aux dieux, il est préférable d'avoir une solution en place pour que les choses fonctionnent pour vous. Ainsi, lorsqu'un DDoS se produit et qu'il se produira certainement, vous êtes prêt en un clic pour l'atténuer.
NetBrain offre une approche unique de l'automatisation du réseau comblant ainsi le fossé entre la détection et l'atténuation des attaques DDoS. La capacité pour NetBrain s'intégrer à la fois aux systèmes de détection et d'atténuation complète la pièce manquante du puzzle du déni de service (DDoS). Ce n'est pas l'entreprise de cartographie mais l'entreprise d'automatisation qui exploite Cartographie dynamique du réseau, exécutable Runbooks et Cadre d'intégration riche d'API et flux de travail pour dépanner tout type de DDoS.