Cap 4 - Securing Your Network

mindmap
  root((Cap 4
Securing
Your Network))
    IDS e IPS
    Metodi di Detection
    Alert FP FN TP TN
    Honeypot e Deception
    Securing Wireless
    Attacchi Wireless
    VPN e Concentrator
    NAC
    IPsec e Tunneling
    Autenticazione Remota

Cosa fa

#

Copre i meccanismi attivi di difesa della rete: IDS/IPS, VPN (IPsec e SSL/TLS), tunneling, wireless security (WPA2/WPA3) e segmentazione avanzata. Segue l'ordine del libro Gibson Cap 4.

TL;DR

#

IDS rileva e avvisa, non blocca. IPS rileva e blocca attivamente — stesso metodo, risposta diversa. Entrambi catturano traffico e lo analizzano come un protocol analyzer (sniffer). IDS/IPS sono security control di tipo detective. HIDS = IDS sul singolo host (vede NIC + file + applicazioni). NIDS = IDS sulla rete.

IDS e IPS

#

mindmap
  root((IDS e IPS))
    IDS
      Detective control
      Out-of-band passivo
      Copia traffico via port mirror
      Invia alert
    IPS
      Preventive control
      In-line nel flusso
      Blocca pacchetti malevoli
      Fail-open vs Fail-closed
    Posizionamento
      HIDS su host
        NIC + file + processi
        Wazuh come esempio
      NIDS su rete
        Sensori su switch e router
        Port mirroring
        Promiscuous mode
      HIPS blocca su host
      NIPS blocca su rete
    NIPS pratico
      NIPS 1 perimetro Internet
      NIPS 2 perimetro SCADA

Differenza fondamentale

#

Come funzionano

#

Sia IDS che IPS catturano il traffico di rete e lo analizzano per rilevare attacchi o anomalie — stessa capacità dei protocol analyzer (sniffer). La differenza emerge quando viene individuato un evento sospetto:

• IDS → invia un alert all'amministratore
• IPS → interviene attivamente per bloccare l'attacco prima che raggiunga i sistemi

sequenceDiagram
    participant ATK as Attaccante
    participant IDS as IDS/IPS
    participant NET as Rete/Sistemi

    ATK->>IDS: Traffico malevolo
    IDS->>IDS: Cattura e analizza pacchetti
    alt IDS
        IDS->>NET: Traffico passa
        IDS-->>NET: Alert all'admin
    else IPS
        IDS->>ATK: Blocca traffico
        IDS-->>NET: Alert + protezione attiva
    end

HIDS — Host-based IDS

#

Perché installare un HIDS oltre all'antivirus?

Un HIDS può rilevare malware che l'antivirus tradizionale non individua, perché analizza comportamenti (modifiche a file critici, pattern applicativi anomali) e non solo signature. Per questo molte organizzazioni installano un HIDS su ogni workstation come layer aggiuntivo.

Casi d'uso tipici:

• Server esposti a Internet (web, mail, database) — monitora sia il traffico di rete che l'applicazione
• Server con dati proprietari sensibili — layer aggiuntivo di protezione su asset ad alto rischio
• Workstation aziendali — in aggiunta all'antivirus, per rilevare comportamenti anomali

Lab — HIDS in pratica (Mustache Project, Sprint 1):

Wazuh agent (wazuh-agent.service) installato su Ubuntu 24.04 — agente HIDS che monitora auth.log, file system (FIM) e processi. Wazuh manager (Docker) raccoglie gli eventi e li correla come SIEM. Da Kali, Hydra lancia brute force SSH: in meno di 60 secondi la dashboard Wazuh mostra 816 authentication failures con MITRE ATT&CK T1110 (Brute Force). Il HIDS ha rilevato l'attacco leggendo /var/log/auth.log in tempo reale — senza interferire con il traffico di rete.

NIDS — Network-based IDS

#

Un NIDS monitora l'attività sull'intera rete, non su un singolo host. L'amministratore installa sensori (o collector) su dispositivi di rete — switch, router, firewall — che raccolgono il traffico e lo inviano a una console NIDS centrale per l'analisi.

Cosa sono i sensori?

I sensori sono agenti software (o appliance dedicate, demoni linux) installati sui nodi di rete. Non analizzano il traffico da soli — lo catturano e lo inoltrano alla console NIDS che fa l'analisi centrale. Sono gli "occhi" distribuiti del NIDS.

Dove si piazzano i sensori (vedere Figure 4.1 sotto):

La scelta dipende da cosa vuoi misurare:

• Solo attacchi dall'esterno → sensore lato Internet
• Solo ciò che penetra → sensore lato interno
• Entrambi → sensori in entrambe le posizioni (configurazione consigliata)

Limitazioni critiche del NIDS:

1. Non vede gli host individualmente — rileva anomalie solo se causano un cambiamento nel traffico di rete. Un malware silenzioso che non genera traffico è invisibile al NIDS.
2. Non decifra il traffico cifrato — un NIDS analizza solo traffico in chiaro (plaintext). Connessioni TLS/HTTPS passano attraverso senza essere ispezionate.

Port mirroring (port spanning):

Senza port mirroring servirebbe un sensore per ogni porta fisica dello switch. Con il mirror, si aggrega tutto su una porta sola → un sensore vede l'intero segmento.

Switch fisico
├── Porta 1  ──cavo──► server web     (eth0 del server)
├── Porta 2  ──cavo──► router         (eth0 del router)
├── Porta 3  ──cavo──► workstation    (eth0 del PC)
└── Porta 24 ──cavo──► sensore NIDS   (eth0 del sensore)
         ↑
    porta mirror: riceve copia di tutto ciò che passa sulle porte 1-23

Il sensore è una macchina dedicata (fisica o VM) con un agent NIDS (daemon, es. Suricata) che gira sopra. Il daemon legge tutto il traffico che arriva sulla sua eth0 e lo inoltra alla console NIDS centrale.

Promiscuous mode:

I pacchetti che arrivano sulla porta mirror sono indirizzati ad altri host (server web, router, workstation) — non al sensore. Normalmente una NIC scarta i pacchetti il cui MAC di destinazione non è il suo:

flowchart TD
    subgraph NORMAL["NIC normale"]
        P1["pacchetto arriva"] --> D1{"MAC dest = mio?"}
        D1 -->|"sì"| A1["accetto"]
        D1 -->|"no"| S1["scarto"]
    end
    subgraph PROMISC["NIC in promiscuous mode"]
        P2["pacchetto arriva"] --> I2["ignora MAC destinazione"]
        I2 --> A2["accetto tutto → passa a Suricata"]
    end

Senza promiscuous mode il sensore scarterebbe silenziosamente tutto il traffico che sta "spiando". Per questo la NIC del sensore deve essere in promiscuous mode — è la stessa modalità che attiva Wireshark quando catturi traffico su un'interfaccia.

Lo stesso principio si applica ai router: si configura un port tap sul router per catturare tutto il traffico che lo attraversa e inviarlo al sensore.

HIPS e NIPS — la matrice completa

#

HIPS (Host-based IPS): stessa posizione del HIDS — installato sull'host — ma può intervenire attivamente: terminare processi, bloccare connessioni, modificare ACL locali. Utile per bloccare malware che non genera traffico di rete visibile al NIDS.

NIPS (Network-based IPS): come il NIDS ma in-line nel flusso di traffico — può droppare pacchetti malevoli prima che raggiungano la rete interna. Il posizionamento pratico (perimetro Internet vs perimetro SCADA) è descritto in #NIPS 1 e NIPS 2 — posizionamento pratico (Figure 4.3).

Lab — HIPS in pratica (Mustache Project, Sprint 1):

fail2ban configurato su Ubuntu come componente HIPS: maxretry = 5, findtime = 60s, bantime = 300s. Dopo 5 tentativi SSH falliti da Kali (192.168.64.200) in 60 secondi, fail2ban scrive una regola iptables che banna l'IP. Su Kali, Hydra riceve Connection refused. Il ciclo visibile in /var/log/fail2ban.log: Found ×5 → Ban → (300s) → Unban → Found ×5 → Ban. Distinzione chiave: HIPS non è inline — i pacchetti SSH arrivano all'host, poi vengono bloccati i tentativi futuri. Inline è solo Suricata in modalità nfqueue (NIPS).

Metodi di Detection

#

mindmap
  root((Detection
Methods))
    Signature-based
      Database firme note
      Come antivirus
      Rileva attacchi noti
      Non rileva zero-day
      SYN flood classico
    Trend-based
      Anomaly-based
      Fase 1 Baseline
      Fase 2 Deviazione
      Rileva zero-day
      Vulnerabile ad APT lenti
      APT paziente sotto soglia
    SYN Flood
      Three-way handshake
      ACK mai inviato
      Risorse esaurite
      IDS rileva pattern
      IPS blocca attivamente
    Data Sources
      Firewall logs
      System logs
      Application logs
      Real-time vs Polling
      Aggregatore SIEM

Un IDS può solo rilevare un attacco, non prevenirlo. Un IPS rileva e blocca prima che l'attacco raggiunga il target. In entrambi i casi, un "attacco" è qualsiasi tentativo di compromettere Confidentiality, Integrity o Availability (CIA triad).

I due metodi primari di detection sono signature-based e heuristic/behavioral-based (detto anche anomaly-based). Un IDS può usare uno dei due o entrambi.

Signature-based (definition-based)

#

Usa un database di vulnerabilità note o pattern di attacco noti. Quando il traffico corrisponde a una firma nel database → alert.

Esempio con SYN flood:

• L'attaccante inonda il target di pacchetti SYN senza mai completare il three-way handshake TCP (manca l'ACK finale)
• Questo consuma risorse sul server fino al crash
• È un attacco noto con un pattern preciso: SYN ripetuti da un IP verso un altro IP
• Il signature database contiene quella definizione → l'IDS la riconosce e genera alert

Limite: funziona solo contro attacchi già noti e catalogati. Un attacco zero-day (mai visto prima) non ha firma → non viene rilevato.

Trend-based Detection (Anomaly-based)

#

Gibson la chiama trend-based — anche detta anomaly-based o behavioral-based, sono sinonimi. Invece di confrontare con firme note, osserva come si comporta il traffico e cerca deviazioni dalla normalità.

Funziona in due fasi:

Fase 1 — Baseline: L'IDS osserva la rete e costruisce un profilo di "normale" — il riferimento di partenza. Analogia: il medico che misura la tua pressione ogni anno costruisce una baseline. Se un giorno è 180/110 sa che è anomalo non per una regola astratta, ma perché conosce il tuo normale.

Esempio di baseline: 500 connessioni/ora, picco traffico 9-11, nessun host con più di 5 login falliti al giorno.

Fase 2 — Detection: Tutto ciò che supera una soglia di scostamento dalla baseline → alert.

Baseline: 500 conn/ora Osservato: 50.000 conn/ora → anomalia → alert

Vantaggio principale: rileva attacchi zero-day — non serve la firma, basta che il comportamento sia anomalo.

Punto debole — l'attaccante paziente (APT):

Un APT che esfiltra 10MB al giorno invece di 10GB in un'ora resta sempre dentro la soglia → nessun alert per mesi.

Caso limite — SYN flood distribuito (DDoS):

SYN flood da un singolo IP → signature-based lo cattura (pattern noto). Distribuito su migliaia di IP (botnet) → nessuna firma per singolo IP → serve trend-based: il volume aggregato si discosta dalla baseline.

SYN Flood — approfondimento

#

Il SYN flood è un attacco DoS classico che sfrutta il three-way handshake TCP.

Analogia: è come un amico che tende la mano per stringertela — tu estendi la tua in risposta — e lui la ritira all'ultimo istante. Tu o io smetteremmo di rispondere. Il server no: continua a rispondere a ogni SYN con un SYN/ACK perché non sa fare altrimenti.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: Normale three-way handshake
    C->>S: SYN
    S->>C: SYN/ACK
    C->>S: ACK
    Note over C,S: Sessione stabilita ✓

    Note over C,S: SYN flood attack
    loop × migliaia (IP spoofati)
        C->>S: SYN
        S->>C: SYN/ACK
        Note right of S: ACK mai inviato — sessione pendente, risorse consumate
    end
    Note over C,S: Risorse esaurite — nuove connessioni bloccate

Ogni sessione incompleta consuma risorse. Quando le risorse si esauriscono, il server non riesce più ad accettare connessioni legittime — non necessariamente crasha, ma diventa inaccessibile.

Difese:

• IDS rileva il pattern → alert
• IPS rileva e blocca attivamente
• Molti firewall includono un SYN flood guard che rileva le sessioni incomplete e le chiude proattivamente

Data Sources e Trends

#

Un IDS raccoglie log da fonti diverse per rilevare pattern di attacco su un perimetro ampio. Le fonti principali:

Real-time vs. Polling:

• Real-time — i log arrivano al sistema di analisi man mano che vengono generati. Rilevamento più rapido.
• Polling — l'IDS interroga le sorgenti a intervalli regolari. Più semplice, ma con ritardo.

Aggregatore:

Un NIDS include spesso un aggregatore che raccoglie i log da tutti i sensori e li centralizza per l'analisi — ruolo simile a un SIEM. Senza aggregazione, ogni sensore genera alert isolati e diventa impossibile correlare eventi distribuiti su più nodi della rete.

Reporting Based on Rules

#

L'IDS analizza i log raccolti e genera notifiche quando rileva pattern sospetti. Il termine usato varia per gravità:

• Alarm — segnale serio, richiede risposta immediata
• Alert — segnale di minore gravità in alcuni sistemi

L'amministratore riceve la notifica e investiga l'evento per determinare se è reale o un falso positivo.

Validazione degli Alert — FP, FN, TP, TN

#

