He trabajado de forma remota durante más de 15 años en tres trabajos diferentes. Aunque no dependo tanto de mi cliente VPN remoto como hace 10 años, todavía hay muchos recursos de la empresa, por ejemplo, los hosts de Radware del laboratorio de piratería, que necesitan que esté en la VPN de la empresa.

A raíz de la pandemia de COVID-19, muchas organizaciones de TI se encuentran luchando por enfrentar el repentino aumento en el tráfico de VPN, ya que la mayoría de los empleados eligen (o se les ha ordenado) trabajar desde casa. Desafortunadamente, esto también presenta una oportunidad de oro para que los atacantes maliciosos interrumpan sus objetivos al lanzar varios tipos de ataques en la infraestructura VPN de la empresa.

La mayoría de las organizaciones usan concentradores y aplicaciones VPN remotas antiguas y anticuadas que funcionan en una arquitectura de radios centrales. Esto se debe a que las VPN siempre se consideraron como un elemento de "llenar el vacío" de la infraestructura de TI, destinado a los trabajadores en viajes de negocios o para las personas que acceden a los recursos de la empresa fuera del horario laboral. El tráfico esperado a través de la VPN era un pequeño porcentaje del tráfico total de TI.

Una vez que nuestros clientes clave en la industria farmacéutica realmente se prepararon para este día. Anticiparon una situación en la que la mayor parte de su fuerza laboral tendría que trabajar desde casa y diseñaron su Defensas DDoS alrededor de esta suposición. No solo eso, contrataron a una compañía externa de pruebas de DDoS para ejecutar ataques en la infraestructura VPN para medir la resistencia de los diferentes componentes.

A continuación se presentan las lecciones aprendidas del DDoS
El ataque se ejecutó en su infraestructura VPN.

Lección #1

Es fácil agotar recursos en concentradores VPN y cortafuegos, incluso con un ataque de bajo volumen.

Incluso con un volumen de ataque tan bajo como 1 Mbps, un ajuste fino Ataque de mezcla TCP–Donde el atacante envía una pequeña cantidad de paquetes TCP con la marca SYN marcada, otro lote de paquetes TCP con la marca ACK, otro conjunto de paquetes URG, etc.– pudo llevar los firewalls de la red a un estado en el que pudieran manejar no más conexiones nuevas. La mayoría de las defensas DDoS no se activan porque los umbrales de volumen no se activan.

[También te puede interesar: Preservar la continuidad del negocio durante la pandemia de coronavirus]

Para protegerse contra este tipo de ataque, debe ajustar sus hosts, sus firewalls y sus políticas DDoS. Muchos firewalls de red tienen una función de "SYN defender" o "conexión embrionaria", que puede proteger contra SYN Floods. Para la política DDoS, use características que permitan la detección y prevención de paquetes fuera del estado.

Un local Dispositivo de mitigación DDoS generalmente permitirá más opciones de ajuste durante un ataque que un servicio DDoS basado en la nube, ya que las políticas están completamente bajo el control de los clientes y no se comparten con otros clientes en la nube. Finalmente, si usa la limitación de velocidad, es mejor establecer umbrales que coincidan con su número esperado de conexiones VPN; muchos dispositivos de mitigación tienen parámetros predeterminados que no siempre funcionan bien para aplicaciones VPN.

Lección #2

Las VPN SSL son susceptibles a las inundaciones SSL, al igual que sus servidores web.

Dos de las pruebas DDoS fueron variaciones de un Ataque de inundación SSL. El primer ataque fue una inundación de conexión SSL de alto volumen. Este ataque intenta agotar los recursos del servidor utilizando un alto volumen de solicitudes de enlace SSL.

[También te puede interesar: ¿Es legal evaluar un servicio de mitigación de DDoS?]

Para protegerse contra este ataque, dispositivos con estado como firewalls, concentradores VPN y equilibradores de carga debe ser monitoreado cuidadosamente para las sesiones y estados de TCP. Además, crear una línea de base y configurar alertas contra esas líneas de base ayudará durante la resolución de problemas durante un ataque real.

