Informe anual de disponibilidad y seguridad de red de Qrator Labs



Tenemos una tradición en Qrator Labs: al principio, y febrero definitivamente no es el final, cada año publique un informe sobre el año anterior.

Como cualquier entidad perenne, está rodeada de muchas historias relacionadas. Por ejemplo, ya se ha convertido en un "buen" augurio cuando a principios de enero llega otro ataque DDoS a nuestras páginas corporativas, que no tenemos tiempo para identificar en el informe. 2020 fue la mitad de la excepción: logramos describir el vector de ataque (amplificación TCP SYN-ACK), pero fue para nosotros, en qrator.net, que el invitado vino (y no uno) solo el 18 de enero, sino inmediatamente con los invitados: 116 Gbps a 26 Mpps

Vale la pena confesar que volver a contar los eventos del año pasado es un género específico. Por lo tanto, decidimos en el proceso de reflexión centrarnos en lo que sucederá, principalmente con nuestro equipo y producto, este año, así que no se sorprenda al leer sobre nuestros planes de desarrollo.

Comenzaremos con dos de los temas más interesantes para nosotros el año pasado: amplificaciones SYN-ACK y "optimizaciones" BGP.

TCP SYN-ACK amplificación y otros protocolos


El crecimiento del mercado de IoT, entre otras cosas, significa que los atacantes pueden explotar dispositivos vulnerables si lo desean, creando un ancho de banda de ataque significativo, como sucedió a mediados de año cuando se utilizó el protocolo WSDD para causar daños visibles. El protocolo ARMS de Apple, que se utilizó para obtener un coeficiente de amplificación del orden de 35.5, también fue visible en los ataques a la red de filtrado de Qrator Labs.

Durante 2019, el público también se enteró de los nuevos amplificadores (PCAP), y también vio personalmente el conocido vector de ataque que involucra TCP - SYN-ACK. La principal diferencia entre este método y la amplificación UDP típica es que el vector SYN-ACK no utiliza una respuesta mayor que la solicitud; en cambio, solo intenta responder a la solicitud TCP varias veces, creando así un coeficiente de amplificación notable. Dado que las nubes públicas en Internet responden a los paquetes falsificando la dirección de origen, los ataques que involucran el vector de amplificación SYN-ACK se han convertido en una de las amenazas de red más graves. El apogeo ocurrió cuando un importante proveedor de alojamiento en la nube Servers.com recurrió a Qrator Labscon una solicitud de ayuda para neutralizar los ataques DDoS, incluido el vector SYN-ACK.

Es bastante interesante el hecho de que el método de reacción más utilizado en el pasado en forma de volcado de todo el tráfico UDP, que prácticamente neutraliza la mayor parte de los ataques mediante amplificación, no ayuda a neutralizar el vector SYN-ACK. Las compañías de Internet más pequeñas tienen enormes dificultades para neutralizar tales amenazas, ya que requieren el uso de medidas integrales para combatir los ataques DDoS.


Aunque la amplificación TCP SYN-ACK no es nueva, hasta ahora se ha mantenido como un vector de ataque relativamente desconocido. Un atacante envía paquetes SYN a todos los servicios TCP públicos en Internet, reemplazando la dirección de origen con la dirección de la víctima, y ​​cada uno de estos servicios a su vez responde varias veces en un intento de establecer una conexión, generalmente de 3 a 5. Durante mucho tiempo, se consideró este vector de ataque no tiene sentido, y solo en julio de 2019 vimos que los atacantes pudieron generar suficiente ancho de banda de ataque para sacudir incluso las infraestructuras de red muy grandes y distribuidas. Esto es especialmente inusual, dado el hecho ya mencionado de la ausencia de una "amplificación de la respuesta" como tal y el uso de solo la posibilidad de reconexión inherente al protocolo en caso de falla. Para esos,cualquier persona interesada en otros protocolos con "capacidades" similares, puede señalar el protocolo QUIC, que ya brinda al servidor la opción de responder a la solicitud de un cliente con una respuesta ampliada (aunque el borrador del protocolo también "recomienda" no enviar una respuesta más de tres veces el tamaño de la solicitud).

La amplificación ha dejado de ser una amenaza con relaciones de aproximadamente 100x; es obvio que 3-5x es suficiente hoy en día. La solución a este problema es casi imposible sin eliminar el fenómeno del tráfico "falso" como categoría: un atacante no debería ser capaz de simular el identificador de red de alguien e inundarlo con tráfico de fuentes de contenido legítimo. BCP38 (un conjunto de prácticas mejores y generalmente aceptadas para establecer redes y resolver situaciones problemáticas) no funciona en absoluto y los creadores de nuevos protocolos de transporte, como QUIC, evalúan mal el peligro que representan incluso las capacidades de amplificación muy pequeñas. Están del otro lado.