mindmap
  root((Alert
Validation))
    Quadranti
      TP True Positive
        Attacco reale rilevato
        Alert corretto
      TN True Negative
        Nessun attacco silenzio
        Comportamento corretto
      FP False Positive
        Evento benigno alert
        Falso allarme
      FN False Negative
        Attacco non rilevato
        Il piu pericoloso
    Soglia threshold
      Bassa piu FP
      Alta piu FN
      Bilanciamento necessario
      Configurazione ambientale
    Alert Fatigue
      Troppi FP
      Admin ignora alert
      Urlare al lupo
      Calibrare non sopprimere
    In-line vs Out-of-band
      IPS in-line blocca
      IDS passivo avvisa
      Fail-open disponibilita
      Fail-closed sicurezza

Un IDS non è infallibile. Ogni evento rientra in uno di quattro quadranti:

• True Positive (TP) — attacco reale, IDS rileva correttamente → alert giusto
• True Negative (TN) — nessun attacco, IDS tace → comportamento corretto
• False Positive (FP) — evento benigno/innocuo, ma IDS genera alert → falso allarme
• False Negative (FN) — attacco in corso, IDS non rileva nulla → il più pericoloso

Soglia SYN — threshold

#

Un pacchetto SYN singolo è normale — ogni connessione TCP inizia con un SYN. Il problema è il volume.

1 SYN/sec    → connessione normale         → no alert
10 SYN/sec   → potrebbe essere normale     → soglia bassa → FP
1000 SYN/sec → quasi certamente un attacco → alert corretto

La threshold è configurabile: l'amministratore imposta il numero di SYN al secondo oltre il quale scatta l'alert. Non esiste una soglia universale — dipende dall'ambiente specifico.

• Soglia troppo bassa → falsi positivi su traffico legittimo
• Soglia troppo alta → falso negativo su attacco reale

Il problema dei falsi positivi — "urlare al lupo"

#

La fiaba "al lupo al lupo" descrive perfettamente il rischio:

Un pastorello urla "al lupo! al lupo!" come scherzo. I contadini corrono — due volte. Quando il lupo arriva davvero, nessuno si muove più.

Un IDS con troppi falsi positivi produce lo stesso effetto: gli amministratori iniziano a ignorare gli alert ("è quasi sempre un falso positivo"). Quando arriva l'attacco reale, l'alert viene trascurato.

IPS vs IDS — In-line vs Passivo

#

In-line vs Out-of-band

#

La differenza fisica tra IDS e IPS è dove si trovano nel percorso del traffico:

In-line significa che il traffico passa fisicamente attraverso l'IPS — come un casello autostradale. Non puoi bypassarlo: ogni pacchetto entra, viene ispezionato, e solo se è pulito prosegue. L'IPS può droppare pacchetti malevoli prima che raggiungano la rete interna.

Out-of-band (passivo) significa che l'IDS riceve una copia del traffico via port mirror, ma il traffico originale va avanti comunque — arriva a destinazione prima ancora che l'IDS lo analizzi. Il NIDS può agire solo dopo che l'attacco è partito, non prima.

Active monitoring vs passive monitoring

Terminologia alternativa equivalente:

SPAN = Switch Port Analyzer — termine Cisco per il port mirroring. Lo switch duplica il traffico di una o più porte su una porta dedicata dove è connesso il sensore IPS/IDS. Sinonimo di port mirror/port spanning.

Perché alcune organizzazioni scelgono il passive monitoring:

• Preoccupazione che un guasto dell'IPS in-line interrompa la rete
• Preoccupazione che l'IPS sia troppo aggressivo e blocchi traffico legittimo (falsi positivi) In questi casi si preferisce la visibilità senza il rischio di downtime o interruzioni involontarie.

Fail-open e fail-closed per IPS in-line

Quando un IPS in-line ha un guasto (hardware, software, alimentazione), cosa succede al traffico?

La maggior parte delle reti preferisce fail-open per non interrompere il servizio, ma non è universale — dipende dal contesto (una rete SCADA potrebbe preferire fail-closed). Verificare sempre la documentazione del dispositivo.

Firewall vs IPS — differenza fondamentale

Il firewall è il buttafuori che controlla il biglietto. L'IPS è il metal detector che controlla cosa hai addosso. Un NGFW li combina: applica regole di rete e ispeziona il contenuto — per questo ha sostituito il VPN concentrator dedicato e l'IPS separato in molte architetture moderne.

Capacità aggiuntive degli IDS avanzati

#

Alcuni IDS, oltre all'alert standard, possono modificare l'ambiente per reagire all'attacco:

• Modifica ACL — l'IDS aggiorna dinamicamente le Access Control List del firewall per bloccare l'IP attaccante
• Terminazione processi — chiude i processi sul sistema target che l'attacco ha avviato
• Deviazione verso honeypot/honeynet — reindirizza l'attaccante verso un ambiente esca dove può essere studiato senza danni reali (honeypot = sistema esca singolo; honeynet = rete di honeypot — approfondito più avanti in questo capitolo)

NIPS 1 e NIPS 2 — posizionamento pratico (Figure 4.3)

#

La figura mostra due NIPS su reti separate, ognuno protegge un perimetro diverso:

NIPS 1 — perimetro Internet:

• Posizionato tra Internet e la screened subnet (DMZ)
• Tutto il traffico Internet passa attraverso NIPS 1
• Ispeziona il traffico in ingresso e blocca gli attacchi prima che raggiungano la rete interna

NIPS 2 — perimetro SCADA (rete privata interna):

• Posizionato tra l'intranet e la rete SCADA (private network)
• Il firewall adiacente ha regole che permettono solo traffico autorizzato (es. solo Homer dal suo PC)
• NIPS 2 ispeziona anche quel traffico autorizzato per bloccare eventuali pacchetti malevoli

Perché serve NIPS 2 se c'è già un firewall?

Un APT (Advanced Persistent Threat) può installare un RAT (Remote Access Trojan) sul PC di Homer tramite phishing o malware. Una volta installato, l'attaccante controlla il PC di Homer dall'interno. Il firewall lascia passare il traffico da Homer perché è nella whitelist — ma NIPS 2 ispeziona quel traffico e blocca i pacchetti malevoli prima che raggiungano la rete SCADA.

SCADA — cos'è

#

SCADA (Supervisory Control and Data Acquisition) è un sistema di controllo industriale usato per gestire infrastrutture critiche: centrali nucleari, reti elettriche, acquedotti, oleodotti. È una rete privata segmentata dall'intranet aziendale — accesso estremamente ristretto, spesso con protocolli legacy e sistemi difficili da aggiornare. Target ad alto valore per APT e attori nation-state.

Honeypot – Honeynet – Honeyfile – Honeytoken

#

mindmap
  root((Deception
Tech))
    Honeypot
      Server finto appetibile
      Dati bogus mai reali
      Distrae e osserva
      Alert durante attacco
    Honeynet
      Gruppo di honeypot
      VM su server fisico
      Osserva lateral movement
      IDS deflette traffico
    Honeyfile
      File nome attraente
      password.txt
      Alert se aperto o copiato
      Rivela esplorazione attiva
    Honeytoken
      Record falso in DB reale
      Email vergine
      Alert dopo esfiltrazione
      Tradisce il ladro
    Know Your Enemy
      Sun Tzu
      Osservare metodologie
      Zero-day usati
      Strumenti attaccante

Honeypot

#

Cos'è: un server costruito appositamente per sembrare un target appetibile — come il miele per un orso. È protetto in modo sciatto (sloppily) per invitare l'attaccante a entrare.

Come funziona: l'attaccante trova un server apparentemente vulnerabile con dati allettanti (credenziali, file proprietari, transazioni). Ha qualche protezione — abbastanza da sembrare realistico: un server completamente aperto insospettirebbe un attaccante esperto. Mentre è dentro, il team di security lo osserva.

Esempio: web server finto in DMZ con cartelle che simulano dati di carte di credito. Oppure honeypot interno con documenti fabbricati su progetti proprietari — usato per individuare una minaccia interna (insider).

Scopo: distrarre (ogni minuto nel honeypot = un minuto non sulla rete reale) + osservare metodologie, strumenti, zero-day usati.

Honeynet

#

Cos'è: un gruppo di honeypot in un segmento di rete separato ma raggiungibile dalla rete principale. Mima un'intera infrastruttura reale — non un singolo server, ma una rete completa.

Come funziona: un singolo server fisico potente ospita più VM, ognuna con il suo OS e applicazioni. Dal punto di vista della rete, 1 server fisico + 6 VM = 7 sistemi distinti sullo stesso subnet. L'attaccante non distingue fisico da virtuale.

Esempio:

Server fisico (1 IP)
  ├── VM 1 — web server finto      (1 IP)
  ├── VM 2 — database finto        (1 IP)
  ├── VM 3 — file server finto     (1 IP)
  ├── VM 4 — workstation finta     (1 IP)
  ├── VM 5 — mail server finto     (1 IP)
  └── VM 6 — domain controller finto (1 IP)
                                   = 7 sistemi visibili sul subnet

Scopo: osservare il lateral movement — l'attaccante si muove tra i nodi della honeynet credendo di essere in una rete reale. Gli IDS avanzati possono deflettere automaticamente il traffico malevolo verso la honeynet.

Honeyfile

#

Cos'è: un file progettato per attirare l'attenzione di un attaccante tramite il nome.

Come funziona: un file chiamato password.txt sembra contenere credenziali reali. Un amministratore esperto non sarebbe così imprudente — ma un attaccante ci cade. Il file viene posizionato dove un attaccante in esplorazione lo troverà. Se qualcuno lo apre o copia, scatta un alert.

Esempio: passwords.txt, credit_cards_2024.xlsx, employee_salaries.csv — nomi che gridano "dati sensibili" a chi sta cercando qualcosa di utile.

Scopo: rivelare che un attaccante sta esplorando attivamente il sistema durante l'intrusione.

Honeytoken

#

Cos'è: un record falso inserito all'interno di un database di produzione reale, progettato per rilevare se i dati sono stati rubati.

Come funziona: si crea un record che non esiste nella realtà, ma è indistinguibile dagli altri. Se quel record compare altrove — in un dump, in una lista venduta, in una campagna spam — si sa con certezza che il database è stato esfiltrato.

Esempio — l'email "vergine":

1. Creo: JamesKate@getcertifiedgetahead.com
2. La inserisco in un record cliente finto nel DB di produzione
3. Non la uso mai altrove — è "vergine"
4. Se quell'email riceve un messaggio → il DB clienti è stato rubato

Quell'email non può ricevere messaggi per nessun altro motivo: non è pubblicata, non è registrata da nessuna parte, non esiste fuori dal DB. Un messaggio su quella inbox ha una sola spiegazione possibile.

Scopo: rilevare l'esfiltrazione dopo che i dati sono già stati rubati — il token tradisce il ladro quando usa il bottino.

Confronto

#

Know Your Enemy — Sun Tzu e la cyberwarfare

#

Sun Tzu scrisse nell'Arte della Guerra: "Tutta la guerra è basata sull'inganno" e "Conosci i tuoi nemici."

La cyberwarfare è guerra quotidiana, e honeypot e honeynet sono strumenti di intelligence offensiva: non solo difendono, ma permettono di conoscere il nemico — come attacca, con quali strumenti, quali vulnerabilità sfrutta, cosa cerca. Chi difende non può farlo bene senza capire come funziona chi attacca.

Securing Wireless Networks

#

mindmap
  root((Wireless
Security))
    Dispositivi
      Switch Layer 2
      AP stesso subnet L2
      Router Layer 3
      Wireless Router AP+Router
    SSID e MAC
      SSID nome rete
      Cambiare default
      MAC filtering debole
      BIA vs LAA spoofable
    Bande e canali
      2.4 GHz portata maggiore
      5 GHz velocita maggiore
      Canali 1 6 11 non sovrapposti
      Site survey heat map
    Protocolli
      WEP deprecato
      WPA deprecato
      WPA2 CCMP AES
        PSK Personal
        Enterprise RADIUS
        Open cleartext
      WPA3 SAE GCMP
        Enhanced Open cifrato
        Perfect Forward Secrecy
        Dragonfly handshake
    Autenticazione
      EAP-TLS cert su entrambi
      PEAP solo server cert
      EAP-TTLS server cert legacy
      EAP-FAST PAC no cert
      802.1X Port-Based NAC
      Captive Portal guest

Le WLAN (Wireless Local Area Networks) sono parte fondamentale sia delle reti domestiche che aziendali. La facilità di deployment è il vantaggio principale — nessun cavo, connessione rapida, riduzione dei costi. Ma le reti wireless rappresentano anche un importante vettore di attacco, e molti utenti non sanno come securizzarle adeguatamente.

I quattro dispositivi di rete — differenze fondamentali

#

Prima di entrare nella sicurezza wireless, è utile avere chiaro il ruolo di ogni dispositivo. I vendor li combinano spesso in un unico box, ma concettualmente sono distinti.

Switch — lavora solo all'interno del segmento locale. Connette PC, server, stampanti sulla stessa subnet. Non sa cosa sia un'altra rete, non fa routing, non ha una porta WAN. È invisibile a Internet.

Access Point puro — stessa logica dello switch, ma wireless. Estende il segmento cablato via radio. Tutti i client wireless finiscono sullo stesso subnet della rete cablata. Non fa routing, non esce su Internet da solo.

PC via cavo ──────────────────┐
                              ├── switch ──── router ──── modem ──── ISP
Laptop WiFi ── (AP) ──────────┘
                  ↑
           Layer 2: stesso subnet
           AP non sa nulla di Internet

Il laptop connesso all'AP è sulla stessa rete del PC cablato. L'AP non ha nulla a che fare con l'uscita su Internet — quella è roba del router.

AP vs range extender/repeater — l'AP non amplifica il segnale wireless. Quello è un dispositivo diverso: il range extender prende il segnale wireless e lo ri-trasmette via radio, senza cavo verso il router. L'AP invece ha sempre un cavo fisico che torna al router/switch — crea un nuovo punto di accesso, non estende quello esistente.

Router — l'unico che sa muoversi tra reti diverse. Instrada tra subnet interni (es. rete ufficio → rete server) e verso Internet via modem. Ha sempre almeno due interfacce: una LAN, una WAN.

