Cet article est le deuxième d'une série de trois consacrée au dépannage des attaques DDoS. Il s'agit d'une contribution de Matt Conran de Network Insight . Dans cet article, Matt aborde les difficultés liées à l'approche manuelle du dépannage des attaques DDoS.
Une attaque DDoS (déni de service distribué) est une embuscade visant à saturer les services en ligne par un trafic massif provenant de nombreuses sources. Lors de cette cyberattaque, l'auteur utilise plusieurs adresses IP distinctes. Ainsi, lorsqu'on évoque les attaques DDoS, les premiers éléments qui nous viennent à l'esprit sont la détection et l'atténuation. Après tout, c'est là que se concentrent les investissements et que de nouvelles fonctionnalités sophistiquées sont développées. Cependant, c'est l'efficacité globale de la solution de bout en bout qui permet de stopper une attaque DDoS à temps.
L'élément manquant, c'est le dépannage. Beaucoup pensent que la cartographie et le dépannage d'un réseau sont des tâches techniques réservées aux ingénieurs. Or, il s'agit d'un processus d'entreprise complet qui doit être intégré pour aboutir à la configuration finale et, ainsi, stopper l'attaque 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 blocage à distance (RTBH) est l'une des méthodes les plus courantes pour atténuer une attaque. Il utilise le protocole BGP (Border Gateway Protocol) au sein du réseau et installe des règles au niveau du point de routage pour bloquer la destination et ainsi contrer une attaque DDoS. En pratique, il exécute l'attaque DDoS pour le compte de l'attaquant. Le RTBH s'est avéré utile par le passé, mais l'un de ses défauts est de combiner le routage en mode mission et les fonctions de sécurité sur un même dispositif.
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 efficace contre les attaques DDoS, il est essentiel d'examiner toutes les couches du modèle OSI (Open Systems Interconnection). Il ne s'agit plus d'une seule couche : les cybercriminels exploitent plusieurs couches pour s'infiltrer dans un réseau. Les attaques parallèles combinent souvent une attaque volumétrique de couche 4 et une attaque applicative de couche 7. En résumé, deux couches du modèle nécessitent une analyse approfondie : les couches 4 et 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 être amené à analyser un groupe de machines et à exécuter des commandes telles que « Netstat » afin de déterminer les connexions ouvertes sur ce serveur ou cet appareil. Un autre encore doit vérifier la charge des machines ou déterminer le nombre de processus HTTP en cours d'exécution. Un administrateur Linux ou de pare-feu doit créer des scripts personnalisés et les exécuter sur les tables IP pour obtenir d'autres 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.
Il pourrait être nécessaire de faire appel à un ingénieur plus expérimenté pour examiner les en-têtes HTTP ou les tables de session d'un équilibreur de charge afin de déterminer s'il s'agit d'une attaque plus sophistiquée. Les attaques de couche 7 ne dépassent pas un paquet par seconde ; il est donc nécessaire d'aller au-delà de l'analyse standard (un quintuplet) et d'identifier 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 est finalement nécessaire, puis toutes les informations de diagnostic doivent être centralisées afin de déterminer la marche à suivre. Répéter ces étapes avec les mêmes personnes, sans automatisation, ne garantit pas un fonctionnement optimal. Le processus comporte de nombreuses étapes et requiert l'intervention de plusieurs équipes aux compétences techniques variées.
Certains appareils nécessaires au dépannage peuvent se trouver sur des réseaux différents et nécessiter des identifiants de connexion distincts. Il se peut même que vous deviez ouvrir un ticket d'assistance pour accéder à l'appareil et commencer le dépannage. Nous sommes déjà fortement pénalisés et les attaques DDoS ont déjà pris le dessus. Ce type de dépannage vous est préjudiciable, surtout dans cette situation tendue. Coordonner les équipes, les compétences techniques et les savoir-faire est une tâche complexe qui exige une bonne gestion d'équipe et de projet. Plutôt que de s'en remettre au hasard, il est préférable de mettre en place une solution efficace. Ainsi, en cas d'attaque DDoS (et cela arrivera certainement), vous pourrez réagir d'un simple clic pour la contrer.
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.