Threat Modeling on My personal blog

Network Security dal cavo in su: la roadmap

Tue, 21 Jul 2026 09:00:00 +0200

Perché una serie, e perché “dal cavo in su”

Sulla sicurezza delle reti si trovano due tipi di materiale: guide molto teoriche, che elencano acronimi senza mai mostrare un pacchetto, e tutorial che spiegano come lanciare uno strumento senza dire perché funziona. Questa serie prova a stare in mezzo.

L’idea è semplice: partire dal livello più basso, il cavo e lo switch, e salire uno strato alla volta fino a TLS e DNS. Per ogni livello vediamo come funziona il protocollo, come viene attaccato e come lo si difende, con comandi reali e un piccolo laboratorio da rifare a casa.

Security is a process, not a product.
― Bruce Schneier, Crypto-Gram, maggio 2000

Questo post è la mappa: resta fissato in cima al blog e verrà aggiornato man mano che escono i capitoli.

Il modello a strati

Ogni livello della rete si fida di quello sotto. Se un attaccante controlla lo strato 2, può leggere e modificare tutto quello che ci passa sopra, a meno che uno strato superiore (ad esempio TLS) non aggiunga protezioni proprie. Per questo la difesa si costruisce in profondità: ogni strato deve reggere anche quando quello sotto è compromesso.

  flowchart BT
    L1["L1 · Fisico<br/>accesso alle porte, tap"]
    L2["L2 · Data link<br/>ARP, VLAN, STP, DHCP"]
    L3["L3 · Rete<br/>IP spoofing, routing, BGP"]
    L4["L4 · Trasporto<br/>firewall stateful, SYN flood"]
    L7["L5-7 · Applicazione<br/>TLS, DNS, HTTP"]
    L1 --> L2 --> L3 --> L4 --> L7
    IDS(["IDS / IPS<br/>osserva tutti gli strati"]) -.-> L2 & L3 & L4 & L7
    ZT(["Zero Trust<br/>nessuno strato è fidato a priori"]) -.-> L7
    classDef attack fill:#fde2e4,stroke:#e63946,color:#111;
    class L1,L2,L3,L4,L7 attack;

La freccia va dal basso verso l’alto: è la direzione in cui si propaga la fiducia, e quindi anche il danno.

La mappa della serie

  mindmap
  root((Network<br/>Security))
    Metodo
      Threat modeling
      Homelab
    Strato 2
      ARP spoofing
      VLAN hopping
    Strato 3-4
      Firewall nftables
      DDoS
    Strato 7
      TLS 1.3
      DNSSEC e DoH
    Rilevamento
      Suricata
      Wireshark
    Tunnel
      IPsec vs WireGuard

#	Capitolo	Di cosa parla	Stato
00	Questa roadmap	Mappa e metodo	✅
01	Threat modeling per le reti	STRIDE applicato a una rete reale	✅
02	Attacchi a livello 2	ARP spoofing, MAC flooding, DHCP starvation	✅
03	VLAN hopping e hardening degli switch	Double tagging, DTP, port security	✅
04	Firewall stateful con nftables	Da iptables a nftables, conntrack	✅
05	IDS/IPS con Suricata	Installazione e scrittura di regole	✅
06	TLS 1.3 in profondità	Handshake, PKI, certificate pinning	✅
07	Sicurezza del DNS	Cache poisoning, DNSSEC, DoH/DoT	✅
08	Anatomia di un DDoS	Attacchi volumetrici, amplificazione, mitigazione	✅
09	IPsec vs WireGuard	Confronto pratico	✅
10	Analisi dei pacchetti	Trovare un attacco in un pcap	✅
11	Un homelab per la sicurezza	OPNsense, VLAN, Suricata	✅

Cosa c’è già sul blog

Alcuni argomenti li ho già trattati in post separati, che la serie riprende e collega:

Sicurezza di BGP con RPKI: come si valida l’origine di una rotta.
Zero Trust Architecture: il modello “mai fidarsi, verificare sempre”.
Network Security Mesh: la sicurezza oltre il perimetro.
SASE: rete e sicurezza come servizio cloud.
WireGuard: la base per il capitolo 09.

