Molte volte nelle reti Enterprise è necessario effettuare un accesso per manutenzione (installazione di pacchetti software, aggiornamenti del sistema operativo) su PC e Workstation Aziendali, in orario diverso da quello di normale utilizzo del dispositivo (ad esempio in orario notturno).
Questa "necessità tecnica" purtroppo entra spesso in conflitto con le più comuni norme aziendali che generalmente prevedono che l'utente lasci la propria postazione di lavoro, al termine del normale orario ufficio, solo dopo essersi disconnesso ed averla spenta.
In questo scenario generale la consuetudine maggiormente diffusa è chiedere agli utenti di lasciare "occasionalmente" accesso il proprio PC in modo da permettere ai tecnici di intervenire via rete ed effettuare l'intervento programmato.
La richiesta di lasciare accessi i PC, oltre che essere avversata dai responsabili la Sicurezza Aziendale per motivi di Safety (in quanto lasciare acceso e non presidiato per un tempo molto lungo un componente elettronico, caratterizzato da una notevole dissipazione, aumenta il rischio d'incendio), è infelice anche dal punto di vista della Sicurezza Logica, in quanto amplifica l'esposizione del sistema a possibili tentativi di intrusione via rete (rendendo il Target di fatto raggiungibile da potenziali attaccanti ad uno stesso indirizzo IP, anche quando nessun utente è connesso e/o in grado di rilevare manualmente eventuali "anomalie di funzionamento" del proprio strumento di lavoro).
D'altra parte, in caso di intervento tecnico programmato, l'accesso fisico alle stazioni per una loro eventuale accensione manuale è altresi difficoltoso in quanto gli uffici vengono generalmente chiusi a chiave ed i tecnici/sistemisti non sono normalmente in possesso delle chiavi di accesso ai locali.
Rimane la possibilità di passare gli aggiornamenti durante le ore lavorative (magari in pausa pranzo), ma potrebbe non essere sufficiente la finestra temporale lasciata ai tecnici e potrebbe esservi il rischio di danneggiare/rallentare il lavoro degli utenti.
Cosa fare in tutti questi casi?
Rinunciare a passare le patches esponendo il PC a rischi di Sicurezza ben maggiori?
Per fortuna esiste una soluzione percorribile, per tutti coloro che non vogliono rinunciare ad effettuare l'intervento anche dopo che l'utente se n'è andato, spengendo il PC: Ricorrere al protocollo Wake-On-Lan.
Il Wake-On-Lan (WOL) permette, a PC dotati di apposite Motherboard (specificatamente motherboard ATX, che mantengono alimentata la scheda di rete anche a PC spento) di svegliare il sistema, mandandogli uno "speciale" Magic Packet via Ethernet.
Per avere l'effetto desiderato, il Server di Management preposto ad effettuare il Wake-UP delle stazioni, deve essere in grado di generare sul segmento di LAN cui è direttamente connesso un pacchetto Ethernet "speciale" con indirizzo Destinazione Broadcast avente il seguente Payload:
Synchronization Stream == costituito dalla sequenza 0xFF ripetuta 6 volte (6 bytes)
Target MAC Address == l'indirizzo MAC della stazione destinataria del Magic Packet ripetuto 16 volte (96 bytes)
Password (opzionale) == una stringa di 4 o 6 bytes contenente una evetuale password predefinita
La possibilità di utilizzare una breve Password (che viene però trasmessa in chiaro) non deve far credere che il WOL dispone di un vero e proprio meccanismo di autenticazione. La Password serve solo per innalzare la difficoltà di un "Attacco Brute Force", portato da un soggetto non autorizzato che cerchi di sostituirsi al Server legittimo.
La principale limitazione rimane comunque legata alla necessità di usare Frame Ethernet con Indirizzo Destinazione Broadcast. Così facendo, con un singolo Server legittimo, è possibile svegliare solo i PC di un unico dominio di broadcast.
Per ovviare a questa limitazione il protocollo prevede la possibilità di utilizzare il protocollo UDP come trasporto per il Magic Packet. Lo standard WOL prevede infatti che la scheda Ethernet ricevente effettui un Parsing completo del frame ricevuto fino a quando non trova la sequenza 0xFF ripetuta 6 volte (solo in questo caso il Frame viene trattato come Magic Packet).
La presenza di una eventuale intestazione IP e UDP non influisce nel processo di Parsing della scheda.
In questo caso è più giusto parlare di Wake-on-WAN, e, nel caso limite in cui la subnet IP della rete locale sia pubblica, un Host connesso ad Internet può provare ad inviare un Magic Packet ad un PC della LAN anche tramite la Rete Pubblica. Per ottenere che il gateway (router) della rete locale in cui si trovano i PC converta il pacchetto UDP ricevuto in un Frame Ethernet Broadcast contenente il Magic Packet è sufficiente che il soggetto remoto specifichi come indirizzo IP Destinazione l'indirizzo di Broadcast della rete locale.
Per evitare che soggetti non autorizzati possano sfruttare questa flessibilità intrinseca del WOL e svegliare i PC di una LAN da remoto è bene rispettare alcune Security Best Practices, riportate anche dalla Microsoft su TechNet (Rif: http://technet.microsoft.com/en-us/library/bb693549.aspx):
1) Adottare l'invio di Magic Packet Unicast. Quando possibile è preferibile infatti inviare Frame Ethernet contenenti l'Indirizzo Destinazione Unicast della scheda interessata. E' comunque necessario verificare prima che la scheda del proprio PC sia in grado di attivare il processo di Parsing anche nel caso di ricezione di un Frame Unicast. Esistono purtroppo schede che non supportano il WOL che utilizza Magic Packet Unicast.
2) Limitare ai soli indirizzi IP sorgente autorizzati la funzionalità del router, direttamente connesso alla LAN, di instradare pacchetti all'Indirizzo IP Broadcast della sottorete locale. Filtrando ogni richiesta che non proviene dall'indirizzo IP del Server legittimo si può cercare di contrastare il tentativo di uso del WOL da parte
di attaccanti esterni. Peccato solo che il meccanismo WOL possa essere agevolmente condotto in condizione di Blind IP Spoofing (con l'attaccante che usa l'indirizzo IP del Server legittimo al posto del proprio).
[N.B.: Per approfondimenti sull'IP Spoofing guardare anche il Post Precedente]
3) Utilizzare una porta UDP non di default per il trasporto del Magic Packet, filtrando tutte le altre sul router. In questo modo aumenta la difficoltà per l'attaccante di individuare quale porta servizio usare per raggiungere il Target, senza ricorrere prima ad UDP Port Scanning.
[N.B.: Per approfondimenti sul Port Scanning aspettate il Prossimo Post]
Nessun commento:
Posta un commento