49 votes

Comment prévenir une attaque DDOS sur Amazon EC2 ?

L'un des serveurs que j'utilise est hébergé sur le nuage Amazon EC2. Tous les quelques mois, il semble que ce serveur soit victime d'une attaque DDOS. Cela ralentit considérablement le serveur. Après environ 30 minutes, et parfois un redémarrage, tout revient à la normale.

Amazon dispose de groupes de sécurité et d'un pare-feu, mais quels sont les autres éléments à mettre en place sur un serveur EC2 pour atténuer ou prévenir une attaque ?

J'ai appris à partir de questions similaires :

  • Limiter le nombre de requêtes/minute (ou secondes) provenant d'une adresse IP particulière par le biais de tables IP (ou peut-être UFW ?).
  • Disposer de ressources suffisantes pour survivre à une telle attaque, ou -
  • Construire éventuellement l'application web de manière à ce qu'elle soit élastique / qu'elle dispose d'un équilibreur de charge élastique et qu'elle puisse rapidement s'adapter 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 façon séquentielle afin que les requêtes lentes n'alourdissent pas le système.

Que me manque-t-il encore ? J'aimerais avoir des informations sur des outils spécifiques et des options de configuration (encore une fois, j'utilise Linux ici), et/ou tout ce qui est spécifique à Amazon EC2.

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

37voto

rahul pandey Points 121

Un DDOS (ou même un DOS), dans son essence, est un épuisement des ressources. Vous ne pourrez jamais éliminer les goulets d'étranglement, car vous ne pouvez que les éloigner.

Sur AWS, vous avez de la chance car la composante réseau est très forte - il serait très surprenant d'apprendre que la liaison en amont est saturée. Cependant, l'unité centrale, ainsi que les entrées/sorties des disques, sont beaucoup plus faciles à inonder.

La meilleure solution consiste à mettre en place un système de surveillance (local comme SAR, à distance avec Nagios et/ou ScoutApp) et un système de journalisation à distance (Syslog-ng). Avec une telle configuration, vous serez en mesure d'identifier les ressources qui sont saturées (socket réseau à cause de Syn flood ; CPU à cause de mauvaises requêtes SQL ou de crawlers ; ram à cause de ). N'oubliez pas d'avoir votre partition de log (si vous n'avez pas activé le logging à distance) sur un volume EBS (pour étudier les logs plus tard).

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

25voto

Accipitridae Points 2595

Vous pouvez également isoler davantage vos instances EC2 en les plaçant derrière un équilibreur de charge élastique (Elastic Load Balancer) et en n'acceptant que le trafic provenant de l'instance ELB. De cette manière, il incombe davantage à Amazon de gérer les attaques DDOS.

Je suppose que vous aurez toujours SSH ouvert à tous, il est donc probable que vous verrez toujours du trafic frauduleux entrer par là, à moins que vous ne puissiez verrouiller ce port à des IP statiques. Vous pourriez changer le port SSHd pour quelque chose de plus obscur (c'est-à-dire autre que 22) afin de réduire davantage les attaques DDOS (la plupart des robots 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 d'accès SSH à 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 provenant d'un ELB) parce qu'il bloquera l'IP du proxy, pas nécessairement l'IP distante d'origine.

Je ne l'ai pas utilisé, mais Apache mod_evasive peut également être intéressant ; cependant, il peut avoir les mêmes faiblesses que fail2ban en ce qui concerne le blocage basé sur l'IP.

5voto

Shyam Sundar C S Points 1063

Si vous utilisez Apache, je vous suggère d'utiliser mod_security . Emballé par la plupart des vendeurs, le jeu de règles de base fait un travail fantastique.

Une autre mesure de renforcement consiste à limiter les demandes au niveau du serveur web. Nginx ., Apache peut étrangler et limiter les requêtes entrantes.

2voto

Jerry P. Points 1

La solution que j'utilise pour bloquer en temps réel les IP de mauvaise activité 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_Addresses_Live_Database_Real-time

Télécharger Blacklist pour CSF Firewall " http://myip.ms/files/blacklist/csf/latest_blacklist.txt

Il n'y a plus de trafic de l'AWS qui soit outrageusement odieux.

2voto

Rip Points 1

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

Cependant, l'utilisation d'une solution d'atténuation du Ddos sur un réseau de diffusion de contenu permet de ne jamais manquer de ressources à l'origine. Cela revient à placer un équilibreur de charge F5 devant votre site, mais réparti sur des milliers de sites à travers le monde.

A

S

A

B

T

F

T

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X