Firewall on My personal blog

Anatomia di un DDoS

Tue, 15 Sep 2026 09:00:00 +0200

Perché conta

La riservatezza e l’integrità si proteggono con la crittografia. La disponibilità no: non esiste una chiave che impedisca a un milione di richieste di saturare un server. Il DDoS (Distributed Denial of Service) attacca proprio questa terza gamba — la minaccia T4 del threat model — e lo fa con la forza bruta distribuita su migliaia di macchine.

È anche il capitolo dove la verità è scomoda: contro un attacco volumetrico grande, da soli non si può fare quasi nulla. Capire perché è il primo passo per difendersi bene.

Tre famiglie, tre bersagli

  flowchart TD
    DDoS[DDoS] --> V["Volumetrici<br/>saturano la banda"]
    DDoS --> P["Di protocollo<br/>saturano le tabelle di stato"]
    DDoS --> A["Applicativi (L7)<br/>saturano la CPU/il DB del server"]
    V --> V1["UDP/DNS/NTP flood<br/>amplificazione"]
    P --> P1["SYN flood<br/>connessioni mai completate"]
    A --> A1["HTTP flood<br/>richieste 'costose' ripetute"]
    style V fill:#fde2e4,stroke:#e63946
    style P fill:#fde2e4,stroke:#e63946
    style A fill:#fde2e4,stroke:#e63946

Volumetrici: riempiono la banda in ingresso. Si misurano in Gbit/s o Tbit/s. Se il tubo è pieno, nessuna regola locale aiuta: il traffico legittimo non arriva nemmeno.
Di protocollo: non serve banda, serve esaurire una risorsa. Il SYN flood riempie la tabella delle connessioni half-open.
Applicativi: poche richieste, ma costose (una ricerca complessa, un login). Difficili da distinguere dal traffico vero.

Il SYN flood e le SYN cookies

Quando un client apre una connessione TCP, manda un SYN; il server risponde SYN-ACK e riserva memoria per la connessione half-open, in attesa dell’ACK finale. Il SYN flood invia molti SYN, spesso con IP sorgente falsificato, e non completa mai l’handshake. La tabella si riempie, e i client veri non entrano più.

La difesa è elegante: le SYN cookies. Il server non riserva memoria al SYN. Codifica lo stato dentro il numero di sequenza del SYN-ACK (una funzione crittografica dei parametri della connessione). Se l’ACK finale torna, il server lo decodifica e ricostruisce lo stato; se non torna — come nel flood — non ha sprecato nulla.

1
2

# attivare le SYN cookies sul kernel Linux
sysctl -w net.ipv4.tcp_syncookies=1

L’amplificazione: perché un attaccante piccolo fa male

Gli attacchi volumetrici più grandi sfruttano l’amplificazione. L’attaccante invia una piccola query a un server pubblico (DNS, NTP, memcached), ma falsifica l’IP sorgente mettendoci quello della vittima. Il server risponde — alla vittima — con un pacchetto molto più grande.

Il fattore di amplificazione è il rapporto:

$$ F = \frac{\text{dimensione della risposta}}{\text{dimensione della richiesta}} $$

Per una query DNS ANY una risposta può essere decine di volte più grande della domanda; con memcached mal configurato si sono visti fattori oltre $10,000$. Con $F = 50$, un attaccante che dispone di 1 Gbit/s di upload genera 50 Gbit/s verso la vittima. La potenza dell’attaccante viene moltiplicata dai server riflettori.

L’amplificazione dipende da due difetti: server pubblici che rispondono a chiunque, e reti che lasciano uscire pacchetti con IP sorgente falsificato (assenza di BCP 38 / source address validation). Entrambi vanno risolti da altri, non dalla vittima — ed è il motivo per cui il DDoS è un problema collettivo.

Cosa si può mitigare da soli, e cosa no

Attacco	Mitigabile localmente?	Come
SYN flood	Sì, in gran parte	SYN cookies, rate limiting sulla `new`
HTTP flood (L7)	In parte	rate limiting per IP, CAPTCHA, cache
Volumetrico piccolo	In parte	rate limiting, filtri sul router
Volumetrico grande	No	serve un servizio di mitigazione a monte (scrubbing)

Per i volumetrici grandi la realtà è semplice: se la banda in ingresso è satura, il filtro va fatto prima che il traffico arrivi al vostro tubo, cioè da un provider di scrubbing o da una CDN che assorbe l’attacco sulla propria rete. È un servizio, non una configurazione.

Localmente, il rate limiting di nftables (dal capitolo 04) aiuta contro gli attacchi piccoli:

