Architettura difensiva e configurazione di hardening

Distribuzione WPA3 e Prevenzione del Downgrade

WPA3-Personal in modalità transizione espone una vulnerabilità critica: pubblicizza contemporaneamente SAE e WPA2-PSK, permettendo ai client di connettersi tramite il handshake più debole. La configurazione deve imporre PMF e restringere la finestra di downgrade.

# hostapd.conf — modalità transizione WPA3-Personal con controlli downgrade
interface=wlan0
ssid=CorpSecure
wpa=2
wpa_key_mgmt=SAE WPA-PSK
wpa_passphrase=legacy_for_transitional_clients_only
sae_password=high_entropy_sae_pmkid_resistant
ieee80211w=2              # 1=opzionale, 2=obbligatorio — obbligatorio blocca client solo-WPA2
sae_require_mfp=1
sae_pwe=2                 # hunting-and-pecking + hash-to-element, mitiga leak di timing

Valore `ieee80211w`	Effetto	Rischio downgrade
0	Disabilitato	Client capaci di PMF possono omettere protezione; deauth banale possibile
1	Opzionale	Client negozia per-associazione; attaccante forza "no PMF"
2	Obbligatorio	Rifiuta associazioni non-PMF; interrompe intenzionalmente client più vecchi

Cosa fa: sae_pwe=2 abilita entrambi i metodi di derivazione PWE secondo la revisione delle specifiche WPA3, chiudendo attacchi side-channel di timing contro sae_pwe=0 (solo hunting-and-pecking). Quando usarlo: Tutte le nuove distribuzioni WPA3; modalità transizione solo durante l'inventario e la sostituzione dei client legacy. Rischi: ieee80211w=2 rifiuterà connessioni da client con implementazioni PMF difettose (alcune skin vendor Android 9, firmware Intel 7260 più vecchi). Output atteso: hostapd -dd mostra RSN: PMF required nelle risposte di associazione; i client rifiutati loggano STA refused due to PMF policy.

Verifica che PMF sia effettivamente imposto, non solo configurato:

# Laboratorio: Cattura risposta di associazione per confermare campo capability PMF
tshark -i wlan0mon -Y "wlan.fc.type_subtype==0x01" -T fields \
  -e wlan.rsn.capabilities.pmf -e wlan.tag.rsn.akm.suites

# Produzione: Audit passivo delle associazioni correnti
iw dev wlan0 station dump | grep -E "station|capability"

Interpretazione realistica dell'output:

aa:bb:cc:dd:ee:ff
    station capab: 0x3          # bit 0x2 = PMF capable, bit 0x1 = PMF required
f0:de:f1:2a:3b:4c
    station capab: 0x1          # Dichiara capable ma non requiring — auditare questo client

Il valore 0x1 per il secondo client merita un'indagine: accetterà associazioni senza PMF se l'AP pubblicizza modalità opzionale. La modalità transizione con ieee80211w=1 è esattamente ciò che un AP evil twin utilizza per catturare handshake WPA2.

Selezione del Metodo EAP Enterprise

L'ordine di caricamento dei moduli EAP RADIUS determina quali metodi sono offerti ai supplicanti. I metodi deboli devono essere rimossi esplicitamente, non semplicemente deprioritizzati.

# /etc/freeradius/3.0/mods-enabled/eap — disabilita tutto tranne TLS-based
eap {
    default_eap_type = tls
    tls-config tls-common {
        private_key_file = /etc/freeradius/3.0/certs/server.key
        certificate_file = /etc/freeradius/3.0/certs/server.pem
        ca_file = /etc/freeradius/3.0/certs/ca.pem
        dh_file = ${certdir}/dh
        verify {
            skip_if_ocsp = no
        }
    }
    # Disabilita esplicitamente: peap, ttls, md5, leap, pwd, gtc
    # Non commentare — rimuovi o imposta 'disable = yes'
}

Metodo	Auth reciproca	Channel binding	Rischio downgrade	Verdetto
EAP-TLS	Sì (cert+privkey)	Nativo via TLS	Nessuno	Baseline per reti ad alta garanzia
PEAP-EAP-TLS	Sì	TLS annidato + inner TLS	La fase PEAP permette fallback MSCHAPv2 se malconfigurato	Solo se supplicant blocca metodo inner
EAP-TTLS	Solo cert server	Optional inner	I metodi inner PAP/CHAP/MSCHAPv2 sono esca per raccolta credenziali	Evitare — complessità senza guadagno di sicurezza
PEAP-MSCHAPv2	Solo cert server	No	Credential relay banale con Responder o Hostapd-WPE	Deprecato; equivalente a testo in chiaro per attaccante motivato

Cosa fa: skip_if_ocsp = no forza OCSP stapling o verifica OCSP diretta; una risposta mancante fallisce l'autenticazione invece di continuare silenziosamente. Quando usarlo: L'automazione del ciclo di vita dei certificati è operativa (OCSP responder raggiungibile, CRL distribution points validi). Rischi: I responder OCSP diventano single point of failure; monitorare con openssl ocsp -url $responder -issuer ca.pem -cert client.pem.

