Protección contra DDoS de OPNsense

Un problema bastante molesto: es un servidor web que se ve regularmente paralizado por un ataque SYN flood. De repente, las páginas web y los servicios dejan de funcionar correctamente, aunque el hardware apenas estaba siendo utilizado. Esto se debe a conexiones TCP semiabiertas, un clásico ataque distribuido de denegación de servicio [DDoS].

Utilizando OPNsense como cortafuegos puedes resolver el problema en la medida de lo posible.

Ataques Syn Flood

Una inundación SYN interrumpe un servicio web utilizando una vulnerabilidad del protocolo TCP/IP. En el enorme mundo de las amenazas cibernéticas, la inundación TCP SYN destaca como un tipo de ataque de denegación de servicio (DoS) especialmente malicioso. Al manipular los protocolos que rigen la comunicación por Internet, los atacantes pueden inundar los servidores, dejándolos inaccesibles para las consultas legítimas.

Una inundación SYN (ataque semiabierto) es un tipo de ataque de denegación de servicio (DoS) que intenta hacer que un servidor sea inaccesible al tráfico genuino utilizando todos los recursos disponibles del servidor. Mediante la transmisión persistente de paquetes de solicitud de conexión inicial (SYN), un atacante puede inundar un ordenador servidor objetivo con todos los puertos accesibles, lo que provoca que el dispositivo reaccione lentamente al tráfico legítimo o no reaccione en absoluto.

Un ataque de inundación TCP SYN intenta explotar el procedimiento de tres pasos de TCP, que es esencial para establecer conexiones en redes TCP/IP. El protocolo TCP tiene tres pasos:

1. Un cliente envía un mensaje SYN (sincronizar) a un servidor, expresando su deseo de establecer una conexión.

2. El servidor confirma esta solicitud devolviendo un mensaje SYN-ACK al cliente.

    El cliente envía un ACK (reconocimiento) y la conexión se establece correctamente.

En un ataque de inundación TCP SYN, la entidad hostil envía una avalancha de solicitudes SYN a un servidor de destino, evitando deliberadamente proporcionar el ACK final. Esto hace que el servidor utilice recursos para cada una de estas conexiones semiabiertas mientras espera una respuesta que no llega.

¿Cómo se mitiga un ataque SYN Flood?

Tenga en cuenta las siguientes características para mejorar la defensa contra DDoS y mitigar más rápidamente los ataques DDoS TCP SYN Flood:

Aumentar la cola de espera: cada sistema operativo de un dispositivo de destino permite un número fijo de conexiones semiabiertas. Aumentar el número máximo de conexiones semiabiertas que permite el sistema operativo es un método para gestionar grandes cantidades de paquetes SYN. Para aumentar adecuadamente la cola máxima, el sistema debe proporcionar recursos de memoria suficientes para gestionar todas las solicitudes entrantes. Si el sistema no tiene suficiente memoria para gestionar el aumento del tamaño de la cola de espera, el rendimiento del sistema se verá afectado; no obstante, esto puede ser preferible a la denegación de servicio.

 

 

Reciclar la conexión TCP semiabierta más antigua: Otro método de mitigación consiste en sobrescribir la conexión semiabierta más antigua después de que se haya eliminado la cola de espera. Este enfoque requiere que las conexiones legales se formen completamente en menos tiempo que la cola de espera de paquetes SYN fraudulentos. Esta protección falla cuando el volumen del ataque aumenta o el tamaño de la cola de espera es insuficiente para ser práctico.

Cookies SYN: Para evitar el peligro de perder conexiones cuando la cola está llena, el servidor responde a cada solicitud de conexión con un paquete SYN-ACK antes de eliminar la solicitud SYN de la cola, eliminándola de la memoria y manteniendo el puerto abierto y listo para aceptar una nueva conexión. Si la conexión es una solicitud válida y el equipo cliente envía un paquete ACK final al servidor, este volverá a crear el elemento de la cola de espera SYN (con algunas limitaciones). Aunque este intento de mitigación pierde cierta información sobre la conexión TCP, es preferible a que los usuarios genuinos sufran una denegación de servicio debido a un ataque.