table inet filter {
    chain input {
        tcp dport 443 ct state new limit rate 50/second burst 100 packets accept
        tcp dport 443 ct state new drop     # oltre la soglia: scarta i nuovi SYN
    }
}

La riga evidenziata limita le nuove connessioni a 50/s: le connessioni già stabilite (established) non sono toccate, quindi gli utenti legittimi collegati continuano a lavorare.

Lab

Nel lab containerlab (traffico contenuto, è una dimostrazione del meccanismo, non un vero flood):

Sul nodo server, attivate tcp_syncookies e osservate netstat -s | grep -i syn.
Dal nodo attacker, generate molti SYN con hping3 -S --flood -p 443 <server>.
Confrontate l’uso della tabella di connessione con e senza SYN cookies.
Aggiungete il rate limiting nftables e misurate quante connessioni nuove passano.

Domanda: perché falsificare l'IP sorgente è utile all'attaccante in un flood volumetrico ma non in un HTTP flood?

In un flood volumetrico o SYN l'attaccante non ha bisogno di ricevere risposte: vuole solo inondare. Falsificare l'IP sorgente nasconde l'origine e, nell'amplificazione, dirige le risposte dei riflettori verso la vittima. In un HTTP flood invece serve completare l'handshake TCP e la sessione TLS per inviare richieste HTTP vere: questo richiede un IP sorgente reale che riceve le risposte, quindi lo spoofing non è possibile. È per questo che gli attacchi L7 usano botnet di macchine reali compromesse, non pacchetti falsificati.

Conclusione

Il DDoS attacca la disponibilità, che la crittografia non protegge. Alcune forme si mitigano da soli — SYN cookies, rate limiting — ma i grandi attacchi volumetrici si fermano solo a monte, ed esistono perché altre reti permettono lo spoofing e l’amplificazione. Difendersi bene significa sia proteggere i propri server, sia non essere parte del problema (niente resolver aperti, source address validation).

Abbiamo attraversato tutti gli strati. Nel prossimo capitolo torniamo a un tema concreto: come proteggere il traffico che attraversa reti non fidate, confrontando i due tunnel più usati.

Prossimo nella serie: 09 · IPsec contro WireGuard · Torna alla roadmap

Microsegmentazione: dividere la rete fino al singolo workload

Sat, 05 Sep 2026 09:00:00 +0200

Perché conta

La segmentazione tradizionale divide la rete in poche zone — uffici, server, ospiti — tipicamente con VLAN e firewall tra di esse. Il problema: dentro una zona, tutto parla con tutto. Un attaccante che compromette un singolo server nella zona “server” può muoversi liberamente verso gli altri. Questo movimento laterale è il modo in cui una singola macchina violata diventa una violazione dell’intera infrastruttura. La microsegmentazione risponde portando il confine fino al singolo workload: ogni carico di lavoro ha la sua politica, e ciò che non è esplicitamente permesso è negato.

Macro contro micro

  flowchart TD
    subgraph MACRO["Segmentazione classica (3 zone)"]
        direction LR
        A1[Web] <--> A2[App]
        A2 <--> A3[DB]
        A1 <-->|tutto libero<br/>dentro la zona| A3
    end
    subgraph MICRO["Microsegmentazione"]
        direction LR
        B1[Web] -->|solo :8080| B2[App]
        B2 -->|solo :5432| B3[DB]
        B1 -.DB negato.-> B3
    end

Nel modello classico, se il web server è compromesso raggiunge direttamente il DB. Nel modello microsegmentato il web può parlare solo all’app sulla porta applicativa, e solo l’app raggiunge il DB: la rotta web→DB semplicemente non esiste. L’attaccante sul web server trova ogni altra porta chiusa.

L’identità, non l’indirizzo IP

La svolta della microsegmentazione è che le regole non si basano più sull’IP — che cambia, si riusa, si falsifica — ma sull’identità del workload: un’etichetta, un ruolo, un certificato. Questo è anche il legame con il modello Zero Trust: la posizione in rete non conferisce fiducia, l’identità sì.

# Kubernetes NetworkPolicy: il DB accetta solo dall'app, solo sulla 5432
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-app-only
spec:
  podSelector:
    matchLabels: { role: database }
  ingress:
    - from:
        - podSelector: { matchLabels: { role: app } }
      ports:
        - { protocol: TCP, port: 5432 }

Le righe evidenziate sono la regola: solo i pod con etichetta role: app possono raggiungere il database, solo sulla 5432. Gli IP dei pod cambiano a ogni riavvio; l’etichetta no. La politica sopravvive alla volatilità dell’infrastruttura.

Default deny: il principio che regge tutto