Variante produzione per validazione certificati senza dipendenza OCSP:

# Più sicuro: controllo CRL con caching locale
crl_file = /etc/freeradius/3.0/certs/crl.pem
check_crl = yes
check_all_crl = yes

Il pinning lato supplicant previene proxy RADIUS evil twin:

# wpa_supplicant.conf — blocco network con CA pinning e controllo nome server
network={
    ssid="CorpSecure-EAP"
    key_mgmt=WPA-EAP
    eap=TLS
    identity="[email protected]"
    ca_cert="/etc/certs/corp-ca.pem"
    subject_match="/CN=radius01.corp.example"
    # Blocca qualsiasi server che presenti CN diverso o catena CA non trusted
    altsubject_match="DNS:radius01.corp.example;DNS:radius02.corp.example"
}

Abilitazione 802.11w (PMF/MFP) e Realtà dei Client

La documentazione vendor dichiara supporto PMF; il comportamento effettivo diverge. Il caso Windows 10/Surface Pro—netsh wlan show profiles riporta supporto PMF, ma l'associazione fallisce quando PMF è obbligatorio—indica un fallimento di negoziazione a livello driver nonostante la capacità OS pubblicizzata.

Piattaforma client	PMF pubblicizzato	PMF required funzionale	Note
Windows 10/11 (Intel AX200+)	Sì	Sì	Dipendente dal driver; PROSet 22.x richiesto
Windows 10 (Surface Pro 2017, Marvell)	Sì	No	OS dichiara supporto, driver rifiuta modalità required
macOS 12+	Sì	Sì	Nessun failure noto della modalità required
iOS 14+	Sì	Sì
Android 10+ (AOSP)	Sì	Sì	Le skin vendor possono disabilitare nel firmware
Android 9 (Samsung Exynos)	Parziale	No	`wpa_supplicant` compilato senza PMF required
Embedded/IoT (vari)	Non comune	Raro	I moduli WiFi industriali spesso omettono 802.11w

Intuizione duramente conquistata: Un client che si associa con successo con ieee80211w=1 (opzionale) non prova nulla sulla sua implementazione PMF. Testare con ieee80211w=2, inventariare i fallimenti e mantenere un allowlist hostapd.accept_mac per le eccezioni—tracciato come debito tecnico con date di remediation.

Configurazione Cisco IOS XE (serie 9800, track 17.16.x):

! Verifica stato operativo PMF, non solo configurato
wireless profile policy CorpSecure-Policy
 security wpa wpa2 wpa3
 security 802.11w
 security 802.11w pmf mandatory   ! Non optional, non default
 no security wps                  ! Disabilita esplicitamente, non assenza implicita

! Audit dell'advertise effettivo delle capability client
show wireless client summary detail | include PMF
show wireless client mac-address aa:bb:cc:dd:ee:ff detail | sec Capabilities

Architettura di Segmentazione di Rete

La segmentazione wireless fallisce quando il VLAN hopping o la compromissione del piano di gestione AP ponte l'isolamento. L'architettura deve assumere la compromissione dell'AP.

[Internet] → [Firewall] → [Core L3 Switch]
                                |
            +-------------------+-------------------+
            |                   |                   |
        [WLC/Native]      [Wireless DMZ VLAN]   [Guest VLAN]
        (management)      (corporate SSID)        (captive portal)
            |                   |
        [RADIUS DMZ]      [Data VLAN 10]
        (auth backend)    (wired equivalent)

# hostapd con tagging VLAN per SSID, imposto all'AP
vlan_file=/etc/hostapd.vlan
dynamic_vlan=2              # RADIUS-Assigned VLAN obbligatorio

# /etc/hostapd.vlan
*   wlan0.#
10  wlan0.10
20  wlan0.20

Livello segmentazione	Controllo	Modalità failure
Mapping SSID/VLAN	Config AP	Override VLAN same-SSID via RADIUS spoofing
Assegnazione VLAN RADIUS	Backend auth	RADIUS compromesso → placement VLAN arbitrario
ACL tra VLAN	L3 switch/firewall	Native VLAN trunking malconfigurato
Isolamento guest	Isolamento client AP + ACL L2	IPv6 ND/RA bypassa ACL solo-IPv4

L'isolamento guest deve bloccare non solo unicast ma discovery multicast/broadcast:

# Isolamento a livello bridge con soppressione multicast
ebtables -A FORWARD -i wlan0-guest -o wlan0-guest -j DROP
ebtables -A FORWARD -p IPv6 --ip6-protocol ipv6-icmp -j DROP

Verifica Disabilitazione WPS e Analisi Entropia

La modalità PIN WPS utilizza un codice statico di 8 cifre con checksum, producendo 10^7 combinazioni effettive e rendendo il bruteforce online fattibile in ore. La caratterizzazione "HACK ME" è accurata: WPS è stato progettato per comodità di pairing senza threat model per attaccanti di prossimità fisica.

