Conferencia NEGRO SOMBRERO. Lecciones de sobrevivir a un ataque DDOS de 300 Gb / s. Parte 1Lo interesante de este ataque fue que no nos atrevimos a atacar directamente, sino que seguimos la cadena de nuestros proveedores. Comenzaron a atacar a los proveedores aguas arriba ubicados sobre CloudFlare, y la fuente del ataque fue en Londres. Al principio no estaba seguro de esto, pero como Spamhaus también estaba en Londres, tal vez el hacker quería ponerlos en una posición vergonzosa. Como dije, el inspirador técnico del ataque parecía ser un adolescente de Londres, quizás de esta manera podría rastrear más efectivamente el efecto de su ataque. Esta diapositiva muestra la ruta de tráfico BGP, que incluía un máximo de 30 nodos de tránsito del próximo salto.
Escondí las extensiones de dirección del proveedor de banda ancha de Londres, el último salto es una de las direcciones IP de Spamhaus, había varias en nuestra red. Verá cómo se enrutó el tráfico, es difícil determinar la ruta exacta a partir de los datos anteriores, pero se envió a nuestro equipo en Londres, donde obtuvo 17 milisegundos después de pasar la dirección IP fronteriza de nuestra red, que funcionaba en Londres.
Al principio, el atacante atacó esta dirección marcada con una flecha, y dado que se usa DNS distribuido aquí, golpeó ligeramente Londres, un poco a Amsterdam y Frankfurt, a Estados Unidos, Asia y un poco a Australia. Luego, el pirata informático se dio cuenta de que el ataque estaba disperso y no era efectivo, y decidió escalar la cadena de enrutamiento sobre partes adicionales de la infraestructura. Por lo tanto, después de la última dirección IP, se mudó a la penúltima dirección IP. Nuevamente, si no sabe cómo funcionan las conexiones y el enrutamiento de Internet, diré que parcialmente el tráfico se intercambia directamente entre las redes cuando conecto mi red directamente a otra red. En este caso particular, el tráfico ingresa a nuestra red desde la red Sky, pasando a través de lo que se conoce como London Internet Exchange, o LINX.
Los atacantes comenzaron a pasar toneladas de tráfico a través de LINX como puerto. Tenemos un puerto en LINX con capacidades relativamente modestas, por lo que si envía 300 gigabytes de tráfico al puerto LINX, sobrecargue nuestro puerto y otros puertos de este intercambio. Entonces, la solución más razonable para nosotros fue dejar caer la conexión a través de este puerto, tan pronto como vimos que estaba siendo atacado, y el tráfico "fluyó" a su alrededor de otras maneras.
El problema era que había daños colaterales que afectaban a los otros puertos LINX, por lo que otros proveedores de grandes redes de Internet también experimentaron problemas porque redujimos el tráfico. Esto fue bastante desagradable, y posteriormente trabajamos con ellos para ayudarlos a proteger sus redes.
El ataque causó violaciones regionales temporales, pero tuvimos una buena oportunidad de redirigir el tráfico a otros nodos para crear la capacidad de permanecer en línea para Spamhaus y todos nuestros otros clientes. Los atacantes también afectaron a nuestros proveedores de tránsito de nivel superior, enviando un montón de tráfico a las personas con las que teníamos contratos para servicios de red. Su objetivo era causar la mayor cantidad de inconvenientes posibles a nuestros clientes, de modo que partes de la infraestructura de red que no estaban directamente relacionadas con nuestra red se vieran afectadas.
Es posible que los ataques hayan alcanzado un nivel superior, sin embargo, no tengo datos que lo confirmen, pero atacaron los enrutadores básicos que operan en el núcleo de varias redes. De hecho, este ataque sirvió como un pentest gigantesco no solo para nuestra red, sino también para las redes que nos rodeaban, los proveedores que utilizamos y los proveedores que utilizaron estos proveedores. Resultó que gracias a este ataque realizamos una auditoría de nuestras vulnerabilidades. Más tarde, fuimos a varios intercambios de Internet, como Londres, e implementamos las mejores soluciones en términos de establecer sus redes para aumentar la efectividad de oponerse a tales ataques. Descubrimos que todo el tráfico interno de la organización no debe enrutarse a través de enrutadores de borde de red. Por lo tanto, si no desea atacar a uno de estos intercambios dentro de la red de intercambios de Internet, su dirección IP no debe enrutarse a través de estos intercambios. Idealmente, debe usar 192.168, una de las direcciones RFC 1918 irresolubles que no pueden enrutarse y pasar el tráfico a través de sí misma, es decir, una red que no requiere acceso externo para funcionar. Esto es lo mejor que puedes hacer para contrarrestar tal ataque.
Hay otras cosas que puede hacer, como el enrutamiento interno del siguiente salto internamente, para asegurarse de que el tráfico destinado a la transmisión dentro de la red no utilice paquetes provenientes del exterior. No solo debe hacer esto para su propia red, sino también convencer a los proveedores ascendentes para que hagan lo mismo.
Hay otra cosa útil: el filtrado de límites para una dirección IP específica, basado en la comprensión del funcionamiento de nuestra aplicación. Por ejemplo, nuestra aplicación funciona con diferentes protocolos, y si vemos un paquete UDP que no está destinado a nuestro servidor DNS, entonces algo salió mal.
Desde entonces, hemos segmentado nuestras redes de tal manera que las direcciones IP para los servidores web son diferentes de las direcciones IP para los servidores DNS, y podemos pedir a nuestros proveedores ascendentes que simplemente bloqueen todo el tráfico UDP que llega a esta dirección IP en particular. para garantizar la seguridad de nuestro segmento de red. Esta separación de direcciones nos permitió realizar un filtrado más agresivo del tráfico de alto nivel.
El filtro BGP Flowspec es nuestro verdadero amigo; es el protocolo que propuso Cisco. A pesar del hecho de que contiene errores, usamos este protocolo y preferimos que los proveedores de tránsito también lo usen, porque nos permite transferir nuestras reglas a nodos de red remotos que afectan nuestras rutas. Esto le permite responder rápidamente a tal ataque.
La arquitectura nLayer de tres niveles merece una mención especial, y quiero expresar mi profunda gratitud a sus creadores de GTT, que han hecho un gran trabajo para hacer que su red sea especialmente resistente a los ataques. Tan pronto como vieron los picos de este ataque, rápidamente vencieron el tráfico incluso desde los bordes de su red. ¿Alguna vez te has preguntado lo genial que es ser un proveedor de nivel 1, capa 3 o NTT? Todo su trabajo es un fin de semana sólido, porque los proveedores de primer nivel no le pagan a nadie por las conexiones, y esto también significa que no pueden transferir el tránsito a nadie. Cuando comenzamos a bloquear el ataque desconectando segmentos de nuestra red, el impacto se concentró en un pequeño número de proveedores de Nivel 1 que estaban en el centro del ataque, y se formó un "agujero negro" dentro de su red, en el que todo el tráfico se precipitó, porque no tenía a dónde ir. . Por lo tanto, fue una prueba difícil para muchos proveedores de primer nivel.
Esta es una de las razones por las que vio el Open Resolver Project creado el primer lunes después del ataque. Los muchachos de nLayer son realmente un equipo experto en tecnología y nos ayudaron mucho. Nos trataron con comprensión, y no solo dijeron: "Sal de aquí, nos creas demasiados problemas". Por lo tanto, hemos desarrollado pasos prácticos que puede seguir para asegurarse de que sus redes sean seguras.
Estas son cuatro recomendaciones, la primera de las cuales suena tonta, pero obvia: ¡primero asegúrate de no ser parte del problema! Creo que mucha gente te lo ha dicho en los últimos años. Simplemente deténgase por al menos un segundo y verifique que estos dos componentes no se estén ejecutando en su red.
El primero son los resolvers abiertos. Si están en el espacio de direcciones IP de la empresa, si sus clientes los usan, debe bloquearlos o limitar la velocidad del tráfico. Es incluso mejor configurar los solucionadores para que solo acepten el tráfico que proviene directamente de su red.
En esta diapositiva, ves mi artículo favorito sobre The Register, escrito por Trevor Pott. Se llama "Reconociendo a un profesional de TI: cómo ayudé al mayor ataque DDoS".
Trevor escribe: “Pensé que estaba haciendo todo bien. Pero resultó que tenía un resolutor abierto, y vi a través de los registros de tráfico cómo las solicitudes llegaban a Spamhouse ”. Sé que hay personas responsables del funcionamiento de redes muy grandes que tienen solucionadores de DNS abiertos. Al hacer esto, contribuyes a la creación del problema anterior, por lo que te pido que pases literalmente un segundo de tiempo y te deshagas de ellos.
En segundo lugar, asegúrese de estar utilizando el BCP38. Los muchachos de la red iBall han hecho un gran trabajo, pero muchas de las personas que proporcionan las grandes redes aquí creen que la red está cerrada si no permiten el acceso externo.
Sin embargo, suponga que tiene un servidor WordPress comprometido en su red que puede comenzar a falsificar paquetes fuente que no están destinados a su red, y esto causará un gran problema para el resto de Internet.
El problema son los solucionadores abiertos, estos son 28 millones de solucionadores, cuyo número aumenta cada semana. Podemos vencer este problema solo mediante esfuerzos conjuntos. Debe establecer marcas en sus enrutadores fronterizos que garanticen que solo reciban paquetes de fuentes confiables dentro de su red. Si haces esto, entonces niega a los atacantes la oportunidad de explotar esta vulnerabilidad. La dificultad es descubrir grandes máquinas comprometidas que operan en redes y que permiten la suplantación de identidad.
Si observa los ataques de fuerza bruta en WordPress, y hay otros ataques allí, por ejemplo, usando la red de botnets, entonces le será difícil adivinar que la razón es precisamente la capacidad de usar la suplantación de identidad.
Otra recomendación es usar protocolos verdaderamente confiables. Puede decir: "Oye, obtuve esta dirección IP e inicio el servicio usando UDP, y el servicio usa TCP y otro tráfico a través de ICMP, y vincularé todos estos protocolos a la misma IP". Quiero advertirle que si surge un problema que limite su capacidad de responder de manera flexible a este tipo de ataque, especialmente porque puede segmentar fácilmente la red para que cada protocolo funcione en su propia dirección IP. Es mejor si puede filtrar el tráfico ascendente. El propósito de cualquiera de estos ataques no es detener el tráfico dentro de su red, sino bloquearlo lo más cerca posible de la fuente de tráfico, por lo tanto, al darle a alguien la capacidad de bloquear todo el tráfico UDP dirigido a cada IP, excepto la dirección seleccionada, reducirá significativamente la superficie de ataque. que puede ser usado por un atacante.
Por lo tanto, los protocolos separados para IP individuales funcionan de manera efectiva cuando interactúan con proveedores ascendentes. Simplemente les hace la pregunta: "Oye, ¿puedes implementar este tipo de filtrado?". Por cierto, una de las razones por las que nosotros, como proveedores, apoyamos a Flowspec es que podemos preguntarles correctamente: "Chicos, ¿apoyan a Flowspec?", Y si responden "Sí", la conversación ha terminado, y Podemos implementar nuestros propios filtros en el borde de la red tan rápido como queramos.
La tercera recomendación es la implementación de la infraestructura de ACL, es decir, el uso de listas de control de acceso. Quiero decir, un paquete no puede ser destinado a su red interna si su fuente no pertenece a esta red interna. Si un paquete proviene de su red o ingresa a su red desde un enrutador perimetral, no debe "viajar" a través de la infraestructura de su red interna. Hay muchas formas de implementar esta disposición. Puede aplicar el filtrado para evitar que ciertas direcciones IP alcancen los límites de la red, puede usar el enrutamiento automático del siguiente salto para evitar el acceso a algunas direcciones internas, puede usar los protocolos RFC 1918 dentro de la red para asegurarse de que sus IP internas no sean utilizado para abordar desde el mundo exterior.
Realmente puede traer un dolor de cabeza adicional, ya que te obliga a verificar la configuración del enrutador, realmente usa la red VPN, en lugar de pretender usarlo, y así sucesivamente. Estas no son las soluciones más populares, pero si no se implementan, el atacante puede examinar su red y apuntar a sus segmentos individuales para hacer aún más daño.
La cuarta recomendación es que debe conocer bien su tráfico ascendente. Quiero enfatizar una vez más que este ataque no usó aplicaciones complejas o paquetes de sincronización, fue solo un hombre de las cavernas con un club pesado. En cierto modo, deberías tener más tránsito que el malo. Puede generar 300 Gbps de tráfico, y estoy seguro de que pocos de los presentes pueden presumir de redes con tal volumen de tráfico. Esto significa que debes tener un amigo que tenga mucho tráfico saliente y, atrayéndolo a la cooperación, te cubres la espalda de tal ataque. Somos muy selectivos sobre el tráfico saliente con el que trabajamos para poder notar un ataque de este tipo a tiempo.
El otro día, hablé con el director técnico de un importante proveedor de tránsito y le pregunté si me iba a vender el tránsito, a lo que respondió: no, muchachos, de esto solo obtendrían un dolor de cabeza adicional como clientes.
Sin embargo, buscamos ese tráfico e incluso pagamos a los proveedores los bonos de tránsito que utilizamos, porque cuando ocurren ataques de este tipo, queremos poder llamarlos y pedir ayuda para mitigar las consecuencias del ataque. No necesita construir redes con un rendimiento de 3-4-5 terabits, si puede distribuir el tráfico máximo entre las redes asociadas.
Estas no tienen que ser compañías con una poderosa protección DDoS, solo necesitan usar la arquitectura nLayer para realmente hacer su trabajo y ayudarlo cuando surjan problemas. Trabaje en estrecha colaboración con ellos para ampliar los límites de su red. Use una política de configuración de red que le permita unirse al límite de sus redes, y los proveedores están dispuestos a hacerlo si tiene proveedores de red competentes. Esa es toda la historia sobre el ataque de 300 gigabits, nos quedan unos 10 minutos para responder sus preguntas.
Le pido que use un micrófono si acepta hacer cola para hacer una pregunta. Otra innovación que olvidé decir: los organizadores de Blackhat quieren tener comentarios con el orador, y si "enciendes" tu insignia desde el exterior, transferirán tu información a la NSA y también recibirán comentarios. Bromeé sobre la primera parte, pero la segunda relativa es cierta: puedes usar los comentarios, así que puedes llamarme idiota y, en general, hacer cualquier pregunta.
Pregunta: ¿Qué protocolos de amplificación, además de UDP y 53, ha encontrado al ejecutar CloudFlare?
Respuesta: usted pregunta, ¿hubo otros protocolos de amplificación además de los mencionados? Todavía estamos observando el uso de ICMP en la realización del viejo ataque Smurf, pero nada es comparable a la escala del ataque del que te hablé. Por lo tanto, el próximo año insistiremos categóricamente en que las personas no usen resolvers abiertos, sino que usen un servidor DNS legítimo y autorizado. Use CloudFlare, Bind o UltraDNS para iniciar sus redes, y si puede enumerar todos los dominios de los que es responsable el servidor autorizado, encontrar dominios que tengan listas muy grandes de nombres, puede proteger su red, porque dicho servidor puede limitar si es necesario velocidad de tráfico Hemos dedicado mucho tiempo a la implementación de esta solución, y estaré encantado de contárselo a quienes estén realmente interesados.
Pregunta: La botnet no se usó en este ataque, pero ¿puede recomendar recursos que permitan detectar si las grandes redes que controla están usando la botnet para llevar a cabo un ataque DDoS?
Respuesta: depende de dónde se encuentre; por ejemplo, puede buscar dichas herramientas en organizaciones que supervisan el comportamiento de la botnet y encontrar una que se adapte a sus necesidades. Si necesita un proyecto de código abierto, le recomiendo Honeypot, que apareció hace unos años. Con él, monitoreamos de manera efectiva una parte importante de las redes globales de botnets, puede especificar el rango de sus direcciones IP y mostrará si hay redes maliciosas allí. Este es solo uno de muchos proyectos de este tipo. Simplemente puede buscar patrones de tráfico anormal que ocurran en su red, por lo que si ve gigabits de tráfico que van a la misma dirección IP, y no hay una razón razonable por la que esto sucede en un momento dado, entonces este tráfico probablemente llegue no desde un servidor web, sino desde una red botnet. Esto debería hacerte sospechar.
Pregunta: Google tiene uno de los solucionadores de DNS abiertos más populares, ¿no crees que esto puede causar problemas?
Respuesta: hicieron un gran trabajo para limitar el tráfico, y la mejor manera de verificar esto es usar la misma solicitud digANY que le di como ejemplo, y reemplazar la dirección IP de la red PCCW con la dirección 888. Cualquiera de los presentes puede enviar esta solicitud solo una veces, repita que no funcionará. . , – UDP, , , , .
: , BGP Flowspec, , , , , , BGP Flowspec?
: , BGP Flowspec, - Cisco, . , , , . , Flowspec , . , Juniper, Flowspec. , 12 Cisco .
: Flowspec CloudFlare?
: , . , , Flowspec. , . , Flowspec, , . , , upstream-.
: CloudFlare, . , - , . , : «, »?
: , , . , , , , . , DDoS- , , 300 / . , Akamai, . , , «», , . , , .
, , , , . , , , . , , Akamai, Amazon, CloudFlare, Google, , , . , , ?
: , BC38, , DNSSec…
: , DNSSec!
: , , DNSSec, , ?
: . , DNSSec , . ? . , , – DNSSec , . , DNSSec, , , DNS-, .
DNSSec, , , , DNSSec. , Cloudflare, DNS, , . DNS- .
: upstream- ? .
: , , , upstream-. , . CloudFlare , , .
, , , - . , DNS DDoS: , , , .
Pregunta: ¿Podría suceder que cambie sus gastos por pagar tráfico excesivo debido a un ataque DDoS a sus clientes, motivando esta decisión con el hecho de que requieren demasiado dinero de usted?Respuesta: ¡subestimas cuánto dinero tenemos en el banco!Gracias a todos, estaré encantado de hablar con ustedes en otro lugar, y ahora es el momento de ceder esta plataforma al próximo orador.Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes?
Apóyenos haciendo un pedido o recomendándolo a sus amigos, un
descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta la primavera sin cargo al pagar por un período de seis meses, puede ordenar
aquí .
Dell R730xd 2 veces más barato? ¡Solo tenemos
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?