¿Cómo mitigar los ataques DDoS basados en SSL?

5

como probablemente sepa, el problema con los ataques DDoS basados en SSL es que el tráfico no puede ser analizado y filtrado por un proveedor de servicios de mitigación DDoS como Prolexic, Akamai, Radware, etc. sin tener la clave para descifrar el tráfico.

Hace poco hablé con uno de los empleados de las empresas mencionadas anteriormente (digamos, compañía A) y dijeron que la única forma es utilizar uno de sus productos, que se encuentra en su red y su propósito es entregar contenido a través de ssl y envíe todo el tráfico en texto sin formato a la solución de defensa (la misma compañía, también la red interna), que a su vez proporciona el "buen tráfico" filtrado a sus servidores web internos.

Otras compañías tienen el enfoque de que usted les entrega la clave ssl, para que puedan descifrar y analizar su tráfico y pasar el tráfico limpio a sus servidores.

La compañía A declaró que lo último es un nogo absoluto y que ni siquiera debería considerarse. El problema es que su solución solo puede filtrar tanto tráfico como su infraestructura y su dispositivo pueden manejar, mientras que las soluciones en la nube tienen capacidades mucho más altas.

Entonces, la pregunta es, ¿hay alguna otra forma de mitigar los ataques DDoS basados en SSL? ¿Es la entrega de su clave ssl realmente tan mala y por qué?

Sé que ya existía una pregunta sobre "almacenar claves en la nube: confiar en el proveedor de la nube frente a su propia computadora portátil, etc." así que lo siento si parte de esto es un duplicado, pero las respuestas no respondieron realmente a mi pregunta.

    
pregunta mohrphium 13.11.2013 - 12:57
fuente

5 respuestas

5

Vamos a aclarar un par de ideas erróneas:

  • Los socios de mitigación de DDoS no pueden trabajar a menos que puedan descifrar el tráfico

Sí, pueden. Simplemente no pueden hacerlo, ya que el contenido no está visible, por lo que las soluciones que funcionan en el flujo de tráfico seguirán funcionando.

  • Entregar tu clave a un tercero es algo malo

No necesariamente. De hecho, esto es extremadamente común para las grandes corporaciones, que de todos modos suelen tener su infraestructura administrada por terceros. Lo que hace es exigir que reemplace algunos de sus controles técnicos con controles contractuales, y que asuma mayores responsabilidades de supervisión / auditoría sobre la tercera parte.

La mitigación de la amenaza de la tercera parte que utiliza incorrectamente la clave o no la protege es una tarea sencilla para evaluar y luego ofrecer una solución.

    
respondido por el Rory Alsop 13.11.2013 - 16:34
fuente
2

Los ataques DDoS SSL deben dividirse en dos -

  • Ataques de mal uso del protocolo - Tales ataques explotan el protocolo que se está utilizando y pueden causar un efecto de denegación de servicio sin completar la creación de una conexión segura (SSL en nuestro caso). Un buen ejemplo puede ser el THC-SSL-DOS, que se puede usar para crear 'renegociaciones' repetidas en la misma conexión, aunque nunca complete la creación de un canal seguro. Los ataques de protocolo, como el mencionado anteriormente, no requieren tener claves. Se pueden mitigar con medidas de protección relativamente simples, como la firma IPS, la aplicación de la configuración del servidor o incluso dispositivos DDoS dedicados Pravail / Riorey / DefensePro / NSFocus / etc.

  • Inundaciones de tráfico SSL - Aquí me refiero a los datos que se están pasando a través del canal seguro creado. Sin más información, estos magníficos dispositivos de mitigación no pueden distinguir entre conexiones válidas a conexiones maliciosas. Ni siquiera pueden emitir un desafío web para intentar evaluar la legitimidad de la fuente. Por lo tanto, o está atascado con nada o con alguna protección de límite de velocidad, propenso a acciones falsas.

Entonces, ¿qué se puede hacer - Algunos dispositivos pueden alimentarse con los certificados o conectarse a otro dispositivo de la misma familia (DefensPro-Alteon / Pravail-VSS), donde el producto hermano abre el cifrado, y el dispositivo ddos hace lo que hace y el flujo puede continuar o está bloqueado. Radware puede emitir un desafío en la solicitud cifrada inicial (y solo en ella). Arbor puede inspeccionar continuamente el tráfico encriptado y bloquear el tráfico sospechoso (sin desafío). Mientras mantenga estas máquinas en su lugar, los riesgos son bastante bajos.

