Estoy bajo DDoS. ¿Que puedo hacer?

Esta es una pregunta canónica sobre la mitigación de DoS y DDoS.

He encontrado un pico de tráfico masivo en un sitio web que me alojan hoy; Estoy recibiendo miles de conexiones por segundo y veo que estoy usando todos los 100Mbps de mi ancho de banda disponible. Nadie puede acceder a mi sitio porque todas las solicitudes de tiempo de espera, y ni siquiera puedo iniciar sesión en el servidor porque SSH veces demasiado! Esto ha ocurrido un par de veces antes, y cada vez que es duró un par de horas y se fue por su cuenta.

Ocasionalmente, mi sitio web tiene otro problema distinto pero relacionado: el promedio de carga de mi servidor (que suele ser alrededor de 0,25) se dispara hasta 20 o más y nadie puede acceder a mi sitio de la misma manera que en el otro caso. También desaparece después de unas horas.

Reiniciar mi servidor no ayuda; ¿Qué puedo hacer para que mi sitio sea accesible de nuevo y qué está pasando?

Relacionado, encontré una vez que por un día o dos, cada vez que comencé mi servicio, consiguió una conexión de una dirección IP particular y se estrelló. Tan pronto como empecé de nuevo, esto sucedió de nuevo y se estrelló de nuevo. ¿Cómo es eso similar, y qué puedo hacer al respecto?

3 Solutions collect form web for “Estoy bajo DDoS. ¿Que puedo hacer?”

Está experimentando un ataque de denegación de servicio. Si ve tráfico procedente de varias redes (IP diferentes en diferentes subredes) tiene una denegación de servicio distribuida (DDoS); Si todo viene del mismo lugar que usted tiene un DoS viejo llano. Puede ser útil comprobar, si es posible; Utilice netstat para comprobar. Esto puede ser difícil de hacer, sin embargo.

Denegación de servicio por lo general cae en un par de categorías: basado en el tráfico, y basado en la carga. El último elemento (con el servicio de bloqueo) es DoS basado en la explotación y es muy diferente.

Si está intentando determinar qué tipo de ataque está ocurriendo, es posible que desee capturar un poco de tráfico (utilizando wireshark, tcpdump o libpcap). Usted debe, si es posible, pero también ser conscientes de que probablemente va a capturar una gran cantidad de tráfico.

En la mayoría de los casos, éstos provendrán de botnets (redes de hosts comprometidos bajo el control central de algún atacante, cuya licitación harán). Esta es una buena manera para que el atacante (muy barato) adquiera el ancho de banda ascendente de un montón de diferentes hosts en diferentes redes para atacar con, mientras que cubre sus pistas. El cañón de iones de baja órbita es un ejemplo de una botnet (a pesar de ser voluntario en lugar de derivado de malware); Zeus es uno más típico.

Basado en el tráfico

Si está bajo un DoS basado en tráfico, está descubriendo que hay tanto tráfico en su servidor que su conexión a Internet está completamente saturada. Hay una alta tasa de pérdida de paquetes al hacer ping a su servidor desde otro lugar, y (dependiendo de los métodos de enrutamiento en uso) a veces también está viendo realmente alta latencia (el ping es alto). Este tipo de ataque suele ser un DDoS.

Si bien este es un ataque realmente "fuerte", y es obvio lo que está pasando, es difícil para un administrador del servidor para mitigar (y básicamente imposible para un usuario de alojamiento compartido para mitigar). Vas a necesitar ayuda de tu ISP; Hágales saber que usted está bajo un DDoS y que podría ser capaz de ayudar.

Sin embargo, la mayoría de los ISP y los proveedores de tránsito de manera proactiva realizar lo que está pasando y publicar una ruta blackhole para su servidor. Lo que esto significa es que publican una ruta a su servidor con el menor costo posible, a través de 0.0.0.0 : hacen que el tráfico a su servidor ya no se puede enrutar en Internet. Estas rutas son típicamente / 32s y eventualmente se eliminan. Esto no te ayuda en absoluto; El propósito es proteger la red del ISP del diluvio. Durante el tiempo, su servidor perderá efectivamente el acceso a Internet.

La única manera que su ISP (o usted, si usted tiene su propio AS) va a ser capaz de ayudar es si están utilizando inteligentes shapers de tráfico que puede detectar y limitar la tasa de tráfico DDoS probable. No todo el mundo tiene esta tecnología. Sin embargo, si el tráfico proviene de una o dos redes, o un host, también podrían bloquear el tráfico que tiene delante.

En resumen, hay muy poco que puedas hacer sobre este problema. La mejor solución a largo plazo es alojar sus servicios en muchos lugares diferentes en Internet que tendrían que ser DDoSed individualmente y simultáneamente, lo que hace que el DDoS mucho más caro. Las estrategias para esto dependen del servicio que usted necesita proteger; DNS puede ser protegido con varios servidores de nombres autoritativos, SMTP con registros MX de copia de seguridad y los intercambiadores de correo, y HTTP con round-robin DNS o multihoming (pero alguna degradación podría ser notable durante la duración de todos modos).

