Comment puis-je empêcher une attaque DDOS sur Amazon EC2?

L'un des serveurs que j'utilise est hébergé sur le cloud Amazon EC2. Tous les quelques mois, nous semblons avoir une attaque DDOS sur ce serveur. Cela ralentit le serveur incroyablement. Après environ 30 minutes, et parfois un redémarrage plus tard, tout est revenu à la normale.

Amazon a des groupes de sécurité et un pare-feu, mais quoi d'autre dois-je mettre en place sur un serveur EC2 pour atténuer ou empêcher une attaque?

De questions similaires, j'ai appris:

• Limiter le taux de requêtes / minute (ou secondes) d'une adresse IP particulière via quelque chose comme des tables IP (ou peut-être UFW?)
• Avoir assez de ressources pour survivre à une telle attaque - ou -
• Créez éventuellement l’application Web pour qu’elle soit élastique / dispose d’un équilibreur de charge élastique et puisse évoluer rapidement pour répondre à une demande aussi élevée)
• Si vous utilisez mySql, configurez les connexions mySql de manière à ce qu'elles s'exécutent de manière séquentielle afin que les requêtes lentes n'enlèvent pas le système.

Que manque-t-il d'autre? J'aimerais des informations sur des outils spécifiques et des options de configuration (ici encore, en utilisant Linux), et / ou sur tout ce qui est spécifique à Amazon EC2.

ps: Des notes sur la surveillance de DDOS seraient également les bienvenues - peut-être avec Nagios? ;)

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 pourrez que les éloigner davantage.

Sur AWS, vous avez de la chance car le composant réseau est très puissant. Il serait très surprenant d'apprendre que le lien en amont était saturé. Cependant, le processeur, ainsi que les disques d'E / S, sont beaucoup plus faciles à saturer.

Le meilleur plan d'action consisterait à lancer une surveillance (locale, telle que SAR, à distance avec Nagios et / ou ScoutApp) et des fonctions de journalisation à distance (Syslog-ng). Avec une telle configuration, vous serez en mesure d'identifier les ressources saturées (socle réseau en raison de Syn flood; processeur en raison de requêtes SQL ou de moteurs de balayage incorrects; mémoire 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 les journaux ultérieurement).

Si l'attaque passe par les pages Web, le journal des accès (ou son équivalent) peut être très utile.

Vous pouvez également isoler davantage vos instances EC2 en les plaçant derrière un Elastic Load Balancer et en acceptant uniquement le trafic provenant de l'instance ELB. Cela oblige davantage Amazon à gérer les attaques DDOS.

Je suppose que SSH sera toujours ouvert à tous. Il est donc probable que du trafic non autorisé parvienne à destination, à moins que vous ne puissiez verrouiller ce port sur des 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 ip pour bloquer des adresses IP spécifiques (par exemple, s'il y a eu 6 tentatives infructueuses de connexion SSH dans votre hôte à partir d'une seule adresse IP, il peut bloquer cette adresse IP pendant 30 minutes ou plus). Gardez à l'esprit que (comme Jordan l'a astucieusement commenté), fail2ban n'est probablement pas approprié pour bloquer le trafic traité par proxy (par exemple, celui provenant 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 les mêmes faiblesses que fail2ban en matière de blocage basé sur IP.

Si vous utilisez Apache, je suggère d'utiliser mod_security . Emballés par la plupart des fournisseurs, les règles de base font un travail fantastique.

Une autre étape de renforcement consiste à limiter les demandes au niveau du serveur Web. Nginx ., Apache peut limiter et limiter les demandes entrantes.

La solution que j’utilise pour bloquer en temps réel les activités IP défectueuses sortant d’AWS et d’autres est la suivante ... Dans mon pare-feu CSF dans la configuration de LFD Blocklists, j’utilise une liste trouvée ici - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time

Télécharger la liste noire du pare-feu CSF » http://myip.ms/files/blacklist/csf/latest_blacklist.txt

Plus de trafic AWS scandaleusement odieux.

Je suis partial, car je travaille pour un réseau de diffusion de contenu en tant qu'ingénieur en prévente de la sécurité.

Cependant, l'utilisation d'une solution d'atténuation de Ddos sur un réseau de diffusion de contenu garantit que vous ne manquerez jamais de ressources à l'origine. Cela équivaut à placer un équilibreur de charge F5 devant votre site, mais à des milliers d'endroits dans le monde.

Un bon cdn vous permettra de masquer l'origine avec une liste blanche que vous installerez sur le pare-feu d'aws. Ainsi, lorsque les attaquants effectuent leur reconnaissance sur Amazon, votre adresse IP apparaîtra vide car tout sera bloqué.

Les attaques Ddos sont donc bloquées lorsque le trafic atteint un nœud aussi proche que possible de l'attaquant. Cela vous permet d'atténuer les attaques Ddos aussi loin que l'actif que vous essayez de protéger.

Un bon cdn peut également effectuer des contrôles de l’état et du trafic de basculement vers d’autres emplacements, par exemple un autre ego sur le cul, Azure, l’espace de rack, une couche logicielle, un contrôleur de domaine physique, etc. RUDY, slowpost, slowloris ainsi que sqli, xss, rfi, lfi etc.

Par défaut, cdn bloque également les attaques de la couche réseau telles que les attaques en forme de larme, les attaques icmp, les synfloods, etc. Donc, les attaques amplificatrices 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é 321 Gbps en juillet 2014. Au cours de cette attaque, il y a eu également une attaque de protocole DNS à 20 Gbps. Vous devez donc vous assurer que votre infrastructure DNS est également résiliente pour résister à un grand nombre de demandes.

D'après la description que vous avez fournie, il semble que vous ayez fait l'objet d'une attaque par épuisement. Un attaquant a ouvert de nombreux threads de manière à ce que tous les threads soient consommés sur le serveur Web, le serveur d'applications ou le pare-feu. Cela ressemble à quelque chose comme un slowpost, slowloris ou RUDY.

Pour bloquer les attaques par épuisement de la couche d'application, vous devez vous procurer un pare-feu pour applications Web (WAF). Un pare-feu réseau typique (y compris le pare-feu amazonien et les pare-feu de nouvelle génération) ne pourra pas le bloquer. Les pare-feu de travail envoyés de nos jours ne peuvent bloquer qu'environ 30% de toutes les attaques de ces jours (novembre 2014).

Voici un outil que j'ai conçu pour ceux qui cherchent à utiliser Fail2Ban sur aws avec apache, ELB et ACL: https://github.com/anthonymartin/aws-acl-fail2ban

C'est utile pour détecter et prévenir les attaques par déni de service et l'utilisation abusive d'instances ec2.

Le pare-feu du serveur de configuration est le meilleur que j'ai jamais vu pour l'atténuation des attaques DDoS dans les machines virtuelles logicielles basées sur EC2. Si vous combinez la fonctionnalité syslog, elle peut protéger contre un environnement à charge équilibrée.

http://configserver.com/cp/csf.html