Digamos que tienes una tienda. Todos los días, es posible que obtengas unos cientos de clientes.

Un día, llegan decenas de miles de personas que entran en la línea de salida, compran una baratija y luego vuelven a la fila para repetir.

Obviamente, está perdiendo negocios de clientes auténticos que deben esperar horas en línea.

Ahora, contrata a un guardia de seguridad en la entrada para verificar que estos clientes cumplan con algunos criterios.

Sin embargo, todavía hay decenas de miles de personas que quieren entrar. La única diferencia es que ahora, todos deben pasar por seguridad.

Te das cuenta de que, desde la perspectiva del cliente auténtico, aún esperas horas en línea, ¡solo que ahora es solo para pasar la seguridad!

TL; DR Las IP de origen múltiple son las que las hacen tan difíciles de defender.

Para la respuesta más larga miramos el nombre. D DoS ataque. Esa primera D significa distribuido. En otras palabras, no hay una IP para bloquear. O dos, o tres, o incluso cuatro ... Hay cientos o miles de IP únicas.

Por lo general, los ataques DDoS se originan a partir de un pirata informático que controla una botnet o una red de máquinas zombie. El atacante emitirá un comando a todos los bots que les indiquen que realicen solicitudes para un recurso / URI en particular. La gran cantidad de solicitudes abruma el servidor y lo elimina.

Además de la excelente respuesta de @Hollowproc, las "direcciones" reales que se utilizan como fuentes a menudo se falsifican en un ataque como este. Un host atacante puede pretender ser cualquier número de otras IP, especialmente en un ataque basado en UDP, como el que se usa contra los proveedores de DNS.

Hay una solución para esto llamada BCP 38 , o el filtrado de ingreso de red. Si todo el mundo se juntara, tuviera una coca cola e implementara controles para bloquear las direcciones falsas donde ingresaban a la red, estos ataques ya no podrían falsificar el tráfico. Los propios Dyn lo mencionan como una defensa útil .

Tenga en cuenta que implementar una defensa en muchos puntos de origen tiene la ventaja de ser escalable; Los requisitos de bloque individuales no son de tamaño oneroso. Sin embargo, son onerosos en el sentido de que más personas deben hacer lo correcto por algo que no les afecta directa y negativamente ... la naturaleza humana ha impedido que esta solución alcance una masa crítica durante más de una década.

Es posible que el impacto creciente de los ataques DDoS estimule una mayor adopción del filtrado de ingreso de red ... Internet trata el daño como censura y encamina a su alrededor :)

El problema con un DDoS es de dos partes:

1) Dado que los bots son tantos, no tienen que tener un acelerador de solicitud tan alto como un solo bot, y por lo tanto no son tan fáciles de reconocer como los bots.

2) Todo lo que ves son direcciones IP (y User-Agent s dependiendo de cómo filtres el tráfico del bot). Cualquier dirección IP podría ser un bot DDoS y cualquier dirección IP podría ser un visitante legítimo. Algunas direcciones IP tendrán un bot DDoS y un visitante legítimo. ¿Qué haces?

Digamos que su sitio puede manejar 1000 req / sy un visitante nunca hace más de 10 req / s. Un bot a 100 req / s es fácil de bloquear, diez bots a 100 req / s son fáciles de bloquear. Pero 200 bots a 5 req / s son difíciles de bloquear, porque se están comportando correctamente.

200 bots a 100 req / s también son difíciles de bloquear, ya que ni siquiera pueden hacer más de 5 req / s, lo que parece que se comportan correctamente. Esta situación es mucho peor que 200 bots a 5 req / s, ya que un visitante tiene ahora 10 entre 10010 solicitudes que intentan integrarse en la conexión en lugar de los 10 más manejables entre 1010 que llegan al servidor con éxito.

1000 bots a 100 req / s harían improbable que cada visitante real se conecte al sitio en absoluto. Y un ataque de esta magnitud también causará problemas en otros lugares.

Una defensa fuerte para tu sitio es un arma poderosa para un atacante:

Si su sitio bloquea las direcciones IP (o incluso los navegadores específicos en las IP) si se comportan mal, alguien podría decidir abusar de su defensa para provocar un ataque DoS en el lado del cliente.

Ejemplo: Mallory crea una página web que tiene cien "imágenes" con margin-left: -1000em; width: 1px; height: 1px; y todas esas imágenes son algunas URL "sensibles" en su sitio. Cuando un visitante visita la página de Mallory, enviará 100 solicitudes abusivas a su servidor y, por lo tanto, se bloquearán.

Por lo tanto, obtener una defensa más agresiva contra los ataques (D) DoS también causará otra vulnerabilidad.

Una defensa "inteligente" como CAPTCHAs (para dar a los visitantes la oportunidad de demostrar que también son visitantes y no solo bots maliciosos) también tendrá el efecto secundario de que realmente requieren recursos del servidor.

Cargar imágenes cuando la conexión está obstruida no parece una buena idea. Tampoco se recuerda una gran cantidad de sesiones para los CAPTCHA, CAPTCHA que no serán respondidas, en parte porque las imágenes no pudieron enviarse, en parte porque la mayoría de los visitantes no son humanos.

Y en un sitio dinámico (altamente o sin caché), estarías combatiendo fuego con gasolina.

Suponga que está hospedando un servicio de algún tipo, cuyo propósito principal es servir a una ubicación geográfica particular, y supongamos que lo hizo mediante algunas reglas de acceso basadas en direcciones IP.

UDP

Ahora, si se toma UDP en ese contexto, cualquier persona con conocimiento de una herramienta de creación de paquetes (por ejemplo, scapy) puede falsificar la IP legítima que tiene acceso permitido, y si opta por el enfoque de bloqueo, estará bloqueando la IP legítima. Usuarios que acceden al servicio.

TCP De manera similar, los ataques DDoS TCP (por ejemplo, sin flujo) pueden hacer que un usuario genuino sufra si se sigue el enfoque de la lista negra activa.

Por lo tanto, para lidiar con DDoS es mejor aplicar un filtrado cuidadoso, usando dispositivos lo suficientemente inteligentes como para distinguir entre el tráfico genuino y el ataque por DPI o por algún otro algoritmo.

CDN, NAT, PROXY

Si los usuarios están detrás de un CDN o algo así, el bloqueo de un usuario puede hacer que todo el grupo detrás del proxy sufra.

Además, " ya sea por direcciones IP o contenido del mensaje u otra cosa, como mencionó, para que los enrutadores puedan filtrar por contenido, eso dificultaría su rendimiento de enrutamiento. Pero sí, todavía hay enrutadores para hacer eso (por ejemplo, NBAR), y todos los que se pueden aplicar dentro de sus instalaciones.

Y el bloqueo debe ser más específico.

Otros han hecho grandes respuestas con respecto a los desafíos técnicos relacionados con la mitigación de DDoS, pero mi respuesta aquí se centrará en lo que sucederá una vez que haya creado la capacidad de filtrar los DDoS bloqueando una gran cantidad de direcciones IP en su sitio.

Bloquear un gran número de direcciones IP no siempre es deseable. Al bloquear un gran número de direcciones IP debido a un DDoS grande, podría estar bloqueando un gran número de usuarios legítimos que podrían compartir esas direcciones IP como un efecto secundario no deseado (por ejemplo, Tor, usuarios proxy, universidades, hogares compartidos, ISP que usan NAT). para guardar direcciones IP públicas).

Esto podría no ser tanto un problema para los sitios personales pequeños, sino para una serie de sitios donde los usuarios tienen una necesidad legítima de anonimato grave, dicen sitios que atienden a activistas políticos, LGBT, servicios femeninos en países opresivos, abuso doméstico , etc. El bloqueo de IP simple está esencialmente cayendo en la estrategia del atacante para estos sitios. Al negar el servicio a los usuarios anónimos para que accedan a su servicio, es posible que esté impidiendo que los usuarios legítimos más vulnerables accedan a su sitio de manera segura, y eso logra el objetivo del atacante tan bien como la DDoS original.