Los equilibradores de carga rara vez son una solución efectiva a este problema, porque el equilibrador de carga en sí está sujeto al mismo problema y simplemente crea un cuello de botella. IPTables u otras reglas de firewall no ayudará porque el problema es que su pipa está saturada. Una vez que las conexiones son vistas por su firewall, ya es demasiado tarde ; El ancho de banda en su sitio se ha consumido. No importa lo que hagas con las conexiones; El ataque se mitiga o termina cuando la cantidad de tráfico entrante vuelve a la normalidad.

Si puede hacerlo, considere utilizar una red de distribución de contenido (CDN) como Akamai, Limelight y CDN77, o utilice un servicio de limpieza de DDoS como CloudFlare o Prolexic. Estos servicios toman medidas activas para mitigar estos tipos de ataques y también tienen tanto ancho de banda disponible en tantos lugares diferentes que inundarlos no es generalmente factible.

Si decide utilizar CloudFlare (o cualquier otro CDN / proxy) recuerde ocultar la IP de su servidor. Si un atacante descubre la IP, puede volver a DDoS su servidor directamente, omitiendo CloudFlare. Para ocultar la IP, su servidor nunca debe comunicarse directamente con otros servidores / usuarios a menos que estén seguros. Por ejemplo, su servidor no debe enviar correos electrónicos directamente a los usuarios. Esto no se aplica si alojas todo tu contenido en el CDN y no tienes un servidor propio.

Además, algunos VPS y los proveedores de alojamiento son mejores para mitigar estos ataques que otros. En general, cuanto más grandes sean, mejor serán en esto; Un proveedor que es muy bien mirado y tiene mucho ancho de banda será naturalmente más resistente, y uno con un equipo de operaciones de red activa y totalmente personal será capaz de reaccionar más rápidamente.

Basado en carga

Cuando experimenta un DDoS basado en carga, observa que el promedio de carga es anormalmente alto (o CPU, RAM o uso de disco, dependiendo de su plataforma y los detalles). Aunque el servidor no parece estar haciendo nada útil, está muy ocupado. A menudo, habrá cantidades copiosas de entradas en los registros que indican condiciones inusuales. Más a menudo que no es esto viene de un montón de lugares diferentes y es un DDoS, pero eso no es necesariamente el caso. Ni siquiera tienen que ser muchos anfitriones diferentes .

Este ataque se basa en hacer que su servicio haga un montón de cosas caras. Esto podría ser algo como abrir un número gigantesco de conexiones TCP y obligarle a mantener el estado para ellos, o cargar archivos excesivamente grandes o numerosos a su servicio, o tal vez hacer búsquedas realmente caras, o realmente hacer cualquier cosa que es costoso de manejar. El tráfico está dentro de los límites de lo que planeó y puede asumir, pero los tipos de solicitudes que se hacen son demasiado caros para manejar tantos .

En primer lugar, que este tipo de ataque es posible es a menudo indicativo de un problema de configuración o un error en su servicio. Por ejemplo, es posible que el registro excesivamente detallado esté activado y puede estar almacenando registros en algo que es muy lento para escribir. Si alguien se da cuenta de esto y hace un montón de algo que hace que usted escriba cantidades copiosas de registros en el disco, su servidor se ralentizará a un rastreo. Su software también podría estar haciendo algo extremadamente ineficiente para ciertos casos de entrada; Las causas son tan numerosas como hay programas, pero dos ejemplos sería una situación que hace que su servicio no cierre una sesión que de otra manera terminó, y una situación que hace que genere un proceso hijo y lo deje. Si terminas con decenas de miles de conexiones abiertas con el estado para realizar un seguimiento, o decenas de miles de procesos secundarios, te encontrarás con problemas.

Lo primero que puedes hacer es usar un firewall para eliminar el tráfico . Esto no siempre es posible, pero si hay una característica que puede encontrar en el tráfico entrante (tcpdump puede ser agradable para esto si el tráfico es ligero), puede dejarlo en el cortafuegos y ya no causará problemas. La otra cosa a hacer es fijar el fallo en su servicio (consiga en tacto con el vendedor y esté preparado para una experiencia larga de la ayuda).

Sin embargo, si se trata de un problema de configuración, empiece allí . Bajar el registro de los sistemas de producción a un nivel razonable (dependiendo del programa, éste suele ser el predeterminado, y normalmente implica asegurarse de que los niveles de "depuración" y "detallado" del registro estén desactivados; Detalle fino, su registro es demasiado detallado). Además, compruebe los límites de los procesos y solicitudes de los hijos , posiblemente las solicitudes entrantes, las conexiones por IP y el número de procesos secundarios permitidos, según corresponda.

No hace falta decir que cuanto más configurado y mejor provisto su servidor, más difícil será este tipo de ataque. Evite ser tacaño con RAM y CPU en particular. Asegúrese de que sus conexiones a cosas como bases de datos back-end y almacenamiento en disco sean rápidas y confiables.

Basado en la explotación

