Comment les FAI peuvent-ils gérer les attaques DDoS?
Comment un FAI à faible bande passante comme 50 Gbps peut-il gérer une attaque DDoS avec plus que cela? Je sais qu'il existe une solution appelée "Black Hole".
- Est-ce suffisant pour atténuer les attaques DDoS ou existe-t-il d'autres solutions d'entreprise?
- Quels types de services d'atténuation des DDoS sont désormais disponibles?
- CDN peut-il atténuer les attaques DDoS?
Il existe un certain nombre de stratégies, chacune ayant ses propres coûts et avantages. En voici quelques-unes (il y en a plus et des variantes):
blackholing
En bloquant le trafic, vous rejetez tout le trafic vers l'adresse IP cible. En règle générale, les FAI essaient d'utiliser RTBH (blackholing déclenché à distance), par lequel ils peuvent demander à leurs réseaux en amont de rejeter le trafic, de sorte qu'il n'atteindra même pas le réseau de destination. L'avantage ici est qu'il ne saturera pas alors les liaisons montantes du FAI. Le plus gros inconvénient ici est que vous faites exactement ce que veulent les attaquants: l'adresse IP cible (et donc les services qui y sont exécutés) est hors ligne. Cependant, le reste des clients du FAI ne souffrira pas de l'attaque et les coûts sont faibles.
blackholing sélectif
Au lieu de noircir une adresse IP pour l'ensemble d'Internet, il peut être utile de modifier le routage BGP pour la plage d'adresses ciblée afin qu'elle ne soit accessible que pour certaines parties d'Internet. Ceci est généralement appelé " blackholing sélectif " et est mis en œuvre par un certain nombre de grands transporteurs. L'idée est que de nombreux services Internet ne doivent être disponibles que dans une région spécifique (généralement un pays ou un continent). Par exemple, en utilisant le blackholing sélectif, un FAI néerlandais attaqué pourrait choisir d'avoir ses plages IP blackholées pour le trafic en provenance de Chine, tandis que les IP européennes pourraient atteindre l'adresse ciblée. Cette technique peut très bien fonctionner si le trafic d'attaque provient de sources très différentes du trafic normal.
nettoyage
Une meilleure solution consiste à utiliser un centre de nettoyage, généralement hébergé en dehors du réseau du FAI en tant que service. En cas d'attaque DDoS, le FAI redirige le trafic pour cette plage IP vers le centre de nettoyage. Le centre de lavage dispose de l'équipement pour filtrer le trafic indésirable, laissant un flux de trafic (principalement) propre qui est redirigé vers le FAI. Comparé au blackholing, c'est une meilleure solution car les services sur l'IP cible restent disponibles. L'inconvénient est que la plupart des centres de récurage sont commerciaux et peuvent coûter très cher. De plus, le nettoyage n'est pas toujours facile, il peut y avoir à la fois des faux positifs (le trafic recherché étant filtré) et des faux négatifs (le trafic indésirable n'étant pas filtré).
ingénierie du trafic
Les réseaux FAI ont généralement un certain nombre de connexions à Internet via des fournisseurs de transit et/ou des points d'échange Internet. En établissant ces connexions, ainsi que des liens au sein de l'épine dorsale du FAI, beaucoup plus importants que nécessaire pour les modèles de trafic normaux, le réseau peut faire face aux attaques DDoS. Cependant, il y a une limite pratique à cela, car la capacité de bande passante inutilisée est coûteuse (par exemple, investir dans un équipement à 100 Gbit/s et des connexions en amont est très cher et peu rentable si vous ne faites que quelques Gbit/s) et cela ne fait généralement que déplacer le problème vers quelque part dans le réseau: quelque part, il y aura un commutateur, un routeur ou un serveur de plus petite capacité, et cela deviendra le point d'étranglement.
Avec certaines attaques, les FAI peuvent être en mesure d'équilibrer le trafic entrant de manière à ce que toutes les connexions externes ne soient pas inondées et qu'une ou quelques-unes deviennent saturées.
Au sein de réseaux plus importants, il est possible de créer un routeur "gouffre" qui n'attire que le trafic pour la plage IP attaquée. Le trafic vers toutes les autres plages IP est acheminé sur d'autres routeurs. De cette façon, le FAI est en mesure d'isoler le DDoS dans une certaine mesure en annonçant la plage IP ciblée dans BGP uniquement sur le routeur gouffre, tout en arrêtant l'annonce de cette plage IP sur d'autres routeurs. Le trafic depuis Internet vers cette destination sera forcé via ce routeur. Cela peut entraîner la saturation de toutes les liaisons montantes de ce routeur de gouffre, mais les liaisons montantes des autres routeurs ne seront pas inondées et les autres plages IP ne seront pas affectées.
Le gros inconvénient ici est que toute la plage dans laquelle l'IP cible est (au moins a/24) peut en souffrir. Cette solution est souvent le dernier recours.
filtrage local
Si le FAI a suffisamment de capacité sur ses liaisons montantes (afin qu'elles ne soient pas saturées), il peut implémenter un filtrage local. Cela peut se faire de différentes manières, par exemple:
- ajouter une liste d'accès sur les routeurs rejetant le trafic sur des caractéristiques telles que l'adresse source ou le port de destination. Si le nombre d'adresses IP source dans une attaque est limité, cela peut fonctionner efficacement
- implémenter des limiteurs de débit pour réduire la quantité de trafic vers l'adresse IP cible
- acheminer le trafic via des zones de nettoyage locales qui filtrent le trafic indésirable
- mise en œuvre BGPFlowspec , qui permet aux routeurs d'implémenter des règles de filtre d'échange à l'aide de BGP (par exemple: 'rejeter tout le trafic de l'adresse IP X vers l'adresse IP Y du port source UDP du protocole 123'))
réseaux de diffusion de contenu et équilibrage de charge
Les hébergeurs Web peuvent utiliser des réseaux de diffusion de contenu (CDN) pour héberger leurs sites Web. Les CDN utilisent l'équilibrage de charge global et ont donc d'énormes quantités de bande passante et de clusters de serveurs de mise en cache partout dans le monde, ce qui rend difficile la suppression complète d'un site Web. Si un ensemble de serveurs tombe en panne en raison d'un DDoS, le trafic est redirigé automatiquement vers un autre cluster. Un certain nombre de gros CDN fonctionnent également comme service de nettoyage.
À une échelle un peu plus petite, un équilibrage de charge local peut être déployé. Dans ce cas, un pool de serveurs est disponible pour héberger un site Web ou une application Web. Le trafic est distribué sur les serveurs de ce pool par un équilibreur de charge, augmentant ainsi la quantité de capacité de serveur disponible, ce qui peut aider à résister à une attaque DDoS.
Bien sûr, les CDN et l'équilibrage de charge ne fonctionnent que pour l'hébergement, ils ne fonctionnent pas pour les FAI d'accès.
Bonne question!
Parlons du contexte d'un scénario pratique d'une application web déployée en production et elle est attaquée par un adversaire avec 10 000 requêtes par seconde au couche d'application couplée par une énorme attaque réseau en couches qui est toujours gérable.
Certes, les FAI peuvent gérer une attaque DDoS mais cela dépend encore une fois de leur configuration générale et de leurs ressources, de leur infrastructure.
Étude de cas -
Donc, pour commencer, je me sens privilégié de répondre à cette question car l'un de mes clients a récemment fait face à une attaque DDoS sur son application Web, il semblait très difficile d'atténuer demander pourquoi ?
Parce que j'ai découvert que c'était une "attaque DDoS de couche application" et la puce intelligente l'attaquant visait différentes ressources au lieu de points finaux particuliers qui n'étaient pas à taux limité
Comme vous pouvez l'imaginer, les points clés à retenir de cette proposition n'étaient pas seulement de mettre en œuvre un puissant [~ # ~] cdn [~ # ~] mais aussi pour améliorer leur -
- équilibrage de charge
- Implémentez limitation de débit via une configuration de serveur appropriée Nginx (ou tout autre serveur), cette limitation de débit comporte à nouveau un certain nombre de sous-ensembles de configuration basés sur l'attaque en considération par laquelle vous pouvez optimiser votre furtivité et défendre votre application. N'hésitez pas à parcourir la documentation pour en savoir plus sur la limitation de débit nginx qui est vraiment l'idéal pour les applications gérant une grande charge.
- Utiliser le Akamai CDN qui est considéré comme très efficace et puissant à cet égard lorsque vous avez surtout une énorme base d'utilisateurs et que vous avez besoin de servir en temps réel
- Implémentation captcha sur presque tous les champs imaginables de l'application après 2 requêtes envoyées par l'utilisateur, dans les conditions de pointe de l'attaque. Les applications les plus populaires sur le Web utilisent Recaptcha et Recaptcha bloque également [~ # ~] tor [~ # ~] exit- nœuds et proxies (qui sont souvent utilisés par les attaquants pour contourner les règles de pare-feu de la couche réseau en passant d'un circuit TOR au suivant ou en utilisant différents proxys comme forme d'évasion avancée), ce qui est un plus car dans notre Dans le cas où une partie du trafic malveillant semble provenir d'un réseau TOR fortement anonymisé.
- Et Enfin, la logique d'application a dû être modifiée pour que la limitation de débit ne puisse pas être contournée
Sur la couche [~ # ~] isp [~ # ~] , vous ne pouvez contrôler que les attaques de couche réseau de manière viable sans nuire à vos utilisateurs qui présente également des inconvénients. Donc le blackholing peut ne pas être suffisant pour votre entreprise et d'autre part, cela peut causer de graves problèmes, des problèmes d'utilisation dans votre application comme ceci -
L'une des principales conséquences de l'utilisation du routage blackhole lorsqu'un bon trafic est également affecté est que l'attaquant a essentiellement atteint son objectif de perturber le trafic vers le réseau ou le service cible. Même s'il peut aider un acteur malveillant à atteindre son objectif, le routage des trous noirs peut toujours être utile lorsque la cible de l'attaque est un petit site faisant partie d'un réseau plus vaste. Dans ce cas, la suppression du trafic dirigé vers le site ciblé pourrait protéger le réseau plus vaste contre les effets de l'attaque.
C'est ce que Cloudflare a à dire à cet égard. Le blackholing achemine donc essentiellement le trafic réseau et le supprime. Mais qu'en est-il de la couche application ou des attaques en couches plus profondes qui utilisent plusieurs sous-réseaux IP? Les méthodes traditionnelles échouent dans ces cas et vous devez rechercher et trouver la principale vulnérabilité dans votre application qui peut être le fait que vous divulgation d'une adresse IP de serveur interne ou d'un point de terminaison vulnérable si vous utilisez Cloudflare, auquel cas Cloudflare échoue aussi.