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

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:

1. Perché conta: il problema in due paragrafi.
2. Come funziona: il protocollo, con un diagramma.
3. L’attacco: cosa fa l’attaccante, con comandi veri.
4. La difesa: la configurazione che lo blocca, con le righe importanti evidenziate.
5. 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

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.