Tempi di attivazione di un collegamento LAN su switch (STP, POE, DHCP, Negoziazione)

Un cliente oggi mi ha domandato il motivo per cui, da quando si collega un client ad uno switch mediante una patch LAN a quando lo stesso diviene in grado di comunicare con il resto della rete, passa del tempo.

 

Molto brevemente proviamo a capire insieme cosa accade:

1. In una fase iniziale lo switch (se POE) cerca di capire se il device è abilitato o meno a ricevere energia elettrica secondo gli standard 802.3af (low energy) o 802.3at(high energy o POE+). Senza entrare nel dettaglio tecnico ampiamente documentato, questa fase richiede del tempo ed è possibile vedere la porta, inizialmente accesa per un attimo, spegnersi e quindi riaccendersi definitivamente. [POE +5 secondi circa]

 

2. Nella fase successiva (o se non abbiamo uno switch POE salteremo direttamente qui), avviene la negoziazione della velocità e del duplex (tipicamente oggi 1Gbit in modalità Full Duplex, ovvero bidirezionale). Gli apparati (switch e device) cercheranno di negoziare la velocità migliore possibile. [AutoNegoziazione +4 secondi circa]

3. Se abbiamo abilitato lo Spanning Tree (tipicamente RSTP), lo switch metterà inizialmente la porta in blocking per evitare loop, dopodichè porterà la porta in listening, learning e infine in forwarding. Durante questi passaggi lo switch ascolta cosa sta accadendo sulla rete e attende di leggere eventuali BPDU per stabilire tutti i percorsi verso il suo root bridge. Non entro in ulteriore dettaglio del protocollo STP, ma questo tempo è utile allo switch per accertarsi che non vi siano broadcast storm (loop) causati da percorsi ridondati e attivi simultaneamente. [Spanning Tree +32 secondi circa]

 

4.  Finalmente siamo pronti a comunicare, ma se il nostro device ottiene l'indirizzo IP non manualmente ma in DHCP, dovremo attendere sia il meccanismo di DHCP Request/Relay sia l'assegnazione dell'IP all'interfaccia di rete (qui dipende molto anche dalla capacità computazionale del device). [DHCP +3 secondi]

 

Conviene disabilitare qualcosa pur di velocizzare l'accesso? Salvo non ci siano esigenze particolari,  certamente no. Parliamo di collegamenti LAN, perlopiù statici. Difficilmente si cambia porta LAN così di frequente da notare un rallentamento in queste operazioni. Anche all'atto dell'accensione di una postazione di lavoro, calcolando che la LAN rimane spesso attiva per il WakeOnLan (ma anche presupponendo una postazione elettricamente spenta), fin quando il sistema operativo viene caricato e l'utente accede alla propria macchina, certamente la LAN sarà più che pronta.

Ovviamente questi dati sono stati presi su uno switch, ma tipicamente questo tipo di comportamento varia da produttore a produttore. Ci sono produttori (soprattutto nello spanning tree) "più conservativi" che preferiscono attendere un tempo maggiore prima di dichiarare la porta "esente da percorsi ridondati", altri che attendono di meno.

 

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

Attacco alle infrastrutture VMware, facciamo chiarezza

In molti mi stanno chiedendo in queste ore lumi circa l'alert diramato dapprima dall'Agenzia Francese e di conseguenza dall'Agenzia per la Cybersecurezza Nazionale (ACN) Italiana in questo comunicato.

In questo breve articolo non parlerò (troppo) della vulnerabilità, ma del perchè ci si ritrova con un server esposto.

 

La vulnerabilità in breve

La CVE-2021-21974 confermata da VMware qui e con un punteggio di 9.8/10 riguarda il servizio SLP, normalmente aperto di default sulla porta 427, che consente di ottenere un accesso permanente e privilegiato sull'hypervisor. Da quando una CVE viene rilasciata in seguito ad un possibile punto di attacco a quando l'attacco diviene realmente applicato nel mondo reale, a volte passa del tempo (altre volte, invece, ci si accorge della vulnerabilità dopo aver concretamente osservato gli attacchi). Motivo per cui oggi, improvvisamente, è esploso il caso.

La vulnerabilità consente di crittografare direttamente le macchine virtuali ignorando totalmente come quanto esse siano protette al loro interno. Aspetto ancor più grave è che potenzialmente i backup fatti dall'Hypervisor (ad esempio con Ghetto o con altri script su volumi direttamente connessi in NFS, iSCSI, etc.), sono anch'essi attaccabili.

Quando ci si ritrova vulnerabili?

Ci si ritrova vulnerabili quando un server VMware viene esposto su internet senza alcuna protezione perimetrale a difesa della macchina. Quando un server VMware viene protetto da un firewall (ma anche da un dispositivo in grado di fare NAT come un router con questa funzionalità attiva), è prassi che i servizi non utilizzati vengano chiusi e non resi accessibili all'esterno. Intendiamoci: l'hypervisor è sacro, va protetto più delle VM in esso contenuto.

Quindi, ricapitolando, per avere un VMware esposto devo:

• Non avere un router con il NAT abilitato (quindi VMware dovrebbe avere direttamente l'IP Pubblico Statico)
  
• Non avere un firewall
• Aver lasciato il servizio slp attivo (com'è di default)

Una situazione che non dovrebbe accadere in un'azienda con i server in casa ma che è la normalità con i server in cloud.

 

Perchè si parla di attacco principalmente alla Francia?

Qui c'è un aspetto interessante della vicenda. Non è nulla di geopolitico, semplicemente in Francia c'è uno dei più grandi Cloud Provider Europei.

Quando si acquista un server dedicato, è prassi che il provider metta a disposizione, tra gli altri sistemi operativi, anche VMware. In questo caso esso verrà pubblicato direttamente sull'IP Pubblico Statico che ci è stato riservato.

Solo raramente ci si preoccupa di mettere in sicurezza questo aspetto invece cruciale. Nella stragrande maggioranza dei casi chi acquista un servizio in cloud si culla sul principio, fittizio, per cui il non avere un server in casa significhi automagicamente che esso sia responsabilità di altri. Cosa, ovviamente, assolutamente non vera. Molto raramente assisteremo ad installazioni in cloud con un Firewall Virtuale a protezione del proprio server, oppure ad un sistema di backup realmente sicuro e robusto. Ed è in questa falsa convinzione che si annida poi l'errore spesso fatale.

I più virtuosi attivano lo spazio di backup messo a disposizione dell'operatore, peccato esso sia vulnerabile in quanto gestito dall'hypervisor stesso (oggetto dell'attacco) e quindi totalmente inutile in questo contesto.

 

Chiudere la vulnerabilità

E' sufficiente dare questi due comandi in ssh sull'hypervisor

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0

Oppure chiudere la porta 427.

 

In conclusione

Oggi si parla di servizio SLP, domani sarà un altro servizio e, perchè no, magari un problema su qualcosa che proprio non possiamo chiudere. La sicurezza di un'infrastruttura non è qualcosa solo da correggere di volta in volta, ma va pensata ad un livello globale e più architetturale. Solo realizzando un'architettura robusta otterremo un livello di protezione tale da contrastare la maggior parte di questi eventi senza doverli affannosamente rincorrere nella speranza di non essere tra i primi ad essere beccato.

 

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.