La microsegmentazione funziona solo se la posizione di partenza è nega tutto. In Kubernetes, una volta che un pod è selezionato da una policy di ingress, tutto ciò che non è esplicitamente permesso è bloccato. Si parte chiudendo, poi si aprono le sole rotte necessarie — l’opposto del modello “apri tutto, poi blocca le minacce note” dei firewall perimetrali.

# default deny: nessun ingresso a meno che un'altra policy lo permetta
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress }
spec:
  podSelector: {}        # tutti i pod del namespace
  policyTypes: [Ingress]

Il vero costo: conoscere i flussi

Scrivere le politiche è la parte facile. La parte difficile è sapere quali flussi sono legittimi: quale servizio parla con quale, su quale porta, in condizioni normali. Senza questa mappa, il default deny spegne l’applicazione. Per questo la microsegmentazione inizia quasi sempre con una fase di osservazione (vedi network observability): si raccolgono i flussi reali, si costruisce la mappa, poi si traduce in politiche. Strumenti basati su eBPF come Cilium fanno proprio questo — osservano e poi applicano.

Lab

In un cluster di test (kind, minikube) con un CNI che supporti le NetworkPolicy (Calico, Cilium — vedi CNI plugins):

Distribuite tre pod: web, app, db con le relative etichette.
Verificate che, senza policy, web raggiunge direttamente db (il problema).
Applicate il default-deny-ingress: tutto si blocca.
Aggiungete le policy che aprono web→app e app→db: l’applicazione torna a funzionare, ma web→db resta negato.
Dimostrate il contenimento: da una shell nel pod web, provate a connettervi al db e osservate il rifiuto.

Domanda: se ho già firewall e VLAN tra le zone, la microsegmentazione non è solo complessità in più?

Dipende da cosa volete fermare. Firewall e VLAN fermano l'attaccante tra le zone, ma non fanno nulla contro il movimento dentro una zona — ed è lì che avviene la maggior parte dei danni dopo una compromissione iniziale. Un ransomware che entra da una workstation di una VLAN uffici, in un modello classico, raggiunge ogni altra macchina di quella VLAN senza incontrare un solo controllo. La microsegmentazione è l'unico modello che contiene questo: anche la macchina accanto è "fuori" per default. Il costo è reale — serve conoscere i flussi e gestirne le politiche — e per questo non si applica ovunque allo stesso livello: si concentra dove i dati valgono di più. Non sostituisce il perimetro, lo completa partendo dall'assunto che il perimetro verrà bucato.

Conclusione

La microsegmentazione sposta il confine di sicurezza dalle poche zone di rete al singolo workload, e lo fa legando le politiche all’identità invece che all’indirizzo. Il suo scopo preciso è contenere il movimento laterale: trasformare una singola macchina compromessa in un vicolo cieco invece che in un trampolino. Regge su un principio — default deny — e su un prerequisito — conoscere i flussi reali. È la traduzione concreta, a livello di rete, del principio Zero Trust.

Firewall stateful con nftables

Tue, 18 Aug 2026 09:00:00 +0200

Perché conta

Il threat model ha prodotto regole come “dalla DMZ nessuna connessione verso la LAN” (T5) e “la rete ospiti non raggiunge la LAN” (T1). Un firewall è lo strumento che le mette in pratica. Ma un firewall scritto male è peggio di nessun firewall: dà un falso senso di sicurezza. La differenza tra un firewall fragile e uno solido sta in una parola: stato.

Su Linux lo strumento moderno è nftables, che dal 2014 sostituisce iptables. Qui vediamo perché lo stato cambia tutto e come scrivere un ruleset leggibile.

Stateless contro stateful

Un firewall stateless giudica ogni pacchetto da solo, senza memoria. Per permettere al PC della LAN di navigare, deve consentire sia i pacchetti in uscita verso la porta 443, sia quelli in ingresso dalla porta 443. Ma “permettere l’ingresso dalla 443” apre la porta a chiunque abbia quella porta di origine: un attaccante la usa per entrare.

Un firewall stateful ricorda le connessioni aperte. Permette l’uscita, e lascia entrare solo le risposte che appartengono a una connessione che l’host ha iniziato. Non serve nessuna regola di ritorno. Su Linux questa memoria è conntrack, e ogni connessione attraversa stati precisi:

  stateDiagram-v2
    [*] --> NEW: primo pacchetto (SYN)
    NEW --> ESTABLISHED: risposta vista (SYN-ACK)
    ESTABLISHED --> ESTABLISHED: traffico nei due sensi
    ESTABLISHED --> [*]: chiusura / timeout
    NEW --> INVALID: pacchetto che non ha senso
    note right of ESTABLISHED
        RELATED: connessione nuova ma legata
        a una esistente (es. dati FTP, errori ICMP)
    end note

