Hardening on My personal blog

Un homelab per la sicurezza

Tue, 06 Oct 2026 09:00:00 +0200

Perché conta

Questa serie ha usato un lab fin dal primo capitolo. L’ultimo passo è renderlo permanente: un ambiente che sta su un PC, si accende quando serve, si descrive in file versionabili e permette di rifare — e inventare — attacchi e difese senza rischi per nessuno. Un homelab non è un lusso: è il posto dove la teoria dei nove capitoli diventa pratica.

L’obiettivo è un lab che copra tutta la serie, su un solo PC, a costo zero di software.

Requisiti

Un PC Linux con 16 GB di RAM e qualche decina di GB di disco. Funziona anche con 8 GB per i lab più piccoli.
Virtualizzazione attiva nel BIOS (per la VM del firewall).
Nessun hardware di rete particolare: tutto è virtuale.

Il principio guida: container dove bastano, VM dove servono davvero. I container condividono il kernel dell’host, quindi decine di nodi di rete stanno in pochi GB; una VM intera (il firewall) ne occupa uno o due da sola.

Architettura

  flowchart TD
    subgraph HOST["PC host (Linux)"]
        subgraph CLAB["containerlab — topologie di rete"]
            ATT["attacker<br/>(scapy, nmap, ...)"]
            VIC["victim"]
            SRV["server / DMZ"]
            SW["sw0<br/>Open vSwitch"]
            ATT --- SW
            VIC --- SW
            SRV --- SW
        end
        GW["VM OPNsense<br/>firewall + DHCP + router"]
        IDS["Suricata<br/>+ EveBox"]
        LOG["Log centralizzati<br/>(syslog / EVE JSON)"]
        SW --- GW
        SW -. port mirror .-> IDS
        IDS --> LOG
        GW --> LOG
    end
    GW -. uplink NAT .-> Internet((Internet))

containerlab ospita i nodi di rete (attaccante, vittime, server) e lo switch Open vSwitch.
Una VM OPNsense fa da gateway: firewall stateful, DHCP, routing tra le VLAN. È l’unico pezzo che conviene tenere come VM intera, perché è un sistema operativo completo con la sua interfaccia.
Suricata riceve il traffico da una porta mirror dello switch (modalità IDS del capitolo 05).
I log di firewall e IDS confluiscono in un punto solo: così si risponde alla minaccia T6 del threat model e si impara a correlare gli eventi.

La topologia della serie in un file

Tutti i capitoli partono dalla stessa base, estesa di volta in volta. Il cuore è il file containerlab, qui con l’aggiunta delle VLAN per i capitoli 02-03:

name: homelab-secnet
topology:
  nodes:
    sw0:      { kind: ovs-bridge }                 # switch reale, gestisce le VLAN
    gateway:  { kind: linux, image: alpine:3.20 }  # oppure l'uplink verso la VM OPNsense
    victim:   { kind: linux, image: alpine:3.20 }
    server:   { kind: linux, image: nginx:alpine } # il "server in DMZ"
    attacker: { kind: linux, image: local/attacker } # immagine con i tool preinstallati
  links:
    - endpoints: ["gateway:eth1",  "sw0:p-gw"]
    - endpoints: ["victim:eth1",   "sw0:p-victim"]
    - endpoints: ["server:eth1",   "sw0:p-srv"]
    - endpoints: ["attacker:eth1", "sw0:p-att"]

Le righe evidenziate sono i punti da personalizzare: lo switch OVS (riga 4), che va pre-creato, e i collegamenti (righe 13-14), che mappano ogni nodo a una porta nominata dello switch — gli stessi nomi che si usano per assegnare VLAN e trunk.

# una tantum: crea lo switch
sudo ovs-vsctl add-br sw0 && sudo ip link set sw0 up

# avvio / spegnimento del lab
sudo containerlab deploy  -t homelab-secnet.clab.yml
sudo containerlab destroy -t homelab-secnet.clab.yml

L’immagine dell’attaccante

Per non reinstallare i tool ogni volta, conviene un’immagine container con tutto pronto. Il Dockerfile è parte del lab, quindi versionato e licenziato insieme al resto:

FROM debian:stable-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
    python3-scapy nmap tcpdump dsniff iproute2 iputils-ping \
    tshark hping3 && rm -rf /var/lib/apt/lists/*

I file di configurazione del lab (.clab.yml, Dockerfile, regole Suricata, ruleset nftables) hanno una licenza diversa dai testi del blog. Vanno pubblicati con una licenza per codice, ad esempio MIT, così chiunque può riusarli; i testi restano sotto la licenza del sito (CC BY-NC-SA).

Cosa fa ciascun capitolo in questo lab

Capitolo	Nel lab
02 ARP/DHCP/MAC	nodi Linux + sw0; scapy, dsniff, macof
03 VLAN	porte OVS access/trunk; double tagging con scapy
04 nftables	ruleset sul nodo gateway o sulla VM OPNsense
05 Suricata	container Suricata su porta mirror di sw0
06-07 TLS/DNS	CA di test, unbound con DNSSEC+DoT
08 DDoS	hping3 tra i nodi (dimostrativo)
09 VPN	WireGuard tra due nodi su rete “non fidata”
10 Wireshark	tshark cattura sulle porte di sw0

Un solo strumento base (containerlab) per quasi tutto; la VM OPNsense e, dove serve, GNS3 con immagini Cisco per DTP, sono le uniche aggiunte.

Lab: il primo avvio

Installate containerlab e Open vSwitch sull’host.
Costruite l’immagine attaccante (docker build -t local/attacker .).
Create sw0 e fate il deploy della topologia.
Verificate la connettività di base: da attacker, ping gli altri nodi.
Rifate l’esercizio del capitolo 02 per confermare che il lab è pronto.

Domanda: perché tenere OPNsense come VM invece di usare un container anche per il firewall?

Per due motivi. Primo, OPNsense è basato su FreeBSD: non gira come container Linux, serve una VM. Secondo, e più importante, il valore didattico sta proprio nell'usare un firewall "vero", con la sua interfaccia web, le sue regole stateful, il DHCP e l'IDS integrati — lo stesso tipo di apparato che si trova in produzione. Per i soli esercizi nftables del capitolo 04 basterebbe un nodo Linux container; ma avere un firewall completo nel lab permette di collegare i concetti della serie a uno strumento che si userà davvero. È un compromesso RAM contro realismo, e per un homelab permanente il realismo vince.

Conclusione

Un homelab trasforma una serie di articoli in una palestra permanente. Con containerlab, Open vSwitch, una VM OPNsense e Suricata — tutto open source, su un solo PC — si ricostruisce ogni scenario della serie e se ne inventano di nuovi, in un ambiente isolato dove sbagliare non ha conseguenze.

Qui finisce “Network Security dal cavo in su”. Dal cavo e dallo switch (capitoli 02-03), su per il firewall e l’IDS (04-05), fino a TLS, DNS e le VPN (06-09), e infine l’analisi (10) e il lab (11): undici capitoli, un solo filo conduttore. La difesa in profondità non è uno slogan, è questo — ogni strato che regge quando quello sotto cede.

Torna alla roadmap per la mappa completa della serie.

802.1X e NAC: autenticare chi si collega alla porta

Fri, 02 Oct 2026 09:00:00 +0200

Perché conta

Nel capitolo sugli attacchi L2 la port security limitava quanti MAC può usare una porta. Ma un MAC si falsifica in un secondo: non prova chi sei, solo che usi un certo indirizzo. In una rete seria — un ufficio, un campus — serve che un dispositivo si autentichi prima di ottenere accesso alla LAN. Questo è 802.1X, il cuore del Network Access Control (NAC): la porta dello switch resta chiusa finché non sai dimostrare di avere diritto a entrare.

I tre attori

802.1X definisce un dialogo a tre:

  flowchart LR
    S["Supplicant<br/>(il dispositivo)"] <-->|EAPOL| A["Authenticator<br/>(lo switch / AP)"]
    A <-->|RADIUS| R["Authentication Server<br/>(RADIUS)"]
    R -.decide.-> A
    A -.apre o chiude la porta.-> S

Supplicant: il client che vuole entrare (un PC, un telefono).
Authenticator: lo switch o l’access point. Non decide: fa da tramite. Tiene la porta in stato “non autorizzato” e inoltra solo il traffico di autenticazione (EAPOL) finché non riceve il via libera.
Authentication Server: tipicamente RADIUS. È lui che verifica le credenziali e dice allo switch sì o no.

La separazione è il punto di forza: lo switch non conserva credenziali, le centralizza nel server. Aggiungere o revocare un utente si fa in un posto solo.

EAP: il metodo dentro il protocollo

802.1X trasporta EAP, che non è un singolo metodo ma un contenitore. Il metodo scelto decide come ci si autentica:

Metodo EAP	Credenziale	Note
EAP-TLS	certificato client	il più sicuro; richiede una PKI
PEAP / EAP-TTLS	utente + password in un tunnel TLS	più semplice da distribuire
EAP-MD5	hash della password	obsoleto, nessuna protezione: da non usare

EAP-TLS lega l’accesso a un certificato per dispositivo: niente password da rubare, e si integra con una PKI interna. È la scelta migliore dove si può gestire l’emissione dei certificati.

Il flusso di autenticazione

  sequenceDiagram
    participant S as Supplicant
    participant A as Authenticator (switch)
    participant R as RADIUS
    Note over A: porta in stato "non autorizzato"
    S->>A: EAPOL-Start
    A->>S: EAP-Request Identity
    S->>A: EAP-Response Identity
    A->>R: RADIUS Access-Request
    R->>S: sfida EAP (via switch)
    S->>R: risposta EAP (certificato o credenziali)
    R->>A: RADIUS Access-Accept (+ VLAN assegnata)
    Note over A: porta autorizzata, traffico consentito

Un dettaglio potente: nell’Access-Accept il server può indicare quale VLAN assegnare alla porta. Così un dipendente finisce nella VLAN uffici, un dispositivo ospite in quella ospiti, un telefono VoIP nella sua — tutto deciso dall’identità, non dalla porta fisica. È la segmentazione dinamica, vicina al principio Zero Trust.

Configurazione: lo switch e RADIUS

Lato switch (sintassi tipo Cisco):

! abilita 802.1X globalmente e sulla porta
dot1x system-auth-control
interface Gi0/1
  authentication port-control auto      ! la porta richiede autenticazione
  dot1x pae authenticator
  spanning-tree portfast

La riga authentication port-control auto è il fulcro: mette la porta in modalità controllata, dove l’accesso dipende dall’esito di 802.1X.

Lato FreeRADIUS, un client (lo switch) in clients.conf e gli utenti/certificati nel backend. Il server valuta le richieste e risponde Accept/Reject, opzionalmente con gli attributi VLAN.

Il problema dei dispositivi senza supplicant

Non tutto parla 802.1X: stampanti, telecamere IP, vecchi apparati. Per loro esistono ripieghi:

MAB (MAC Authentication Bypass): la porta autentica in base al MAC (debole, ma almeno centralizzato e tracciato).
Guest VLAN: chi non si autentica finisce in una VLAN isolata con accesso minimo.

MAB eredita la debolezza del MAC spoofing: va usato solo dove 802.1X è impossibile, e limitando pesantemente ciò che quella VLAN può raggiungere.

Lab

Con FreeRADIUS e uno switch (o hostapd in modalità wired 802.1X, o Open vSwitch con un supplicant wpa_supplicant):

Configurate FreeRADIUS con un utente di test (PEAP) e lo switch come client RADIUS.
Sul client, configurate wpa_supplicant per 802.1X e collegatevi.
Osservate la porta passare da “non autorizzato” ad “autorizzato”.
Provate a collegare un dispositivo senza credenziali: deve restare bloccato o finire nella guest VLAN.

Domanda: 802.1X autentica la porta all'inizio; cosa impedisce a un attaccante di staccare il cavo del PC autenticato e collegare il proprio?

È un limite reale di 802.1X "classico". Se la porta autentica una volta e poi resta aperta, un attaccante che si inserisce fisicamente dopo l'autenticazione (o con un hub tra PC e presa) può sfruttare la sessione. Le contromisure sono: la ri-autenticazione periodica (il server forza nuove verifiche a intervalli), il legame con MACsec (802.1AE) che cifra e autentica ogni frame a livello 2, e il monitoraggio del link-down sulla porta (se il cavo si stacca, la porta torna non autorizzata). È anche il motivo per cui 802.1X è un controllo d'accesso, non una garanzia assoluta: va accompagnato dalla segmentazione e dal monitoraggio.

Conclusione

802.1X sposta il controllo d’accesso dalla porta fisica all’identità: nessuno entra in rete senza autenticarsi presso un server RADIUS centrale, e la VLAN può essere assegnata in base a chi sei. È il passo che la port security da sola non può fare. I punti aperti — dispositivi senza supplicant, sessioni dopo l’autenticazione — si coprono con MAB limitato, ri-autenticazione e, dove serve, MACsec.

Sicurezza Wi-Fi e WPA3: cosa cambia davvero

Thu, 01 Oct 2026 09:00:00 +0200

Perché conta

La rete Wi-Fi è l’unico mezzo trasmissivo che chiunque, dal parcheggio, può ascoltare senza collegare un cavo. Per vent’anni la protezione è stata WPA2, solido ma con due debolezze diventate celebri: l’attacco KRACK del 2017 e, soprattutto, la possibilità di catturare l’handshake e provare le password offline, senza limiti di velocità. WPA3, obbligatorio nei dispositivi certificati Wi-Fi 6, cambia proprio queste regole.

Il problema di WPA2: l’handshake catturabile

In WPA2-Personal la chiave di sessione deriva dalla password condivisa tramite un handshake a 4 vie. Un attaccante non ha bisogno della password per catturare l’handshake: gli basta ascoltare un client che si connette (o forzarne la riconnessione con un frame di deautenticazione). Poi, offline, prova miliardi di password al secondo contro quella cattura.

  flowchart LR
    A["Attaccante<br/>in ascolto"] -->|deauth| C[Client]
    C -->|si riconnette| AP[Access Point]
    A -.cattura il 4-way handshake.-> H[(Handshake)]
    H --> Crack["Cracking offline<br/>miliardi di tentativi/s"]
    style A fill:#fde2e4,stroke:#e63946

Il tempo per rompere una password dipende solo dalla sua entropia. Con un alfabeto di dimensione $N$ e lunghezza $L$, lo spazio da provare è:

$$ S = N^{L} $$

Una password di 8 caratteri minuscoli ($N=26$, $L=8$) ha circa $2 \times 10^{11}$ combinazioni: poche ore per hardware moderno. È per questo che in WPA2 la sicurezza dipende interamente dalla forza della password.

Cosa cambia con WPA3: SAE

WPA3-Personal sostituisce l’handshake con SAE (Simultaneous Authentication of Equals), basato sullo scambio Dragonfly. La differenza chiave: SAE è un PAKE (Password-Authenticated Key Exchange). La password non viene più usata in un modo che permetta di verificarla offline su una cattura passiva.

Conseguenze pratiche:

Niente cracking offline: catturare lo scambio SAE non dà all’attaccante nulla da attaccare offline. Ogni tentativo richiede una nuova interazione con l’access point, che può essere limitata (rate limiting) e rilevata.
Forward secrecy: ogni sessione usa una chiave fresca. Rubare la password domani non decifra il traffico catturato oggi.
Protezione anche con password deboli: non è un invito a usarle, ma una password mediocre non crolla più in poche ore come in WPA2.

Protected Management Frames

WPA3 rende obbligatori i Protected Management Frames (PMF, 802.11w). I frame di gestione — tra cui la deautenticazione — sono ora autenticati. L’attacco di deauth che forzava la riconnessione (il primo passo dello schema qui sopra) non funziona più: l’access point ignora i frame di deauth falsificati.

La configurazione (hostapd)

Su un access point Linux con hostapd:

# WPA3-Personal
wpa=2
wpa_key_mgmt=SAE                 # SAE invece di WPA-PSK
ieee80211w=2                     # PMF obbligatorio
sae_require_mfp=1                # SAE richiede i frame di gestione protetti
rsn_pairwise=CCMP

Le righe evidenziate attivano SAE (wpa_key_mgmt=SAE) e rendono obbligatorio PMF (ieee80211w=2), i due pilastri di WPA3.

Modalità di transizione

Molti dispositivi vecchi non parlano WPA3. La transition mode (wpa_key_mgmt=WPA-PSK SAE) permette a client WPA2 e WPA3 di coesistere. Ma attenzione: in questa modalità un attaccante può tentare un downgrade, forzando il client a usare WPA2 e riaprendo il cracking offline. La transizione è un compromesso per la compatibilità, non una configurazione pienamente sicura: dove possibile, SAE puro.

Lab

Con una scheda Wi-Fi che supporta AP mode e hostapd:

Configurate un AP in WPA2-PSK e uno in WPA3-SAE.
In WPA2, catturate un handshake (airodump-ng) e osservate che è acquisibile offline.
In WPA3-SAE, verificate che lo stesso approccio non produce materiale attaccabile offline.
Provate un frame di deauth con PMF attivo: l’AP deve ignorarlo.

Domanda: se WPA3 protegge anche le password deboli, serve ancora una password lunga?

Sì. SAE elimina il cracking offline, ma non l'attacco online: un attaccante può ancora provare password contro l'access point, un tentativo alla volta, interagendo con lui. È molto più lento e rilevabile (e limitabile con rate limiting), ma una password banale come "password1" cadrebbe comunque in un attacco a dizionario online. WPA3 alza enormemente il costo dell'attacco, non lo azzera: una password lunga e casuale resta la base. La differenza è che con WPA2 anche una password discreta cadeva offline, con WPA3 solo quelle davvero deboli cadono, e solo online.

Conclusione

WPA3 non è un ritocco di WPA2: cambia il modello di attacco. SAE toglie il cracking offline degli handshake, la forward secrecy protegge il traffico passato, PMF chiude gli attacchi di deauth. Il punto debole residuo è la modalità di transizione, dove il downgrade a WPA2 riapre i vecchi problemi. Dove i dispositivi lo permettono, SAE puro; e, come sempre, una password robusta.

SSH hardening: chiavi, cifrari e difesa dagli accessi

Wed, 30 Sep 2026 09:00:00 +0200

Perché conta

SSH è il modo in cui si amministra praticamente ogni server Linux. È anche il primo servizio che una botnet prova a forzare: su qualunque IP pubblico, i log mostrano migliaia di tentativi di login al giorno. Un SSH mal configurato — password deboli, root abilitato, cifrari vecchi — è una delle vie d’ingresso più comuni in assoluto. L’hardening di SSH è il singolo intervento con il miglior rapporto tra sforzo e sicurezza guadagnata.

Il modello: chiavi, non password

L’autenticazione a chiave pubblica sostituisce la password con una coppia crittografica. La chiave privata resta sul client e non lascia mai la macchina; il server conserva solo la pubblica.

  sequenceDiagram
    participant C as Client (chiave privata)
    participant S as Server (chiave pubblica in authorized_keys)
    C->>S: richiesta di login per l'utente X
    S->>C: sfida (un nonce casuale)
    Note over C: firma la sfida con la chiave privata
    C->>S: firma
    Note over S: verifica con la chiave pubblica
    S->>C: accesso consentito

Una password può essere indovinata o intercettata; una chiave Ed25519 no, in pratica. E poiché il server non riceve mai un segreto riutilizzabile, non c’è nulla da rubare dal lato server.

# generare una chiave moderna (Ed25519) sul client
ssh-keygen -t ed25519 -C "matteo@laptop"

# installarla sul server (aggiunge la pubblica ad authorized_keys)
ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@server

La configurazione del server

Il cuore dell’hardening è /etc/ssh/sshd_config. Le righe che contano:

# /etc/ssh/sshd_config
PasswordAuthentication no        # niente password: solo chiavi
PermitRootLogin no               # root non accede via SSH; si usa sudo
KbdInteractiveAuthentication no  # chiude anche la via interattiva/PAM alle password
PubkeyAuthentication yes
AllowUsers matteo                # solo questo utente può entrare
MaxAuthTries 3                   # pochi tentativi per connessione
LoginGraceTime 20                # finestra breve per autenticarsi

Le tre righe evidenziate sono le decisive: eliminano del tutto l’autenticazione a password, che è il bersaglio del brute force. Con PasswordAuthentication no, i milioni di tentativi delle botnet falliscono prima ancora di iniziare, perché il server non accetta quel metodo.

Dopo ogni modifica, validare e ricaricare:

1
2

sshd -t                  # verifica la sintassi: se sbagli, non ricaricare!
systemctl reload sshd

Attenzione irreversibile: prima di impostare PasswordAuthentication no, verificate di poter entrare con la chiave in una seconda sessione già aperta. Un errore qui può chiudervi fuori dal server.

Cifrari e algoritmi moderni

SSH negozia algoritmi di scambio chiavi, cifratura e MAC. Le versioni vecchie permettevano opzioni oggi deboli. Si restringono alle moderne:

1
2
3

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

I MAC in modalità Encrypt-then-MAC (-etm) sono preferibili. Queste liste tolgono dalla negoziazione CBC, i MAC SHA-1 e lo scambio Diffie-Hellman su gruppi deboli.

Ridurre la superficie

Oltre alla configurazione, due misure riducono l’esposizione:

Rate limiting / ban: fail2ban o una regola nftables che limita le nuove connessioni alla porta 22. Non sostituisce le chiavi, ma riduce il rumore nei log.
Niente SSH su internet quando evitabile: dietro una VPN (vedi IPsec vs WireGuard) o con accesso limitato a IP noti.

# limita i nuovi tentativi SSH a 10 al minuto per IP
table inet filter {
    chain input {
        tcp dport 22 ct state new meter ssh { ip saddr limit rate 10/minute } accept
        tcp dport 22 ct state new drop
    }
}

Spostare SSH su una porta diversa dalla 22 (“security through obscurity”) riduce solo il rumore dei log, non il rischio reale: non è hardening, è cosmesi.

Lab

Su una VM o un container:

Generate una chiave Ed25519 e installatela sul server.
Verificate l’accesso con la chiave, poi impostate PasswordAuthentication no e ricaricate.
Da un altro terminale, provate a forzare la password (ssh -o PubkeyAuthentication=no ...): deve essere rifiutato.
Aggiungete la regola nftables e osservate i tentativi scartati.

Domanda: se uso le chiavi, perché dovrei comunque disattivare la password invece di lasciarla come ripiego?

Perché finché la password è accettata, la superficie d'attacco del brute force resta aperta, a prescindere dal fatto che voi usiate le chiavi. Un attaccante non sa (e non gli importa) che voi preferite le chiavi: tenterà comunque le password, e se un qualsiasi account del sistema ne ha una debole, entra. Le chiavi come metodo aggiuntivo non proteggono: proteggono solo quando sono l'unico metodo. Il "ripiego" a password è esattamente il buco che l'hardening chiude.

Conclusione

L’hardening di SSH si riduce a pochi principi: solo chiavi, niente root diretto, cifrari moderni, superficie ridotta. La singola riga PasswordAuthentication no elimina da sola la categoria di attacco più comune contro i server esposti. È cinque minuti di lavoro che chiude una delle porte più battute di internet.

TLS 1.3 in profondità

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

Perché conta

Tutti gli attacchi dei capitoli precedenti — ARP spoofing, DHCP rogue, uomo nel mezzo — hanno lo stesso punto debole come bersaglio: il traffico in chiaro. TLS è la risposta. Risolve un problema che sembra impossibile: due macchine che non si sono mai parlate devono accordarsi su una chiave segreta, mentre un attaccante registra ogni byte che si scambiano. E devono anche essere sicure di parlare con chi credono, non con l’uomo nel mezzo.

TLS 1.3 (RFC 8446, 2018) ha ripulito vent’anni di debolezze. Vediamo come funziona.

Il problema dello scambio di chiavi

La cifratura simmetrica è veloce ma richiede una chiave condivisa. Come la si concorda su un canale che l’attaccante ascolta? La risposta è lo scambio Diffie-Hellman, in TLS 1.3 nella variante su curve ellittiche (ECDHE).

L’idea, semplificata: client e server scelgono ciascuno un segreto privato ($a$ e $b$) e si scambiano un valore pubblico derivato. Grazie alla proprietà matematica dello scambio, entrambi calcolano lo stesso segreto condiviso $S$ senza mai trasmetterlo:

$$ S = g^{ab} \bmod p $$

L’attaccante vede passare $g^a$ e $g^b$, ma per ricavare $S$ dovrebbe risolvere il problema del logaritmo discreto, computazionalmente proibitivo con i parametri usati. La chiave non viaggia mai sul filo: viene calcolata alle due estremità.

L’handshake TLS 1.3

La novità più visibile di TLS 1.3 è la velocità: l’handshake si completa in un solo giro (1-RTT), contro i due di TLS 1.2. Il client azzarda i parametri già nel primo messaggio.

  sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (versioni, cifrari, key_share g^a)
    Note over S: sceglie i parametri, calcola S = (g^a)^b
    S->>C: ServerHello (key_share g^b)
    S->>C: {Certificate, CertificateVerify, Finished} (già cifrati)
    Note over C: calcola S = (g^b)^a, verifica il certificato
    C->>S: {Finished} (cifrato)
    Note over C,S: canale cifrato stabilito in 1-RTT

Dal ServerHello in poi tutto è già cifrato, inclusi il certificato del server. In TLS 1.2 il certificato viaggiava in chiaro.

Autenticazione: la catena di certificati

Lo scambio ECDHE protegge dall’ascolto, ma non dall’uomo nel mezzo: un attaccante potrebbe fare un proprio scambio con il client fingendosi il server. Serve autenticazione, e la dà la PKI.

Il server presenta un certificato che lega il suo nome di dominio a una chiave pubblica, firmato da una Certificate Authority (CA). Il client verifica la firma risalendo la catena fino a una CA radice di cui si fida già (sono preinstallate nel sistema).

  flowchart TD
    Root["CA radice<br/>(preinstallata, fidata)"] -->|firma| Inter["CA intermedia"]
    Inter -->|firma| Leaf["Certificato del server<br/>esempio.it"]
    Leaf -.verificato dal.-> Client

In CertificateVerify il server firma l’handshake con la chiave privata corrispondente al certificato: prova di possedere la chiave, non solo di esibire il certificato. Un uomo nel mezzo non ha quella chiave privata, quindi non può produrre quella firma.

Due proprietà che contano

Forward secrecy. In TLS 1.3 ogni connessione usa una coppia ECDHE effimera, nuova ogni volta e cancellata dopo. Se un attaccante registra oggi il traffico cifrato e tra un anno ruba la chiave privata del server, non può decifrare quel traffico: la chiave di sessione non derivava da quella del server, ed è sparita. TLS 1.2 lo permetteva solo con i cifrari giusti; 1.3 lo rende obbligatorio.

Niente cifrari deboli. TLS 1.3 ha rimosso dalla negoziazione RC4, 3DES, MD5, lo scambio RSA statico e la rinegoziazione. Molti attacchi storici (BEAST, POODLE, downgrade) sfruttavano proprio quelle opzioni: toglierle dal protocollo le chiude per costruzione.

Vederlo nel lab

Con openssl si ispeziona un handshake reale:

# handshake completo verso un server, con dettagli
openssl s_client -connect esempio.it:443 -tls1_3

# guardare il certificato e la sua catena
openssl s_client -connect esempio.it:443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Nel lab containerlab si può generare una CA di test, emettere un certificato per un server interno e osservare la verifica della catena, senza toccare internet.

La configurazione lato server

# solo TLS 1.2 e 1.3; niente versioni vecchie
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;         # in 1.3 la lista cifrari è già sicura
ssl_session_tickets off;               # i ticket possono indebolire la forward secrecy

Le due righe evidenziate sono il minimo: disattivare le versioni obsolete e lasciare a TLS 1.3 la scelta dei cifrari, che sono già tutti robusti.

Lab

Nel lab, create una CA di test (openssl req -x509 ...) ed emettete un certificato per un server interno.
Avviate un server TLS 1.3 (openssl s_server) e collegatevi con openssl s_client.
Osservate con quale key_share e cifrario si conclude l’handshake.
Provate a forzare -tls1_1: il server deve rifiutare.

Domanda: se tutto è cifrato, l'IDS del capitolo 05 serve ancora a qualcosa?

Sì, ma vede meno. Con TLS, un IDS passivo non legge il contenuto HTTP: vede solo i metadati — indirizzi IP, dimensioni e tempi dei pacchetti, e il nome del server nell'estensione SNI (in chiaro anche in TLS 1.3, salvo ECH). Può ancora rilevare schemi (scan, beaconing di malware, destinazioni note come malevole), ma non il payload. Per ispezionare il contenuto cifrato servirebbe la decifratura TLS (un proxy che termina e ri-origina la connessione), che però rompe la forward secrecy end-to-end e introduce un punto in cui il traffico è di nuovo in chiaro. È un compromesso di sicurezza serio, non una funzione da attivare a cuor leggero.

Conclusione

TLS 1.3 risolve due problemi distinti con due meccanismi distinti: ECDHE per la segretezza (nessuno ascolta), la PKI per l’autenticazione (parli con chi credi). La forward secrecy obbligatoria e l’eliminazione dei cifrari deboli chiudono per costruzione gli attacchi che affliggevano le versioni precedenti.

TLS protegge il trasporto. Ma prima ancora di aprire una connessione, il client deve sapere quale IP ha esempio.it: lo chiede al DNS. E il DNS, per impostazione predefinita, è in chiaro e senza autenticazione — il prossimo bersaglio.

Prossimo nella serie: 07 · Sicurezza del DNS: DNSSEC e DoH · Torna alla roadmap

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

VLAN hopping e hardening degli switch

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

Perché conta

La segmentazione in VLAN è la risposta alla minaccia T1 del threat model: la rete ospiti e la LAN uffici sulla stessa infrastruttura fisica, ma su VLAN diverse, senza rotte tra loro. Funziona finché un attaccante non riesce a uscire dalla propria VLAN. Il VLAN hopping fa esattamente questo, e nei due casi classici non sfrutta un bug: sfrutta configurazioni lasciate ai valori di default.

Ripasso: tag, access e trunk

Un frame che viaggia in una VLAN porta un tag 802.1Q: 12 bit che dicono a quale VLAN appartiene. Le porte dello switch sono di due tipi:

access: appartiene a una sola VLAN; i frame entrano ed escono senza tag.
trunk: porta più VLAN tra switch; i frame viaggiano con il tag, tranne quelli della VLAN nativa, che per compatibilità storica vanno senza tag.

Quest’ultima eccezione — la VLAN nativa non taggata — è la porta d’ingresso di entrambi gli attacchi.

Attacco 1: switch spoofing (DTP)

Sugli switch Cisco il Dynamic Trunking Protocol (DTP) negozia automaticamente se una porta diventa trunk. Di default molte porte sono in dynamic auto o dynamic desirable: se l’altro lato chiede un trunk, lo switch glielo concede.

L’attaccante finge di essere uno switch e chiede un trunk. Se la porta accetta, da quel momento l’attaccante riceve il traffico di tutte le VLAN che passano sul trunk.

1
2

# yersinia fa la negoziazione DTP fingendosi uno switch
yersinia dtp -attack 1 -interface eth1

Nota sul lab: DTP è un protocollo proprietario Cisco. Open vSwitch non lo parla, quindi questo attacco si riproduce solo in GNS3 con un’immagine Cisco IOSvL2 (o IOU). Le immagini Cisco non sono redistribuibili: per il resto della serie restiamo su containerlab.

Attacco 2: double tagging

Questo funziona anche senza DTP, su qualunque switch 802.1Q, ed è il motivo per cui la VLAN nativa non va mai usata per host reali. L’attaccante, su una porta access della VLAN nativa (VLAN 1), costruisce un frame con due tag: uno esterno (VLAN 1, quella nativa) e uno interno (la VLAN bersaglio, es. VLAN 20).

  flowchart LR
    A["attacker<br/>VLAN nativa 1"] -->|frame con 2 tag:<br/>outer=1, inner=20| S1[Switch 1]
    S1 -->|toglie il tag nativo 1,<br/>resta inner=20| S2[Switch 2 / trunk]
    S2 -->|consegna in VLAN 20| V["victim<br/>VLAN 20"]
    style A fill:#fde2e4,stroke:#e63946

Il primo switch toglie il tag esterno — è la VLAN nativa, va rimossa — e inoltra il frame sul trunk. A quel punto resta solo il tag interno, VLAN 20: il secondo switch lo consegna nella VLAN bersaglio. Il frame ha saltato la VLAN. È monodirezionale (la risposta non torna indietro allo stesso modo), ma basta per iniettare pacchetti, ad esempio un DHCP rogue in un’altra VLAN.

Nel lab con Open vSwitch si riproduce configurando le porte e inviando un frame a doppio tag:

1
2
3

# porta attaccante: access sulla VLAN nativa 1; porta vittima: trunk con VLAN 20
ovs-vsctl set port p-attacker tag=1
ovs-vsctl set port p-victim   trunks=1,20

from scapy.all import Ether, Dot1Q, IP, ICMP, sendp
# doppio tag: outer VLAN 1 (nativa), inner VLAN 20 (bersaglio)
frame = (Ether()/Dot1Q(vlan=1)/Dot1Q(vlan=20)/IP(dst="10.0.20.10")/ICMP())
sendp(frame, iface="eth1")

La difesa: hardening dello switch

Quattro regole chiudono entrambi gli attacchi. Le prime due riguardano il double tagging, le ultime due lo switch spoofing.

! 1. spegni esplicitamente DTP su tutte le porte di accesso
switchport mode access
switchport nonegotiate
! 2. la VLAN nativa del trunk deve essere una VLAN "morta", non usata da nessun host
switchport trunk native vlan 999
! 3. consenti sul trunk solo le VLAN che servono davvero
switchport trunk allowed vlan 10,20,30
! 4. metti in shutdown le porte inutilizzate e assegnale a una VLAN inesistente

Le due righe evidenziate sono le decisive:

switchport nonegotiate spegne DTP: la porta non negozia più nulla, lo switch spoofing fallisce.
switchport trunk native vlan 999 sposta la VLAN nativa su una VLAN che non contiene host. Il double tagging ha bisogno che l’attaccante sia sulla VLAN nativa: se la nativa è una VLAN morta, nessun attaccante ci si trova, e l’attacco non parte.

La regola generale: la VLAN nativa non deve mai coincidere con una VLAN di dati, e DTP va sempre spento a mano.

Lab

Con Open vSwitch, configurate p-attacker come access VLAN 1 e p-victim come trunk con VLAN 20.
Da victim, catturate il traffico sulla VLAN 20 (tcpdump -i eth1.20).
Da attacker, inviate il frame a doppio tag con lo script scapy.
Verificate che l’ICMP arrivi sulla VLAN 20, pur partendo dalla VLAN 1.
Cambiate la VLAN nativa del trunk (ovs-vsctl set port p-victim ... tag) e ripetete.

Domanda: perché il double tagging è monodirezionale?

Il trucco funziona solo all'andata, perché sfrutta il fatto che il primo switch rimuove il tag della VLAN nativa. La vittima, rispondendo, invia un frame normale a singolo tag nella VLAN 20: quando arriva allo switch non c'è nessun tag nativo da togliere che la rimandi magicamente nella VLAN 1 dell'attaccante. Per questo il double tagging si usa per iniettare (un DHCP rogue, un pacchetto malevolo), non per instaurare una sessione bidirezionale.

Conclusione

Il VLAN hopping non buca la cifratura né sfrutta un difetto del protocollo: sfrutta due default. DTP che negozia da solo e la VLAN nativa condivisa con gli host. Spegnere DTP e isolare la VLAN nativa sono due righe di configurazione che molti dimenticano.

Finora abbiamo lavorato sotto il livello 3. Dal prossimo capitolo saliamo: un firewall stateful che decide quale traffico IP può attraversare i confini di fiducia disegnati nel threat model.

Prossimo nella serie: 04 · Firewall stateful con nftables · Torna alla roadmap