Las redes necesitan una forma confiable de descartar o al menos limitar el tráfico falso, y esta herramienta debe tener suficiente información sobre la legitimidad de la fuente de la solicitud. Las redes en la nube propiedad de compañías como Amazon, Akamai, Google y Azure hoy en día son un objetivo casi ideal para la amplificación de TCP: tienen una gran cantidad de hardware potente que puede satisfacer casi todos los objetivos del atacante.



Es difícil eliminar las consecuencias de tales ataques en Internet moderno. Como ya se mencionó, las interfaces y aplicaciones de fondo modernas de aplicaciones y bibliotecas utilizadas para crearlas se integran mutuamente. El uso de las capacidades de las soluciones de software de código abierto ubicadas dentro de grandes nubes en su propia pila de desarrollo puede ocasionar serios problemas como resultado de un ataque que utiliza la amplificación SYN-ACK desde la misma nube. Los repositorios rotos y los archivos de configuración que no se actualizan como resultado del bloqueo (debido a una dirección falsa del origen de la solicitud, su dirección) del lado del proveedor de servicios en la nube es una situación en la que nadie quiere estar. Durante 2019, enfrentamos esta situación varias veces, atendiendo las quejas de las empresas afectadas,descubrió dependencias críticas inimaginables por primera vez durante su existencia y desarrollo.

Es necesario un mayor desarrollo del protocolo BGP para usarlo en la lucha contra la suplantación de identidad en la pila de protocolos TCP / IP. Las tablas de enrutamiento son fundamentalmente diferentes de las tablas de subred, y debemos enseñar a la red a aislar y descartar rápidamente un paquete ilegítimo; en otras palabras, proporcionar autenticación a nivel de infraestructura de red. Se debe prestar atención no a la "dirección de destino", sino a la "dirección de origen" para que coincida con la información contenida en la tabla de enrutamiento.


BGP - "optimizadores"


Los incidentes de BGP siempre están en curso. Según la escala actual de magnitud de los incidentes de la red, las fugas de ruta y las intercepciones de subredes anunciadas que se han extendido lo suficiente conllevan el peligro principal en cuanto al alcance de la propagación y el tiempo requerido para eliminar las consecuencias. Quizás esto se deba a que el desarrollo del componente de red en sí mismo fue mucho más lento que el resto del mundo del desarrollo de hardware y software nuevos. Durante mucho tiempo, esto fue cierto: es hora de abandonar esta herencia. Es necesario invertir tiempo y dinero en software y hardware de red, así como en personas que configuran filtros BGP.

Los incidentes de 2019 relacionados con los optimizadores de BGP mostraron que las estadísticas de BGP en las que todos confían tienen muchos problemas. El hecho es que en el anuncio de BGP recibido por el igual, puede cambiar casi todo el contenido antes de que se anuncie nuevamente: el protocolo es muy flexible. Esto es exactamente lo que usa el optimizador: prefijos de red más grandes o más pequeños, junto con filtros inactivos y la opción de pref local. Si alguien desagrega el prefijo en dos más pequeños, generalmente ganará la competencia por el derecho a transmitir el tráfico. Los optimizadores toman la ruta correcta y anuncian su parte más pequeña, de manera bastante directa. Y funciona al dividir las grandes partes de Internet.

Los optimizadores de BGP existen porque una gran cantidad de compañías desean controlar el flujo de tráfico saliente automáticamente, sin pensar en el tráfico como tal. Aceptar rutas que no deberían existir es un gran error, porque no existen tales rutas en el punto desde el que se originan.

Muchos textos fueron escritos para 2019, incluso por nuestra empresa., sobre los riesgos de la "optimización BGP". En el caso de Verizon, por supuesto, crear una nueva política de filtrado para cada nuevo consumidor del servicio es desagradable. Y también se sabe que Verizon no tiene filtros, ya que tomó cientos de rutas problemáticas del propio cliente de AS396531, que es un "trozo", un sistema autónomo con una sola conexión. Además, el gigante de las telecomunicaciones tampoco tenía un límite de subred para esta conexión. Ni siquiera hubo una verificación básica de la presencia de otros operadores de nivel 1 en el camino del consumidor (este tipo de verificación se inicia por defecto y no requiere soporte o cambio).


En la prensa, este incidente, incluidos Verizon y Cloudflare, se discutió con bastante intensidad. Además de la posible acción de Verizon, muchos han notado los beneficios de RPKI y un estricto récord máximo en ROA. ¿Pero qué hay de maxLength? Se sabe que con una verificación estricta de la duración máxima de grabación, todos los anuncios con una indicación de subredes más pequeñas se vuelven incorrectos cuando se verifica el ROA. También se sabe que existe una política para restablecer rutas no válidas. También hay un borrador dentro del IETF, que indica que maxLength debe ser igual a la longitud del prefijo de red.

