Mon expérience des attaques DoS et DDoS est basée sur le fait d'être ingénieur Cisco pour un FAI et plus tard en tant que Security Manager pour un très grand Global. Sur la base de cette expérience, j'ai constaté que pour traiter efficacement des attaques complexes et à grande échelle, il fallait un bon partenariat entre l'organisation attaquée et son FAI ou son partenaire d'atténuation DDoS (Oui, il y a maintenant des entreprises dédiées à cela, par essence, elles sont très grand FAI à part entière mais utilise son réseau mondial pour prendre en charge le trafic supplémentaire généré lors d'une attaque).

Voici quelques considérations si vous êtes confronté à une attaque qui est en dehors de votre tolérance de bande passante (aka consommation de bande passante ) et vous avez besoin d'aide pour y répondre.

Là où il n'y a pas de partenaire d'atténuation: Établissez une relation solide avec votre FAI. Identifiez les bonnes équipes et contacts dont vous aurez besoin en cas d'attaque.

Utilisez votre pare-feu (ou autre dispositif de journalisation) pour obtenir des preuves de l'attaque (IP source, protocole, longueur de paquet, etc.) comme ces informations peuvent être extrêmement précieuses pour le FAI lorsqu'il décide de la manière de réagir. Ce n'est pas amusant d'essayer de piéger le trafic sur un périphérique de routage Cisco à partir de la ligne de commande à trois heures du matin! Donc, toute aide est appréciée. :-)

Avec cela, votre approche probable sera de filtrer le trafic dans le cloud ISP. Si vous avez été en mesure de fournir suffisamment d'informations et que le trafic est tel, le FAI peut bien être en mesure de filtrer le trafic malveillant et de laisser le trafic réseau valide libre pour accéder à votre réseau. Cependant, si vous causez des problèmes de latence pour le FAI, il est susceptible de troubler tout votre itinéraire au niveau de sa passerelle BGP et vous disparaîtrez du réseau. Des filtres de routage supplémentaires entraînent une charge sur les passerelles, alors ne vous attendez pas à ce que votre FAI ajoute plusieurs filtres, car cela pourrait avoir un impact sur ses autres utilisateurs.

Utilisation d'un partenaire d'atténuation:

Je ne peux parler que de l'expérience d'un seul fournisseur pour cela, vous devrez donc faire vos devoirs pour décider si vous en avez besoin et, le cas échéant, qui serait le mieux placé pour fournir le service.

Le service était basé sur la publicité d'itinéraire BGP et la surveillance des attaques. Une fois qu'une attaque a été identifiée, le partenaire d'atténuation annonce que votre itinéraire passe par son réseau, où les routeurs principaux sont utilisés pour filtrer le trafic malveillant avant de le transmettre à l'organisation.

Mon rôle dans tout cela était de tester la mise en œuvre d'une approche en partenariat pour l'atténuation des attaques DDoS. Cela impliquait d'utiliser une équipe mondiale d'ingénieurs en sécurité pour générer suffisamment de trafic pour permettre un test valide. Nous testions à la fois la capacité d'identifier une attaque, puis de réagir efficacement. Sur cette base, nous avons été très impressionnés par leur approche globale et la solution a fonctionné.

Ce sont vraiment deux attaques différentes, bien que similaires.

Le DoS "régulier" est basé sur la tentative de planter le serveur / pare-feu, à travers une sorte de bogue ou de vulnérabilité. Par exemple. les attaques SYN Flood bien connues. Les protections contre ceux-ci sont bien sûr spécifiques à la faille (par exemple les cookies SYN), et au codage / conception sécurisé en général.

Cependant, DDoS tente simplement de submerger le serveur / pare-feu en l'inondant avec des masses de requêtes apparemment légitimes.
En vérité, un seul pare-feu ne peut pas vraiment se protéger contre cela, car il n'y a pas de véritable moyen de marquer les «mauvais» clients. C'est juste une question de "meilleur effort", comme la limitation elle-même pour ne pas planter, les équilibreurs de charge et les systèmes de basculement, tentative de liste noire des adresses IP (si ce n'est pas en fonction de "badness", puis selon l'utilisation ), et bien sûr, en avertissant activement les administrateurs.
Ce dernier peut être le plus important, car en cas de DDoS apparent (je dis apparent, car une simple utilisation régulière de pointe pourrait ressembler à DDoS - histoire vraie) il faut vraiment un humain pour différencier le contexte de la situation, et déterminer s'il faut arrêter, au mieux, approvisionner une autre boîte, etc. (ou utiliser une contre-attaque ... ssshhh !!)

Un type de protection contre DDOS non effectué directement par les pare-feu consiste à distribuer le contenu de la page dans le monde entier de manière à ce que toutes les requêtes provenant d'un pays soient exécutées sur un serveur local et les requêtes depuis un autre pays, vers la même URL ou le même domaine, sont effectuées contre d'autres serveurs locaux répartissant la charge entre les serveurs locaux et ne surchargeant pas un serveur unique. Un autre point de ce système est que les requêtes ne voyagent pas trop loin.

C'est un travail pour les DNS et l'infrastructure s'appelle Content Delivery Network ou CDN .

Des entreprises comme CloudFlare proposent ce type de services.

DDOS est généralement fait en envoyant une quantité écrasante de paquets au serveur, dans lequel le serveur essaiera frénétiquement de traiter, naturellement. Une fois qu'un pare-feu remarque un DDOS possible, il peut être configuré pour mettre sur liste noire tous les clients avec un PPS (paquets par seconde) suffisamment élevé.

Les filtres peuvent être activés et désactivés à tout moment, de sorte que si vous rencontrez un DDOS, vous pouvez activer un filtre avec un ensemble de règles très strict.

J'aime répondre à la première partie de la question qui est " utiliser un serveur avec beaucoup de ressources (par exemple CPU et mémoire) pour faire évoluer l'application ". Il est recommandé d'effectuer la mise à l'échelle de l'application avant d'effectuer la mise à l'échelle du serveur. Le profilage de l'application peut être décomposé en étapes suivantes:

1. Test de chargement: effectuez des tests de résistance sur votre application via des outils de test de charge tels que pylot.
2. Optimisation des requêtes: deuxième tâche est une requête d'optimisation, c'est-à-dire une requête qui peut fonctionner efficacement pour les petites bases de données mais qui ne parvient pas à évoluer pour les grandes bases de données.
3. Partage d'application: déployer la plupart du contenu d'accès sur un disque plus rapide.

Il y a beaucoup à ajouter à cette liste et une bonne lecture est "Comment faire évoluer une application Web"