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

Encontré un pico de tráfico masivo en un sitio web que alojo hoy; Estoy obteniendo miles de conexiones por segundo y veo que estoy usando todos los 100 Mbps de mi ancho de banda disponible. Nadie puede acceder a mi sitio porque se agotaron todas las solicitudes, y ni siquiera puedo iniciar sesión en el servidor porque SSH también agota el tiempo de espera. Esto ha sucedido un par de veces antes, y cada vez ha durado un par de horas y ha desaparecido por sí solo.

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

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

En relación con esto, descubrí una vez que durante un día o dos, cada vez que comencé mi servicio, tenía una conexión desde una dirección IP en particular y luego fallaba. Tan pronto como comencé de nuevo, esto sucedió nuevamente y se estrelló nuevamente. ¿En qué se parece eso y qué puedo hacer al respecto?

Está experimentando un ataque de denegación de servicio. Si ve tráfico proveniente de múltiples redes (diferentes IP en diferentes subredes), tiene una denegación de servicio distribuida (DDoS); si todo proviene del mismo lugar, tiene un DoS simple y antiguo. Puede ser útil verificar, si puede; use netstat para verificar. Sin embargo, esto puede ser difícil de hacer.

La denegación de servicio generalmente se divide en un par de categorías: basadas en el tráfico y en la carga. El último elemento (con el servicio de bloqueo) es DoS basado en exploits y es bastante diferente.

Si está tratando de precisar qué tipo de ataque está ocurriendo, es posible que desee capturar algo de tráfico (usando wireshark, tcpdump o libpcap). Debería, si es posible, pero también tener en cuenta que probablemente capturará una gran cantidad de tráfico.

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

Basado en el tráfico

Si está bajo un DoS basado en el 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 se observa una latencia realmente alta (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á sucediendo, es difícil de mitigar para un administrador del servidor (y básicamente imposible de mitigar para un usuario de hosting compartido). Necesitará ayuda de su ISP; hágales saber que usted está bajo un DDoS y podrían ayudarlo.

Sin embargo, la mayoría de los ISP y proveedores de tránsito se darán cuenta de manera proactiva de lo que está sucediendo y publicarán una ruta de agujero negro 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 sea enrutable 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. Mientras dure, su servidor perderá efectivamente el acceso a Internet.

La única forma en que su ISP (o usted, si tiene su propio AS) será capaz de ayudarlo si está utilizando modeladores de tráfico inteligentes que pueden detectar y limitar el tráfico probable de DDoS. No todos tienen 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 pueda hacer sobre este problema. La mejor solución a largo plazo es alojar sus servicios en muchas ubicaciones diferentes en Internet, que tendrían que ser DDoS de forma individual y simultánea, haciendo que el DDoS sea mucho más costoso. Las estrategias para esto dependen del servicio que necesita proteger; El DNS se puede proteger con múltiples servidores de nombres autorizados, SMTP con registros MX de respaldo e intercambiadores de correo, y HTTP con DNS de round-robin o multihoming (pero de todos modos puede notarse cierta degradación durante el tiempo que sea necesario).

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

Si puede hacerlo, considere usar una red de distribución de contenido (CDN) como Akamai, Limelight y CDN77, o use un servicio de limpieza 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 generalmente no es posible inundarlos.

Si decide usar CloudFlare (o cualquier otro CDN / proxy) recuerde ocultar la IP de su servidor. Si un atacante descubre la IP, puede nuevamente DDoS su servidor directamente, sin pasar por 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 aloja todo su contenido en el CDN y no tiene un servidor propio.

Además, algunos proveedores de VPS y hosting son mejores para mitigar estos ataques que otros. En general, cuanto más grandes sean, mejor serán en esto; un proveedor que esté muy bien entrenado y tenga mucho ancho de banda será naturalmente más resistente, y uno con un equipo de operaciones de red activo y con personal completo podrá reaccionar más rápidamente.

Basado en la carga

Cuando experimente un DDoS basado en la carga, notará que el promedio de carga es anormalmente alto (o uso de CPU, RAM o disco, dependiendo de su plataforma y los detalles). Aunque el servidor no parece estar haciendo nada útil, está muy ocupado. A menudo, habrá grandes cantidades de entradas en los registros que indican condiciones inusuales. La mayoría de las veces esto proviene de muchos lugares diferentes y es un DDoS, pero ese no es necesariamente el caso. Ni siquiera tiene que haber muchos hosts diferentes .

Este ataque se basa en hacer que su servicio haga muchas cosas costosas. Esto podría ser algo así como abrir una cantidad gigantesca de conexiones TCP y forzarlo a mantener el estado para ellas, o cargar archivos excesivamente grandes o numerosos a su servicio, o tal vez hacer búsquedas realmente costosas, o realmente hacer algo que sea 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 realizan son demasiado costosos para manejar muchos de ellos .

En primer lugar, que este tipo de ataque es posible es a menudo indicativo de un problema de configuración o errora su servicio Por ejemplo, puede tener activado el registro excesivamente detallado y puede estar almacenando registros en algo en lo que es muy lento escribir. Si alguien se da cuenta de esto y hace muchas cosas que le hacen escribir grandes cantidades de registros en el disco, su servidor se ralentizará. 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ían una situación que hace que su servicio no cierre una sesión que de otro modo se haya terminado, y una situación que hace que genere un proceso secundario y lo abandone. Si termina con decenas de miles de conexiones abiertas con estado para realizar un seguimiento o decenas de miles de procesos secundarios, se encontrará con problemas.

Lo primero que puede hacer es utilizar 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 bueno para esto si el tráfico es ligero), puede soltarlo en el firewall y ya no causará problemas. La otra cosa que debe hacer es corregir el error en su servicio (póngase en contacto con el proveedor y prepárese para una larga experiencia de soporte).