Cloudflare sigue las mejores prácticas. Sin embargo, hay un pequeño problema. Verizon no admite la política de restablecimiento para rutas no válidas. Quizás no tenía ninguna verificación RPKI en absoluto. Como resultado, todas las rutas con subredes más pequeñas se extendieron aún más, aunque eran incorrectas desde el punto de vista de la validación de Route Origin y atrajeron todo el tráfico sobre sí mismas. Al mismo tiempo, a pesar del estado no válido, Cloudflare no podía anunciar las mismas rutas, ya que sus proveedores las descartarían por incorrectas.

Se puede eliminar una fuga de ruta simplemente manipulando el atributo AS_PATH en la forma: ASx AS396531 ASx (donde ASx es el número del sistema fuente autónomo) durante la creación del anuncio; esto ayudará a evitar fugas mediante el uso del mecanismo de detección de bucle mientras el problema se resuelve de otras maneras. Aunque cada vez con tal manipulación será necesario tener en cuenta dichas políticas.

Con mayor frecuencia en la vida real, se utiliza el método estándar: la queja. Lo que resulta en horas extra de espera. La comunicación puede ser dolorosa y no podemos culpar a Cloudflare por esto: hicieron todo lo que pudieron, dadas las circunstancias.


Cual es el resultado? A veces se nos pregunta qué tan difícil es usar BGP para organizar algo malo. Supongamos que eres un villano novato. Es necesario conectarse a un operador de telecomunicaciones grande, lo cual es malo con la configuración del filtro. Luego seleccione cualquier objetivo y tome sus prefijos de red anunciando sus partes más pequeñas. Además, no olvide descartar todos los paquetes de tránsito. ¡Felicidades! Acaba de crear un agujero negro en Internet para todo el tráfico de tránsito de este servicio a través de su proveedor. La víctima perderá dinero real debido a tal denegación de servicio y, muy posiblemente, sufrirá importantes pérdidas de reputación. Se necesitan al menos una hora para encontrar las causas de tal incidente, y se requiere una hora parapara que todo vuelva a la normalidad, siempre que tal situación no sea intencional y haya buena voluntad de resolución entre todos los participantes.

En marzo de 2019, hubo otro caso , que en un momento no asociamos con la optimización de BGP. Sin embargo, también merece atención.

Imagine que es un proveedor de tránsito que anuncia subredes de sus propios clientes. Si dichos clientes tienen varios proveedores, y usted no uno, recibirá solo una parte de su tráfico. Pero cuanto más tráfico, mayor es el beneficio. Por lo tanto, decide anunciar subredes más pequeñas de estas redes con el mismo atributo AS_PATH para obtener todo el tráfico de dichas redes. Con el dinero restante, por supuesto.

¿ROA ayudará en este caso? Quizás sí, pero solo si decide no usar maxLength y no tiene registros de ROA con prefijos que se crucen. Para algunos operadores de telecomunicaciones, esta opción no es factible.

Si hablamos de otros mecanismos de seguridad BGP, ASPA no ayudaría en este tipo de intercepción, porque AS_PATH pertenece a la ruta correcta. BGPSec actualmente es ineficiente debido a la falta de soporte y la capacidad restante para realizar ataques de degradación.

Sigue existiendo un motivo para aumentar la rentabilidad debido a la recepción de todo el tráfico de sistemas autónomos con varios proveedores y la ausencia de protección.


El número total de bucles estáticos en la red.

¿Qué se puede hacer todavía? El paso obvio y más radical es revisar las políticas de enrutamiento actuales. Esto lo ayudará a dividir el espacio de direcciones en las partes más pequeñas posibles (sin intersecciones) que le gustaría anunciar. Firme un ROA solo para estas rutas con la opción maxLength. La validación actual del ROV puede salvarlo de tal ataque. Pero, de nuevo, algunos no pueden permitirse el lujo de usar solo las subredes más pequeñas.

Usando Radar.Qrator, puede rastrear tales eventos. Para hacer esto, necesitamos información básica sobre sus prefijos. Puede establecer una sesión de BGP con un recopilador y proporcionar información sobre su visibilidad de Internet. También apreciamos positivamente a aquellos que están listos para enviarnos una tabla de enrutamiento completa (vista completa); esto ayuda a rastrear el alcance de los incidentes, pero para su propio beneficio y comenzar a usar la herramienta, una lista de rutas es suficiente solo para sus prefijos. Si ya tiene una sesión con Radar.Qrator, compruebe que está enviando rutas. Para la detección y notificación automáticas de ataques en su espacio de direcciones, esta información es necesaria.