No hay una solución simple o única para los ataques DDOS, ya que se pueden realizar de muchas maneras diferentes. La naturaleza de la tecnología que está detrás de Internet no se presta a nada, sino que está muy abierta. Hay muchos parches y soluciones para tratar de apuntalar la seguridad y mitigar muchos problemas. En la balanza, es mucho más difícil proteger un sitio o red contra un ataque que atacar. Ese es el estado de seguridad hoy.

Para el ataque a nivel de red (como nuevamente el DNS más reciente para Dyn), el filtrado de ingreso a la red como se mencionó anteriormente, hubiera sido útil. Eso al menos ayuda con el problema de spoofing.

Sin embargo, un problema más urgente con este tipo de ataque es la escala. Con el número de sistemas infectados en una red de bots para un ataque considerable que llega a decenas de miles, si no cientos de miles de sistemas, el bloqueo basado en IP no es razonable. ¿Tendrás que estar lejos de la cadena? ¿Tendrás que bloquear para sobrevivir si lo haces? Se afirmó que el ataque Krebs DDOS estaba en el rango de 600Gbs. ¿Puede usted o su proveedor manejar eso (o incluso un problema más típico en mi experiencia 10-120Gbs)? En cualquier caso, solo estás jugando whack-a-mole en ese punto, ya que una vez bloqueado, tu atacante probablemente cambiará a otro conjunto de máquinas explotadas con diferentes IPs.

Si decides jugar al juego de reputación de IP < cough > CloudFlare < cough > puedes hacer cosas estúpidas como terminar bloqueando grandes proveedores, por ejemplo. Pokemon Go eliminando la mayoría / todo el tráfico de Bélgica. Nuevamente, esto es solo una locura y no una solución viable.

Hablemos más arriba en la pila. Los ataques de servicios web, como el relleno de credenciales o el raspado, a menudo se verán como tráfico legítimo. Los chiquillos de las ligas menores tendrán la firma del navegador que puedes buscar, pero cosas como Sentry MBA o incluso PhantomJS imitarán los navegadores adecuados que anularán esta simplificación de la huella HTTP / la identificación con el dedo del navegador. Los mejores atacantes incluso simularán el uso correcto del mouse y el teclado, ocultando aún más su naturaleza automatizada.

Los captchas son caros, tanto desde el punto de vista de la implementación (ya sea de recursos en sus servidores o de outsourcing $$). Los simples pueden ser derrotados con algoritmos razonables de detección de imágenes. Los captchas más complejos comienzan a molestar a los usuarios y pueden causar problemas de accesibilidad para los usuarios con discapacidades visuales. También hay sistemas que efectivamente derrotan a los captchas a través de los turcos mecánicos ya sea directamente (hordas de personas que pagaron centavos en el captcha) o indirectamente (el captcha de su sitio es respondido por un usuario confiado en otro sitio).

De todos modos, como los ataques son múltiples, necesitas un enfoque de defensa múltiple. Los grandes operadores incluso han tomado la ofensiva, ya que Microsoft ha trabajado con el FBI para tomar el control y apagar las botnets. Desafortunadamente, IoT acaba de abrir un nuevo conjunto de sistemas que salen de la caja abiertos para su explotación.

El genio de los ataques DDoS se deriva del hecho de que el tráfico proviene de IPs potencialmente legítimas de clientes reales.

Digamos que una persona normal que vive en los EE. UU. podría tener su enrutador comprometido y usarlo para DDoS. La empresa víctima bloqueó la dirección IP por completo, ahora esa persona no puede conectarse al servicio web de la empresa en absoluto porque la compañía bloqueó la IP completamente, impidiendo que una IP potencialmente válida vuelva a acceder a sus servidores.

