# TCP SYN Flood

## **📋 Índice**

1. [Conceitos Fundamentais](#-conceitos-fundamentais)
2. [O Three-Way Handshake](#-o-three-way-handshake)
3. [Mecanismo do Ataque](#-mecanismo-do-ataque)
4. [Técnicas de Exploração](#-técnicas-de-exploração)
5. [Cenários de Exploração Prática](#-cenários-de-exploração-prática)
6. [Detecção e Ferramentas](#-detecção-e-ferramentas)
7. [Mitigação e Prevenção](#-mitigação-e-prevenção)

***

## **🔍 Conceitos Fundamentais**

O **TCP SYN Flood** é um dos ataques de Negação de Serviço (DoS) mais clássicos e eficazes na camada de transporte (camada 4). Ele explora o funcionamento do processo de estabelecimento de conexão TCP para exaurir os recursos do servidor, impedindo que novos usuários legítimos se conectem.

***

## **🤝 O Three-Way Handshake**

Para entender o ataque, devemos primeiro entender como uma conexão TCP normal é estabelecida:

1. **SYN (Synchronize):** O cliente envia um pacote SYN ao servidor para iniciar a conexão.
2. **SYN-ACK (Synchronize-Acknowledge):** O servidor responde com um pacote SYN-ACK, confirmando o recebimento e reservando recursos (buffer, portas) para a conexão. A conexão entra no estado **HALF-OPEN (Meio-Aberta)**.
3. **ACK (Acknowledge):** O cliente responde com um pacote ACK, e a conexão é estabelecida (**ESTABLISHED**).

***

## **🏗️ Mecanismo do Ataque**

No ataque SYN Flood, o atacante envia uma avalanche de pacotes SYN, mas **nunca responde** ao SYN-ACK do servidor, ou utiliza **IPs falsificados (Spoofed)** que não podem responder.

### **O Fluxo do Ataque**

```mermaid
sequenceDiagram
    participant A as Atacante (Spoofed IP)
    participant S as Servidor Alvo
    participant V as Vítima Real (IP Forjado)

    A->>S: Enviando SYN (IP forjado de V)
    S->>V: Enviando SYN-ACK (Tentando confirmar)
    Note over S: Conexão em estado HALF-OPEN
    V->>S: Ignora ou envia RST (Não solicitou conexão)
    A->>S: Enviando +10.000 pacotes SYN...
    Note over S: Tabela de conexões (Backlog) cheia!
    S->>S: Recusando conexões legítimas
```

Quando a tabela de conexões pendentes do servidor (chamada de **SYN Backlog**) fica cheia, o servidor não consegue mais processar novos pedidos de conexão, ficando indisponível para usuários reais.

***

## **🔧 Técnicas de Exploração**

### **1. SYN Flood Direto**

O atacante usa seu próprio IP real. É fácil de rastrear e bloquear, mas eficaz se o alvo não tiver proteção básica.

### **2. Spoofed SYN Flood**

O atacante falsifica o endereço IP de origem em cada pacote SYN. Isso torna o rastreio difícil e faz com que o servidor envie os SYN-ACKs para terceiros, espalhando o tráfego.

### **3. Distributed SYN Flood (DDoS)**

Uso de uma **Botnet** para enviar pacotes SYN de milhares de origens diferentes simultaneamente, tornando o bloqueio por IP praticamente impossível.

***

## **🚀 Cenários de Exploração Prática**

### **Cenário A: Teste de Stress com Hping3**

O `hping3` é a ferramenta de linha de comando mais comum para realizar testes de SYN Flood.

```bash
# Inundação de SYN com IP de origem aleatório (--rand-source)
sudo hping3 -S --flood -V --rand-source -p 80 192.168.1.10
```

* `-S`: Define a flag SYN.
* `--flood`: Envia pacotes o mais rápido possível (sem esperar resposta).
* `--rand-source`: Falsifica o IP de origem.
* `-p 80`: Alvo na porta 80.

### **Cenário B: Uso do Nmap para Detecção de Vulnerabilidade**

O Nmap pode ser usado para verificar se um serviço está processando conexões de forma ineficiente.

```bash
nmap -p 80 --script http-slowloris --max-parallelism 400 <target>
```

***

## **🔍 Detecção e Ferramentas**

### **1. Netstat (Visualização do Backlog)**

No servidor alvo, você verá muitas conexões no estado `SYN_RECV`.

```bash
netstat -an | grep SYN_RECV | wc -l
```

Se este número for muito alto (centenas ou milhares), você provavelmente está sob ataque.

### **2. Tcpdump / Wireshark**

Monitorar a entrada de pacotes SYN massivos sem os respectivos ACKs de resposta.

***

## **🛡️ Mitigação e Prevenção**

### **1. SYN Cookies (A defesa principal)**

O servidor não reserva recursos imediatamente. Ele envia um SYN-ACK com um "número de sequência criptografado" (cookie). O servidor só reserva recursos após receber o ACK final validando esse cookie.

```bash
# Habilitar no Linux
sysctl -w net.ipv4.tcp_syncookies=1
```

### **2. Aumentar o SYN Backlog**

Aumentar o tamanho da fila de conexões pendentes que o sistema pode suportar.

```bash
sysctl -w net.ipv4.tcp_max_syn_backlog=2048
```

### **3. Reduzir o Timeout de SYN-ACK**

Diminuir o tempo que o servidor espera pelo ACK final antes de fechar a conexão pendente e liberar os recursos.

```bash
sysctl -w net.ipv4.tcp_synack_retries=2
```

### **4. Firewall e IPS**

Configurar limites de conexões SYN por segundo por IP de origem no Iptables ou em soluções como Cloudflare/AWS Shield.

```bash
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
```

***

> O TCP SYN Flood continua sendo uma ameaça séria, especialmente em ataques DDoS volumétricos. A implementação de **SYN Cookies** é a primeira e mais importante linha de defesa em qualquer servidor exposto à internet.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/rede-and-infraestrutura/tcp/tcp-syn-flood.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.