Come leggere i capitoli

Ogni capitolo segue lo stesso schema, così è facile orientarsi:

Perché conta: il problema in due paragrafi.
Come funziona: il protocollo, con un diagramma.
L’attacco: cosa fa l’attaccante, con comandi veri.
La difesa: la configurazione che lo blocca, con le righe importanti evidenziate.
Lab: un esercizio da fare nel proprio laboratorio, con la soluzione nascosta.

Gli attacchi vanno provati solo in un laboratorio vostro o su reti per cui avete un’autorizzazione scritta. Il capitolo 11 spiega come costruirne uno con poca spesa.

Cosa serve per i lab

Basta un PC Linux con 16 GB di RAM. Per quasi tutti i capitoli usiamo containerlab: descrive una topologia in un solo file YAML, avvia i nodi come container (quindi consuma poca RAM) e usa un vero switch Open vSwitch quando serve lavorare sulle VLAN. Solo il capitolo 11 passa a macchine virtuali intere.

La topologia minima dei primi capitoli — attaccante, vittima, gateway e uno switch — sta in un file lab-l2.clab.yml:

name: lab-l2
topology:
  nodes:
    sw0:       { kind: ovs-bridge }          # switch reale (Open vSwitch, pre-creato)
    gateway:   { kind: linux, image: alpine:3.20 }
    victim:    { kind: linux, image: alpine:3.20 }
    attacker:  { kind: linux, image: alpine:3.20 }
  links:
    - endpoints: ["gateway:eth1",  "sw0:p-gw"]
    - endpoints: ["victim:eth1",   "sw0:p-victim"]
    - endpoints: ["attacker:eth1", "sw0:p-attacker"]

1
2
3

sudo ovs-vsctl add-br sw0 && sudo ip link set sw0 up   # crea lo switch una volta
sudo containerlab deploy -t lab-l2.clab.yml            # avvia il lab
sudo containerlab destroy -t lab-l2.clab.yml           # lo smonta

Esercizio zero: perché lo switch è un nodo Open vSwitch e non un normale bridge Linux?

Un bridge Linux fa passare i frame tra i nodi, ma gestisce le VLAN 802.1Q in modo limitato: il double tagging del capitolo 03 ha bisogno di un dataplane che tratti i tag come uno switch vero. Open vSwitch lo fa, e permette di configurare porte access e trunk con ovs-vsctl, proprio come su uno switch gestito. Per ARP spoofing, DHCP e MAC flooding (capitolo 02) basterebbe anche il bridge, ma usare OVS da subito evita di cambiare lab a metà serie.

Conclusione

La sicurezza di una rete è forte quanto il suo strato più debole. Questa serie li attraversa tutti in ordine, dal livello più basso al più alto, mostrando per ciascuno un attacco concreto e la sua difesa.

Prossimo nella serie: 01 · Threat modeling per le reti. Prima di difendere qualcosa bisogna sapere cosa si sta difendendo e da chi.

Threat modeling per le reti: STRIDE su una rete vera

Tue, 28 Jul 2026 09:00:00 +0200

Perché conta

Quasi ogni rete che ho visto è stata messa in sicurezza al contrario: prima si compra il firewall, poi si decide cosa deve bloccare. Il risultato sono regole scritte “a sensazione”, porte aperte che nessuno ricorda perché, e zone della rete che si fidano l’una dell’altra senza motivo.

Il threat modeling ribalta l’ordine. Prima si disegna la rete, poi si chiede cosa può andare storto, e solo alla fine si sceglie la difesa. È il capitolo 01 della serie perché tutti i capitoli successivi rispondono a minacce che troveremo qui.

What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?
― Threat Modeling Manifesto

Quattro domande. Il resto del post le applica una per una.

Domanda 1: su cosa stiamo lavorando?

L’esempio è un piccolo ufficio, il tipo di rete che si trova in uno studio professionale o in una startup:

15 postazioni e una stampante di rete;
un NAS con i documenti condivisi;
una rete Wi-Fi per gli ospiti;
un server web pubblico in DMZ;
accesso remoto in VPN per chi lavora da casa.

Il diagramma