Repetimos: si se detecta una situación similar, puede intentar contrarrestarla. El primer enfoque es el anuncio propio de rutas con prefijos de subredes más pequeñas. En el próximo ataque a estos prefijos, repita. El segundo enfoque es castigar al atacante negando el acceso del sistema autónomo a sus caminos. Como se describió anteriormente, esto se logra al agregar el número de sistema autónomo del atacante a AS_PATH de sus rutas antiguas, lo que hace que la protección contra bucles funcione.

Bancos




En 2019, llevamos a cabo un estudio en Rusia , que mostró que las instituciones financieras registraron un aumento en la importancia de la seguridad de la información y comenzaron a dar a esas inversiones una mayor prioridad.

Los bancos encuestados identifican los daños financieros y de reputación como las consecuencias más graves de las infracciones de seguridad de la información.

La mayoría de las instituciones financieras encuestadas consideran que las soluciones híbridas son el medio más efectivo para contrarrestar los ataques distribuidos de denegación de servicio.

La dinámica de los últimos dos años indica claramente que el campo de la seguridad de la información está creciendo a un ritmo enorme: en los últimos 2 años, la mayoría de los bancos han aumentado la inversión en seguridad de la información. La ciberseguridad ya se ha hecho visible a nivel de gestión de la empresa. Los líderes empresariales están comenzando a prestar más atención a los procesos de implementación de políticas de seguridad, y el cargo de Director de Seguridad de la Información ha adquirido un nuevo rol. Los gerentes de SI se están convirtiendo gradualmente en asesores clave para los altos gerentes de organizaciones financieras, introduciendo tácticas comerciales y estrategias de seguridad de acuerdo con las necesidades de la empresa.

Comercio electrónico




Se realizó un estudio similar en el campo del comercio electrónico, donde descubrimos que los ataques DDoS siguen siendo una amenaza importante para el comercio minorista ruso, especialmente para el desarrollo de canales de servicios digitales. El número de ataques en este segmento continúa creciendo.

En algunos segmentos del mercado, a pesar de su estabilización y consolidación general, la confianza en la limpieza de los competidores sigue siendo baja. Al mismo tiempo, las grandes tiendas en línea en su mayor parte confían en sus consumidores y no consideran los motivos personales de los clientes como una causa grave de ciberataques.

Como regla general, las empresas de comercio electrónico medianas y grandes aprenden sobre su preparación para ataques DDoS solo en la práctica, pasando una "prueba de batalla". La necesidad de una evaluación preliminar del riesgo de la preparación del proyecto está lejos de ser reconocida por todos, y aún menos empresas realmente llevan a cabo dicha evaluación. Las principales razones de la piratería, los encuestados consideran un mal funcionamiento de la tienda, así como el robo de la base de usuarios.

En general, el nivel de madurez minorista en los enfoques para garantizar la ciberseguridad está creciendo. Por lo tanto, todos los encuestados utilizan algunos medios de protección DDoS y WAF.
En otros estudios, se planea incluir una muestra representativa de pequeñas empresas en línea entre los encuestados y estudiar en detalle este segmento del mercado, sus riesgos y el nivel actual de seguridad.

DNS sobre HTTPS vs DNS sobre TLS


Uno de los temas más candentes de 2019 fue el debate sobre qué tecnología tiene el futuro: DoH o DoT. La contradicción inicial se debe tanto a diferencias significativas en diferentes legislaturas (GDPR de la UE frente a leyes federales y estatales en los EE. UU.) Como a la competencia en el mercado principal de navegadores: Google Chrome y Mozilla Firefox, así como Apple Safari. No estamos listos para decir si la introducción de alguna de estas tecnologías reducirá la cantidad de amplificadores en Internet. Sin embargo, con la opción DoT, esto parece más posible desde un punto de vista arquitectónico debido a la creación de conexiones seguras entre los solucionadores de DNS. En cuanto a otras previsiones, esperaremos una decisión que tomará el mercado.


Las industrias más atacadas en 2019.

Vulnerabilidades de reconocimiento de TCP


En junio de 2019, aparecieron los primeros detalles sobre la existencia de vulnerabilidades graves en algunas implementaciones de la pila de protocolos TCP / IP, según informó Netflix . Presumiblemente, el problema se descubrió originalmente en el sistema operativo FreeBSD, después de lo cual nuestra empresa recibió la confirmación de la presencia de la misma y otras vulnerabilidades en Linux.

El CVE-2019-11477 (SACK Panic) más peligroso, que puede permitir a un atacante llamar al kernel panic utilizando una secuencia de paquetes especialmente formados. Otras tres vulnerabilidades pueden conducir al consumo excesivo de recursos, lo que podría resultar en la denegación de servicio.

