Solution 1 :
Un DDOS (ou même un DOS), dans son essence, est un épuisement des ressources. Vous ne pourrez jamais éliminer les goulots d'étranglement, car vous ne pouvez que les repousser plus loin.
Sur AWS, vous avez de la chance car la composante réseau est très forte - il serait très surprenant d'apprendre que le lien amont était saturé. Cependant, le processeur, ainsi que les E/S des disques, sont beaucoup plus faciles à inonder.
Le meilleur plan d'action serait de démarrer une surveillance (locale telle que SAR, à distance avec Nagios et/ou ScoutApp) et certaines installations de journalisation à distance (Syslog-ng). Avec une telle configuration, vous serez en mesure d'identifier quelles ressources sont saturées (socket réseau en raison d'une inondation Syn ; CPU en raison de mauvaises requêtes SQL ou de robots d'indexation ; ram en raison de …). N'oubliez pas d'avoir votre partition de journal (si vous n'avez pas activé la journalisation à distance) sur un volume EBS (pour étudier ultérieurement les journaux).
Si l'attaque passe par les pages Web, le journal d'accès (ou l'équivalent) peut être très utile.
Solution 2 :
Vous pouvez également isoler davantage vos instances EC2 en les plaçant derrière un Elastic Load Balancer et en n'acceptant que le trafic provenant de l'instance ELB. Cela impose une plus grande responsabilité à Amazon pour gérer les attaques DDOS.
Je suppose que vous aurez toujours SSH ouvert à tous, il est donc probable que vous verrez toujours du trafic malveillant y entrer, à moins que vous ne puissiez verrouiller ce port sur certaines adresses IP statiques. Vous pouvez changer le port SSHd en quelque chose de plus obscur (c'est-à-dire autre chose que 22) pour réduire davantage les hits DDOS (la plupart des bots ne vérifient que les ports connus).
Je mentionnerai également fail2ban, qui peut surveiller les journaux et modifier temporairement vos tables d'adresses IP pour bloquer des adresses IP spécifiques (par exemple, s'il y a eu 6 tentatives infructueuses de SSH sur votre hôte à partir d'une seule adresse IP, il peut bloquer cette adresse IP pendant 30 minutes environ). Gardez à l'esprit que (comme Jordan l'a astucieusement commenté) fail2ban n'est probablement pas approprié pour bloquer le trafic proxy (par exemple, celui d'un ELB) car il bloquera l'adresse IP du proxy, pas nécessairement l'adresse IP distante d'origine.
Je ne l'ai pas utilisé, mais Apache mod_evasive peut également valoir la peine d'être étudié; cependant, il peut avoir la même faiblesse que fail2ban en ce qui concerne le blocage basé sur IP.
Solution 3 :
Si vous utilisez Apache, je suggère d'utiliser mod_security. Emballé par la plupart des fournisseurs, l'ensemble de règles de base fait un travail fantastique.
Une autre étape de durcissement consiste à limiter les requêtes au niveau du serveur Web. Nginx., Apache peut accélérer et limiter les requêtes entrantes.
Solution 4 :
La solution que j'utilise pour bloquer les mauvaises activités IP en temps réel provenant d'AWS et d'autres est la suivante ... Dans mon pare-feu CSF dans la configuration des listes de blocage LFD, j'utilise une liste trouvée ici - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Adresses_Live_Database_Real-time
Télécharger la liste noire pour le pare-feu CSF » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
Plus de trafic AWS scandaleusement odieux.
Solution 5 :
Je suis partial, car je travaille pour un réseau de distribution de contenu en tant qu'ingénieur avant-vente en sécurité.
Cependant, l'utilisation d'une solution d'atténuation Ddos sur un réseau de diffusion de contenu garantit que vous ne manquerez jamais de ressources à l'origine. Cela revient à placer un équilibreur de charge F5 devant votre site, mais étendu à des milliers d'emplacements à travers le monde.
Un bon cdn vous permettra de masquer l'origine avec une liste blanche que vous installez sur le pare-feu aws. Ainsi, lorsque les attaquants effectueront leur reconnaissance sur Amazon, votre adresse IP sera vide car tout sera bloqué.
Ainsi, les attaques Ddos sont bloquées lorsque le trafic atteint un nœud aussi proche que possible de l'attaquant. Cela garantit que vous atténuez les attaques Ddos aussi loin que possible de l'actif que vous essayez de protéger.
Un bon cdn peut également effectuer des vérifications de l'état et basculer le trafic vers d'autres emplacements, par exemple un autre ego dans le cul, Azure, un espace rack, une couche logicielle, un dc physique, etc. RUDY, slowpost, slowloris ainsi que sqli, xss, rfi, lfi etc.
Par défaut, le cdn bloque également les attaques de la couche réseau comme les larmes, les attaques icmp, les synfloods, etc. Un cdn est capable d'atténuer les attaques Ddos car ils ont de grandes quantités de capacité pour accepter les demandes, filtrer le mauvais trafic et transmettre le bon trafic. Ainsi les attaques amplifiées comme les attaques volumétriques ntp, DNS, ssdp, chargen et snmp peuvent être bloquées.
La plus grande attaque que j'ai vue à ce jour a été de 321 Gbit/s en juillet 2014. Au cours de cette attaque, il y a également eu une attaque de protocole DNS à 20 Gbit/s. Vous devrez donc vous assurer que votre infrastructure DNS est également résiliente pour résister à un grand nombre de requêtes.
D'après la description que vous avez fournie, il semble que vous ayez été victime d'une attaque par épuisement, où l'attaquant a ouvert de nombreux threads de sorte que tous les threads ont été consommés sur le serveur Web, le serveur d'applications ou le pare-feu. C'est similaire à quelque chose comme un slowpost, slowloris ou RUDY.
Pour bloquer les attaques par épuisement de la couche application, vous devez vous procurer un pare-feu d'application Web (WAF). Un pare-feu réseau typique (y compris le pare-feu amazon et les pare-feu de nouvelle génération) ne pourra pas le bloquer. De nos jours, les pare-feu de travail envoyés ne peuvent bloquer qu'environ 30 % de toutes les attaques de nos jours (novembre 2014).