⚠️ El único matiz: "Conexión" vs. "Petición"

Como OPNsense es un firewall de red (Capa 4) y el tráfico HTTPS viaja completamente cifrado, el firewall no puede ver las peticiones HTTP reales que van por dentro. Solo ve los "tubos" (conexiones TCP) que se abren para enviar esa información.

Esto tiene dos lecturas en el mundo real:

• El ataque común (Scrapers, bots, fuerza bruta): La inmensa mayoría de herramientas automatizadas y scripts de ataque abren una conexión TCP nueva por cada intento.

• El tráfico legítimo moderno (HTTP/2 o HTTP/3): Cuando un usuario real entra a tu web, los navegadores modernos abren una sola conexión TCP (o muy pocas) y, a través de ese único "tubo", piden de golpe las 60 imágenes, estilos y textos de tu página. Para OPNsense, eso cuenta como 1 sola conexión, por lo que los usuarios reales nunca serán bloqueados por error, aunque tu web cargue muchísimos elementos.

Paso 1: reenvío de puertos al servidor web

Si el servidor web funciona con OPNsense, has tenido que configurar un reenvío de puertos clásico (DST NAT) desde el puerto WAN 443 (HTTPS) a la IP interna del servidor.

Lo bueno es que, al crear una regla NAT de este tipo en OPNsense, se genera automáticamente una regla de firewall en la interfaz WAN. A continuación, puedes ajustar precisamente esta regla para incorporar la protección contra SYN Flood.

Paso 2: Activar la protección contra SYN Flood

En la regla WAN creada automáticamente (para el puerto 443), realiza el cambio decisivo en el área Advanced Options:

    State Type: establecido en Synproxy state.

 

De este modo, el cortafuegos se encarga del protocolo de enlace TCP (SYN → SYN/ACK → ACK). Solo cuando el cliente confirma correctamente la conexión, el tráfico se transmite al servidor real.

Hint: Select which type of state tracking mechanism you would like to use. If in doubt, use keep state.

Keep state is used for stateful connection tracking.

Sloppy state works like keep state, but it does not check sequence numbers. Use it when the firewall does not see all packets.

Synproxy state proxies incoming TCP connections to help protect servers from spoofed TCP SYN floods. This option includes the functionality of keep state and modulate state combined.

None: Do not use state mechanisms to keep track. This is only useful if you're doing advanced queueing in certain situations. Please check the documentation.

Esto tiene dos ventajas:

• Las conexiones semiabiertas (por ejemplo, de bots que solo envían SYN, pero no ACK) ni siquiera llegan al servidor web.
• El cortafuegos detecta y bloquea los clientes que no completan el protocolo de enlace de forma intencionada.

Esto supone una gran diferencia, especialmente en los ataques DDoS con miles de conexiones falsas, ya que el servidor apenas se ve afectado.

Paso 3: Limitar las conexiones por IP (cliente)

El segundo problema: algunos clientes (o atacantes) abren un número extremadamente elevado de conexiones paralelas. Incluso si consiguen establecer el handshake, pueden bloquear el servidor.

Aquí también OPNsense ofrece ajustes útiles en las opciones avanzadas de la regla del cortafuegos:

    Máximo de conexiones establecidas por host: → 20

    → Solo se permiten 20 conexiones TCP simultáneas por IP de origen.

    Máximo de nuevas conexiones por segundo por host: → p. ej., 5

    → De este modo, los bots no pueden abrir cientos de nuevas conexiones en un segundo.

    Máximo de entradas de estado por host: opcional, si también se desea limitar UDP u otros protocolos.