Routing solo tra subnet interne — il router può instradare anche senza uscire su Internet:

192.168.1.0/24  (ufficio) ──┐
                             ├── Router ──── Internet
192.168.2.0/24  (server)  ──┘

I due subnet non si parlano direttamente — passano sempre per il router. Un AP puro non può farlo: vede solo un subnet, tutti sullo stesso segmento Layer 2.

AP e Wireless Router — Distinzione fondamentale

#

Un access point (AP) connette i client wireless a una rete cablata — stesso subnet, Layer 2. Un wireless router è un AP con router integrato: può instradare tra subnet e uscire su Internet.

L'AP ti porta sulla LAN. Quello che puoi fare da lì dipende da cosa c'è sulla LAN, non dall'AP:

Casa (un box solo):
  Laptop WiFi
      │  ← radio
     (AP + Router + Modem) ──── presa ISP

Enterprise / due box:
  Laptop WiFi
      │  ← radio
     (AP)
      │  ← cavo
     switch
      │
     router ──── modem ──── presa ISP   (di fatto arrivi wireless alla rete)  

Se sulla LAN c'è un router che va su Internet → arrivi su Internet. Ma il merito è del router, non dell'AP. L'AP ha fatto solo da ponte wireless→cablato.

Se la LAN non ha un router (es. rete isolata di laboratorio) → sei sulla LAN e basta, nessun accesso a Internet.

L'AP è trasparente: dal punto di vista della rete, sei esattamente come un PC collegato con il cavo — stesso subnet, stessi accessi, stesse regole. La differenza è solo il mezzo fisico (radio invece di rame).

Wireless Router — perché crea confusione:

In commercio quasi tutti i dispositivi venduti come "AP" o "router WiFi" ai consumer sono in realtà wireless router — combinano tutto in un box:

[Modem] ←→ [Router] ←→ [Switch (4 porte RJ-45)] + [Access Point WiFi]
              NAT
              DHCP
              firewall base

Questo fa tutto: riceve il segnale ISP (se ha il modem integrato), fa routing tra LAN e Internet, assegna IP via DHCP, connette sia via cavo che wireless. Gibson fa la distinzione precisa AP vs wireless router proprio perché l'esame la fa — nel mondo reale i due termini vengono usati come sinonimi.

Anatomia di un Wireless Router — Figure 4.4

#

La figura mostra un wireless router che fornisce connettività a client sia cablati che wireless. I componenti principali:

• Switch component — gestisce le porte RJ-45 per i client cablati
• Router component — fornisce connettività a Internet via broadband modem/ISP
• Wireless transceiver — gestisce trasmissione e ricezione dei segnali radio per i client wireless

I client cablati (via RJ-45) e i client wireless convergono sullo stesso switch component interno — per il resto della rete sono indistinguibili.

Servizi aggiuntivi del wireless router:

Questi servizi integrati riducono drasticamente il tempo di setup della WLAN rispetto a configurare ogni componente separatamente.

Band Selection e Channel Overlaps

#

Le reti wireless usano due bande radio principali: 2.4 GHz e 5 GHz. I dispositivi non trasmettono esattamente su quella frequenza — ogni banda è suddivisa in più canali che partono da circa 2.4 GHz o 5 GHz.

Regola da ricordare: 2.4 GHz = più portata, 5 GHz = più velocità.

Standard e bande:

Channel overlap — Figure 4.5:

Nella banda 2.4 GHz i canali si sovrappongono. In 802.11b i canali sono 1-11 (in Italia/EU), ma solo 1, 6 e 11 sono non-sovrapposti:

• Canale 1 si sovrappone con i canali 2-5
• Canale 6 si sovrappone con i canali 2-10
• Canale 11 si sovrappone con i canali 7-10

Se un dispositivo vicino usa un canale sovrapposto al tuo, il traffico interferisce e le performance calano.

Esempio pratico: hai il router su canale 6 in un condominio. I router dei vicini usano canale 5 e 7 — entrambi sovrapposti al 6. Soluzione: spostare il tuo router su canale 1 o 11 (non sovrapposti al 6) → interferenze eliminate.

La maggior parte dei dispositivi sceglie automaticamente il canale migliore, ma alcuni permettono la selezione manuale per ottimizzare le performance in ambienti affollati.

2.4 GHz:

• Pochi canali (11-13 totali)
• Si sovrappongono quasi tutti
• Solo 3 non si sovrappongono: 1, 6, 11
• Risultato: interferenze frequenti, specialmente in condomini

5 GHz:

• Molti più canali (20+ a seconda del paese)
• Sono più larghi e non si sovrappongono
• Risultato: molto meno interferenza

Access Point SSID

#

Il SSID (Service Set Identifier) è semplicemente il nome della rete wireless — quello che vedi quando cerchi reti WiFi sul tuo dispositivo.

Alcuni AP arrivano con SSID di default impostati dal vendor (es. il vecchio default Linksys era "Linksys"). I vendor più recenti obbligano l'utente a scegliere un nome al primo avvio, senza imporre un default.

Perché cambiare l'SSID di default è importante (defense-in-depth):

Un SSID di default rivela il vendor dell'AP. Se un attaccante vede "Linksys" sa che stai usando un AP Linksys — e può sfruttare vulnerabilità note specifiche di quel modello. Un SSID generico come "Success" non fornisce nessun indizio sul dispositivo sottostante.

MAC Filtering

#

Il MAC address (physical address / hardware address) è un indirizzo a 48 bit in esadecimale che identifica ogni NIC. Formato tipico: 00-16-EA-DD-A6-60.

I wireless router consentono di configurare una whitelist o blacklist di MAC address:

• Whitelist — permetti solo i MAC elencati, blocca tutti gli altri
• Blacklist — blocca i MAC elencati, permetti tutti gli altri

Sembra una misura di sicurezza, ma è facilmente aggirabile.

Come funziona il bypass:

1. Attaccante mette wlan0 in modalità monitor (promiscuous)
2. Cattura frame wireless → legge i MAC address dei client autorizzati
3. Cambia il proprio MAC (LAA) con uno di quelli autorizzati
4. Si connette alla rete bypassando il filtro

Perché funziona — BIA vs LAA:

Ogni NIC ha due livelli di indirizzo:

L'AP vede solo quello che il client trasmette — il LAA. Il BIA non viaggia in rete. Quindi l'attaccante imposta il proprio LAA al MAC della vittima e l'AP non può distinguerlo.

Un device, due MAC:

Un laptop ha NIC separate per wired e wireless — due MAC distinti, uno per scheda:

eth0  (Ethernet) → MAC: 00-16-EA-DD-A6-60
wlan0 (WiFi)     → MAC: 00-16-EA-DD-A6-61

L'attaccante può spoofar entrambi — stesso meccanismo. Il MAC spoofing su eth0 bypassa il port security degli switch (→ cap-03-security-architecture); su wlan0 bypassa il MAC filtering wireless.

MAC Address Cloning:

Caso specifico: clonare il MAC della porta WAN del router sul PC. Usato legittimamente per risolvere problemi di connettività su reti home/office dove l'ISP lega la sessione al MAC della prima NIC registrata.

In un MAC cloning attack (= MAC spoofing attack) l'attaccante clona il MAC di un sistema autorizzato per bypassare il filtro.

Antenne: Omni vs Directional

#

Omnidirectional (omni) — trasmette e riceve segnale in tutte le direzioni contemporaneamente, come una lampadina. È l'antenna standard su AP e dispositivi wireless: permette la connessione da qualsiasi direzione.

Directional — trasmette e riceve in una direzione sola. Tutta la potenza è concentrata in un punto → gain maggiore rispetto all'omni → raggiunge distanze maggiori.

Site Survey, Heat Map e Wireless Footprinting

#

• Interferenze da altre reti sul stesso canale (2.4 GHz specialmente, canali sovrapposti)
• Dispositivi che operano sulla stessa frequenza (microonde, baby monitor, Bluetooth)
• Dead spot — zone senza copertura
• Hotspot — zone con segnale eccessivamente forte che "sconfina" fuori dall'edificio

Non si fa solo una volta: l'amministratore ripete il survey periodicamente per verificare che l'ambiente non sia cambiato e per rilevare eventuali AP non autorizzati (rogue AP).

Wi-Fi Analyzer — tool che analizza l'attività sui canali dello spettro wireless:

• Mostra ogni canale e il suo livello di attività su un grafico
• Mostra i livelli di potenza (signal strength) per canale
• Permette di vedere quali reti vicine usano quali canali → identifica le interferenze
• Analizza una frequenza alla volta (2.4 GHz o 5 GHz)

Heat Map — rappresentazione a colori dell'intensità del segnale wireless:

Verde  → segnale forte
Giallo → segnale medio
Rosso  → segnale debole o assente (dead spot)

Si crea camminando per l'edificio con il tool attivo — registra la posizione e la potenza del segnale in ogni punto. Il risultato è una mappa visiva che mostra copertura completa vs dead spot.

Wireless Footprinting — diagramma dettagliato che sovrappone la heat map alla planimetria dell'edificio. Mostra la posizione fisica degli AP, le zone di copertura, i dead spot e gli hotspot.

Strumenti: software o hardware?

Spectrum Analyzer — strumento hardware o software che mostra tutti i segnali su una frequenza, indipendentemente dalla sorgente. A differenza del Wi-Fi Analyzer (che vede solo AP), lo spectrum analyzer rileva qualsiasi dispositivo che emette su quella banda: forni a microonde, baby monitor, telefoni cordless, dispositivi Bluetooth. Utile per identificare interferenze non-WiFi che degradano la rete.

Wi-Fi Analyzer:    vede solo → [AP-1] [AP-2] [AP-3]
Spectrum Analyzer: vede tutto → [AP-1] [AP-2] [microonde] [baby monitor] [Bluetooth]

Protocolli wireless — dal più debole al più forte

#

Le reti wireless trasmettono nell'aria: chiunque abbia un transceiver wireless può intercettare il traffico. Nella storia del wireless, la sicurezza è stata un'aggiunta tardiva — i primi protocolli erano deboli e gli attaccanti trovarono rapidamente il modo di sfruttarli.

WPA2 — IEEE 802.11i

#

WPA2 (Wi-Fi Protected Access 2) è lo standard wireless definito da IEEE 802.11i. Usa AES come algoritmo di cifratura e CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) come protocollo crittografico. Sostituisce WEP e WPA, entrambi deprecati.

WPA2 fa due cose distinte:

1. Autenticazione — controlla chi può accedere alla rete (PSK o Enterprise)
2. Cifratura — cifra tutti i pacchetti nell'aria tra device e AP con CCMP/AES

Protegge solo il tratto wireless (device → AP). Dal router in poi non è responsabilità di WPA2 — lì ci pensa HTTPS/TLS se presente.

graph LR
    D["Device"] -->|"WPA2 cifra qui"| A["AP"]
    A -->|"non protetto da WPA2"| R["Router"]
    R --> I["Internet"]
    style D fill:#2d6a4f,color:#fff
    style A fill:#2d6a4f,color:#fff

Tre modalità WPA2:

PSK — Pre-Shared Key: Tutti conoscono la stessa password. Il traffico è cifrato, ma l'AP non sa chi sei — solo che conosci la chiave. Non c'è autenticazione nel senso di "identificazione dell'utente".

È il WiFi di casa: la password stampata sotto il router è la PSK. Chiunque la conosca entra — nessuna identità, nessun log per utente.

RADIUS – Remote Authentication Dial-In User Service

#

RADIUS (Remote Authentication Dial-In User Service) — server dedicato all'autenticazione centralizzata:

Enterprise mode — 802.1X + RADIUS:

Enterprise mode forza ogni utente ad autenticarsi con credenziali uniche prima di accedere alla rete.

