Mitigação simples de ataques DDoS com SYN Proxy - Histórico de revisão

Henri.godoy: Up2

2025-02-17T16:57:03Z

Up2

Henri.godoy em 16h07min de 17 de fevereiro de 2025

2025-02-17T16:07:40Z

Henri.godoy em 15h55min de 17 de fevereiro de 2025

2025-02-17T15:55:39Z

Henri.godoy em 15h53min de 17 de fevereiro de 2025

2025-02-17T15:53:32Z

Henri.godoy em 15h52min de 17 de fevereiro de 2025

2025-02-17T15:52:56Z

Henri.godoy em 15h50min de 17 de fevereiro de 2025

2025-02-17T15:50:08Z

Henri.godoy: Up1

2025-02-17T15:45:47Z

Up1

Henri.godoy: Inicio.

2025-02-17T15:37:08Z

Inicio.

Página nova

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:

<nowiki>#</nowiki> 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:

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

<nowiki>#</nowiki> 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

<nowiki>#</nowiki> 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.

<nowiki>#</nowiki>!/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:

<nowiki>#</nowiki> 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:

<nowiki>#</nowiki> sysctl -w /net/netfilter/nf_conntrack_max=2000000

Ajustar o tamanho do hash do rastreamento de conexão

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

Habilitar timestamps para melhorar a eficácia do SYN Proxy

<nowiki>#</nowiki> 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 :

<nowiki>#</nowiki> net.netfilter.nf_conntrack_tcp_loose=0

<nowiki>#</nowiki> net.ipv4.tcp_syncookies=1

<nowiki>#</nowiki> 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''':

<nowiki>#</nowiki> 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.

@@ Linha 1: / Linha 1: @@
-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.
+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 '''[https://blog.cloudflare.com/pt-br/ddos-threat-report-for-2024-q4/ 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 '''[https://securityleaders.com.br/volume-de-ataques-ddos-aumenta-cerca-de-400-nos-ultimos-seis-meses/ 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.
+Diante desse cenário e previsões cada vez mais de ataques sofisticados para 2025, segundo a '''[https://www.fortinet.com/br/blog/threat-research/previsoes-de-ameacas-para-2025-prepare-se-para-ataques-maiores-e-mais-ousados 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 o '''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:
@@ Linha 81: / Linha 81: @@
 </pre>
-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:
+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:
 <pre>
@@ Linha 89: / Linha 89: @@
 </pre>
-Além disso, ajustes adicionais no Kernel podem ser feitos para otimizar o funcionamento do '''SYN Proxy''':
+Além disso, ajustes adicionais no '''Kernel''' podem ser feitos para otimizar o funcionamento do '''SYN Proxy''':
 <pre>
@@ Linha 130: / Linha 130: @@
 === 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.
+Sim, para quem está a frente do tempo, realizou a lição de casa, e está utilizando o '''IPv6''', deve trocar 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á atende 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.
+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.'''
+Portanto, 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.
+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 [[Data Center IPv6-only com SIIT-DC e Jool|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.
 [[Arquivo:Fig 2.png|alt=|centro|miniaturadaimagem|640x640px|Figura 2 - Solicitações TCP SYN em servidores IPv6-only.]]

← Edição anterior		Edição das 15h55min de 17 de fevereiro de 2025
Linha 144:		Linha 144:

	Além disso, monitorar a rede com o '''nf_conntrack''' é essencial para evitar sobrecarga e garantir um funcionamento eficiente da rede.		Além disso, monitorar a rede com o '''nf_conntrack''' é essencial para evitar sobrecarga e garantir um funcionamento eficiente da rede.
		+
		+	Qualquer dúvida, sugestões, críticas, estou a disposição. [https://www.linkedin.com/in/henri-alves-godoy/ Linkedin]
		+
		+	Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Henri.godoy Henri A. Godoy]
		+
		+	[[Categoria:Infraestrutura]]
		+	[[Categoria:DDoS]]

@@ Linha 59: / Linha 59: @@
 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.
+Para configurar o '''SYN Proxy''' com o '''nftables,''' utilize as linhas abaixo. Aqui agradeço a colaboração do meu amigo Mestre [[Usuário:Gondim|Marcelo Gondim]] que enviou as linhas para o nftables.
 <pre>

@@ Linha 120: / Linha 120: @@
 === 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''':
 <nowiki>#</nowiki> 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.

@@ Linha 26: / Linha 26: @@
 === Por que o iptables --limit não funciona? ===
 Muitos administradores de rede tentam mitigar ataques '''SYN Flood''' com regras como:
 <nowiki>#</nowiki> 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.
@@ Linha 33: / Linha 37: @@
 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? ===
+=== 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.
@@ Linha 56: / Linha 60: @@
 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.
 <nowiki>#</nowiki>!/usr/sbin/nft -f
@@ Linha 72: / Linha 78: @@
 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:
 <nowiki>#</nowiki> 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:
@@ Linha 90: / Linha 104: @@
 <nowiki>#</nowiki> 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 :
 <nowiki>#</nowiki> net.netfilter.nf_conntrack_tcp_loose=0
@@ Linha 99: / Linha 117: @@
 <nowiki>#</nowiki> 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''':

@@ Linha 42: / Linha 42: @@
 === Implementação do SYN Proxy no Linux ===
 Para configurar o '''SYN Proxy''' no '''iptables''', utilize as seguintes linhas:
 <nowiki>#</nowiki> iptables -t raw -I PREROUTING -i eth0 -p tcp --syn --dport 80 -j CT --notrack
@@ Linha 48: / Linha 50: @@
 <nowiki>#</nowiki> 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).

@@ Linha 21: / Linha 21: @@
 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? ===
@@ Linha 108: / Linha 110: @@
 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 ===