La desactivación de la funcionalidad SACK puede conducir a mayores retrasos, sin embargo, esto protegerá a los servidores de posibles ataques de denegación de servicio: una disminución temporal en el rendimiento de TCP / IP, según Qrator Labs, es una forma razonable de neutralizar una vulnerabilidad grave. Los parches que cubren estas vulnerabilidades han estado disponibles durante mucho tiempo y se recomiendan para la instalación.

El futuro del enrutamiento BGP


A finales de 2019, Radar.Qrator es la plataforma de análisis y recopilación de enrutamiento global BGP más grande con más de 650 sesiones establecidas.

El equipo de Radar.Qrator está trabajando para mejorar la usabilidad y la confiabilidad del servicio, realizando mejoras en el modelo de relación BGP, que es la base de un servicio pago para monitorear un sistema autónomo en tiempo real.

En 2019, se hicieron grandes esfuerzos para acelerar el procesamiento de datos y la ejecución de SLA, lo que garantiza la calidad del flujo de datos analíticos. Hoy, Radar es la plataforma analítica más grande y el recopilador de BGP en el mundo, con más de 600 sesiones establecidas, y esperamos utilizar los datos al máximo para notificar a los consumidores de la parte paga del servicio sobre todos los eventos que ocurren en el enrutamiento de BGP sin demora.

Radar.Qrator está creciendo más rápido de lo esperado, tanto en términos de la cantidad de visitantes del sitio web como de la cantidad de suscriptores al mismo tiempo. En 2020, gracias a los comentarios de los clientes, se presentarán varias mejoras significativas a la vez, una de esas cosas será un nuevo almacenamiento de incidentes para cada sistema autónomo.

Uno de los problemas que encontramos fue el tiempo de respuesta esperado en la interfaz web de Radar, accesible para todos los visitantes del sitio. Con el aumento en la cantidad de datos, se hizo necesario actualizar tanto el modelo de almacenamiento de datos como la arquitectura de las solicitudes de los usuarios. Radar debería poder enviar rápidamente todos los datos del período solicitado a cualquier visitante.


El esquema propuesto del mecanismo ASPA.

También esperamos que durante este año ASPAse convertirá en RFC, un estándar de red aprobado. La necesidad de una solución más amplia que la combinación de IRR / RPKI y más liviana que la solución BGPSec es obvia para todos en la industria. En 2019, quedó claro cómo una configuración incorrecta de BGP puede conducir a fugas de ruta con terribles consecuencias en forma de falta de disponibilidad de una gran cantidad de servicios que involucran a los mayores proveedores de servicios de Internet. Sorprendentemente, estos incidentes demostraron una vez más que no hay una bala de plata que pueda superar todos los escenarios posibles de su desarrollo.

Los proveedores de Internet más grandes del mundo necesitan apoyar el movimiento inicial. El siguiente paso es involucrar a las comunidades grandes que pueden ayudar a encontrar la fuente del desvío de ruta. En términos simples, ASPA es una nueva entidad que combina las capacidades actuales de ROA y RPKI: implementa el principio simple: "Conozca a su proveedor". El propietario de AS solo necesita conocer su flujo ascendente para implementar una forma suficientemente confiable de protección contra incidentes de enrutamiento BGP.

Como en el caso de ROA, ASPA le permite filtrar rutas para cualquier conexión: con un proveedor superior, un vecino o, por supuesto, un consumidor. La combinación de ROA y ASPA puede resolver la mayor parte de las tareas de seguridad de la red sin la necesidad de cambios fundamentales en el protocolo en sí mismo, filtrando ataques intencionales y errores relacionados con el factor humano. Sin embargo, también será necesario esperar el soporte de los fabricantes de software y hardware, aunque existe la confianza de que el soporte de código abierto no tardará en llegar.

Una de las principales ventajas de ASPA es que es una idea muy simple. En 2020, se planea completar el trabajo sobre un proyecto de protocolo, y si tiene éxito, el IETF y los coautores del proyecto llegarán a un consenso sobre la consolidación del estado del protocolo.



Desarrollo actual y futuro de la red de filtración Qrator

Lógica de filtrado


Durante los dos años anteriores, hemos invertido una cantidad considerable de tiempo y esfuerzo en mejorar la lógica de filtrado, que es la base del servicio de mitigación de ataques que brindamos. Hasta la fecha, ya están trabajando en toda la red, mostrando un aumento significativo tanto en la eficiencia operativa como en una disminución de la carga en la memoria y el procesador central en los puntos de presencia. Los nuevos filtros también le permiten analizar solicitudes sincrónicamente y proporcionar una variedad de tareas de JavaScript para verificar la legitimidad del visitante, mejorando la calidad de la detección de ataques.