Importante: estos límites se aplican por regla. Por lo tanto, si se publican varios servicios (por ejemplo, HTTP en el puerto 80 y HTTPS en el puerto 443), se deben introducir los valores de forma coherente.

Un límite de 20 conexiones HTTPS por cliente es más que suficiente: los navegadores normales lo gestionan sin problemas, pero los atacantes alcanzan el límite inmediatamente.

Maximum new connections per host / per second(s) and overload table to use (TCP only), the default virusprot table comes with a default block rule in floating rules.

Opciones avanzadas - Límite de conexiones

Las opciones avanzadas contienen algunos ajustes para limitar el uso de una regla o especificar tiempos de espera específicos para la misma. La mayoría de los ajustes genéricos (por defecto) para estas opciones se pueden encontrar en Cortafuegos ‣ Configuración ‣ Avanzado

• Estados máximos

Limita el número de estados concurrentes que la regla puede crear. Cuando se alcanza este límite, los paquetes adicionales que crearían estados no coincidirán con esta regla hasta que los estados existentes caduquen.

• Nodos de origen máximos

Limita el número máximo de direcciones de origen que pueden tener simultáneamente entradas en la tabla de estados.

• Máximo establecido (Max established)

Limita el número máximo de conexiones TCP simultáneas que han completado el handshake de 3 vías que puede realizar un único host.

• Número máximo de estados de origen (Max source states)

Limita el número máximo de entradas de estado simultáneas que una única dirección de origen puede crear con esta regla.

• Máximo de nuevas conexiones (Max new connections)

Limita la tasa de nuevas conexiones en un intervalo de tiempo. La tasa de conexiones es una aproximación calculada como media móvil. (número de conexiones / segundos) Sólo se aplica a conexiones TCP. (aka Rate Limit)

Este método de limitación de velocidad ayuda a garantizar que una alta velocidad de conexión TCP no sobrecargue un servidor o la tabla de estado del cortafuegos. Por ejemplo, se pueden poner límites a las conexiones entrantes a un servidor de correo, reduciendo la carga de ser sobrecargado por spambots. 

 

 

También se puede utilizar en reglas de tráfico saliente para establecer límites que impidan que una sola máquina cargue la tabla de estado del cortafuegos o realice demasiadas conexiones rápidas, comportamientos que son comunes con los virus. 

Se puede configurar para la regla una cantidad de conexiones y un número de segundos para el periodo de tiempo. Cualquier dirección IP que exceda el número especificado de conexiones dentro del periodo de tiempo dado será bloqueada por el cortafuegos durante una hora. Entre bastidores, esto es manejado por la tabla virusprot, llamada así por su propósito típico de protección contra virus. Esta opción sólo está disponible para conexiones TCP.

• Tiempo de espera de estado

Tiempo de espera de estado en segundos (sólo se aplica a TCP)

max-src-nodes <number>
Limits the maximum number of source addresses which can simultaneously have state table entries.

max-src-states <number>
Limits the maximum number of simultaneous state entries that   a single source address can create with this rule.

For stateful TCP connections, limits on established connections (connections which have completed the TCP 3-way handshake) can also be enforced per source IP.

max-src-conn <number>
Limits the maximum number of simultaneous TCP connections which have completed the 3-way handshake that a single host can make.

max-src-conn-rate <number> / <seconds>
Limit the rate of new connections over a time interval.  The connection rate is an approximation calculated as a moving averag

Puede establecer límites de velocidad en las reglas del cortafuegos para:

• Maximum number of established connections per host (TCP only)
• Maximum number of unique source hosts
• Maximum new connections per host / per second(s) (TCP only)

Paso 4: Configuración avanzada del cortafuegos

En Cortafuegos → Configuración → Avanzado, también he activado «habilitar syncookies» en siempre. Se trata de una función de protección para todo el sistema que ofrece una protección adicional.

• Activar syncookies