Sin embargo, si se trata de un problema de configuración, comience allí . Desactive el inicio de sesión en los sistemas de producción a un nivel razonable (dependiendo del programa, este suele ser el predeterminado, y por lo general implicará asegurarse de que los niveles de inicio de sesión "depuración" y "detallado" estén desactivados; si todo lo que hace un usuario se registra exactamente fino detalle, su registro es demasiado detallado). Además, verifique el proceso secundario y los límites de solicitud , posiblemente acelere las solicitudes entrantes, las conexiones por IP y la cantidad de procesos secundarios permitidos, según corresponda.

No hace falta decir que cuanto mejor configurado y mejor provisto esté 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 de fondo y almacenamiento en disco sean rápidas y confiables.

Basado en exploits

Si su servicio se cuelga misteriosamente extremadamente rápido después de ser presentado, particularmente 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 esté experimentando un DoS basado en exploits. Esto puede provenir de tan solo un host (con casi cualquier tipo de conexión a Internet), o de 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 hace que su servidor sea un desperdicio, sino que muera. El atacante generalmente está explotando una vulnerabilidad de bloqueo remota, como una entrada confusa que causa una anulación de referencia o algo en su servicio.

Maneje esto de manera similar a un ataque de acceso remoto no autorizado. Cortafuegos contra los hosts de origen y el tipo de tráfico si se pueden fijar. Utilice la validación de proxies inversos si corresponde. Reúna evidencia forense (intente capturar parte del tráfico), presente una multa por error con el proveedor y considere presentar también una queja de abuso (o queja legal) contra el origen.

Estos ataques son bastante baratos de montar, si se puede encontrar un exploit, y pueden ser muy potentes, pero también relativamente fáciles de rastrear y detener. Sin embargo, las técnicas que son útiles contra los DDoS basados ​​en el tráfico son generalmente inútiles contra los DoS basados ​​en exploits.

Si eres una empresa, tienes muchas opciones. Si eres un tipo pequeño como yo, alquilando un VPS o un servidor dedicado para servir un sitio web pequeño, el costo puede volverse rápidamente prohibitivo.

Desde mi experiencia, creo que la mayoría de los proveedores dedicados y VPS no establecerán reglas de firewall especiales solo para su servidor. Pero hoy en día, tienes 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 hacerlo a través de CDN. Sin embargo, esto puede exponer la dirección IP de su servidor a los atacantes.

Nube privada

Las nubes privadas generalmente son soluciones empresariales costosas, pero Amazon VPC cuesta casi nada de configurar. Sin embargo, el ancho de banda de Amazon en general es costoso. Si puede permitírselo, 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 aún puede atacar el puerto de su servidor TCP. Si se trata de un servidor web, considere usar algo como nginx que use IO sin bloqueo y pueda manejar una gran cantidad de conexiones. Más allá de eso, no hay mucho que pueda hacer además de asegurarse de ejecutar la última versión del software del servidor.

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

Esta es una solución que desarrollé que se aplica a los servidores que no son web que no pueden esconderse detrás de una CDN, como WebSocket, contenido de medios / servidores de transmisión. CloudFlare admite WebSocket pero solo para empresas en este momento.

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

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

Hable con su servidor y vea si pueden emitirle otra dirección IP como una forma temporal de acceder al servidor o si el servidor tiene acceso remoto a la consola (como si estuviera sentado frente a él). Desde aquí puede ver si es una única dirección IP y bloquearla del sitio o un ataque distribuido.

Cuando estás bajo ataque DDoS, tu ISP puede ayudarte más, pero si no tienen protección DDoS, es muy probable que estés fuera de servicio hasta que se detenga el ataque. Por lo general, verán la dirección IP atacada y anularán la red en su enrutador ascendente. Si no tiene mucho tráfico, hay muchos servicios en línea para la protección DDoS, donde su tráfico se redirige, se filtra y se envía de vuelta a su servidor.

Tenemos la misma situación similar antes. A continuación se muestra lo que hicimos.

Primero, desconecte el cable de red de su servidor. Ahora, verifique que los servicios de su servidor vuelvan al comportamiento normal mirando el monitor de rendimiento y el administrador de tareas. De lo contrario, escanee su servidor con software malwarebytes para asegurarse de que su servidor esté limpio. Este paso generalmente asegurará que su servidor desconectado vuelva a la normalidad nuevamente.

Luego, ¿tienes un firewall instalado? En caso afirmativo, ¿renovó la suscripción? Asegúrese de habilitar la función de intrusión IPS en el firewall. Solo renovando la suscripción al firewall resolvió nuestro ataque DDOS.

Aprendimos que debemos renovar la suscripción de seguridad (por ejemplo, firwall o antivirus) y no tomarlo a la ligera. El ataque DDOS ocurre todos los días y también puede sucederle a las pequeñas empresas. Espero que esto ayude.