Flusso di autenticazione:
1. Utente inserisce username + password sull'AP
2. AP impacchetta le credenziali e le manda al RADIUS server
   (l'AP si autentica al RADIUS con la "shared secret")
3. RADIUS controlla nel suo database
4. RADIUS risponde all'AP: accesso concesso / negato
5. AP apre o blocca la connessione

Tre parametri da configurare sull'AP per Enterprise mode:

802.1X può anche usare certificati per l'autenticazione — l'azienda emette un certificato al dispositivo/utente, che lo presenta invece di username/password.

WPA3 — Simultaneous Authentication of Equals (SAE)

#

WPA3 è la generazione più recente di sicurezza wireless, introdotto nel 2018, ora adottato dalla maggior parte delle aziende. Supporta tre modalità:

Enhanced open mode — sostituisce la open mode non sicura di WPA2. Cifra il traffico anche delle connessioni senza password (reti guest). WPA2 open = cleartext; WPA3 enhanced open = cifrato anche senza password.

SAE mode — Simultaneous Authentication of Equals — sostituisce la PSK di WPA2:

• Usa ancora una passphrase ma l'autenticazione avviene tramite Diffie-Hellman con chiavi effimere
• Ogni sessione genera una coppia di chiavi temporanee usa-e-getta — non derivate direttamente dalla passphrase
• Questo garantisce Perfect Forward Secrecy (PFS): anche se un attaccante cattura l'handshake e in seguito scopre la passphrase, non può decifrare il traffico precedente perché le chiavi effimere sono già state distrutte
• Mutual authentication: sia il client che l'AP si autenticano reciprocamente — nessuno dei due è privilegiato
• Le chiavi di sessione vengono derivate localmente sui dispositivi — nessun hash attraversa la rete (a differenza del 4-way handshake di WPA2)
• Ogni client ottiene una chiave di sessione diversa anche se condividono la stessa passphrase
• Nelle documentazioni IEEE 802.11 viene chiamato dragonfly handshake
• In WPA2-PSK invece: handshake catturato + passphrase = tutto il traffico passato decifrabile

Enterprise mode — come WPA2 Enterprise, usa RADIUS e autenticazione individuale.

Nomi commerciali WPA3:

GCMP — Galois Counter Mode Protocol — il protocollo di cifratura introdotto con WPA3:

• Più forte di CCMP usato in WPA2
• Fornisce data confidentiality tramite cifratura del traffico
• Integra un MIC (Message Integrity Check) basato su GMAC (Galois/Counter Message Authentication Code) che garantisce l'integrità di ogni pacchetto
• GCMP include sia la cifratura che l'integrity check in un unico protocollo

Protocolli crittografici wireless — espansione acronimi:

Protocolli di Autenticazione — EAP e varianti

#

IEEE 802.1X e 802.1X sono la stessa cosa. IEEE è solo il nome dell'ente che ha pubblicato lo standard (Institute of Electrical and Electronics Engineers) — come "ISO" in ISO 27001. In pratica tutti dicono "802.1X" senza il prefisso.

EAP (Extensible Authentication Protocol) è un framework, non un protocollo completo. Definisce come due sistemi creano una chiave condivisa (PMK — Pairwise Master Key) da cui deriva la PTK (Pairwise Transient Key) usata da CCMP per cifrare il traffico. Su EAP si costruiscono metodi specifici con diversi livelli di sicurezza.

Gibson indica esplicitamente cosa studiare per l'esame: "A key point to remember for each of these methods is if they support or require certificates."

Ancora mnemonico:

• PEAP → P di Password (solo server ha cert, utente usa password)
• EAP-TLS → T di Two-sided (tutti e due hanno cert — il più sicuro)
• EAP-TTLS → Tunneled (server cert, legacy dentro il tunnel)
• EAP-FAST → Flexible/Fast, no cert, PAC, Cisco

RADIUS Federation — federazione tra organizzazioni via 802.1X e RADIUS: gli utenti di un partner si autenticano con le proprie credenziali e accedono alle risorse condivise senza nuovo login. Stesso concetto delle federazioni SAML (→ cap-02-identity-access-management) ma applicato al layer di rete wireless.

WPA2 — 4-Way Handshake

#

Gerarchia delle chiavi:

flowchart TD
    A["PSK (passphrase)
o credenziali 802.1X"] --> B["PMK — Pairwise Master Key
mai usata direttamente per cifrare"]
    B -->|"4-way handshake
scambio di nonce casuali"| C["PTK — Pairwise Transient Key
chiave di sessione effimera"]
    C --> D["CCMP/AES cifra il traffico"]

I 4 messaggi (EAPOL frames):

sequenceDiagram
    participant C as Client (Supplicant)
    participant A as AP (Authenticator)

    Note over C,A: Entrambi conoscono già la PMK
    A->>C: M1 — ANonce
    Note right of A: AP genera nonce casuale
    C->>A: M2 — SNonce + MIC
    Note left of C: Client calcola PTK (PMK+ANonce+SNonce+MAC) — prova di conoscere PMK
    Note right of A: AP verifica MIC, calcola PTK
    A->>C: M3 — GTK + MIC
    Note right of A: Installa PTK, invia chiave broadcast GTK
    C->>A: M4 — ACK
    Note left of C: Installa PTK e GTK
    Note over C,A: Traffico cifrato con PTK (CCMP/AES)

• ANonce / SNonce — numeri casuali usa-e-getta (number used once). Garantiscono che la PTK sia diversa ad ogni sessione anche se la passphrase non cambia
• PTK — derivata da: PMK + ANonce + SNonce + MAC client + MAC AP. Unica per ogni sessione
• GTK (Group Temporal Key) — chiave separata usata per cifrare il traffico broadcast/multicast (pacchetti inviati a tutti i client)
• MIC (Message Integrity Code) — firma che prova che chi manda il messaggio conosce davvero la PMK, senza rivelarla

Perché il disassociation attack viene usato per catturare l'handshake:

L'attaccante vuole craccare la passphrase WPA2-PSK offline. Per farlo ha bisogno dei 4 messaggi EAPOL (che contengono i nonce e il MIC da cui verificare le guess). Il flusso di attacco:

1. Attaccante fa sniffing passivo — aspetta
2. Manda disassociation frame al client (con MAC spoofato) → client disconnesso
3. Client tenta di riconnettersi → esegue il 4-way handshake
4. Attaccante cattura i 4 frame EAPOL
5. Offline: prova milioni di passphrase → calcola PMK → calcola PTK → verifica il MIC
6. Se il MIC coincide → passphrase trovata

Tool: aircrack-ng (cattura handshake + brute force), hcxdumptool + hashcat (più veloce con GPU).

Perché WPA2-PSK è vulnerabile e WPA3-SAE no:

IEEE 802.1X Security — Port-Based NAC

#

802.1X implementa NAC port-based: prima di poter usare una porta di rete (fisica o wireless), il device deve autenticarsi.

MAC filtering vs 802.1X — differenza fondamentale:

MAC filtering dice "accetto solo i MAC in questa lista" — un attaccante cambia il suo MAC in un minuto (ip link set wlan0 address AA:BB:CC:DD:EE:FF) e bypassa tutto. È security through obscurity.

"Port-based" significa che il controllo avviene a livello di porta fisica o virtuale:

• Wired: ogni presa RJ-45 a muro (wall jack) è una porta switch. 802.1X tiene la porta in stato "unauthorized" finché il device non si autentica
• Wireless: ogni client ha una "porta virtuale" — l'AP blocca il traffico finché 802.1X non autorizza

flowchart TD
    A["Device collegato al wall jack RJ-45"] --> B["Switch: porta UNAUTHORIZED"]
    B --> C{"802.1X autentica via RADIUS"}
    C -->|"OK"| D["Switch: porta AUTHORIZED
traffico normale"]
    C -->|"Fallita"| E["Switch: porta UNAUTHORIZED
device bloccato"]

Rogue device — dispositivo non autorizzato collegato alla rete, non gestito dall'IT:

• Laptop personale di un dipendente portato da casa
• Raspberry Pi nascosto dentro un armadio o dietro una scrivania
• Switch non autorizzato collegato a una presa libera
• Qualsiasi device senza certificato aziendale valido

802.1X blocca i rogue device al livello più basso: la porta resta chiusa indipendentemente da cosa dice il device.

802.1X + VPN — due livelli di autenticazione in sequenza:

1. Il device si connette fisicamente (wired) o wireless
2. 802.1X autentica il device: porta aperta solo se autenticazione OK
3. Solo dopo, il client VPN stabilisce il tunnel cifrato verso la rete aziendale

Anche se qualcuno ruba le credenziali VPN, non può nemmeno avviare la connessione VPN senza prima passare l'autenticazione 802.1X sulla porta.

Combinazione 802.1X + VLAN — dopo l'autenticazione, il RADIUS comunica allo switch in quale VLAN mettere il device:

• Dipendente con cert aziendale → VLAN staff (accesso completo)
• Appaltatore con cert temporaneo → VLAN vendor (accesso limitato)
• Device sconosciuto / auth fallita → VLAN quarantena (solo internet, no rete interna)

Questo è Zero Trust a livello di rete: identità verificata + accesso minimo necessario.

"Dial-in" nel nome RADIUS — termine storico. Negli anni '90 gli utenti si collegavano via modem telefonico (dial-up). RADIUS autenticava quelle connessioni. Oggi "dial-in" indica qualsiasi accesso remoto, il nome è rimasto.

Force wireless clients — l'AP rifiuta connessioni che non usano 802.1X. Un client che tenta di connettersi con solo PSK (o senza autenticazione) viene bloccato a priori. Non è una scelta dell'utente: l'infrastruttura impone 802.1X.

Sicurezza fisica degli AP — 802.1X protegge via software, ma un attaccante con accesso fisico può:

• Premere il tasto reset → AP torna a factory default → niente più 802.1X, rete aperta
• Scollegare l'AP e collegarne uno rogue con lo stesso SSID (evil twin attack)
• Collegare un device direttamente al cavo Ethernet dietro l'AP

La sicurezza fisica degli AP è parte integrante della wireless security: AP montati in alto, in contenitori lockati, o con viti antimanomissione.

802.1X = NAC port-based — 802.1X è il Network Access Control (NAC) implementato a livello di porta. NAC è il concetto ("nessuno accede senza autenticarsi"), 802.1X è lo standard che lo implementa. Sono sinonimi nel contesto Security+.

I tre attori del processo 802.1X (EAP):

sequenceDiagram
    participant S as Supplicant (device)
    participant A as Authenticator (AP/switch)
    participant AS as Auth Server (RADIUS)

    S->>A: 1. Tenta connessione alla rete
    Note over A: Porta UNAUTHORIZED — blocca tutto tranne EAP
    A->>S: 2. EAP-Request Identity
    S->>A: 3. EAP-Response: "Sono James"
    A->>AS: 4. RADIUS Access-Request con identità
    AS->>A: 5. Conferma — continua autenticazione
    A->>S: 6. EAP-Request credenziali
    S->>A: 7. Username + password (nel tunnel EAP)
    A->>AS: 8. RADIUS Access-Request con credenziali
    AS->>A: 9. RADIUS Access-Accept
    Note over A: Porta AUTHORIZED
    A->>S: 10. EAP-Success — accesso concesso

Il processo avviene in millisecondi — l'utente non lo percepisce. Finché le credenziali sono corrette, vede solo "connesso".

Captive Portal

#

Captive Portal = pagina web di login che intercetta il traffico di un client prima di dargli accesso alla rete. Il browser viene "catturato" e reindirizzato alla pagina di login.

Scenario tipico (aeroporto, hotel, ospedale — rete guest):

Utente si connette al WiFi guest
         ↓
Tenta di aprire qualsiasi sito (es. google.com)
         ↓
Il gateway intercetta la richiesta HTTP
         ↓
Reindirizza a https://login.hotel.com
         ↓
Utente inserisce codice stanza / accetta ToS
         ↓
Gateway sblocca accesso internet per quell'IP/MAC

Perché i captive portal invece di 802.1X?

Come funziona tecnicamente:

1. Il gateway assegna IP via DHCP ma blocca tutto il traffico (ACL: solo porta 80/443 verso il captive portal server)
2. Dopo login/accettazione ToS, il gateway aggiunge il MAC/IP alla lista autorizzati
3. Il traffico viene sbloccato per quella sessione (timeout configurabile)

Hotspot pubblici e captive portal — gli hotspot (WiFi pubblici: bar, aeroporti) usano quasi sempre captive portal. Dopo l'accesso, il traffico transita sulla rete pubblica: senza VPN, chiunque sulla stessa rete può intercettare il traffico non cifrato.

Attacchi Wireless

#



mindmap
  root((Wireless
Attacks))
    Deauth Attack
      Management frame forgiati
      MAC spoofing
      DoS Layer 2
      Fix 802.11ac PMF
      WPA3 MFP obbligatorio
    WPS
      PIN 8 cifre
      Due meta 4+4 11k combo
      Reaver cracking
      Disabilitare dopo uso
    Rogue AP
      Wall jack libero
      Sniffer o accesso
      Data exfiltration
      Disconnetti subito
    Evil Twin
      Stesso SSID
      Proxy trasparente
      MITM HTTP traffic
      SSL stripping
    Jamming
      Rumore RF Layer 1
      SNR abbassato
      Fox hunt antenna direzionale
      Attenuatore per localizzare
    IV Attack
      Solo WEP
      IV 24 bit riusato
      Packet injection
      Aircrack-ng
    NFC RFID
      NFC 4 cm eavesdropping
      RFID sniffing cloning DoS
      Faraday sleeve protezione
    Bluetooth
      Bluejacking messaggi
      Bluesnarfing dati
      Bluebugging backdoor
    War Driving
      Ricognizione reti
      Audit legittimo
      War flying drone

Deauthentication / Disassociation Attack — DoS

#

Due tipi di frame, stesso attacco:

In pratica i due termini vengono usati come sinonimi per questo attacco — sia deauthentication che disassociation frame possono essere forgiati dall'attaccante per disconnettere la vittima. All'esame Security+ troverai entrambi: puntano allo stesso concetto.

È un DoS. L'effetto per la vittima è identico al jamming lato esperienza: si disconnette dalla rete senza avviso, non riesce a riconnettersi finché l'attaccante continua, e non capisce cosa sta succedendo. La differenza è il layer: jamming = Layer 1 (fisico), deauth attack = Layer 2 (management frames).

Il problema: In 802.11 (pre-802.11ac), i management frame non sono autenticati. L'AP non verifica se il frame è davvero partito da quel client — si fida ciecamente del MAC nel frame.

L'attacco:

1. L'attaccante fa sniffing passivo (airodump-ng wlan0mon) → individua il MAC della vittima associata all'AP e il BSSID dell'AP
2. Crea un deauth frame con il MAC della vittima come sorgente (MAC spoofing)
3. Lo invia all'AP (aireplay-ng -0 0 -a <BSSID_AP> -c <MAC_vittima> wlan0mon)
4. L'AP lo accetta → disconnette la vittima
5. Ripete in loop → la vittima non riesce più a stare connessa

Attaccante (sniffer)          AP               Vittima (MAC: AA:BB:CC:DD:EE:FF)
       |                       |                          |
       |-- airodump-ng ------> |   vedo MAC vittima       |
       |                       |                          |
       | deauth frame          |                          |
       | src=AA:BB:CC:DD:EE:FF |                          |
       |---------------------->|                          |
       |                       |-- connessione terminata ->|
       |                       |                          | ← kiccat, si tenta riconnessione
       |-- deauth loop ------->|                          |
       |                       |-- kiccat di nuovo ------->|  ← loop infinito

Tool standard: airodump-ng (scoprire MAC), aireplay-ng -0 (inviare deauth frames). Parte della suite aircrack-ng su Kali.

Caso hotel (Gibson): Alcuni hotel individuavano i Personal Hotspot degli ospiti (iPhone in tethering) e lanciavano disassociation attack in loop → connessione continuamente interrotta → l'ospite si arrendeva e pagava il WiFi a pagamento dell'hotel.

La fix — 802.11ac e Protected Management Frames:

Gli engineer del comitato IEEE 802.11 riconobbero il problema. La fix fu incorporata nello standard 802.11ac (e versioni successive): i management frame chiave vengono ora cifrati per default. Frames ora protetti: disassociate, authenticate, channel switch announcements.

Frames che rimangono in chiaro anche su 802.11ac (devono essere leggibili prima che la cifratura entri in gioco):

• Beacon frames (annuncio della rete)
• Probe frames (device che cerca AP)
• Authentication frames (handshake iniziale)
• Association frames (prima connessione)

Se fai una packet capture su una rete 802.11ac vedrai ancora alcuni management frame in chiaro — è normale e intenzionale.

WPA3 rende obbligatori i Management Frame Protection (MFP) — i management frame (inclusi disassociation/deauth) vengono firmati crittograficamente. Un attaccante non può più forgiare frame con il MAC di un'altra vittima.

Caso reale: DEF CON (Las Vegas, ogni anno) — la conferenza di sicurezza più grande al mondo. La rete WiFi è notoriamente uno dei posti più ostili al mondo: ricercatori e partecipanti lanciano deauth attack continuamente come dimostrazione. Gli organizzatori hanno risposto prima con AP enterprise WPA2 e poi con WPA3 + MFP, l'unico modo per rendere il disassociation attack inefficace. Il WiFi di DEF CON è diventato un benchmark per la sicurezza wireless.

WPS — Wi-Fi Protected Setup

#

• Button method (WPS button): Premi il bottone sull'AP e sul device → il device si configura automaticamente in ~30 secondi. Quello che fa Fastweb per collegare nuovi device alla rete di casa.
• PIN method: Trovi l'8-cifre PIN stampato sull'AP → lo inserisci sul nuovo device.

WPS PIN attack (es. Reaver): L'attaccante prova sistematicamente tutti i PIN possibili finché non trova quello corretto:

• 8 cifre → teoricamente 100 milioni di combinazioni
• Ma WPS valida il PIN in due metà separate da 4 cifre → solo ~11.000 combinazioni effettive
• Reaver trova il PIN in ~10 ore (spesso molto meno)
• Una volta trovato il PIN → ricava la passphrase WPA2

Distinzione importante: WPS serve per collegare device alla rete — non ha niente a che fare con accedere alla pagina di configurazione del router (quella si apre via browser su 192.168.1.1 con username/password admin).

WPS è safe con WPA3 — il protocollo è stato rafforzato. Con WPA2 va disabilitato immediatamente dopo uso (o del tutto).

Caso reale: 2011 — Stefan Viehböck (ricercatore austriaco) e Craig Heffner (indipendentemente) pubblicano il WPS PIN vulnerability. US-CERT emette l'advisory TA12-006A. Heffner rilascia Reaver, tool open-source che automatizza il brute force del PIN WPS. Milioni di router domestici in tutto il mondo erano vulnerabili — molti vendor impiegarono anni a patchare, e alcuni router non hanno mai ricevuto un fix (solo la disattivazione manuale del WPS da parte dell'utente risolve il problema). Ancora oggi scannerizzando le reti residenziali si trovano router con WPS attivo.

Rogue Access Point

#

Come si collega alla rete cablata: L'attaccante trova una presa RJ-45 libera (wall jack) in un corridoio, armadio di rete, sala riunioni, o qualsiasi punto con scarsa sicurezza fisica — e ci collega fisicamente il rogue AP via cavo Ethernet.

[Rete cablata interna]
         |
    [Switch aziendale]
         |
    [Wall jack libero] ←── cavo Ethernet ── [Rogue AP] ))) segnale wireless
                                                              |
                                                    [Attaccante nel parcheggio]
                                                    riceve tutto il traffico