Esta opción es bastante similar a la configuración del kernel syncookies, previniendo la asignación de memoria para servicios locales antes de que se realice un handshake apropiado.

Cuando los syncookies están activos, OPNSense responderá a cada TCP SYN entrante con un syncookie SYNACK, sin asignar ningún recurso.

En modo adaptativo, OPNSense activará el modo syncookie cuando un determinado porcentaje de la tabla de estado esté ocupado por conexiones TCP a medio abrir, es decir, aquellas que vieron el SYN inicial pero no terminaron el handshake de tres vías.

En este caso pf estará protegido contra el agotamiento de la tabla de estados.

Están disponibles los siguientes modos:

• nunca (por defecto)
• siempre
• adaptativo - en cuyo caso se debe especificar un porcentaje inferior y superior referido al uso de la tabla de estado (Firewall States)

Entrada man de pf.conf:

           never     pf will never send syncookie SYNACKs (the default).

           always    pf will always send syncookie SYNACKs.

           adaptive  pf will enable syncookie mode when a given percentage of

                     the state table is used up by half-open TCP connections,

                     as in, those that saw the initial SYN but didn't finish

                     the three way handshake.  The thresholds for entering and

                     leaving syncookie mode can be specified using

                           set syncookies adaptive (start 25%, end 12%)

Prefiero configurarlo como adaptativo, para que en escenarios normales sólo use syncookies cuando haya un problema real.

Ves a Firewall -> Configuración -> Avanzado

Habilitar syncookies: adaptativo:

Inicio (%): 70

Fin (%): 30

Por ejemplo:

El porcentaje inicial es la cantidad de entradas de la tabla de estado en las que las syncookies están habilitadas y el porcentaje final es cuando el modo syncookie se deshabilita de nuevo.

Optimización del firewall

La optimización de la tabla de estado del cortafuegos que se va a utilizar influye en el número de estados activos del sistema y solo se puede cambiar en escenarios de implementación específicos.

• [normal] (predeterminado) Como su nombre indica, es el algoritmo de optimización normal.
• [alta latencia] Se utiliza para enlaces de alta latencia, como los enlaces por satélite. Caduca las conexiones inactivas más tarde de lo predeterminado.
• [agresivo] Caduca las conexiones inactivas más rápidamente. Uso más eficiente de la CPU y la memoria, pero puede descartar conexiones inactivas legítimas.
• [conservador] Intenta evitar descartar cualquier conexión inactiva legítima a costa de un mayor uso de la memoria y la CPU.

Tiempos de espera adaptativos del firewall

Los tiempos de espera para los estados se pueden escalar de forma adaptativa a medida que aumenta el número de entradas de la tabla de estados.

• [start] Cuando el número de entradas de estado supera este valor, comienza el escalado adaptativo. Todos los valores de tiempo de espera se escalan linealmente con el factor (adaptive.end - número de estados) / (adaptive.end - adaptive.start).
• [fin] Al alcanzar este número de entradas de estado, todos los valores de tiempo de espera se convierten en cero, purgando efectivamente todas las entradas de estado de forma inmediata. Este valor se utiliza para definir el factor de escala, por lo que no debe alcanzarse realmente (establezca un límite de estado inferior, véase más abajo).

Conclusión

Con estos ajustes, el servidor debe funcionar de forma estable, incluso cuando una red de bots intenta volver a bloquearlo con paquetes TCP-SYN. Los usuarios honestos no notan nada, pero los atacantes se quedan en nada.

Especialmente cuando se utilizan redireccionamientos de puertos (por ejemplo, para HTTPS), no se deben dejar las reglas generadas automáticamente tal cual, sino que es imprescindible activar estos mecanismos de protección.

Fuentes:

https://schroederdennis.de/security/opnsense-ddos-protection-diese-2-optionen-schuetzen-syn-flood/

https://www.linkedin.com/pulse/mitigating-ddos-attacks-pfsense-firewall-q2lpf