Solución 1:
Un DDOS (o incluso un DOS), en esencia, es un agotamiento de recursos. Nunca podrá eliminar los cuellos de botella, ya que solo puede alejarlos más.
En AWS, tiene suerte porque el componente de red es muy fuerte:sería muy sorprendente saber que el enlace ascendente estaba saturado. Sin embargo, la CPU, así como las E/S de los discos, son mucho más fáciles de saturar.
El mejor curso de acción sería iniciar algún monitoreo (local como SAR, remoto con Nagios y/o ScoutApp) y algunas instalaciones de registro remotas (Syslog-ng). Con tal configuración, podrá identificar qué recursos se saturan (socket de red debido a Syn flood; CPU debido a consultas SQL incorrectas o rastreadores; ram debido a...). No olvide tener su partición de registro (si no tiene habilitado el registro remoto) en un volumen de EBS (para estudiar los registros más adelante).
Si el ataque llega a través de las páginas web, el registro de acceso (o equivalente) puede ser muy útil.
Solución 2:
También puede aislar aún más sus instancias EC2 colocándolas detrás de un Elastic Load Balancer y aceptando solo el tráfico de la instancia ELB. Esto pone más responsabilidad en Amazon para administrar los ataques DDOS.
Supongo que todavía tendrá SSH abierto para todos, por lo que es probable que aún vea tráfico no autorizado, a menos que pueda bloquear ese puerto a algunas direcciones IP estáticas. Puede cambiar el puerto SSHd a algo más oscuro (es decir, algo que no sea 22) para reducir aún más los accesos DDOS (la mayoría de los bots solo verifican los puertos conocidos).
También mencionaré fail2ban, que puede monitorear registros y modificar temporalmente sus tablas de ip para bloquear IP específicas (por ejemplo, si ha habido 6 intentos fallidos de SSH en su host desde una sola dirección IP, puede bloquear esa IP por 30 minutos más o menos). Tenga en cuenta que (como comentó astutamente Jordan) fail2ban probablemente no sea apropiado para bloquear el tráfico proxy (por ejemplo, el de un ELB) porque bloqueará la IP del proxy, no necesariamente la IP remota original.
No lo he usado, pero también puede valer la pena investigar Apache mod_evasive; sin embargo, puede tener la misma debilidad que fail2ban cuando se trata de bloqueo basado en IP.
Solución 3:
Si está utilizando Apache, sugiero usar mod_security. Empaquetado por la mayoría de los proveedores, el conjunto de reglas básicas hace un trabajo fantástico.
Otro paso de fortalecimiento es limitar las solicitudes a nivel del servidor web. Nginx., Apache puede acelerar y limitar las solicitudes entrantes.
Solución 4:
La solución que utilizo para bloquear las IP de mala actividad en tiempo real que salen de AWS y otras es esta... En mi CSF Firewall en la configuración de LFD Blocklists, utilizo una lista que se encuentra aquí:http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time
Descargar Blacklist para CSF Firewall » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
No más tráfico de AWS escandalosamente desagradable.
Solución 5:
Soy parcial, ya que trabajo para una red de entrega de contenido como ingeniero de preventa de seguridad.
Sin embargo, aprovechar una solución de mitigación de Ddos en una red de entrega de contenido garantiza que nunca se quede sin recursos en el origen. Es similar a colocar un balanceador de carga F5 frente a su sitio, pero se extendió a miles de ubicaciones en todo el mundo.
Un buen cdn le permitirá encubrir el origen con una lista blanca que instale en el firewall aws. Entonces, cuando los atacantes realicen su reconocimiento en Amazon, su dirección IP aparecerá vacía ya que todo estará bloqueado.
Entonces, los ataques Ddos se bloquean cuando el tráfico llega a un nodo lo más cerca posible del atacante. Esto garantiza que mitigará los ataques Ddos lo más lejos posible del activo que intenta proteger.
Un buen cdn también puede realizar comprobaciones de estado y conmutación por error del tráfico a otras ubicaciones, por ejemplo, otro ego en el culo, Azure, espacio de rack, capa blanda, un centro de datos físico, etc. También debe tener un WAF para asegurarse de que puede bloquear los ataques de agotamiento de la capa de aplicación como RUDY, slowpost, slowloris, así como sqli, xss, rfi, lfi, etc.
De forma predeterminada, el cdn también bloquea los ataques de la capa de red como teardrop, ataques icmp, synfloods, etc. Los ataques de amplificación como los ataques volumétricos ntp, DNS, ssdp, chargen y snmp pueden bloquearse.
El ataque más grande que he visto hasta la fecha ha sido de 321 gbps en julio de 2014. Durante este ataque también hubo un ataque de protocolo DNS a 20 gbps. Por lo tanto, deberá asegurarse de que su infraestructura de DNS también sea resistente para soportar una gran cantidad de solicitudes.
Según la descripción que proporcionó, parece que estuvo sujeto a un ataque de agotamiento, donde el atacante abrió muchos subprocesos de modo que todos los subprocesos se consumieron en el servidor web, el servidor de aplicaciones o el firewall. Es similar a algo así como un poste lento, slowloris o RUDY.
Para bloquear los ataques de agotamiento de la capa de aplicación, deberá obtener un firewall de aplicaciones web (WAF). Un firewall de red típico (incluido el firewall de Amazon y los firewalls de próxima generación) no podrá bloquearlo. Los firewalls de trabajo enviados en estos días solo pueden bloquear alrededor del 30% de todos los ataques en estos días (noviembre de 2014).