Due modalità di attacco:

Data exfiltration: Trasferimento non autorizzato di dati dall'organizzazione verso una location controllata dall'attaccante.

Risposta: Se trovi un AP non autorizzato → disconnetti il cavo Ethernet immediatamente. Isolare prima, investigare dopo.

Caso reale: 2008 — Hannaford Bros. (catena di supermercati USA). Rogue AP installato fisicamente negli armadi di rete di alcuni punti vendita, collegato ai segmenti dei terminali POS (Point of Sale). Risultato: 4,2 milioni di numeri di carte di credito esfiltrati verso server esterni. L'AP era nascosto dove i tecnici raramente facevano ispezioni fisiche. Primo caso di alto profilo a dimostrare che la sicurezza di rete dipende anche dall'accesso fisico agli spazi.

Evil Twin

#

Come funziona:

1. In un luogo pubblico (caffè, aeroporto, hotel), l'AP legittimo trasmette SSID "CoffeeShop_WiFi"
2. L'attaccante configura il suo AP (anche un laptop con scheda wireless) con lo stesso SSID
3. Client ignari si connettono all'evil twin — spesso perché ha segnale più forte o è il più vicino
4. Tutto il traffico della vittima passa attraverso l'attaccante

La vittima naviga normalmente? Sì — l'attaccante ha connessione internet (tethering del proprio telefono, o una seconda NIC verso un AP legittimo). Funge da proxy trasparente: la vittima non nota niente di anomalo, ma tutto il traffico HTTP, le form di login, le email passano in chiaro davanti all'attaccante.

Vettori di attacco:

• Credenziali catturate da form HTTP o pagine login fasulle presentate dall'attaccante
• Analisi del traffico per estrarre dati sensibili (email, cookie di sessione)
• SSL stripping per degradare HTTPS a HTTP

Setup minimo: Un laptop con scheda wireless in un bar. Visivamente indistinguibile da qualsiasi utente normale.

Rilevamento: Site survey con wireless scanner — il segnale dell'evil twin diventa più forte avvicinandosi a esso (aiuta a localizzarlo fisicamente).

Caso reale: 2024 — Australia. La AFP (Australian Federal Police) arresta un uomo che durante voli domestici e in aeroporti aveva configurato un evil twin con SSID identico al WiFi di bordo/aeroporto. I passeggeri si connettevano, venivano presentate pagine login fasulle Google/Facebook → credenziali catturate. L'uomo era seduto in cabina con un laptop e un AP portatile — visivamente indistinguibile da un normale passeggero che lavora. Condannato per frode informatica. Primo caso documentato di evil twin attack su voli commerciali.

Jamming Attack

#

In italiano, in ambito tecnico, ”jamming” significa “interferenza” o “disturbo intenzionale del segnale radio”.

L'obiettivo dell'attaccante è abbassare il signal-to-noise ratio (SNR): il client sente più rumore che segnale reale dall'AP. Se non riesce a decodificare il segnale legittimo → non può né ricevere né trasmettere.