La razón principal para actualizar la lógica de filtrado es la necesidad de detectar una clase completa de bots desde la primera solicitud. Qrator Labs utiliza combinaciones de comprobaciones con y sin memorización de estado, y solo después de la confirmación de la legitimidad del usuario envía la solicitud al servidor protegido. Por lo tanto, es necesario que los filtros funcionen muy rápidamente: los ataques DDoS modernos pasan con una intensidad de decenas de millones de paquetes por segundo, y algunos de ellos pueden ser solicitudes únicas y únicas.

En 2020, como parte de este proceso, también se realizarán cambios significativos en el proceso de "incorporación" del tráfico, es decir, el inicio del trabajo con un nuevo servicio protegido. El tráfico de cada servicio es único a su manera y nos esforzamos por garantizar que, sin importar qué, los nuevos clientes reciban rápidamente la neutralización completa de todo tipo de ataques, incluso si el modelo no está bien entrenado. Como resultado, aseguraremos una inclusión más fluida del filtrado cuando esté conectado bajo ataque, y el comienzo del filtrado irá acompañado de menos falsos positivos. Todo esto es importante cuando el servicio y las personas detrás de él están en medio de la lucha por la supervivencia bajo ataques masivos de la red.


Distribución de ataques DDoS para 2019 por banda usada.

HTTP / 2


Los problemas con las implementaciones del protocolo HTTP / 2 (vulnerabilidades de denegación de servicio) se resolvieron principalmente durante 2019, lo que nos permitió habilitar el soporte para este protocolo dentro de la red de filtrado de Qrator.

Ahora el trabajo está en curso para proporcionar protección HTTP / 2 a cada cliente, completando un período de prueba largo y profundo. Junto con el soporte para HTTP / 2, TLS 1.3 introdujo la posibilidad de usar eSNI con la emisión automatizada de certificados de seguridad Let's Encrypt.

Actualmente, HTTP / 2 está disponible a pedido como una opción adicional.

Contenedores y Orquestación


Las tendencias actuales de contenedorización son poco compatibles con nuestros enfoques de seguridad. Esto significa que trabajar con Kubernetes tiene que superar una variedad de desafíos. La seguridad y la accesibilidad se encuentran entre las prioridades más altas, lo que no nos permite confiar en prácticas comunes entre quienes trabajan con Kubernetes, principalmente dando al proceso de orquestación un control total sobre el sistema operativo con todas las características; esto nos dejaría exclusivamente a merced de los desarrolladores y complementos de Kubernetes. Hasta el momento, Kubernetes no tiene todas las capacidades necesarias listas para usar, y algunas incluso están ocultas para el estado "usar como está, no hay garantía" y no se pueden investigar en detalle. Pero todo esto no se aleja del trabajo adicional sobre la implementación de Kubernetes en la gestión de la red de filtrado,gradualmente ajustándolo a nuestros requisitos y convirtiéndolo en una parte bastante importante de la infraestructura interna.

El futuro del desarrollo y desarrollo de redes distribuidas y tolerantes a fallas requiere la introducción de herramientas apropiadas (CI / CD y pruebas automáticas son parte de ello) y la capacidad de usarlo para crear y administrar un sistema estable y confiable. A medida que la cantidad de datos solo aumenta, los esfuerzos de monitoreo deberían crecer después de ellos. La forma más natural de crear monitoreo es proporcionar un método de comunicación seguro y fácilmente observable para las aplicaciones. Creemos que Kubernetes ya ha demostrado su versatilidad y aplicabilidad, y su mayor especialización para las necesidades de la infraestructura que lucha contra los ataques DDoS es la realidad de trabajar con cualquier solución de código abierto.


Cambio en la duración promedio de los ataques DDoS de 2018 a 2019.

Yandex.Cloud e Ingress 2.0


En 2019, junto con Yandex.Cloud, presentamos una versión actualizada de nuestro servicio para filtrar el tráfico entrante: Ingress, ampliando significativamente sus capacidades de filtrado y configuración, proporcionando al usuario final interfaces de administración claras. La nueva versión del servicio ya funciona en la red de filtrado de Qrator Labs, así como en la red Yandex.Cloud.

El equipo de Yandex.Cloud ha recorrido un largo camino con nosotros, combinando dos infraestructuras utilizando nodos físicos de Qrator Labs ubicados dentro de la infraestructura del socio que trabaja en su tráfico.

Finalmente, después de un período de pruebas en profundidad, la nueva versión de Ingress está lista para usar. Con la ayuda de Yandex, pudimos crear una de las mejores soluciones para filtrar el tráfico entrante, creado específicamente para las necesidades de los servicios que generan mucho contenido.

También consideramos un gran éxito que la nueva versión del servicio sea intuitiva para el usuario final y le permita configurar de manera más flexible los parámetros de filtrado.

TLS 1.3 y certificados ECDSA