# Verifica che WPS sia assente da beacon e probe response, non solo disabilitato nell'UI
wash -i wlan0mon -C           # Rilevamento WPS in monitor mode

# Atteso: SSID target assente dall'output di wash
# Fallimento: SSID appare con stato "Locked" — WPS presente, temporaneamente throttled

Audit entropia generazione PIN per distribuzioni WPS inevitabili (IoT legacy):

# Estrai PIN da nvram/firmware per analisi
strings /dev/mtd0 | grep -E '^[0-9]{8}$' | while read pin; do
    checksum=$(( (10 - (3*$(echo $pin | cut -c1) + 1*$(echo $pin | cut -c2) + \
        3*$(echo $pin | cut -c3) + 1*$(echo $pin | cut -c4) + \
        3*$(echo $pin | cut -c5) + 1*$(echo $pin | cut -c6) + \
        3*$(echo $pin | cut -c7)) % 10) % 10 ))
    [ "$checksum" -eq "$(echo $pin | cut -c8)" ] && echo "VALID WPS PIN: $pin"
done

Rilevazione	Rischio	Azione
PIN derivato da MAC address (algoritmico)	Predizione banale	Sostituire firmware o ritirare dispositivo
PIN statico su modello dispositivo	Compromissione batch	Disclosure vendor, isolamento rete
PIN "random" ma bassa entropia (seed LCG)	Recuperabile dal seriale	Reimplementazione RNG custom se possibile
WPS solo push-button, nessun PIN	Superficie di attacco ridotta	Accettabile per location fisicamente sicure

Rinforzo Configurazione Client

La scansione proattiva crea impronte digitali di probe request ed espone liste di network preferiti. Sopprimere questo comportamento e restringere le connessioni automatiche.

# wpa_supplicant.conf — soppressione probing e blocco profili network
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ap_scan=1
fast_reauth=0               # Disabilita EAP fast reauth; previene abuso session resumption

network={
    ssid="CorpSecure"
    scan_ssid=0             # Non sondare attivamente per SSID nascosto
    key_mgmt=WPA-EAP
    # Blocco a BSSID specifico previene roaming verso evil twin con stesso SSID
    bssid=00:11:22:33:44:55
    # Disabilita connessione automatica; richiede azione utente esplicita
    disabled=1
}

# Override systemd service per VPN auto-connect su associazione wireless
# /etc/systemd/system/wpa_supplicant.service.d/vpn-up.conf
[Service]
ExecStartPost=/usr/local/bin/wireguard-up-on-assoc.sh

Script VPN auto-connect con validazione associazione:

#!/bin/bash
# wireguard-up-on-assoc.sh — attiva tunnel solo su BSSID autorizzato
AUTHORIZED_BSSIDS="00:11:22:33:44:55 00:11:22:33:44:66"
CURRENT_BSSID=$(wpa_cli status | grep bssid | cut -d= -f2)

if echo "$AUTHORIZED_BSSIDS" | grep -qw "$CURRENT_BSSID"; then
    wg-quick up corp-tunnel
    # Applica routing strict: tunnel è default, wireless è solo stub
    ip route add 192.0.2.0/24 dev wlan0 scope link table 42
    ip rule add from 192.168.1.0/24 lookup 42
else
    logger -p auth.warning "VPN soppressa: BSSID non autorizzato $CURRENT_BSSID"
    # Opzione: deautentica immediatamente
    # wpa_cli disconnect
fi

Errori comuni:

Errore	Perché ti colpisce
`ieee80211w=1` su AP, `optional` su supplicant	Attaccante pubblicizza `ieee80211w=0`, entrambi i lati effettuano downgrade silenzioso
Certificate CN match solo, nessun check SAN	Evil twin usa CA legittima + SAN diverso; validazione CN passa
RADIUS `check_cert_cn` senza `check_cert_exp`	Certificato attaccante revocato ma non scaduto accettato
Guest VLAN con IPv6 non filtrato	IPv6 RA hijacking bypassa intera architettura ACL IPv4
WPS "disabilitato" in web UI, non nel firmware	Wash rileva ancora WPS IE; modalità PIN attiva a livello 802.11
`ap_scan=2` con `autoscan` periodico	Probing background continuo espone pattern di viaggio e SSID network domestici

Checklist verifica configurazione:

[ ] hostapd -dd mostra WPA: PMF required per tutti i tentativi di associazione
[ ] eapol_test verso server RADIUS fallisce con certificato server untrusted
[ ] Output wash vuoto per tutti gli SSID di produzione dopo 5 minuti di monitor
[ ] iw dev wlan0 station dump riporta MFP per ogni stazione associata
[ ] Tunnel VPN stabilito entro 3 secondi dall'associazione wireless; traceroute 198.51.100.1 esce via interfaccia tunnel
[ ] Client guest non può ping6 ff02::1%wlan0 per scoprire altri host del segmento