Ya hemos visto a lo largo de estos años, entradas anteriores con algunas contra-medidas para intentar detener ataques DDoS, diferentes scripts bash como DDoS Deflate y FloodMon para mitigar ataques de flood, módulos Anti-DDoS para servidor web Nginx, usar CloudFlare para proteger el tráfico web, y mitigaciones (sobretodo basadas en iptables y el kernel de Linux) contra ataques basados en UDP y ahora le toca el turno a las inundaciones basadas en TCP usando SYNPROXY (iptables/netfilter)

Ataques Denegación de Servicio (DoS) basados en TCP

• SYN Flood
• SYN-ACK Flood
• ACK & PUSH ACK Flood
• ACK Fragmentation Flood
• RST/FIN Flood

La mayoría de los ataques TCP flooding son:

• Ataques usando 3-Way HandShake (3WHS)

SYN-DDoS – es el conjunto de escenarios de ataques DDoS que explotan las peculiaridades de la realización del protocolo TCP (Transmission Control Protocol, protocolo de control de transmisión). El establecimiento de una conexión TCP transcurre en tres etapas, que recuerdan el proceso de dar un apretón de manos: El cliente envía un paquete con la bandera SYN. El servidor, al recibir el paquete SYN, responde con un paquete con encabezados SYN y ACK. Después, el cliente envía un paquete ACK, con lo que confirma la conexión. Durante el proceso de SYN-flood el atacante envía un paquete con la bandera SYN, pero no exige un paquete de respuesta con las banderas SYN+ACK para establecer la conexión, lo que obliga al servidor de la víctima a gastar recursos en el procesamiento de estas solicitudes y el envío de paquetes de respuesta.

TCP-DDoS – es el conjunto de escenarios de ataques que de la misma manera que SYN-flood, explotan las peculiaridades de la realización del protocolo TCP, pero al mismo tiempo establecen conexión con el servidor de la víctima. En los ataques de tipo TCP-flood, después de la realización del procedimiento del “apretón de manos” (handshake), la parte atacante envía datos “basura” de gran tamaño y de una forma muy lenta por la conexión establecida. Esto recarga el servidor y no le permite dar recursos a las conexiones legítimas.

Mitigación de inundaciones (Flood) SYN con iptables - SYNPROXY

SYNPROXY es una novedad de iptables que se ha añadido en la versión del kernel 3.12 de Linux e iptables 1.4.21. CentOS 7 ha portado la característica y está disponible por defecto en su kernel 3.10.

El propósito de synproxy es comprobar si el host que envió el paquete SYN en realidad establece una conexión TCP completa o simplemente no hace nada después del envío del paquete SYN. Si no hace nada, se descarta el paquete con un impacto mínimo en el rendimiento.




Configurar synproxy puede ser complicado sin una guía paso a paso, ya que se necesitan algunos ajustes previos.

Podemos usar un script bash de configuración:

• https://github.com/netoptimizer/network-testing/blob/master/iptables/iptables_synproxy.sh

Ajuste de la configuración del kernel

Debido a la característica de "synproxy" utiliza syncookies y syncookies utilizan marcas de tiempo, lo tenemos que habilitar en nuestra configuración del kernel. Puedes editar tu fichero /etc/sysctl.conf para reflejar estos ajustes o aplicarlos directamente con:

sysctl -w net/ipv4/tcp_syncookies=1
sysctl -w net/ipv4/tcp_timestamps=1

Por otra parte tenemos que ajustar la configuración del conntrack, ya que una parte importante de la función "synproxy" es la de no realizar un seguimiento de las conexiones TCP que no estén constituidos por completo, debido a que necesita una gran cantidad de recursos. La siguiente configuración excluirá paquetes ACK de seguimiento de conexiones y los marcará como no válido.

sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

Si ese comando anterior devuelve un error, tratar de aplicarlo más tarde, cuando el módulo conntrack del  núcleo está realmente activo.

Ahora sentido el aumento de tamaño conntrack hash y el ajuste conntrack_max, ya que si tienes un sitio con mucho tráfico, se recomienda realizar el ajuste de entrada del conntrack para aumentar el límite de 64 K conn predeterminado. Sin embargo, es crucial para el rendimiento que también recuerda a aumentar el tamaño conntrack hash.

echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize
sysctl -w net/netfilter/nf_conntrack_max=2000000

Estos son sólo dos de los ajustes más importantes, hay un montón de otras configuraciones del kernel que pueden ser ajustadas con el fin de aumentar el rendimiento de la red para soportar muchas conexiones / paquetes


Recuerda que debes establecer sus propios límites y calcular el uso de la memoria. En este ejemplo, 2 millones de entradas veces 288 bytes = max 576,0 MB de uso de la memoria potencial. Para el hash, cada lista de hash "cabeza" es sólo 8 bytes por 1 millón es sólo 8 MB de memoria asignada fija (importaría L3 cache-size de la CPU al elegir el tamaño de hash).



Mientras que las reglas de iptables que hemos proporcionado otras veces ya bloquean la mayoría de los ataques basados en TCP, el tipo de ataque todavía puede complicarse si es lo suficientemente sofisticado ataque de inundación SYN. Es importante tener en cuenta que el rendimiento de las reglas siempre será mejor si nos encontramos con un cierto patrón o firma a bloquear, tales como la longitud del paquete (longitud -m), TOS (-m tos), TTL (TTL -m) o cadenas y los valores hexadecimales (cadena -m y u32 -m para los usuarios más avanzados). Sin embargo, en algunos casos raros, no es posible o al menos no es fácil de archivar. Por lo tanto, en estos casos, se puede hacer uso de synproxy.


Aquí están las reglas de iptables synproxy que ayudan a mitigar las inundaciones SYN que traspasan otras reglas:

iptables -t raw -D PREROUTING -p tcp -m tcp --syn -j CT --notrack
iptables -D INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -D INPUT -m conntrack --ctstate INVALID -j DROP 

La primera regla que insertamos, excluye paquetes SYN del seguimiento de conexiones, porque eso sería utilizar una gran cantidad de recursos y, obviamente no es lo que queremos. Le decimos a la tabla "raw" maneja las conexiones sin seguimiento, el objetivo "CT" es sinónimo de "conntrack" y la opción "--notrack" los excluye de seguimiento. Es para asegurarse de que las conexiones que necesitan protección no crean nuevas entradas conntrack para paquetes SYN.

La segunda regla se aplica a los paquetes SYN (sin seguimiento (UNTRACKED) según la regla anterior) y los paquetes ACK (inválidos por "nf_conntrack_tcp_loose = 0") y los reenvía al destino synproxy, que los verifica los syncookies (en paralelo, lo que no era posible anteriormente) y establece las conexiones TCP completas.

La tercera y última regla que añadimos elimina (DROP).


Estas reglas se aplican a todos los puertos. Si desea utilizar synproxy sólo en determinados puertos TCP que están activas (recomendado - También se debe bloquear todos los puertos TCP que no están en uso utilizando la tabla mangle y la cadena PREROUTING), puede simplemente añadir -- dport 80 a cada una de las reglas si quieren utilizar synproxy en el puerto 80 solamente.

Para verificar que synproxy está trabajando, puedes hacerlo con:

watch -n1 cat /proc/net/stat/synproxy

Si los valores cambian cuando se establece una nueva conexión TCP con el puerto que utiliza el synproxy, es que entonces funciona.


Fuentes:
http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/
https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html
https://javapipe.com/iptables-ddos-protection

Vía:
http://www.hackplayers.com/2016/04/proteccion-ddos-mediante-iptables.html