A principios de 2019, Qrator Labs escribió sobre la compatibilidad con la versión 1.3 de TLS y deshabilitó SSL v.3. Debido a la disponibilidad del servicio de neutralización DDoS sin revelar claves de cifrado, se realizaron mejoras adicionales a este esquema de filtrado, aumentando la velocidad y la confiabilidad de la traducción de syslog. Recordemos los resultados de las mediciones de rendimiento .
Tipo de firmaApretones de manos por segundo
ECDSA (prime256v1 / nistp256)3358,6
RSA 2048972,5

Como puede ver, en el mismo núcleo de la CPU Intel® Xeon® Silver 4114 @ 2.20GHz (lanzado en el tercer trimestre de 17), la diferencia total entre el rendimiento de ECDSA y el RSA generalmente aceptado con una longitud de clave de 2048 bits es 3.5 veces.

Veamos los resultados de ejecutar el comando openssl -speed para ECDSA y RSA en el mismo procesador.
Tipo de firma
firmar
verificar
signo / seg
verificar / seg
RSA 2048 bit
717 μs
20,2 μs
1393,9
49458,2
256 bits ECDSA (nistp256) 
25,7 μs
81,8 μs
38971,6
12227,1

Aquí podemos encontrar la confirmación de una tesis escrita previamente sobre cómo las operaciones computacionales de una firma y su verificación difieren entre ECC y RSA. Actualmente, armado con TLS 1.3, la criptografía basada en curvas elípticas proporciona un aumento significativo en el rendimiento del servidor con un mayor nivel de protección en comparación con RSA. Esta es la razón principal por la que nosotros en Qrator Labs recomendamos y alentamos a los clientes que también están listos para usar certificados ECDSA. En las CPU modernas, la ganancia de rendimiento a favor de ECDSA es 5x.

Pequeñas mejoras


Una de las innovaciones pequeñas y discretas, pero sin embargo importantes durante 2019, fue la introducción del proceso de verificación activa del estado ascendente. Si por alguna razón sucede algo durante una de las conexiones superiores de nuestro cliente durante el ataque, el servicio de filtrado será el primero en saberlo, dejando la conexión fuera de servicio hasta que se resuelva el problema. En esto, ayuda no solo a controlar los errores y las condiciones del tráfico, sino también a configurar una interfaz de verificación de accesibilidad especial, que se realiza junto con el consumidor del servicio.

A finales de 2019, se realizó una gran actualización de la interfaz de usuario del servicio de filtrado. Y aunque se ofrece la posibilidad de usar la versión anterior de su cuenta personal, ya se están desarrollando nuevas funciones en la parte actualizada, que proporciona una funcionalidad más amplia, por ejemplo, la administración de certificados TLS.

Mientras que la versión anterior de la cuenta personal utilizaba la representación del lado del servidor, la versión actualizada en las mejores tradiciones de la web moderna es una aplicación de JavaScript que se ejecuta en un cliente que se comunica con el servidor a través de la API REST. Este enfoque le permitirá proporcionar rápidamente nuevas funciones al usuario, a la vez que brinda oportunidades más profundas para la configuración individual de cada cuenta personal de un consumidor individual. Una de esas cosas es la sección de Análisis, donde es posible personalizar las métricas individuales, cuyo número aumenta constantemente.


Comparación de los dos principales grupos de clasificación para ataques DDoS para 2019.

IPv6


Qrator Labs se está preparando activamente para comenzar a usar IPv6 como parte de los servicios de filtrado de tráfico. Para cualquier empresa de ciberseguridad, dicha transición no puede ser elemental. Debido a la naturaleza de los ataques DDoS, la neutralización de los ataques de red que utilizan IPv6 requiere un cambio radical de enfoque, ya que ya no es posible lidiar con ninguna forma de "lista", que trata con un límite teórico de 2.128 direcciones IP. Y solo se trata de TCP, sin considerar UDP.

Para nosotros, 2020 será el año de IPv6. Con el agotamiento del espacio libre de direcciones IPv4, no hay otra forma de desarrollar una red que cumpla con los requisitos futuros. Esperamos poder responder eficazmente a todos los desafíos que enfrentamos en el marco de neutralizar los ataques IPv6. En primer lugar, esto significa que podremos anunciar la subred IPv6 de los servicios de filtrado de consumidores utilizando nuestra red, al tiempo que ofrecemos un servicio de ciberseguridad de primera clase.

Antibot


En 2019, la industria observó una feroz batalla entre las huellas digitales (identificación del visitante) y los intentos de limitarla. Es comprensible el deseo de los propietarios y desarrolladores de servicios de Internet de limitar o separar las solicitudes de usuarios legítimos de las solicitudes automatizadas de bots. Por otro lado, no hay nada extraño en el deseo de los desarrolladores de navegadores de proteger a los usuarios de software. Durante años, Qrator Labs le recordó al mercado que si alguna información está disponible públicamente y no se requiere autorización para recibirla, entonces la probabilidad de protegerla del análisis automático tiende a cero. Al mismo tiempo, les recordamos a los propietarios del negocio digital que tienen derecho a elegir qué hacer con las solicitudes que llegan al servidor. Un enfoque proactivo en ciertas situaciones ayuda a evaluar e identificar la amenaza.

