Mitigação simples de ataques DDoS com SYN Proxy

Nos últimos anos, os ataques de negação de serviço distribuídos (DDoS) tornaram-se cada vez mais frequentes e sofisticados. Em 2024, os sistemas autônomos (AS) de defesa contra DDoS da Cloudflare bloquearam aproximadamente 21,3 milhões de ataques, representando um aumento de 53% em comparação com 2023. No Brasil, essa tendência também é evidente. O Scrubbing Center da integradora Sencinet registrou um aumento de 400% no volume de ataques nos últimos seis meses de 2023.

Diante desse cenário e previsões cada vez mais de ataques sofisticados para 2025, segundo a Fortinet, a ideia deste artigo surgiu da necessidade em se mitigar e oferecer uma solução eficiente, sem custo e rápida para os ataques SYN Flood em um Webserver / Linux, utilizando SYN Proxy, para garantir a segurança e estabilidade da rede, evitando o esgotamento dos recursos do servidor.

Antes de abordarmos na prática o assunto, uma breve classificação sobre os tipos de ataques:

Classificação dos ataques DDoS

Os ataques DDoS podem ser categorizados de acordo com a técnica utilizada:

Ataques Volumétricos: Visam sobrecarregar a largura de banda da vítima com tráfego massivo. Exemplos: UDP Flood, DNS Amplification.
Ataques de Protocolo: Exploram vulnerabilidades na pilha de protocolos para consumir recursos da infraestrutura alvo. Exemplos: SYN Flood, ACK Flood.
Ataques de Aplicação: Buscam exaurir os recursos de aplicações específicas. Exemplos: HTTP Flood, Slowloris.
Ataques Carpet Bombing: Distribuem tráfego malicioso para múltiplos alvos dentro da mesma rede, dificultando a mitigação.

Como funciona um ataque SYN Flood?

O ataque SYN Flood explora o three-way handshake, aperto de mão de três vias do TCP, que pode sobrecarregar um servidor da seguinte maneira:

O atacante envia um grande volume de pacotes SYN, abrindo conexões falsas.
O servidor responde com SYN-ACK, aguardando o ACK final do cliente.
Como o ACK nunca chega, a conexão fica pendente, consumindo memória e processador

Em ataques massivos, milhares de conexões ficam presas no estado SYN_RECV, impedindo conexões legítimas. Com um simples comando no Linux por exemplo, o netstat (sim eu ainda uso o netstat e não largo mão) você pode verificar o estado das conexões e uma poluição visual grande do ataque acontecendo.

Conforme podemos ver, a Figura 1 mostra a quantidade de solicitações SYN ao servidor Web em IPv4:

Por que o iptables --limit não funciona?

Muitos administradores de rede tentam mitigar ataques SYN Flood com regras como:

# iptables -A INPUT -p tcp --syn -m limit --limit 10/s -j ACCEPT

Porém, isso não resolve o problema real. O tráfego ainda chega ao servidor, consumindo recursos. Além disso, o atacante pode distribuir conexões entre diferentes IPs para contornar o limite imposto.

Uma solução eficiente é impedir que as conexões falsas sequer alcancem o servidor. Neste caso, o SYN Proxy surge como uma solução eficiente.

Como o SYN Proxy Resolve o Problema?

O SYN Proxy atua como intermediário no processo de handshake do TCP, validando apenas conexões legítimas. O funcionamento segue os passos abaixo:

O cliente envia um SYN para o servidor.
O SYN Proxy responde com SYN-ACK, sem repassar a solicitação.
Apenas se o cliente responder com ACK, a conexão é encaminhada ao servidor real.

Se um atacante estiver enviando apenas SYNs falsos, eles nunca chegam ao servidor.

Implementação do SYN Proxy no Linux

Para configurar o SYN Proxy no iptables, utilize as seguintes linhas:

# iptables -t raw -I PREROUTING -i eth0 -p tcp --syn --dport 80 -j CT --notrack

# iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460

# iptables -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state INVALID -j DROP

Nesse caso, as linhas do comando iptables estão atuando na porta 80. Caso queiram, podem ser adicionados as portas 443 também, ou outras portas onde a aplicação Web está sendo ouvida, como por exemplo: 8080 (Tomcat).