Il diagramma serve a una cosa sola: rendere visibili i confini di fiducia (trust boundary), cioè i punti in cui i dati passano da una zona con un livello di fiducia a un’altra. Le minacce si concentrano quasi sempre lì.

  flowchart LR
    Internet((Internet))
    subgraph DMZ["DMZ · fiducia bassa"]
        Web[Server web]
    end
    subgraph LAN["LAN uffici · fiducia media"]
        PC[Postazioni]
        PR[Stampante]
        NAS[(NAS)]
    end
    subgraph GUEST["Wi-Fi ospiti · nessuna fiducia"]
        G[Dispositivi ospiti]
    end
    Remote[Utenti VPN]
    FW{{Firewall}}
    Internet <--> FW
    Remote -. tunnel VPN .-> FW
    FW <--> Web
    FW <--> PC
    PC <--> NAS
    PC --> PR
    FW <--> G
    classDef tb stroke:#e63946,stroke-width:2px,stroke-dasharray:6 4;
    class DMZ,LAN,GUEST tb;

Ogni riquadro tratteggiato è una zona; ogni freccia che attraversa il firewall attraversa un confine di fiducia. In questa rete ce ne sono quattro: Internet–firewall, firewall–DMZ, firewall–LAN e firewall–ospiti. Il tunnel VPN ne aggiunge un quinto.

L’inventario

Il diagramma deve corrispondere alla rete reale, non a quella che si crede di avere. Una scansione della LAN dice cosa c’è davvero:

# Host attivi nella LAN, senza scansione delle porte
sudo nmap -sn 192.168.10.0/24 -oG - | awk '/Up$/{print $2, $3}'

# Servizi esposti sul NAS: spesso ce ne sono più di quanti ne servano
sudo nmap -sV --top-ports 200 192.168.10.20

Quasi sempre salta fuori qualcosa che non era nel diagramma: una telecamera IP, un vecchio access point, un’interfaccia di gestione della stampante raggiungibile in HTTP.

Domanda 2: cosa può andare storto?

Qui entra STRIDE. È un acronimo che elenca sei categorie di minaccia, ognuna opposta a una proprietà di sicurezza. Serve a non dimenticare nulla: per ogni elemento del diagramma si passano in rassegna tutte e sei.

Lettera	Minaccia	Proprietà violata	Esempio in rete
S	Spoofing	Autenticazione	ARP spoofing, DHCP rogue, IP spoofing
T	Tampering	Integrità	Modifica del traffico in transito, DNS poisoning
R	Repudiation	Non ripudio	Nessun log delle connessioni VPN
I	Information disclosure	Riservatezza	Protocolli in chiaro, SNMP con community `public`
D	Denial of service	Disponibilità	SYN flood, DHCP starvation, broadcast storm
E	Elevation of privilege	Autorizzazione	Ospite che raggiunge la LAN, VLAN hopping

STRIDE applicato ai confini

Applicato ai confini del nostro ufficio, STRIDE produce un elenco come questo (ridotto alle voci più interessanti):

ID	Confine	STRIDE	Minaccia
T1	Ospiti → LAN	E	Un ospite raggiunge il NAS perché la Wi-Fi ospiti e la LAN sono sulla stessa VLAN
T2	Dentro la LAN	S, T	Un PC compromesso fa ARP spoofing e si mette in mezzo tra le postazioni e il gateway
T3	Dentro la LAN	I	Il NAS espone SMBv1 e un’interfaccia web in HTTP
T4	Internet → DMZ	D	SYN flood contro il server web
T5	DMZ → LAN	E	Il server web compromesso apre connessioni verso il NAS
T6	VPN → LAN	R	Gli accessi VPN non vengono registrati: dopo un incidente non si sa chi era collegato
T7	Internet → utenti	T	Risposte DNS falsificate verso le postazioni

Ogni riga dice dove (il confine), cosa (la categoria STRIDE) e come (lo scenario concreto). Una minaccia scritta in modo vago, come “il NAS potrebbe essere attaccato”, non aiuta a scegliere una difesa.

Domanda 3: cosa facciamo?