En los firewalls, utilice funciones como "límite de conexión simultánea" y reduzca los tiempos de espera de sesión para las conexiones sin paquetes de datos. En la política DDoS, permita que se establezca un número limitado de conexiones al mismo tiempo desde una dirección IP de origen determinada. Además, reduzca los tiempos de espera de las sesiones para liberar las tablas de conexión en el firewall.

Finalmente, Radware ofrece un par de mecanismos de defensa patentados que pueden ayudar con las inundaciones de SSL, tanto en las instalaciones como en la nube: DefensaSSL identifica el tráfico sospechoso mediante el análisis de comportamiento y luego activa el módulo SSL incorporado para el descifrado. A través de un conjunto de mecanismos de respuesta al desafío, aplicados solo al tráfico sospechoso, el ataque se identifica y mitiga. Si el cliente supera todos los desafíos, las solicitudes HTTPS posteriores pueden llegar directamente al servidor protegido, creando así una nueva sesión TLS / SSL entre el cliente y el servidor SSL protegido.

Este modelo de implementación único permite una solución que introduce latencia cero en tiempo de paz y latencia mínima bajo ataque, solo en la primera sesión HTTPS por cada cliente. Para escenarios en los que no es posible usar un certificado para descifrar, se puede usar la protección SSL de comportamiento. Esto puede proteger contra inundaciones SSL sin descifrar la conexión SSL.

El segundo ataque SSL fue un Inundación de renegociación SSL.  Un ataque de renegociación SSL / TLS aprovecha la potencia de procesamiento necesaria para negociar una conexión TLS segura en el lado del servidor. Envía datos espurios al servidor o constantemente solicita renegociar la conexión TLS, agotando así los recursos del servidor más allá de sus límites.

Para protegerse contra este ataque, deshabilite la renegociación SSL en el servidor. Las suites de cifrado débiles también deberían deshabilitarse. Otra opción es utilizar la descarga SSL utilizando equilibradores de carga externos de alta capacidad para liberar su firewall o concentrador VPN. Radware puede proteger contra este tipo de ataque tanto en implementaciones locales como en la nube.

Lección #3

Las VPN son susceptibles a las inundaciones UDP.

Dos de los escenarios de ataque incluyeron inundaciones UDP. Una fue una inundación UDP aleatoria y la segunda fue una inundación IKE. IKE se utiliza para las VPN IPSec para autenticación y encriptación.

Debido a que los números de puerto UDP son aleatorios, utilice un mecanismo de defensa DDoS basado en el comportamiento, por ejemplo, BDoS de Radware, que es capaz de detectar inundaciones UDP mediante la generación de firmas en tiempo real.

[También te puede interesar: 5 mitos sobre DDoS en 2020]

Lección #4

El monitoreo y las alertas son obligatorios..

La mitigación de muchos de los ataques realizados requería visibilidad en tiempo real y ajuste de parámetros en la política DDoS, así como en los firewalls de red y concentradores VPN. Para ajustar los umbrales con precisión, es imperativo tener un conocimiento profundo de su tráfico VPN normal, tanto el volumen (en Mbps o Gbps) como el número normal de conexiones que se esperan. Monitorear conexiones en diferentes dispositivos puede ser más fácil con un SIEM. Además, las medidas en tiempo real, como la reducción de los tiempos de espera de sesión y la limitación de velocidad, funcionan mejor si conoce las líneas de base normales.

Si bien las lecciones anteriores provienen de una prueba DDoS controlada, muchos de los vectores de ataque utilizados en la prueba son como lo que uno puede esperar de las entidades maliciosas. Mientras se esfuerza por aumentar la capacidad de sus VPN para soportar el aumento de trabajadores remotos, no se olvide de prepararse también para la protección DDoS.

Manténgase seguro y saludable: espero que salga más fuerte al otro lado del túnel.