A medida que los bots generan una proporción creciente de tráfico, podemos esperar un momento futuro en el que los servicios grandes crearán interfaces especiales para buenos bots, dándoles información legítima. El resto será bloqueado. Incluso ahora, a principios de 2020, se puede argumentar que no un usuario 100% legítimo no podrá acceder de inmediato a ningún recurso en Internet; muchos no lo permitirán si, por ejemplo, simplemente cambia el agente de usuario del navegador a uno arbitrario.

Dentro de Qrator Labs, el servicio antibot se ha desarrollado activamente durante varios años, y en 2020 esperamos ofrecerlo a nuestros primeros clientes como parte del servicio beta. Este servicio funcionará en modos semiautomático y automático, lo que permite identificar y establecer reglas de seguridad frente a una serie de solicitudes automatizadas o salientes de bots.


Equipo


Después de probar los nuevos procesadores AMD, los empleados responsables de la compañía estaban tan intrigados que en el primer trimestre de 2020 Qrator Labs pondrá en marcha un nuevo punto de presencia en Osaka, Japón, completamente construido sobre procesadores AMD. PCI Express de cuarta generación, disponible con CPU AMD, promete duplicar el ancho de banda entre la CPU y la interfaz de red. Durante el año, se probará y evaluará el uso de este ligamento en los escenarios más estresantes. El canal entre la interfaz de red y el procesador se convierte gradualmente en un cuello estrecho con un aumento en la cantidad de datos transmitidos en las redes. La combinación de núcleos adicionales, un caché más grande y la nueva versión de PCI Express promete traer un buen resultado.

Otra razón para usar la CPU AMD es la necesidad de diversificar la arquitectura de red, aunque este es el primer punto de presencia de Qrator Labs, construido completamente en el nuevo procesador.

Estamos ansiosos por el inicio del trabajo de nuevos equipos, cuyo lanzamiento se informará por separado a principios de 2020. Esperamos que la combinación de procesadores AMD y tarjetas de red de alto rendimiento con PCI Express 4 cumpla con nuestros requisitos. El mercado asiático es uno de los de más rápido crecimiento, y me gustaría apreciar las perspectivas de neutralizar los ataques DDoS con nuevos equipos allí.

Al mismo tiempo, se espera la llegada de una nueva generación de procesadores Intel: Ice Lake. Su uso posterior en nuestra infraestructura dependerá en gran medida de los resultados de sus pruebas y comparaciones.

Además de los procesadores, toda la industria espera el lanzamiento de las tarjetas de red Intel serie 800. En 2020, intentaremos encontrar su aplicación dentro de la infraestructura de la red de filtración.

Con respecto a los interruptores, Qrator Labs continúa trabajando con Mellanox, que ha demostrado en repetidas ocasiones ser un proveedor y socio confiable.

Decir que esto no es fácil, pero mientras Broadcom domina el mercado de equipos de red, esperamos que la fusión con NVidia le brinde a Mellanox la oportunidad de una competencia digna.

Futuras mejoras a la red de filtrado.


Durante 2020, nuestra compañía espera profundizar significativamente su asociación con proveedores de una amplia variedad de servicios y servicios, como el firewall de aplicaciones web y la red de entrega de contenido dentro de la red de filtrado. Siempre hemos intentado integrar una variedad de proveedores en la infraestructura para proporcionar las mejores combinaciones de servicios posibles para los consumidores. Para fines de 2020, está previsto anunciar la disponibilidad de una serie de nuevos proveedores de servicios junto con Qrator.

2019 también reveló una serie de preguntas sobre la protección de la tecnología WebSockets. Su prevalencia y popularidad solo está creciendo, y la complejidad de la protección adecuada no se reduce. Durante 2020, esperamos trabajar con algunos de nuestros clientes que utilizan la tecnología WebSockets para encontrar la mejor manera de protegerlo, incluso si enviamos datos arbitrarios (desconocidos).

Lo que hacemos no es know-how ni revelación. La compañía llegó a este mercado más tarde que muchos competidores. El equipo hace grandes esfuerzos para hacer algo único y funcional. Parte de esta oportunidad también radica en el interés genuino de los empleados de la compañía en la investigación académica y científica en las principales áreas de esfuerzo, lo que nos permite estar preparados para eventos “repentinos”.

Como has leído hasta el final, aquí está el .pdf para distribución . No se olvide de la seguridad de la red usted mismo, y no se la dé a otros.

Source: https://habr.com/ru/post/undefined/


All Articles