[AP]  )))  2.4 GHz  (((  [Client]
               ↑
       [Jammer emette rumore RF su 2.4 GHz]
               ↓
   SNR troppo basso — pacchetti illeggibili
   tutti i client perdono la connessione

Analogia: Urlare in una stanza dove altri stanno cercando di parlare — il segnale legittimo viene sopraffatto dal rumore.

Tipi di jamming:

Jamming accidentale — è comune: Forno a microonde (2.4 GHz), luci fluorescenti, baby monitor, telefoni cordless. La differenza con un attacco intenzionale è solo l'intenzionalità — l'effetto tecnico è identico.

Come si localizza un jammer — il Fox Hunt:

L'attaccante deve essere fisicamente vicino all'AP (il segnale RF si attenua con la distanza). Una volta confermato che il jamming è intenzionale, la procedura è:

1. Antenna direzionale — a differenza di un'antenna omnidirezionale (che riceve da tutte le direzioni), un'antenna direzionale concentra la ricezione in un settore. Il tecnico gira fisicamente con l'antenna cercando la direzione da cui il segnale è più forte.

2. Il paradosso della vicinanza: Quando sei molto vicino alla fonte, il segnale diventa così forte in tutte le direzioni che è difficile capire esattamente dove si trova.

3. Attenuatore — dispositivo che riduce la potenza del segnale ricevuto. Usato vicino alla fonte: con il segnale abbassato artificialmente, l'antenna direzionale torna a distinguere la direzione. Si triangola avanzando da più punti.

Fox Hunter con antenna direzionale:

    Punto A  ← segnale forte da Est
    Punto B  ← segnale forte da Nord-Est
    Punto C  ← segnale forte da Nord
                    ↓
    Intersezione delle tre direzioni = posizione del jammer

Questo processo si chiama fox hunt — termine preso dagli operatori radio amatoriali che lo usano come gioco per trovare trasmettitori nascosti. In security: stesso metodo, scopo operativo.

Mitigazioni (parziali):

• Cambiare canale — ma se l'attaccante monitora, cambia canale anche lui
• Passare a 5 GHz se il jammer è su 2.4 GHz (o viceversa)
• Soluzione definitiva: trovare e rimuovere fisicamente il jammer

Caso reale: 2015 — Marriott International multata dalla FCC (Federal Communications Commission USA) per 600.000 dollari. Il Marriott Gaylord Opryland Hotel di Nashville aveva deliberatamente jammato i personal hotspot degli ospiti durante le conferenze, usando un sistema Wi-Fi enterprise configurato per inviare frame di deautenticazione (tecnicamente un disassociation attack, ma con lo stesso effetto del jamming sul servizio). Scopo: forzare i partecipanti alle conferenze a pagare il WiFi Marriott ($250–$1.000 al giorno). La FCC definì la pratica illegale sotto il Communications Act. Marriott cercò di fare lobby per rendere la pratica legale — il tentativo fu respinto con ulteriori polemiche.

IV Attack (WEP)

#

Il problema di WEP: WEP usava un IV da soli 24 bit = ~16 milioni di valori possibili. Su una rete trafficata, tutti i valori si esaurivano e lo stesso IV veniva riusato con la stessa chiave → stessa keystream.

L'attacco:

• Stesso IV + stessa chiave = stesso keystream
• Attaccante raccoglie due pacchetti cifrati con lo stesso IV
• XOR dei due ciphertext → XOR dei due plaintext (il keystream si cancella)
• Se uno dei due plaintext è noto (protocolli hanno strutture prevedibili) → si ricava l'altro plaintext e infine la chiave

Packet injection per accelerare:

• L'attaccante inietta pacchetti noti nella rete → l'AP risponde generando più ciphertext
• Più pacchetti = più probabilità di riusare un IV → collisione forzata più in fretta
• Aircrack-ng può craccare WEP in pochi minuti con questa tecnica

Pre-shared key: Sì, è esattamente la classica password WiFi di casa. PSK = la passphrase che tutti conoscono e usano per connettersi alla rete. Nessuna autenticazione individuale — chiunque abbia la password ha accesso alla rete.

WEP è deprecato — WPA2 e WPA3 usano IV molto più lunghi e meccanismi che prevengono il riuso.

Caso reale: 2007 — TJX Companies (proprietaria di Marshalls, TK Maxx, HomeGoods). Breach da 45,6 milioni di carte di credito — il più grande della storia fino ad allora. Gli attaccanti erano parcheggiati nel parcheggio di un negozio Marshalls in Florida con un'antenna direzionale. La rete WiFi dei punti vendita usava WEP → craccato in pochi minuti. Da lì si sono mossi lateralmente fino ai server centrali di TJX dove risiedevano i dati delle carte. Il costo totale stimato per TJX: oltre 250 milioni di dollari. Questo caso accelerò il passaggio obbligatorio a WPA2 nello standard PCI-DSS per tutte le reti che gestiscono dati di pagamento.

Cronologia Grafica

#

NFC Attack — Near Field Communication

#

NFC (Near Field Communication) è uno standard wireless a cortissimo raggio (~4 cm) usato nei pagamenti contactless (carte di credito, smartphone) e nella condivisione dati tra device.

Come funziona il pagamento contactless: Il reader NFC emette un campo elettromagnetico → la carta/telefono si alimenta da quel campo (tag passivo) → trasmette i dati della transazione → pagamento completato senza inserire la carta.

Cosa viene trasmesso (e il rischio):

NFC Eavesdropping attack: L'attaccante usa un'antenna potenziata per estendere il range dell'NFC reader oltre i 4 cm previsti. In spazi affollati (metropolitana, cassa supermercato) può catturare la trasmissione tra carta e reader senza che la vittima se ne accorga.

Indicatore principale: Addebiti non autorizzati sull'estratto conto della carta.

Protezione: Portafogli RFID/NFC blocking (Faraday sleeve) o carte con token dinamici (Apple Pay, Google Pay generano un token diverso per ogni transazione, inutilizzabile se catturato).

Caso reale: 2012 — ricercatori di sicurezza dimostrano a Black Hat che leggere i dati di carte Visa payWave e Mastercard PayPass in chiaro (numero + scadenza) era possibile con un'app Android modificata a <10 cm di distanza. Milioni di carte europee erano vulnerabili. Visa e Mastercard accelerarono la migrazione ai token dinamici, ma il processo richiese anni.

RFID Attack — Radio-Frequency Identification

#

RFID è la tecnologia che usa onde radio per identificare e tracciare oggetti tramite tag. NFC è un sottoinsieme di RFID (solo 13.56 MHz, ~4 cm). RFID copre distanze e frequenze molto più ampie.

RFID vs NFC:

Tag attivi vs passivi:

• Passivo: nessuna batteria — si alimenta dal campo RF del reader. Range: cm-pochi metri. Costa pochi centesimi. Dura decenni. Usato in: badge accesso, carte contactless, tag inventario, microchip animali.
• Attivo: ha batteria propria → può trasmettere a decine/centinaia di metri, può iniziare la comunicazione. Usato in: container shipping, sistemi di tracking flotte, pedaggi autostradali (telepass è RFID attivo).

Attacchi RFID:

Caso reale: 2006 — Chris Paget (ricercatore USA) clona badge di accesso HID (standard aziendale usato in milioni di edifici) a distanza di oltre 1 metro usando hardware da meno di $50. Il badge HID trasmetteva l'ID in chiaro senza autenticazione. Dimostrazione a DEF CON: clona il badge di un partecipante mentre gli stringe la mano. HID ha introdotto crittografia solo nelle versioni successive (HID iClass). Ancora oggi molti edifici usano badge HID senza crittografia.

Bluetooth Attacks

#

Bluetooth è uno standard wireless a corto raggio (~10 m) usato nelle PAN (Personal Area Network) — la rete di device attorno a una persona: smartphone, cuffie, mouse, tastiera, smartwatch.

Discovery mode: Quando un device Bluetooth è in "Discovery mode", trasmette il proprio MAC address e accetta richieste di pairing. Necessario per configurare nuovi device. Problema: nelle versioni precedenti di Bluetooth, il pairing poteva avvenire senza conferma esplicita dell'utente.

Tre attacchi principali:

Discovery mode nelle versioni precedenti: Sì — nelle prime implementazioni Bluetooth, un device in Discovery mode accettava richieste di pairing automaticamente, o con un PIN che era quasi sempre "0000" o "1234". Bluesnarfing sfruttava esattamente questo. Oggi il pairing richiede conferma esplicita su entrambi i device — per questo gli attacchi Bluetooth sono rari nel 2026.

Faraday cage: Mettere il device in una scatola metallica conduttiva (Faraday cage) blocca tutti i segnali wireless incluso Bluetooth — protezione fisica assoluta, ma ovviamente il device non è più utilizzabile.

Caso reale: 2017 — BlueBorne (Armis Security). Vulnerabilità critica in Bluetooth che colpiva 5,3 miliardi di device (Android, iOS, Windows, Linux). Non richiedeva pairing — un attaccante a portata Bluetooth poteva eseguire codice arbitrario sul device senza nessuna interazione dell'utente e senza che il device fosse in Discovery mode. Patch rilasciata rapidamente, ma milioni di device non ricevettero mai l'aggiornamento. BlueBorne dimostrò che anche Bluetooth "moderno" non è immune da vulnerabilità gravi.

Wireless Replay Attack

#

Il core è sempre impersonation: l'attaccante non rompe la crittografia, non scopre la password — si limita a "riprodurre" credenziali già validate per bypassare l'autenticazione.

Flusso normale:
Client ──── auth frame cifrato ────► Server ──► accesso OK

Replay attack:
Attaccante cattura auth frame
              ↓
Attaccante ritrasmette lo stesso frame ore/giorni dopo
              ↓
Server: "frame valido" → accesso OK (senza conoscere la password)

WPA2 e WPA3 sono resistenti ai replay attack tramite:

• Sequence numbers nei frame: ogni frame ha un numero progressivo. Frame con numero già visto → scartato
• Timestamp + nonce: i token di autenticazione hanno scadenza breve e includono valori casuali usa-e-getta

Protezione principale: Non usare protocolli wireless deprecati (WEP non ha protezione replay efficace).

Caso reale: 2017 — KRACK (Key Reinstallation Attack, Mathy Vanhoef). Vulnerabilità nel 4-way handshake di WPA2: l'attaccante forzava la reinstallazione della PTK ritrasmettendo il messaggio 3 del handshake (un replay) → il nonce veniva azzerato → keystream riusato → traffico decifrabile. Colpiva quasi tutti i device WPA2 esistenti. Patch rilasciata, ma dimostrò che anche WPA2 era vulnerabile a replay in condizioni specifiche. WPA3 risolve strutturalmente con SAE.

War Driving e War Flying

#

Non è un attacco in sé — è ricognizione. Il nome viene da "war dialing" (anni '80: comporre migliaia di numeri di telefono automaticamente, cercando modem).

Cosa trova un attacker con war driving:

• Reti non cifrate o con WEP/WPA1 (deprecati → vulnerabili)
• AP con SSID predefinito del vendor (spesso = router mai configurato = default password)
• Rogue AP e evil twin (segnale incoerente con la topologia dell'edificio)
• AP con segnale che fuoriesce eccessivamente dall'edificio (esfiltrazione radio)

War driving come audit legittimo: Gli amministratori usano le stesse tecniche per:

• Verificare il footprint del segnale (fino a dove arriva la rete wireless dell'azienda)
• Rilevare AP non autorizzati (rogue AP, evil twin)
• Controllare la cifratura di tutti gli AP visibili
• Verificare la potenza delle antenne (troppo alta = segnale in strada)

War flying: Stessa cosa ma da aereo o drone. Un drone con hardware WiFi può coprire interi campus aziendali in pochi minuti. Segnali 2.4 GHz sono intercettabili anche da 2.500 piedi di quota. Usato anche in pentesting per reconnaissance aerea (foto del sito + scan wireless).

Caso reale: 2010 — Google Street View. Le auto di Google, mentre fotografavano le strade per Street View, raccoglievano automaticamente: SSID di tutte le reti WiFi, MAC address degli AP, e in alcuni casi payload del traffico non cifrato di reti aperte. Google raccolse dati da 30+ paesi per anni. Multata in Germania, Francia, Australia, Canada. Google definì l'acquisizione dei payload un "errore" nel codice. Il caso definì il confine legale tra war driving passivo (SSID/MAC = ok in molti paesi) e cattura del traffico (illegale ovunque).

Cronologia Grafica

#

VPN e VPN Concentrator

#

mindmap
  root((VPN e
Concentrator))
    VPN concetto
      Tunnel cifrato rete pubblica
      Non e un protocollo
      IPsec TLS WireGuard L2TP
    Concentrator
      Hardware Cisco ASA
      NGFW integrato
      Software OpenVPN
      Cloud AWS Azure
    Tipologie
      Remote Access
        Host to gateway
        Utente avvia connessione
        RADIUS LDAP autenticazione
      Site-to-Site
        Gateway to gateway
        Trasparente agli utenti
        Always-on o on-demand
    Tunnel
      Split Tunnel
        Solo IP privati nel tunnel
        Internet via ISP diretto
      Full Tunnel
        Tutto il traffico cifrato
        UTM aziendale controlla tutto
    Altri protocolli
      L2TP no cifratura propria
      SSTP TLS porta 443
      HTML5 VPN Portal browser
      WireGuard moderno leggero

VPN (Virtual Private Network)

#

tunnel cifrato attraverso una rete pubblica (Internet) che permette l'accesso a una rete privata come se si fosse fisicamente connessi ad essa. Diventata infrastruttura standard da quando il lavoro da remoto è diffuso.

VPN non è un protocollo — è una tecnologia (o servizio di rete) che crea un canale cifrato e privato sopra una rete pubblica. È il concetto, non l'implementazione.

I protocolli che la realizzano sono quelli sottostanti:

• IPsec (con AH e ESP)
• SSL/TLS (OpenVPN, SSL VPN)
• WireGuard
• L2TP (spesso abbinato a IPsec)

Analogia da dev: è come "REST" — non è un protocollo, è un concetto architetturale. HTTP è il protocollo che lo implementa. La VPN è il concetto, IPsec o TLS sono i protocolli che la implementano.

Per Security+: quando una domanda chiede "quale protocollo usa la VPN site-to-site?" la risposta è IPsec. Quando chiede "quale VPN funziona meglio con NAT?" la risposta è SSL/TLS. La VPN in sé non è mai la risposta corretta a "quale protocollo".

VPN Concentrator

#

Il concentrator è un ruolo, non per forza un dispositivo fisico separato. Le implementazioni possibili:

Il client VPN installato sul laptop dell'utente è la controparte del concentrator: cifra il traffico in uscita e decifra quello in arrivo. La chiave di sessione è negoziata via IKE tra i due.

Remote Access VPN — flusso completo

#

Remote access VPN e Direct Access VPN sono termini usati in modo intercambiabile da Gibson. "Direct Access" in senso stretto è la feature Microsoft (Windows Server) che crea una VPN always-on automatica senza intervento dell'utente. Per l'esame Security+ sono sinonimi.

Flusso di connessione:

sequenceDiagram
    participant U as Utente remoto
    participant I as Internet (ISP)
    participant V as VPN Server (screened subnet)
    participant R as RADIUS server
    participant L as LDAP / Domain Controller
    participant INT as Rete interna

    U->>I: 1. Connessione broadband a internet
    U->>V: 2. Inizia connessione VPN (IP pubblico del VPN server)
    V->>R: 3. Invia credenziali utente a RADIUS
    R->>L: 4. RADIUS passa credenziali a LDAP per verifica
    L->>R: 5. LDAP conferma: credenziali valide
    R->>V: 6. RADIUS autorizza: accesso OK + policy
    V->>U: 7. Tunnel cifrato stabilito
    U->>INT: 8. Traffico privato dentro il tunnel

Posizionamento nella rete:

• Il VPN server è nella screened subnet (DMZ), raggiungibile dall'Internet con IP pubblico
• Il firewall esterno apre solo le porte VPN verso il VPN server (es. UDP 1194 per OpenVPN, UDP 51820 per WireGuard, TCP/UDP 443 per SSL VPN)
• Il VPN concentrator poi instrada il traffico privato attraverso il firewall interno verso la rete interna

RADIUS + LDAP — catena di autenticazione

#

RADIUS (Remote Authentication Dial-In User Service) è il protocollo AAA (Authentication, Authorization, Accounting) che gestisce l'autenticazione VPN. Il nome "Dial-In" è storico — negli anni '90 l'accesso remoto avveniva via modem (dial-up). Oggi: qualsiasi accesso remoto.

LDAP (Lightweight Directory Access Protocol) è il protocollo per accedere alle directory di utenti (Active Directory in ambienti Microsoft). È il backend dove vivono gli account utente e le password.

Come si dividono i ruoli:

Chiarimento importante: RADIUS fa sia autenticazione che autorizzazione — non solo una delle due. La distinzione è che RADIUS è il protocollo di accesso alla rete, mentre LDAP è il database degli utenti. RADIUS delega la verifica delle credenziali a LDAP, ma poi prende lui la decisione di accesso.

Site-to-Site VPN

#

HQ e Remote Office si parlano perché i loro gateway hanno ciascuno un VPN server che mantiene il tunnel tra le due reti. Gli utenti del remote office accedono ai server dell'HQ come se fossero in ufficio — la VPN è trasparente per loro, non devono fare nulla.

Gibson distingue due modelli:

Il vantaggio del site-to-site: nessun client VPN da installare, nessuna azione richiesta all'utente. Il tunnel esiste sempre (o si attiva on-demand) tra i due gateway, e tutti i client dietro di loro ne beneficiano automaticamente.

Always-On VPN

#

Alcune VPN sono always-on — il tunnel è mantenuto continuamente invece di essere stabilito solo quando serve.

In un contesto site-to-site: i due gateway mantengono il tunnel attivo 24/7. L'alternativa è la connessione on-demand: il tunnel si apre solo quando un utente prova a raggiungere una risorsa remota, e si chiude dopo un periodo di inattività.

In un contesto direct access (utente remoto):

• Il dispositivo tenta di connettersi al VPN aziendale non appena ha una connessione Internet
• PC di casa: VPN attiva subito all'avvio
• Smartphone: se l'utente entra in un coffee shop e si connette al Wi-Fi pubblico → il telefono si connette automaticamente alla VPN aziendale prima ancora che l'utente apra un'app

Questo garantisce che tutto il traffico del dispositivo passi sempre sotto il controllo dell'azienda (UTM, URL filter, malware scan) — indipendentemente dalla rete su cui si trova l'utente.

L2TP — Layer 2 Tunneling Protocol

#

L2TP (Layer 2 Tunneling Protocol) è un protocollo di tunneling che opera a Layer 2 (data link) invece che a Layer 3 come IPsec. La versione corrente è L2TPv3.

Il punto critico: L2TP non cifra nulla.

L2TP crea il tunnel (il "tubo") ma non mette nessun lucchetto. Da solo è inutilizzabile per una VPN sicura. Per questo viene sempre abbinato a IPsec:

L2TP/IPsec:
  ┌─────────────────────────────────────┐
  │  IPsec (ESP)  ← cifratura/integrità │
  │    ┌──────────────────────────┐     │
  │    │  L2TP  ← transport/tunnel│     │
  │    │    ┌───────────┐         │     │
  │    │    │  Payload  │         │     │
  │    │    └───────────┘         │     │
  │    └──────────────────────────┘     │
  └─────────────────────────────────────┘

Analogia dev: L2TP è come TCP (trasporta i dati), IPsec è come TLS (li cifra). L2TP/IPsec = TCP + TLS, dove i due livelli fanno cose diverse ma complementari.

Perché esiste L2TP se non cifra? Perché il tunneling e la cifratura sono preoccupazioni separate. L2TP permette di trasportare frame Layer 2 (Ethernet) su reti IP — utile per connettere due LAN a Layer 2 come se fossero sulla stessa rete fisica. IPsec poi si occupa della sicurezza.

HTML5 VPN Portal

#

Alcuni dispositivi di rete supportano un HTML5 VPN portal: accesso VPN direttamente via browser, senza installare alcun client.

Come funziona: l'organizzazione espone una pagina web aziendale (es. vpn.company.com), il dipendente/consulente si autentica con le credenziali AD, e il browser diventa un client per raggiungere risorse interne (server interni, PBX VoIP, applicazioni gestionali). Non per navigare su internet — per entrare nella rete privata aziendale.

Limitazione principale: è resource-intensive sul server. Il server deve gestire la sessione TLS per ogni utente, fare il proxying del traffico, e tutto il lavoro che normalmente il client VPN distribuisce lato utente. Per questo non si usa per tutta l'organizzazione.

Caso d'uso tipico: accesso occasionale per utenti limitati.

Gibson fa l'esempio di un consulente esterno che gestisce il centralino VoIP (PBX) aziendale: l'organizzazione gli dà accesso via HTML5 VPN portal solo a quella risorsa. I dipendenti normali usano la VPN tradizionale.

Come dev: è come un reverse proxy web applicativo che espone risorse interne via HTTPS — invece di un tunnel di rete vero e proprio, il browser proxia le richieste attraverso il server.

NAC — Network Access Control

#

mindmap
  root((NAC
Network
Access Control))
    Scopo
      Ispeziona salute client
      Antivirus aggiornato
      Patch OS correnti
      Firewall abilitato
    Flusso
      Client tenta connessione
      NAC Health Server verifica
      Salute OK accesso rete
      Salute KO quarantena
      Remediation e riprova
    Agent
      Permanent agent sempre
      Dissolvable agent elimina
      Agentless scansione remota
    Uso
      VPN remote access
      Client interni rete
      Visitatori wall jack
      BYOD WiFi aziendale
    FP in NAC
      Client sano in quarantena
      Non puo lavorare
      Tuning critico

Un utente infetto che si connette alla VPN porta il malware dentro la rete privata, dove può diffondersi lateralmente a tutti gli altri host. NAC è la soluzione a questo scenario.

NAC (Network Access Control) fornisce monitoraggio continuo della sicurezza: ispeziona il client prima (e durante) la connessione e lo blocca — o lo isola — se non soddisfa i requisiti di salute predefiniti.

Il problema che NAC risolve

#

Gli amministratori controllano completamente i computer aziendali: possono imporre antivirus aggiornato, patch OS correnti, firewall abilitato. Ma non controllano i dispositivi personali degli utenti che lavorano da casa o in viaggio. NAC porta un livello di controllo anche su questi dispositivi.

I controlli NAC sono controlli tecnici (automatizzati, verificati da software) che applicano policy amministrative (le regole scritte dall'admin: "tutti i client devono avere antivirus versione X e patch del mese Y"). Non sono solo policy su carta — sono enforcement automatico.

Flusso NAC + VPN

#

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart TD
    C["Client VPN"] -->|"1. Tenta connessione"| V["VPN Server"]
    V -->|"2. Chiede requisiti di salute"| N["NAC Health Server"]
    N -->|"3. Risponde con requisiti minimi"| V
    V -->|"4. Chiede statement of health"| C
    C -->|"5. Agent riporta stato salute"| V
    V --> D{Salute OK?}
    D -->|Si| NET["Rete interna - accesso completo"]
    D -->|No| Q["Quarantine Network"]
    Q --> FIX["Remediation: patch, antivirus, signatures"]
    FIX -->|"Riprova dopo aggiornamento"| C

La quarantine network è brillante: non lascia l'utente bloccato senza spiegazioni — gli fornisce esattamente le risorse per rimettersi a posto (patch server, antivirus update server), e poi lo fa riprovare. NAC mantiene il client in buona salute nel tempo, non solo al primo accesso.

NAC non è solo per VPN — anche per client interni

#

NAC può ispezionare anche i computer già dentro la rete:

• Un PC interno che ha saltato un giro di patch → rilevato → quarantena
• Un visitatore che collega il laptop a una wall jack libera → NAC ispeziona → se non passa, accesso solo a Internet (isolato dalla rete interna)
• Dipendente con portatile personale su Wi-Fi aziendale → stessa logica

Agent vs Agentless NAC

#

NAC usa agenti (health agent / authentication agent) per raccogliere lo stato di salute del client. Esistono tre modalità:

IPsec e Tunneling Protocol

#

mindmap
  root((IPsec e
Tunneling))
    Modalita IPsec
      Tunnel Mode VPN
        Cifra header e payload
        IP interni nascosti
        Nuovo header esterno
      Transport Mode LAN
        Cifra solo payload
        Header visibili
        Host-to-host privato
    Sotto-protocolli
      AH IP proto 51
        Autenticazione e integrita
        No confidenzialita
      ESP IP proto 50
        Confidenzialita
        Autenticazione integrita
        Cifra il payload
      IKE UDP 500
        Negozia chiavi
        Security Associations
        ECDH per chiavi cifra
    WireGuard vs IPsec
      WireGuard scelto
        4000 righe codice
        ChaCha20 Poly1305
        UDP 51820
      IPsec imposto
        Standard enterprise
        400k righe
        Massima interoperabilita
    SSL TLS VPN
      SSTP porta 443
      Attraversa NAT
      OpenVPN open source
      Flessibile autenticazione

IPsec — Tunnel Mode vs Transport Mode

#

IPsec (Internet Protocol Security) cifra i dati in transito operando a livello IP (Layer 3). Supporta due modalità:

IPsec è uno standard — una suite di protocolli (IKE + ESP + AH). Non è software, è una specifica RFC. Il kernel Linux capisce ESP e AH nativamente, ma qualcuno deve gestire la negoziazione IKE: scambiare chiavi, creare le SA, autenticarsi.

Tunnel Mode — cifra l'intero pacchetto IP, inclusi payload e header. Le VPN usano comunemente Tunnel Mode. Gli header del pacchetto contengono gli indirizzi IP (e MAC). Il beneficio: gli IP della rete interna sono cifrati e invisibili a chi intercetta il traffico. Se un attaccante intercetta il traffico, vede l'IP sorgente del client e l'IP del VPN server, ma l'IP addressing interno rimane nascosto.

Transport Mode — cifra solo il payload, non gli header. Viene usato comunemente nelle reti private, non nelle VPN. Se il traffico transita e viene usato solo all'interno di una rete privata, non c'è bisogno di nascondere gli IP cifrandoli — sono già al sicuro dietro il firewall.

flowchart LR
    subgraph TUN["Tunnel Mode — VPN"]
        A1["Header IP originale
(IP sorgente + destinazione)"] --> E1["CIFRATO — invisibile
all'intercettatore"]
        B1["Payload"] --> E1
        C1["Nuovo header IP esterno
(client → VPN server)"] --> V1["Visibile"]
    end
    subgraph TRA["Transport Mode — Host-to-Host"]
        A2["Header IP
(IP sorgente + destinazione)"] --> V2["Visibile"]
        B2["Payload"] --> E2["CIFRATO"]
    end

Perché non si usa sempre Tunnel Mode? Tunnel Mode aggiunge un nuovo header IP esterno e cifra l'intero pacchetto originale → overhead maggiore (più byte per pacchetto, più CPU per cifrare/decifrare). Per comunicazioni host-to-host interne dove gli endpoint si fidano già della rete, Transport Mode è più efficiente senza perdere sicurezza sul contenuto. Regola pratica: Tunnel Mode su reti non fidate (Internet), Transport Mode su reti già protette (LAN interna).

Come funziona l'encapsulation in Tunnel Mode

Il pacchetto originale (IP header + data) non può viaggiare su Internet in chiaro. In Tunnel Mode, il processo è:

[IP header originale] [Data]
         ↓  cifra tutto
[Nuovo IP header] [IPsec header] [IP header cifrato + Data cifrata] [IPsec trailer]

1. IP header originale + data → vengono cifrati insieme (ESP)
2. IPsec header e IPsec trailer → wrappano il contenuto cifrato, indicano dove inizia/finisce il payload IPsec
3. Nuovo IP header esterno → contiene IP sorgente del client e IP del VPN concentrator — è l'unica cosa visibile ai router lungo il percorso

Il pacchetto diventa più grande del originale — questo è l'overhead del tunnel. I router Internet vedono solo il nuovo header esterno e instradano verso il concentrator. Arrivato al concentrator: rimuove il nuovo IP header, IPsec header e trailer, decifra, e manda in chiaro il pacchetto originale alla rete interna.

La chiave di cifratura — IKE, non RADIUS

RADIUS si occupa di chi sei (autenticazione utente). La chiave di cifratura del tunnel è una cosa separata, negoziata tramite IKE (Internet Key Exchange, UDP 500): un handshake tra client e concentrator che genera una chiave simmetrica di sessione. Ogni sessione ha la sua chiave, generata al volo — il concentrator la tiene in memoria per quella sessione, il client la tiene nel client VPN. RADIUS non tocca mai questa chiave.

Perché Transport Mode compare qui: Gibson lo introduce per contrasto con Tunnel Mode. Nell'esame può comparire la domanda "quale modalità IPsec usano le VPN?" → Tunnel. "Quale non cifra gli header?" → Transport.

IPsec non vive dentro la VPN — IPsec può essere la VPN stessa.

VPN è un concetto (tunnel sicuro su rete pubblica). IPsec è uno dei protocolli che lo implementa:

VPN = concetto
       ↑
       implementato da uno di questi protocolli:
       ├── IPsec Tunnel Mode   ← il più comune in enterprise
       ├── TLS/SSTP            ← porta 443, attraversa NAT
       ├── WireGuard           ← moderno, leggero
       └── OpenVPN             ← open source, flessibile

Quando dici "VPN IPsec" stai dicendo "VPN costruita usando IPsec come protocollo di tunneling". IPsec è la VPN, non vive dentro di essa.

Esempi concreti:

• Sei a casa e ti connetti alla rete aziendale → VPN (usa IPsec Tunnel Mode o TLS) — devi nascondere gli IP interni e attraversare Internet
• Il web server aziendale parla con il database server sulla stessa rete interna in modo cifrato → IPsec Transport Mode — nessuna VPN, stessa rete, non serve nascondere gli IP

Analogia: VPN è come dire "voglio una comunicazione sicura". IPsec è uno dei linguaggi con cui la costruisci — come HTTPS è HTTP costruito sopra TLS.

IPsec — AH e ESP

#

IPsec fornisce sicurezza tramite due sotto-protocolli:

IP Protocol number — non è una porta:

Le porte (0–65535) identificano servizi TCP/UDP: TCP 443 = HTTPS, UDP 53 = DNS. Gli IP Protocol number operano a un livello più basso — identificano il tipo di protocollo nel campo Protocol dell'header IP, prima ancora di TCP/UDP:

AH ed ESP non sono applicazioni TCP/UDP — sono protocolli IP diretti, come ICMP. Un firewall li riconosce guardando il campo Protocol nell'header IP, non una porta. I packet filter usano questi numeri per permettere o bloccare traffico IPsec.

IKE (Internet Key Exchange) — negoziazione delle chiavi IPsec:

• Porta: UDP 500
• Funzione: autentica i due host che avviano la sessione IPsec e crea le Security Associations (SA) — accordi su algoritmi di cifratura, chiavi, durata della sessione
• È l'unico componente IPsec che usa una porta tradizionale (UDP 500)

PSK vs chiavi di cifratura — due cose separate:

Il PSK (Pre-Shared Key) è usato solo per autenticazione durante IKE — dimostrare "sono io, conosco il segreto". Non viene usato per cifrare il traffico ESP.

Le chiavi di cifratura vengono da ECDH (Elliptic Curve Diffie-Hellman): entrambi gli host generano coppie di chiavi temporanee, si scambiano le pubbliche, e derivano la stessa chiave condivisa senza mai trasmetterla sul cavo.

IKE_SA_INIT → ECDH: entrambi calcolano chiave condivisa (mai sul cavo)
IKE_AUTH    → PSK:  "sono io" — firma un messaggio col segreto condiviso
ESP         → chiavi derivate da ECDH, il PSK non entra più

È come la parola "Fidelio" in Eyes Wide Shut — ti apre la porta, dimostra che appartieni. Ma quello che succede dentro la stanza è separato dalla parola. Per questo il PSK deve essere forte: se qualcuno lo indovina, può impersonare un host — ma non può decifrare traffico già catturato perché le chiavi ESP vengono da ECDH.

Stessa logica in WPA2/WPA3: la password WiFi è un PSK — autentica il dispositivo ma non deriva le chiavi di sessione direttamente. Le chiavi vengono dal 4-way handshake (WPA2) o da SAE (WPA3).

SSL/TLS come Tunneling Protocol

#

SSL VPN per remote access — tre modalità di client

Always-on SSL VPN — configurazione in cui il tunnel si stabilisce automaticamente all'avvio del dispositivo. Tutto il traffico è sempre cifrato, senza azione richiesta all'utente. Usato in ambienti ad alta sicurezza o con policy di zero trust.

Flessibilità di autenticazione SSL VPN — a differenza di IPsec che spesso richiede configurazioni rigide, SSL VPN non forza un tipo specifico di credenziale. Si può usare: username/password, certificati digitali, shared secret, o combinazioni (es. password + OTP). Questa flessibilità è uno dei motivi per cui SSL VPN è preferito per il remote access degli utenti finali.

SSTP — Secure Socket Tunneling Protocol:

• Cifra il traffico VPN tramite TLS su porta 443
• Porta 443 = stessa porta di HTTPS → attraversa quasi tutti i firewall e NAT senza configurazione aggiuntiva
• Utile quando IPsec non è praticabile (es. reti con NAT aggressivo o firewall che bloccano UDP 500/50/51)
• Sviluppato da Microsoft, integrato in Windows

SSL vs TLS nel nome SSTP: Il nome dice "SSL" perché fu progettato quando SSL era il termine dominante (Windows Vista, 2007). Oggi SSTP usa TLS — SSL è deprecato dal 2015. È lo stesso fenomeno di "certificati SSL" (che sono TLS) e OpenSSL (libreria TLS). Per l'esame: nome dice SSL, funziona con TLS.

OpenVPN e OpenConnect:

• Applicazioni open-source che usano TLS per creare il canale sicuro
• OpenVPN: porta configurabile, spesso UDP 1194 o TCP/UDP 443
• OpenConnect: compatibile con Cisco AnyConnect, usa TLS/DTLS

IPsec vs TLS/SSL — confronto per l'esame:

IPsec vs WireGuard — quando usare quale

#

IPsec è una suite definita da RFC negli anni '90: AH + ESP + IKE. Negozia la sessione tramite IKE (UDP 500), usa IP protocol number 50/51 (non porte TCP/UDP), ha due modalità (tunnel/transport), ed è implementato in praticamente ogni stack di rete enterprise. Complessità alta, interoperabilità massima.

WireGuard (2016, Jason Donenfeld) ha una crypto stack propria completamente diversa:

• ChaCha20 — cifratura
• Poly1305 — autenticazione/integrità
• Curve25519 — key exchange
• BLAKE2 — hashing

Nessun IKE, nessun AH, nessun ESP. Porta UDP 51820. Gira come modulo kernel Linux (~4.000 righe di codice vs ~400.000 di IPsec). Non negozia algoritmi — la crypto è fissa, non configurabile.

Entrambi sono VPN protocols — il calderone corretto. Ma sono implementazioni indipendenti: un endpoint IPsec non parla WireGuard e viceversa.

Usa IPsec quando:

• L'altro endpoint è un router/firewall enterprise (Cisco ASA, Palo Alto, FortiGate, pfSense) — parlano IPsec per default
• Stai configurando un site-to-site VPN tra sedi aziendali con hardware diverso
• Il cloud VPN gateway (AWS, Azure) richiede IPsec per la connessione on-premise
• La compliance lo richiede esplicitamente (alcuni framework specificano IPsec)
• Non controlli l'altro endpoint — il vendor ha già deciso

Usa WireGuard quando:

• Controlli entrambi gli endpoint (lab, DevSecOps, accesso admin)
• Remote access VPN per sviluppatori o admin
• Ambienti cloud-native Linux
• Vuoi semplicità: config in 10 righe, chiave pubblica, fatto
• Performance è critica (gaming, video, IoT)

La regola pratica:

WireGuard è quello che scegli quando puoi scegliere. IPsec è quello che usi quando l'altra parte l'ha già deciso.

Split Tunnel vs Full Tunnel

#

Dipende dalla configurazione del tunnel.

Split Tunnel — l'amministratore VPN definisce quale traffico usa il tunnel cifrato. Solo il traffico verso gli IP privati dell'azienda passa nel tunnel. Il resto va direttamente a Internet via ISP.

flowchart LR
    L["Lisa (casa)"] -->|"Traffico verso 10.0.0.x
— cifrato nel tunnel"| V["VPN Server aziendale"]
    L -->|"Traffico verso google.com
— diretto via ISP"| I["Internet"]

• Ricerca Google di Lisa → ISP → Google (tunnel bypassato)
• Accesso al server interno → tunnel cifrato → rete aziendale

Full Tunnel — tutto il traffico passa nel tunnel mentre l'utente è connesso alla VPN. Anche la navigazione pubblica transita attraverso il VPN server aziendale.

flowchart LR
    L["Lisa (casa)"] -->|"TUTTO il traffico
cifrato nel tunnel"| V["VPN Server aziendale"]
    V --> U["UTM aziendale
(URL filter, malware scan,
content inspection)"]
    U --> I["Internet / Google"]
    I --> U
    U --> V
    V -->|"risposta cifrata
nel tunnel"| L

• Ricerca Google di Lisa → tunnel → VPN server → UTM → Google → UTM → VPN server → tunnel → Lisa
• Il sito vede l'IP dell'azienda, non l'IP di casa di Lisa

UTM (Unified Threat Management) — dispositivo all-in-one che combina: firewall + IPS + antivirus + URL filtering + content inspection + ispezione malware. Con il full tunnel, tutto il traffico internet degli utenti remoti passa attraverso i controlli di sicurezza aziendali — come se fossero fisicamente in ufficio.

Confronto:

IPsec — scenari di utilizzo (non solo company-to-company):

IPsec non è limitato alle connessioni azienda-azienda — è lo stesso protocollo usato sia per collegare sedi tra loro sia per i singoli utenti remoti.

Autenticazione Remota — PAP, CHAP, RADIUS, TACACS+

#

mindmap
  root((Remote
Auth))
    PAP
      Password in cleartext
      PPP dial-up
      Vulnerabile sniffing
      Non usare mai
    CHAP
      Challenge Handshake
      Nonce usa e getta
      Hash shared secret
      Mai password in chiaro
      Replay resistente
    RADIUS
      Centralizzato multi-server
      UDP best effort
      Cifra solo password default
      Con EAP cifra sessione
      VPN e 802.1X
    TACACS+
      Cisco proprietario
      TCP guaranteed
      Cifra intera sessione
      Kerberos compatibile
      Dispositivi di rete
    AAA
      Authentication chi sei
      Authorization cosa puoi fare
      Accounting log attivita
      RADIUS completo
      TACACS+ completo
      Kerberos no accounting

Un passaggio fondamentale nell'implementazione di una VPN è garantire che solo le entità autorizzate possano accedervi. L'autorizzazione inizia con l'autenticazione — e le VPN supportano diversi metodi.

PAP — Password Authentication Protocol

#

PAP (Password Authentication Protocol) viene usato con PPP (Point-to-Point Protocol) per autenticare i client.

Il problema critico: PAP invia la password in chiaro sulla rete.

PPP nacque per le connessioni dial-up (modem, anni '90). In quel contesto, l'intercettazione di una linea telefonica era considerata remota — la sicurezza era un ripensamento. Oggi PPP + PAP si usa solo come ultima risorsa, o abbinato a un protocollo che fornisce cifratura.

CHAP — Challenge Handshake Authentication Protocol

#

CHAP (Challenge Handshake Authentication Protocol) usa anch'esso PPP ma è molto più sicuro di PAP. L'obiettivo è permettere al client di autenticarsi su una rete pubblica senza mai inviare la password in chiaro.

Come funziona:

sequenceDiagram
    participant C as Client
    participant S as Server

    S->>C: 1. Challenge (nonce — numero usato una sola volta)
    C->>C: 2. Hash(shared_secret + nonce)
    C->>S: 3. Invia l'hash (MAI la password)
    S->>S: 4. Calcola lo stesso hash indipendentemente
    S->>C: 5. Confronta — se coincide: autenticato

• Client e server condividono un shared secret (come una password) — ma non viene mai trasmesso
• Il server invia un nonce (challenge) — numero casuale usa-e-getta
• Il client calcola hash(shared_secret + nonce) e invia solo l'hash
• Il server fa lo stesso calcolo e confronta — se coincide, il client è autenticato

Protezione contro replay attack: anche se un attaccante intercetta l'hash, non può riusarlo — il nonce cambia ad ogni sessione. CHAP ripete questo handshake periodicamente durante la connessione, non solo all'inizio.

Gancio mnemonico — Bitcoin: il nonce di CHAP e il nonce di Bitcoin sono lo stesso principio: un numero usato una volta sola per rendere irripetibile una risposta. In Bitcoin i miner cercano un nonce che produca un hash con un certo numero di zeri iniziali (proof-of-work). In CHAP il server genera un nonce casuale e il client dimostra di conoscere la password producendo un hash di nonce + password. Contesti diversi, stesso scopo: il nonce rende ogni risposta unica e non riusabile.

Analogia dev: è lo stesso principio di HMAC-based authentication — non si invia mai il segreto, si invia la prova che lo si conosce.

RADIUS — Autenticazione Centralizzata

#

Il problema che RADIUS risolve:

Immagina un'azienda con sedi a Virginia Beach, Atlanta e Chicago — ciascuna con il proprio VPN server. Bart è un agente di vendita che si connette da qualsiasi sede. Se ogni VPN server ha il proprio database utenti, quando Bart cambia password devono aggiornarla su tutti e tre i server — labor-intensive, fonte di errori.

La soluzione: un RADIUS server centralizzato.

Ogni VPN server è configurato con uno shared secret che corrisponde al RADIUS server. Quando un utente tenta di autenticarsi, il VPN server inoltra la richiesta al RADIUS server — non gestisce l'autenticazione da solo.

flowchart LR
    B["Bart\n(client VPN)"] --> VA["VPN Server\nVirginia Beach"]
    B --> AT["VPN Server\nAtlanta"]
    B --> CH["VPN Server\nChicago"]
    VA -->|shared secret| R["RADIUS Server\n(centralizzato)"]
    AT -->|shared secret| R
    CH -->|shared secret| R
    R -->|verifica credenziali| L["LDAP / Domain Controller\n(Active Directory)"]

Caratteristiche tecniche di RADIUS:

RADIUS + LDAP: è più comune che il RADIUS server non abbia un database utenti proprio, ma acceda a un LDAP server (es. Active Directory Domain Controller). Bart ha un solo account — quando cambia la password, il DC la aggiorna una volta sola.

TACACS+ — Alternativa a RADIUS

#

TACACS+ (Terminal Access Controller Access-Control System Plus) è un'alternativa a RADIUS sviluppata da Cisco. Offre due vantaggi di sicurezza significativi:

Caso d'uso specifico di TACACS+: autenticazione per accedere ai dispositivi di rete (router, switch). Un amministratore che vuole accedere alla pagina di configurazione di un router deve autenticarsi — TACACS+ può gestire questa autenticazione. I dispositivi di rete devono essere TACACS+-enabled.

TACACS+ + Kerberos: poiché Microsoft Active Directory usa Kerberos per l'autenticazione, TACACS+ permette a un VPN concentrator Cisco di integrarsi in un ambiente AD.

AAA — Authentication, Authorization, Accounting

#

AAA è la triade dei servizi di controllo accessi:

Protocolli AAA completi:

• RADIUS — authentication + authorization + accounting ✓
• TACACS+ — authentication + authorization + accounting ✓
• Diameter — evoluzione di RADIUS, stessi tre servizi ✓

Kerberos — caso speciale: Kerberos è spesso citato come AAA, ma non fornisce accounting da solo. Può interfacciarsi con sistemi di accounting esterni, ma da solo copre solo authentication e authorization.

Gibson — Obiettivi Esame Capitolo 4

#

Riepilogo ufficiale Gibson degli obiettivi Security+ SY0-701 del capitolo 4.

IDS e IPS

• IDS/IPS ispezionano il traffico per rilevare e rispondere alle minacce
• HIDS rileva attacchi su sistemi locali (workstation, server) — può rilevare malware che l'antivirus non individua
• NIDS monitora l'intera rete tramite sensori e console centrali
• Signature-based: confronta contro firme di attacchi noti
• Trend-based (anomaly): usa una baseline, rileva deviazioni — include zero-day
• False positive = alert inviato quando non c'è attacco — False negative = nessun alert quando c'è un attacco
• IPS è in-line, monitora e blocca attivamente; IDS è out-of-band, passivo
• IDS/IPS usati anche su reti private interne come SCADA

Honeypot e Deception

• Honeypot/honeynet distrae gli attaccanti dalla rete reale e permette di osservare le metodologie
• Honeyfile = file con nome attraente per rilevare esplorazione attiva
• Honeytoken = record falso in un database per rilevare furto di dati

Sicurezza Wireless

• Disabilitare SSID broadcast nasconde la rete agli utenti casuali (non sicurezza reale)
• MAC filtering limita l'accesso — ma gli attaccanti possono scoprire i MAC autorizzati e spoofing
• Site survey identifica problemi; wireless footprinting usa heat map per diagramma AP/dead spot
• WPA2 usa CCMP/AES; supporta open, PSK, Enterprise
• Enterprise mode più sicura di Personal: aggiunge autenticazione 802.1X individuale
• WPA3 usa SAE al posto di PSK; supporta enhanced open, SAE, Enterprise
• Open mode = no PSK, no 802.1X; WPA3 enhanced open cifra anche senza password
• 802.1X = port-based NAC; blocca dispositivi non autorizzati
• EAP varianti: PEAP, EAP-FAST, EAP-TLS, EAP-TTLS
• EAP-TLS = più sicuro — certificato su server E su ogni client
• PEAP usa MS-CHAPv2; EAP-TTLS permette protocolli legacy (PAP) dentro tunnel TLS

Attacchi Wireless

• Disassociation attack: rimuove un client forzandolo a riautenticarsi (management frames non autenticati)
• WPS attack: PIN a 8 cifre → crack in ~11.000 tentativi → bypass WPA/WPA2
• Rogue AP: AP non autorizzato; Evil Twin: rogue AP con stesso SSID dell'AP legittimo
• Jamming: interferenza che blocca la frequenza wireless (Layer 1 DoS)
• IV attack: sfrutta il riutilizzo del vettore di inizializzazione in WEP → passphrase decifrabile
• Wireless replay attack: cattura dati, li modifica, impersona una delle parti
• NFC attacks: lettura dati da dispositivi mobili a corto raggio
• RFID attacks: eavesdropping, replay, DoS su tag RFID
• War driving: ricerca di reti wireless vulnerabili da veicoli o aerei

VPN e Accesso Remoto

• VPN fornisce accesso a reti private tramite rete pubblica
• IPsec: Tunnel Mode cifra l'intero pacchetto IP (VPN); Transport Mode cifra solo il payload (rete privata)
• ESP (IP proto 50): confidenzialità + integrità + autenticazione
• Full tunnel: tutto il traffico cifrato nel tunnel; Split tunnel: solo traffico privato nel tunnel
• Site-to-site VPN: due reti collegate — on-demand o always-on
• Altri protocolli VPN: TLS (SSTP), L2TP (no cifratura propria), HTML5 VPN Portal (browser-based, resource-intensive)

NAC — Network Access Control

• Permanent agent: installato e rimane sul client
• Dissolvable agent: scaricato, eseguito, eliminato dopo la sessione
• Agentless: scansione remota senza installare codice
• NAC usato sia per client VPN che per client interni

Autenticazione Remota

• PAP: usa password/PIN — invia in cleartext → vulnerabile allo sniffing
• CHAP: più sicuro di PAP — usa handshake con challenge/nonce, non invia la password in chiaro
• RADIUS: autenticazione centralizzata per VPN server multipli — UDP, cifra solo la password di default, può usare EAP per sessioni cifrate
• TACACS+ (Cisco): alternativa a RADIUS — TCP, cifra l'intera sessione, usabile con Kerberos
• Protocolli AAA completi: RADIUS, TACACS+, Diameter — Kerberos NON ha accounting nativo

Collegato a

#

• glossario-cyber — IDS/IPS, honeypot, wireless attacks, VPN, NAC, IPsec, PAP, CHAP, RADIUS, TACACS+, AAA
• cap-03-security-architecture — firewall, DMZ, screened subnet, architettura di rete
• cap-02-identity-access-management — autenticazione, RADIUS, Kerberos, controlli di accesso
• network — protocolli di rete, Layer OSI, TCP/IP
• indice-gibson-messer-burning-Ice — indice completo del libro