Architettura VLAN: Le Porte Native e le implicazioni di sicurezza

Architettura VLAN: Le Porte Native e le implicazioni di sicurezza

Abbiamo concluso la lezione precedente con un interrogativo spinoso: sappiamo che una porta configurata come Trunk si aspetta di ricevere dal cavo esclusivamente traffico etichettato con il protocollo 802.1Q. Ma cosa accade, a livello di logica hardware, se a quella porta Trunk colleghiamo per errore un dispositivo obsoleto (come un vecchio hub) o un PC che non supporta il tagging, il quale invia inesorabilmente un frame Ethernet Untagged, puro e senza etichette?

Se lo switch applicasse la rigidità di una porta Access, scarterebbe immediatamente il pacchetto. Tuttavia, i creatori dello standard 802.1Q hanno dovuto garantire la retrocompatibilità con gli apparati preesistenti. Per risolvere questo dilemma hanno inventato il concetto di Native VLAN (VLAN Nativa). Purtroppo, questa soluzione tecnica si è trasformata nel corso degli anni in una delle vulnerabilità di sicurezza più sfruttate nelle reti aziendali.

La Native VLAN: l'ancora di salvezza per il traffico Untagged

Per definizione, ogni singola porta Trunk 802.1Q possiede una (e una sola) Native VLAN configurata internamente. Su quasi tutti gli switch di livello enterprise (inclusi i dispositivi Cisco), il valore di default della Native VLAN è la VLAN 1.

Il comportamento del processore ASIC dello switch è rigidamente codificato in base alla direzione del traffico, ma presenta un'eccezione mirata:

1. Processo di Ingress (Ricezione sul Trunk):
Se il Trunk riceve un frame con il Tag 802.1Q, lo smista normalmente nella VLAN corrispondente al numero del Tag. Ma se riceve un frame privo di etichetta (Untagged), invece di scartarlo, lo inietta silenziosamente all'interno della Native VLAN  . È un meccanismo di salvataggio per il traffico "orfano".

2. Processo di Egress (Trasmissione dal Trunk):
Se lo switch deve spedire fuori dal Trunk un frame appartenente, ad esempio, alla VLAN 20, applica l'etichetta "20". Ma attenzione: se lo switch deve trasmettere dal Trunk un frame appartenente proprio alla Native VLAN, non applica alcuna etichetta  . Il pacchetto esce dal Trunk completamente Untagged. Questo permetteva storicamente agli hub ignoranti collegati in mezzo a due switch di processare e leggere almeno quel traffico di base.

Il disastro configurativo: Il VLAN Mismatch

Questa asimmetria comportamentale è causa di uno degli errori di progettazione più insidiosi: il Native VLAN Mismatch. Supponiamo che due giovani sistemisti configurino due switch collegati da un cavo Trunk.

Nello Switch A, il sistemista lascia la Native VLAN di default (VLAN 1). Nello Switch B, il secondo sistemista per eccesso di zelo cambia la Native VLAN del Trunk portandola alla VLAN 99.

Cosa accade se un computer sulla VLAN 1 dello Switch A invia un pacchetto broadcast? Lo Switch A sa che il pacchetto deve uscire dal Trunk. Dato che appartiene alla VLAN 1 (che è la sua Native VLAN), lo invia sul cavo senza etichetta. Il pacchetto viaggia sul cavo e arriva allo Switch B. Lo Switch B riceve un pacchetto senza etichetta. Controlla qual è la sua Native VLAN (che è la 99) e immette il pacchetto nella VLAN 99.

Risultato? Abbiamo appena fuso segretamente due domini di broadcast diversi senza passare per un router. È un VLAN Leak (perdita di traffico). Nelle reti professionali, protocolli di discovery come il CDP (Cisco Discovery Protocol) analizzano continuamente i link e, se rilevano questa discrepanza, intasano i log di sistema con allarmi di "Native VLAN Mismatch", perché sanno che la rete è compromessa.

Il tallone d'Achille: L'attacco di VLAN Hopping (Double Tagging)

Oltre agli errori di configurazione, la Native VLAN è il vettore principale per un attacco informatico devastante noto come VLAN Hopping, basato sulla tecnica del Double Tagging.

L'obiettivo di un hacker è saltare dalla VLAN in cui si trova (spesso quella per gli Ospiti o per i normali dipendenti) a una VLAN blindata, come quella dei Server o dell'Amministrazione, scavalcando totalmente i Firewall e i Router (che agiscono a Livello 3).

La sequenza di attacco a basso livello:
1. L'hacker crea artigianalmente dal suo PC Linux un frame Ethernet contenente DUE etichette 802.1Q (una dentro l'altra).
2. L'etichetta esterna è impostata su "VLAN 1". L'etichetta interna, nascosta, è impostata su "VLAN 50" (la rete blindata da colpire).
3. Il primo switch riceve il frame. Legge l'etichetta esterna (VLAN 1) e decide che il frame deve viaggiare sul Trunk.
4. Poiché sul Trunk la VLAN 1 è la Native VLAN, il primo switch strappa l'etichetta esterna per spedire il frame Untagged, convinto di fare la cosa giusta.
5. Il frame arriva al secondo switch spogliato della prima etichetta, ma... sorpresa! L'etichetta interna (VLAN 50) è ora esposta e visibile.
6. Il secondo switch legge l'etichetta "VLAN 50" e inoltra il frame del malware direttamente al Server, senza che il Firewall lo abbia mai analizzato.

Hardening e Best Practices: il Black Hole

Sintesi applicativa e chiusura del modulo

Con questa lezione chiudiamo il grande capitolo dedicato all'architettura di Livello 2. Abbiamo trasformato una rete piatta, instabile e insicura, in una fortezza a compartimenti stagni. Le VLAN hanno arginato le tempeste di broadcast; i Trunk ci hanno permesso di estendere questa logica su edifici interi; e infine la corretta gestione del "Buco Nero" per la Native VLAN ha blindato la nostra rete da infiltrazioni subdole e VLAN Leak.

Ora l'infrastruttura è sicura e isolata a livello hardware. Ma preparati alla sfida successiva: il CEO dell'azienda (nella VLAN 10 Direzione) ha urgente bisogno di stampare un documento sulla stampante del reparto Commerciale (VLAN 20). Hai costruito dei muri invalicabili di Livello 2. Come farai a far passare questo singolo documento, senza distruggere la sicurezza e l'isolamento che hai faticosamente costruito in queste lezioni? La risposta richiederà di salire di un livello nella pila OSI.