Si su servicio se bloquea misteriosamente extremadamente rápido después de haber surgido, especialmente si puede establecer un patrón de solicitudes que preceden al bloqueo y la solicitud es atípica o no coincide con los patrones de uso esperados, es posible que experimente un DoS basado en vulnerabilidades. Esto puede venir de tan pocos como sólo un host (con prácticamente cualquier tipo de conexión a Internet), o muchos hosts.

Esto es similar a un DoS basado en la carga en muchos aspectos, y tiene básicamente las mismas causas y mitigaciones. La diferencia es simplemente que en este caso, el error no causa que el servidor sea un desperdicio, sino que muera. El atacante suele explotar una vulnerabilidad de falla remota, como una entrada distorsionada que causa una negación nula o algo en su servicio.

Maneje esto de forma similar a un ataque de acceso remoto no autorizado. Firewall contra los hosts de origen y el tipo de tráfico si se puede fijar. Utilice la validación de proxies inversa, si procede. Reúna pruebas forenses (trate de capturar parte del tráfico), presente un boleto de error con el proveedor y considere presentar una queja de abuso (o queja legal) contra el origen también.

Estos ataques son bastante baratos de montar, si se puede encontrar una hazaña, y pueden ser muy potentes, pero también relativamente fácil de rastrear y detener. Sin embargo, las técnicas que son útiles contra los DDoS basados ​​en tráfico son generalmente inútiles contra el DoS basado en la explotación.

Cambiar su dominio para ir a un agujero negro como 0.0.0.0 por un período corto.

Hable con su servidor y ver si puede emitir con otra dirección IP como una forma temporal de acceder al servidor o ver si el servidor tiene acceso a la consola remota (como si estuviera sentado frente a ella). Desde aquí puedes ver si es una dirección IP única y bloquearla desde el sitio o un ataque distribuido.

Si usted es una empresa, tiene muchas opciones. Si eres un tipo pequeño como yo, alquilar un VPS o un servidor dedicado para servir a un sitio web pequeño, el costo puede llegar a ser rápidamente prohibitivo.

Desde mi experiencia, creo que la mayoría de los proveedores dedicados y de VPS no establecerán reglas especiales de cortafuegos sólo para su servidor. Pero hoy en día, usted tiene algunas opciones.

CDN

Si está ejecutando un servidor web, considere colocarlo detrás de un CDN como CloudFlare o Amazon CloudFront.

Las CDN son caras. Para mantener el costo bajo control, sirva archivos grandes (imágenes grandes, audio, video) directamente desde su servidor en lugar de a través de la CDN. Sin embargo, esto puede exponer la dirección IP del servidor a los atacantes.

Nube privada

Las nubes privadas por lo general son soluciones empresariales caras, pero Amazon VPC cuesta casi nada establecer. Sin embargo, el ancho de banda de Amazon en general es caro. Si puede permitirse eso, puede configurar el grupo de seguridad de Amazon VPC y la ACL de red para bloquear el tráfico antes de que llegue a su instancia. Debe bloquear todos los puertos excepto el puerto del servidor TCP.

Tenga en cuenta que un atacante todavía puede atacar el puerto del servidor TCP. Si se trata de un servidor web, entonces considerar el uso de algo como nginx que utiliza IO no bloqueante y puede manejar un gran número de conexiones. Aparte de eso, no hay mucho que puedas hacer al lado de asegurarte de ejecutar la última versión del software de servidor.

Cuando su puerto TCP es atacado y todo lo demás falla

Esta es una solución que desarrollé y que se aplica a servidores que no pueden ocultarse detrás de un CDN, como WebSocket, contenido de medios / servidores de streaming. CloudFlare es compatible con WebSocket pero sólo para empresas en este momento.

El objetivo es cambiar el puerto de escucha TCP lo suficientemente rápido como para que una botnet no pueda mantenerse al día, digamos una vez cada 10 segundos. Esto se logra utilizando un simple programa proxy que realiza el roaming del puerto. La secuencia de puertos es pseudoaleatoria, pero debe basarse en la hora del servidor. Y el algoritmo para calcular el tiempo y el puerto del servidor se debe ocultar en su código del javascript / flash del cliente. El programa también debe modificar el firewall a medida que cambia el puerto de escucha, y el cortafuegos debe tener estado. Si alguien está interesado, subiré mi script node.js que funciona con Amazon, a GitHub.

  • Mi servidor sigue siendo vulnerable a heartbleed incluso después de que actualice OpenSSL
  • Habilitar soporte hash basado en blowfish para la cripta
  • ¿Por qué necesitaría un servidor de seguridad si mi servidor está bien configurado?
  • ¿Es posible limitar una clave EC2 a sólo ec2-asociar dirección?
  • ¿Cómo evitar que una violación de seguridad tome sus copias de seguridad en línea con él?
  • Aislamiento de los virtuales de Apache del resto del sistema
  • Agregar un usuario al grupo "Team Foundation Service Accounts" en TFS
  • ¿Cómo puedo consultar todas las reglas de selinux / contextos de archivos por defecto / etc que afectan a un tipo
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.