Algunos servicios en la nube le ofrecen darles sus claves. Práctica no muy recomendada. Sin embargo, Prolexic, publicado recientemente, pueden vivir con claves de duración corta para lograr lo mismo. Esta podría ser una solución suficiente, considerando todas las demás limitaciones y restricciones cuando se trata de tráfico seguro (encriptado).

Y por último, ¿es malo proporcionar tu clave? De una manera muy básica: su clave es importante para asegurar sus comunicaciones. Si alguien tiene su clave, teóricamente puede "leer" sus comunicaciones o hacerse pasar por usted mientras se comunica con otros. Sin embargo, como alguien respondió antes que yo, puede practicar compartir o tener copias de sus llaves en diferentes lugares. Depende de su infraestructura, de quién gestione su red, etc. Sobre todo se relaciona con la CONFIANZA. Si confía en esta protección DDoS 'nacida ayer' en el servicio en la nube, vaya, déles sus llaves :). Hay empresas en las que se puede confiar y que hacen un gran esfuerzo para cumplir con todos los requisitos reglamentarios. No proporciona seguro al 100%, pero, francamente, nada lo hace.

    
respondido por el Ichilov 14.11.2013 - 14:14
fuente
1

Todos los proveedores le darán la misma respuesta: debe entregarles su clave para un producto de seguridad basado en la nube o para una caja que suministran que se encuentra en su red. De cualquier manera, no puede mitigar por completo la amenaza de tener sus claves.

La alternativa es mitigar las amenazas planteadas por ataques individuales mediante:

  • Mantener sus sistemas y aplicaciones actualizados: muchos ataques de ddos previamente graves han sido eliminados por el sistema operativo y las actualizaciones de software
  • Modificación de las configuraciones: a menudo puede modificar el sistema operativo y las aplicaciones para que sean mucho más resistentes
  • Descargue los cálculos de SSL: hay varias soluciones en esta área, a menudo los balanceadores de carga tienen motores criptográficos que pueden hacer el trabajo

Lo que realmente necesita hacer es realizar (o hacer que alguien realice) un análisis de amenazas para descubrir sus mayores preocupaciones, y luego buscar soluciones a esas. Puede ser que una solución de proveedor sea su mejor manera de avanzar, o puede hacerlo perfectamente usando soluciones tácticas, de bajo costo o de bajo costo.

    
respondido por el GdD 13.11.2013 - 13:40
fuente
1

La respuesta de Ichilov es más relevante.

Dos ataques SSL no vulnerables

  1. Enviar datos de basura en lugar de un secreto pre-maestro (SSL Handshake flood)
  2. Vuelva a negociar continuamente el secreto per-master desde el protocolo de enlace de nuevo & otra vez

La explicación de Hope Ichilov es suficiente

Mitigación:

  • El rompecabezas del cliente puede ayudar a mitigar los ataques DDoS. El puzzle del cliente Se podría desarrollar un mecanismo para el protocolo. Se basa en Sistemas de prueba de trabajo. Para SSL, un borrador IETF está disponible en enlace . El mecanismo de Client-Puzzle es un mecanismo de seguridad basado en la intención que no solo elimina a los clientes maliciosos, sino que aumenta la Costo del atacante. También estos mecanismos son más efectivos contra mitigación basada en firmas, que emplea sistemas IDS / IPS con enorme cantidad de reglas.

  • El otro método es externalizar el cálculo del exponente modular, Una operación altamente intensiva en recursos. Un cálculo parcial puede ser subcontratado a un sistema (s) daemon. De lo contrario, un sistema con Se puede utilizar crypto-chip. La subcontratación puede mejorar el rendimiento de el servidor, pero no elimina el cliente malicioso.

Ya desarrollé un mecanismo cliente-rompecabezas para trabajar con HTTP. También planeé desarrollar para SSL. Esperanza, puedes sentir el artículo interesante. enlace

    
respondido por el Gopi 23.07.2015 - 07:19
fuente
1

Hay formas y medios de monitorear los protocolos TCP y SSL para determinar el mal comportamiento antes de descifrar / descargar realmente.

Mire el hola del cliente / servidor para el cumplimiento sin RFC y considere la limitación de velocidad para las inundaciones 'hola' basadas en esto.

HTH.

    
respondido por el Ed Daniel 23.01.2017 - 16:00
fuente

Lea otras preguntas en las etiquetas