Non si può risolvere tutto subito. Per decidere l’ordine serve una stima del rischio. La formula più semplice è anche la più usata:

$$ R = P \times I $$

dove $P$ è la probabilità che la minaccia si realizzi e $I$ è l’impatto se succede, entrambi su una scala da 1 a 5. Il risultato va da 1 a 25. Non è una misura precisa: serve solo a confrontare le minacce tra loro con lo stesso metro.

ID	$P$	$I$	$R$	Difesa	Capitolo
T1	4	5	20	VLAN separata per gli ospiti, nessuna rotta verso la LAN	03
T5	3	5	15	Firewall: dalla DMZ nessuna connessione verso la LAN	04
T2	3	4	12	Dynamic ARP Inspection, DHCP snooping	02
T3	3	4	12	Disattivare SMBv1, HTTPS sull’interfaccia del NAS	—
T7	2	4	8	Resolver con DNSSEC, DoT verso l’esterno	07
T4	2	3	6	Rate limiting, SYN cookies, protezione a monte	08
T6	2	3	6	Log centralizzati delle sessioni VPN	09

Ordinando per $R$, la priorità diventa evidente: la prima cosa da fare non è comprare un IDS, ma separare la rete ospiti. Costa poco e chiude la minaccia con il rischio più alto.

Il registro delle minacce

Conviene tenere le minacce in un file versionato accanto alla configurazione della rete. Un formato semplice basta:

- id: T1
  boundary: guest -> lan
  stride: [E]
  threat: Un ospite raggiunge il NAS sulla stessa VLAN
  likelihood: 4
  impact: 5
  risk: 20
  mitigation: VLAN 30 per gli ospiti, ACL deny verso 192.168.10.0/24
  status: open
  owner: rete

Le righe evidenziate sono quelle che decidono la priorità. Il campo status permette di vedere a colpo d’occhio cosa resta aperto.

Domanda 4: abbiamo fatto un buon lavoro?

Un threat model non è mai finito. Va ripreso ogni volta che la rete cambia: un nuovo servizio in DMZ, un nuovo tipo di dispositivo, un fornitore che chiede l’accesso remoto. Tre controlli pratici:

Il diagramma corrisponde alla rete? Ripetere la scansione dell’inventario e confrontare.
Ogni minaccia ha una difesa e un responsabile? Le righe senza owner non vengono chiuse.
Le difese funzionano? Provarle davvero. Ad esempio, da un dispositivo nella Wi-Fi ospiti:

1
2

# Deve fallire: gli ospiti non devono raggiungere il NAS
nc -zv -w 3 192.168.10.20 445 && echo "T1 ANCORA APERTA" || echo "T1 chiusa"

Lab

Prendete la rete di casa vostra (o del laboratorio descritto nella roadmap) e rispondete alle quattro domande:

Disegnate il diagramma con le zone e i confini di fiducia.
Applicate STRIDE ad almeno tre confini.
Calcolate $R$ per ogni minaccia e ordinatele.
Scegliete la prima difesa da applicare e verificate che funzioni.

Suggerimento: la minaccia che quasi tutti trovano a casa

I dispositivi IoT (TV, prese smart, telecamere) stanno quasi sempre sulla stessa rete dei PC e del NAS. Sono dispositivi che non ricevono aggiornamenti e che parlano con server esterni: in STRIDE è una minaccia di tipo E (un dispositivo compromesso raggiunge tutto il resto), con probabilità alta. La difesa è la stessa della rete ospiti: una rete separata, con accesso solo verso Internet. Molti router domestici la offrono già come "rete ospiti" o "rete IoT".

Conclusione

Il threat modeling non richiede strumenti costosi: un diagramma, una tabella e quattro domande. Il valore sta nell’ordine che impone: prima capire la rete, poi scegliere le difese in base al rischio, non all’abitudine.

Le minacce trovate qui sono la scaletta dei prossimi capitoli. Si parte dalla T2, perché è la più sottovalutata: un attaccante già dentro la LAN che si mette in mezzo al traffico.

Prossimo nella serie: 02 · Attacchi a livello 2: ARP spoofing, MAC flooding e DHCP starvation · Torna alla roadmap