Este fue un ejemplo simple, pero imagine que una universidad tiene algunas IPs de NAT para navegar por la web y una compañía bloqueó algunas de esas IP de NAT durante una mitigación DDoS. Ahora, decenas de miles de personas en ese campus podrían perder la conectividad con los servidores de esa compañía, lo que es catastrófico para los negocios.

Sin mencionar que los ataques DDoS lo suficientemente grandes pueden emplear una gran cantidad de direcciones IP diferentes.

No es fácil distinguir entre un tráfico normal y un tráfico DDoS.

DDoS se puede explicar con palabras sencillas como -
Como ser humano, solo puedo discutir (tener un chat de chit) cosas con una persona a la vez y si decenas de personas me hablan al mismo tiempo, entonces no lo haré Podré responder a cualquiera de ellos y estaré en estado no disponible para todos ellos.

Los atacantes generalmente generan el ataque DDoS desde máquinas comprometidas (también conocido como ** bot). Puede darse el caso de que, al momento de escribir la respuesta a su pregunta, mi máquina pueda involucrarse en un ataque de ddos a algún destino (si mi máquina está comprometida, aunque la posibilidad es muy baja).

Como se explicó, no hay una solución en blanco y negro disponible para controlar (o bloqueo) ddos ataque.

Como lo explica @gowenfawr, si el patrón de ataque de ddos es de udp, entonces la implementación de URF a nivel de ISP a través de Internet, puede ayudar a bloquear el tráfico falsificado y, por lo tanto, ayudar a controlar el ataque de ddos.

Historia verdadera aquí

Solíamos vender un sistema de cámara pequeña. Era una marca de renombre y la cámara no era espectacular, pero aún así costaba una cantidad decente. Un día, alguien nos llamó por un cargo en su tarjeta de crédito. Resultó que alguien lo había comprado y solía comprar una de estas cámaras y se lo habían enviado a alguien que probablemente las agregaba y las cerraba directamente o las enviaba en grandes cantidades a los ladrones.

Siendo un administrador emprendedor, busqué en los registros para averiguar de dónde venía el fraude. Encontré uno de una IP africana, pero el resto de las órdenes sospechosas tenían IP estadounidenses. De hecho, todos estaban siendo enviados a través de servidores comprometidos en el mismo centro de datos en el que se encontraban nuestros servidores web. Además de informar al host, no había nada que hacer. Quienquiera que hizo esto estaba tirando de las cuerdas a través de máquinas comprometidas. Simplemente no hay forma de protegerse contra este tipo de cosas mirando la fuente de la red en sí. Nunca se sabe dónde o cuándo alguien se verá comprometido y su IP se convertirá en un arma.

El reciente ataque a Dyn mostró lo estúpido que es ahora

  

La botnet, formada por dispositivos como enrutadores Wi-Fi domésticos y cámaras de video con protocolo de Internet, está enviando un gran número de solicitudes al servicio DNS de Dyn. Esas solicitudes parecen legítimas, por lo que es difícil para los sistemas de Dyn eliminarlas de las solicitudes de búsqueda de nombres de dominio normales.

Y

  

Son ataques difíciles de detener porque a menudo se canalizan a través de proveedores recursivos. No se pueden almacenar en caché debido al prefijo aleatorio. Comenzamos a ver ataques de prefijos aleatorios como estos hace tres años, y siguen siendo un ataque muy común. Si se usan dispositivos de IoT, eso explicaría el tamaño y la escala [y cómo afectaría el ataque]: alguien del tamaño de Dyn.

Con IPv6 despegando, pronto podría tener miles de millones de dispositivos, cada uno con su propia IP, para trabajar. El alcance es demasiado grande para filtrar efectivamente contra.

Un protocolo que permite a "alguien" decirle a la infraestructura de Internet / partes de la red troncal que dejen de aceptar / reenviar el tráfico de ciertas direcciones solo significa que este "alguien" ni siquiera tendría que emplear técnicas de DDOS para poner a nadie que quiera fuera de línea. Sin una "autoridad central que no existe", sería difícil llegar a un acuerdo sobre a quién se le debería confiar ese tipo de poder.