[TODO] Lab - SYN Flood con hping3 e difesa con SYN Cookies

Capitolo: Gibson Cap 7 — Protecting Against Advanced Attacks Concetti: SYN flood, half-open connections, IP spoofing, SYN cookies, connection table

Obiettivo

#

Simulare un SYN flood attack da Kali verso Ubuntu, osservare in tempo reale come si riempie la connection table con half-open connections, poi attivare SYN cookies come contromisura e verificare che il comportamento cambi.

Security angle: capire un attacco dal punto di vista del difensore. Un Cloud Security Engineer deve sapere riconoscere un SYN flood nei log e nei metric, e sapere quali knob del kernel Linux proteggono da questo. Lo stesso meccanismo è alla base di alert Suricata e regole WAF.

Ambiente

#

• Kali (192.168.64.200): lancia il flood
• Ubuntu (192.168.64.3): vittima — monitora in tempo reale
• Mac: opzionale — Wireshark per osservare il traffico raw

Apri due terminali: uno su Kali per lanciare il flood, uno su Ubuntu per monitorare.

Parte 1 — Baseline pre-attacco

#

Prima di lanciare qualsiasi cosa, stabilisci una baseline su Ubuntu.

Obiettivo: conta quante connessioni TCP sono in stato SYN_RECV adesso (dovrebbero essere zero o pochissime). Salva il numero — lo confronterai dopo.

Come sai che hai finito: hai il numero baseline e sai qual è il comando per monitorare le connessioni SYN_RECV in tempo reale.

Parte 2 — SYN Flood da Kali

#

Da Kali, lancia un SYN flood verso la porta 80 di Ubuntu con IP sorgenti randomici. Usa hping3 con i flag per: settare il flag SYN, mandare pacchetti il più veloce possibile, randomizzare l'IP sorgente.

Lascialo girare 20-30 secondi, poi fermalo con Ctrl+C.

Obiettivo: mentre il flood è attivo, osserva su Ubuntu:

• Il numero di connessioni SYN_RECV — cresce?
• Il carico CPU
• Se riesci ancora a connetterti a Ubuntu da un altro terminale (il servizio è degradato?)

Come sai che hai finito: hai visto le half-open connections accumularsi durante il flood e hai documentato il picco raggiunto.

Parte 3 — Analisi post-flood

#

Dopo aver fermato il flood, osserva su Ubuntu quanto tempo impiegano le half-open connections a sparire (timeout del kernel).

Obiettivo: rispondi a queste domande:

• Quanto tempo ci ha messo la connection table a tornare alla baseline?
• Nei log di sistema (dmesg o /var/log/syslog) c'è qualche traccia dell'evento?
• Con IP sorgenti randomici, il traffico arrivava da IP diversi ad ogni pacchetto — cosa significa per un firewall che filtra per IP sorgente?

Come sai che hai finito: hai risposto alle tre domande sopra con dati reali osservati sul sistema.

Parte 4 — Difesa con SYN Cookies

#

SYN cookies è un meccanismo del kernel Linux che permette al server di rispondere ai SYN senza allocare memoria per la half-open connection. Il server codifica le informazioni di sessione nel numero di sequenza del SYN-ACK — la memoria viene allocata solo quando arriva l'ACK finale (che con IP spoofati non arriverà mai).

Obiettivo: verifica lo stato attuale di SYN cookies su Ubuntu, abilitalo se non è attivo, poi ripeti il flood della Parte 2 e confronta:

• Il numero di SYN_RECV raggiunge lo stesso picco?
• Il servizio rimane raggiungibile durante il flood?

Il parametro kernel da cercare è net.ipv4.tcp_syncookies.

Come sai che hai finito: hai un confronto documentato tra flood senza SYN cookies e flood con SYN cookies attivi.

Parte 5 — Prova a buttarlo giù (modalità hard)

#

Finora Ubuntu aveva le protezioni di default attive. Ora le togli e vedi cosa succede davvero.

Setup: disabilita SYN cookies e abbassa il backlog massimo per le half-open connections. I due parametri kernel da modificare sono net.ipv4.tcp_syncookies e net.ipv4.tcp_max_syn_backlog.

Poi ripeti il flood dalla Parte 2.

Obiettivo: osserva se questa volta:

• Le SYN_RECV raggiungono il limite e il kernel inizia a droppare connessioni
• SSH da un nuovo terminale viene rifiutato o va in timeout
• Il servizio su porta 80 smette di rispondere

Documentare cosa succede — crash completo, degradazione totale, o solo rallentamento?

Come sai che hai finito: hai provato il flood con protezioni disabilitate e documentato il comportamento reale. Puoi non riuscire ad abbatterlo — un singolo Kali su rete virtuale ha throughput limitato. L'importante è osservare la differenza rispetto alla Parte 4.

Parte 6 — Osservare il traffico in Wireshark

#

Apri Wireshark sul Mac con capture sull'interfaccia host-only (di solito bridge100 o simile su macOS) prima di lanciare il flood.

Obiettivo — durante il flood normale (SYN cookies attivi):

• Filtra solo i SYN in entrata verso Ubuntu: tcp.flags.syn <mark> 1 and tcp.flags.ack </mark> 0 and ip.dst == 192.168.64.3
• Gli IP sorgenti sono tutti diversi? Scorri la colonna Source — vedi il pattern random?
• Filtra i SYN-ACK in uscita da Ubuntu: tcp.flags.syn <mark> 1 and tcp.flags.ack </mark> 1 and ip.src == 192.168.64.3
• Verso quali IP vanno quei SYN-ACK? Qualcuno risponde mai con un ACK?

Obiettivo — confronto con protezioni disabilitate (Parte 5):

• Il volume di SYN in entrata cambia o è uguale?
• I SYN-ACK in uscita spariscono a un certo punto (kernel che dropa le nuove connessioni)?
• Riesci a vedere il momento in cui Ubuntu smette di rispondere?

Filtro utile per vedere solo il flood senza altro rumore: tcp.flags.syn <mark> 1 and ip.dst </mark> 192.168.64.3 and not ip.src == 192.168.64.200

Il terzo filtro esclude i SYN legittimi da Kali — mostra solo i pacchetti con IP sorgente spoofato.

Come sai che hai finito: hai catturato almeno un pcap durante il flood e riesci a rispondere: gli ACK finali arrivano mai? Perché no?

Domande di chiusura

#

Prima di chiudere il lab, rispondi a queste:

1. Perché il flood usa IP sorgenti randomici invece dell'IP reale di Kali?
2. Cosa succederebbe se Ubuntu non avesse limiti sulla connection table?
3. SYN cookies risolve completamente il problema o mitiga solo parzialmente? Perché?
4. In un ambiente cloud (AWS/Azure), come si manifesterebbe un SYN flood? Quali metriche guarderesti?

Collegato a

#

• cap-07-advanced-attacks — teoria SYN flood
• mustache-project — lab environment