Para configurar o SYN Proxy com o nftables, utilize as linhas abaixo. Aqui agradeço a colaboração do meu amigo Mestre Marcelo Gondim que enviou as linhas para o nftables.

#!/usr/sbin/nft -f

add table inet filter

add synproxy inet filter https-synproxy mss 1460 wscale 12 timestamp sack-perm

add chain inet filter pre { type filter hook prerouting priority raw; policy accept; }

add rule inet filter pre tcp dport 443 tcp flags syn notrack counter

add chain inet filter in { type filter hook input priority filter; policy accept; }

add rule inet filter in ct state invalid,untracked synproxy name "https-synproxy" counter

add rule inet filter in ct state invalid counter drop

Para descobrir os valores corretos de MSS e WSCALE a ser inserido e assim deixar suas configurações mais otimizada e de acordo com a sua rede, podemos utilizar o tcpdump:

# tcpdump -pni eth0 -c 1 'tcp[tcpflags] == (tcp-syn|tcp-ack)' and port 80

Além disso, ajustes adicionais no Kernel podem ser feitos para otimizar o funcionamento do SYN Proxy:

Ajustar a conexão máxima no rastreamento de conexão:

# sysctl -w /net/netfilter/nf_conntrack_max=2000000

Ajustar o tamanho do hash do rastreamento de conexão

# echo 2000000 > /sys/module/nf_conntrack/parameters/hashsize

Habilitar timestamps para melhorar a eficácia do SYN Proxy

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

E para o nftables as linhas abaixo precisam estar configuradas e podem ser adicionadas permanentemente no arquivo /etc/sysctl.conf :

# net.netfilter.nf_conntrack_tcp_loose=0

# net.ipv4.tcp_syncookies=1

# net.ipv4.tcp_timestamps=1

Monitorando o uso do nf_conntrack

Como o nf_conntrack é essencial para o gerenciamento de conexões, é importante monitorar sua utilização. Para isso, podemos utilizar o comando lnstat:

# lnstat -c -1 -f nf_conntrack

Esse comando permite visualizar estatísticas como conexões rastreadas, novas conexões estabelecidas e pacotes detectados pelo subsistema de rastreamento de conexões do Linux.

Funciona com o IPv6 ?

Para quem está a frente do tempo, realizou a lição de casa, e está utilizando o IPv6, deve trocar o comando os comando correspondentes para as opções com IPv6, no caso do iptables por ip6tables apenas. O resto nada muda. No caso do uso do nftables, as regras utilizando inet já atendem tanto o IPv4 quanto IPv6.

Lembrando que a porcentagem de ataques de DDoS é muito maior em IPv4 do que em IPv6. Se em seu Data Center, seus servidores estão em pilha dupla (dual-stack) os ataques podem chegar por ambos os protocolos, assim, a duplicação da configuração acima, no caso do uso com iptables deve ser realizada adicionando outra linha com o ip6tables.

Assim, quanto mais avançarmos num modelo IPv6-only nos serviços Web de um Data Center, as chances são bem menores que você seja atingido por uma tempestade de conexões SYN-ACK.

A Figura 2 ilustra um fato curioso, apesar do servidor Web estar configurado apenas em IPv6, os pedidos de SYN listados está vindo de origens IPv4. Como assim ? O servidor está configura em sua infraestrutura do Data Center com o mecanismo de transição SIIT-DC para que clientes que estão isolados utilizando IPv4 apenas possam acessar os serviços Web que estão somente IPv6. Os endereços IPv6 listados na figura, são endereços IPv4 traduzidos para IPv6, comprovando que a maioria dos ataques ainda estão em IPv4.

Conclusão

Apesar deste artigo cobrir apenas um tipo de ataque DDoS, espero que o assunto tenha contribuído e auxiliado toda a comunidade técnica, demonstrando como o SYN Proxy realmente atua para que você tenha resultados eficazes no combate de ataques SYN Flood na sua rede, utilizando ferramentas livres (iptables, nftables) garantindo que apenas conexões legítimas cheguem ao seu servidor.

Além disso, monitorar a rede com o nf_conntrack é essencial para evitar sobrecarga e garantir um funcionamento eficiente da rede.