La regola d’oro di ogni firewall stateful sta in una riga: accetta ciò che è established o related, scarta ciò che è invalid, e giudica con attenzione solo i pacchetti new.

Un ruleset nftables commentato

Questo è il firewall di un host o di un gateway. nftables usa un unico file, con una sintassi più leggibile di iptables.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;   # default: scarta tutto

        ct state established,related accept                 # le risposte alle connessioni aperte
        ct state invalid drop                               # pacchetti incoerenti: via subito
        iif lo accept                                       # il traffico di loopback è sempre ok

        ip protocol icmp icmp type echo-request limit rate 5/second accept
        tcp dport 22 ct state new accept                    # SSH: solo pacchetti nuovi
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        # DMZ (10.0.1.0/24) non deve raggiungere la LAN (10.0.10.0/24) -> minaccia T5
        ip saddr 10.0.1.0/24 ip daddr 10.0.10.0/24 drop
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Le righe che contano:

policy drop (riga 8 e la gemella nella catena forward): il default è negare. Tutto ciò che non è esplicitamente permesso viene scartato. È l’opposto di “apri e poi chiudi i buchi”.
ct state established,related accept (riga 9): è la riga che rende il firewall stateful. Le risposte passano senza regole di ritorno.
ct state invalid drop (riga 10): scarta pacchetti che non appartengono a nessuna connessione valida, come certi scan.
tcp dport 22 ct state new accept (riga 15): SSH è permesso solo come nuova connessione. Nota che non serve nessuna regola per far tornare le risposte: le gestisce già la riga 9.

Si carica e si ispeziona così:

1
2
3

nft -f firewall.nft        # carica il ruleset
nft list ruleset           # lo mostra
conntrack -L               # elenca le connessioni tracciate in tempo reale

L’attacco che lo stato ferma

Un classico scan nmap -sA (ACK scan) invia pacchetti ACK senza una connessione sottostante, per capire quali porte sono filtrate. Su un firewall stateless mal scritto, che accetta gli ACK “perché sembrano risposte”, lo scan mappa la rete. Su quello sopra, quei pacchetti cadono in ct state invalid o non trovano una connessione established, e vengono scartati. Lo scan non ottiene informazioni.

1
2

# dal nodo attacker, contro il gateway: lo scan non deve rivelare nulla
nmap -sA 10.0.0.1

nftables contro iptables

	iptables	nftables
Tabelle	separate per IPv4/IPv6 (`iptables`/`ip6tables`)	una sola (`inet`) per entrambi
Sintassi	una regola per riga, verbosa	insiemi, mappe, sintassi compatta
Più condizioni	più regole	un’unica regola con `set` e `map`
Stato del progetto	in manutenzione	successore ufficiale

Non c’è motivo di scrivere nuovi firewall in iptables nel 2026. Chi ha ruleset iptables esistenti può convertirli con iptables-translate.

Lab

Nel lab containerlab, sul nodo gateway:

Caricate il ruleset con nft -f firewall.nft e verificate nft list ruleset.
Da victim, aprite una connessione in uscita (curl verso un servizio sul gateway) e guardate conntrack -L sul gateway: la connessione appare come ESTABLISHED.
Da attacker, provate nmap -sA 10.0.0.1 e poi nmap -sS 10.0.0.1.
Osservate quali pacchetti incrementano il contatore invalid (nft list ruleset mostra i contatori se aggiungete counter alle regole).

Domanda: perché la catena output ha policy accept e non drop?

È una scelta, non un obbligo. Per un host singolo, filtrare anche l'output è più sicuro (limita cosa un processo compromesso può contattare), ma rende il ruleset molto più lungo e rischia di rompere servizi legittimi. Per un firewall didattico si parte con output in accept e si filtra solo input e forward. In un ambiente ad alta sicurezza si mette anche output in policy drop e si elencano le destinazioni permesse: è lo stesso principio Zero Trust del post dedicato, applicato al traffico in uscita.

Conclusione

Un firewall solido si regge su tre scelte: default drop, stato con conntrack, e regole che dicono solo cosa è nuovo e permesso. Lo stato elimina intere categorie di errori — le regole di ritorno — e con esse intere categorie di attacchi.

Il firewall blocca ciò che riconosce come vietato. Ma cosa succede quando il traffico è permesso e contiene comunque un attacco? Serve qualcosa che guardi dentro i pacchetti. È il compito di un IDS/IPS.

Prossimo nella serie: 05 · IDS/IPS con Suricata · Torna alla roadmap