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]
venerdì 13 maggio 2011
lunedì 9 maggio 2011
Identità degli host in una rete IP: Possiamo fidarci?
Purtroppo la risposta è lapidaria e preoccupante: NO, dell'indirizzo IP non ci si può proprio fidare!
La principale vulnerabilità riconosciuta del protocollo IP consiste infatti nell’impossibilità di stabilire dall'analisi di un pacchetto chi realmente lo ha immesso nella rete. Un attaccante può agire arbitrariamente sul campo dell'intestazione IP denominato Indirizzo Sorgente per far assumere alla sua stazione una identità IP diversa da quella legittimamente assegnata dall’amministratore della rete locale.
L’indirizzo IP inserito come indirizzo sorgente non viene generalmente validato dai Router e dagli Switch coinvolti nell’instradamento dei pacchetti, rendendo di fatto possibile per l’attaccante assumere identità "fittizie", anche riconducibili a sottoreti diverse da quella di appartenenza.
Pur non essendo un attacco completo, l’IP Spoofing è una tecnica base tra le più usate per la conduzione di attacchi complessi. Infatti, nonostante la relativa semplicità con cui un hacker può attribuirsi un qualsiasi indirizzo IP, molti server, e numerosi strumenti per la gestione remota degli apparati di rete e dei sistemi, validano le richieste di servizio che pervengono loro, proprio sulla base dell’indirizzo IP della presunta stazione sorgente.
Nelle reti dati l’IP Spoofing esiste in due forme distinte, tra loro differenziate sulla base della condizione in cui si colloca l’attaccante.
La forma più semplice è quella che prevede la condizione Man-in-the-middle (ovvero quando l'attaccante è in grado di intercettare tutto il traffico trasmesso sulla rete). Questa situazione è particolarmente pericolosa perché permette all’hacker, che assume una identità IP arbitraria di intercettare i pacchetti di ritorno prodotti dalla stazione destinazione, target dell’attacco. L’eliminazione fisica dei datagrammi IP di ritorno è sufficiente per mascherare la presenza dell’attaccante alle stazioni che posseggono l’identità oggetto di spoofing.
La forma più complessa di IP spoofing prevede invece un attaccante non in grado di intercettare i pacchetti di ritorno. In questo scenario l’attaccante viene definito "cieco" e la tecnica condotta viene indicata come Blind IP Spoofing. Pur procedendo alla cieca, la conoscenza dettagliata dei protocolli e degli applicativi utilizzati dagli utenti legittimi per la fruizione di un dato servizio può consentire all’hacker di creare un flusso di pacchetti coerente con le risposte prodotte dal server (risposte che non è in grado di intercettare).
Indipendentemente dalla tecnica utilizzata, la conduzione di IP spoofing compromette la possibilità di validare l'identità della sorgente dei datagrammi IP.
Pertanto, in tutti quei casi in cui, su una rete aziendale, risulta necessario poter stabilire "oltre ogni ragionevole dubbio" l'identità di una stazione attestata alla rete occorre abbandonare le limitate possibilità di "validazione" intrinsecamente offerte dal protocollo IP, per adottare un qualche protocollo di trasporto più evoluto, in grado di assicurare funzioni di "Autenticazione" e "Integrità Dati" ad ogni pacchetto trasmesso.
La soluzione stato dell'arte maggiormente diffusa è quella di ricorrere alla Suite di protocolli noti come IPSec. IPSec opera allo stesso livello del modello ISO/OSI a cui opera il protocollo IP, di conseguenza non richiede una esplicita modifica delle applicazioni per poter essere introdotto in azienda.
Una soluzione alternativa è invece ricorrere alle funzioni di "Sicurezza" incluse nel protocollo TLS, validando i soggetti coinvolti direttamente a livello di Sessione applicativa. In questo secondo caso è generalmente richiesta la modifica/upgrade delle componenti Client e Server coinvolte nel servizio.
La principale vulnerabilità riconosciuta del protocollo IP consiste infatti nell’impossibilità di stabilire dall'analisi di un pacchetto chi realmente lo ha immesso nella rete. Un attaccante può agire arbitrariamente sul campo dell'intestazione IP denominato Indirizzo Sorgente per far assumere alla sua stazione una identità IP diversa da quella legittimamente assegnata dall’amministratore della rete locale.
L’indirizzo IP inserito come indirizzo sorgente non viene generalmente validato dai Router e dagli Switch coinvolti nell’instradamento dei pacchetti, rendendo di fatto possibile per l’attaccante assumere identità "fittizie", anche riconducibili a sottoreti diverse da quella di appartenenza.
Pur non essendo un attacco completo, l’IP Spoofing è una tecnica base tra le più usate per la conduzione di attacchi complessi. Infatti, nonostante la relativa semplicità con cui un hacker può attribuirsi un qualsiasi indirizzo IP, molti server, e numerosi strumenti per la gestione remota degli apparati di rete e dei sistemi, validano le richieste di servizio che pervengono loro, proprio sulla base dell’indirizzo IP della presunta stazione sorgente.
Nelle reti dati l’IP Spoofing esiste in due forme distinte, tra loro differenziate sulla base della condizione in cui si colloca l’attaccante.
La forma più semplice è quella che prevede la condizione Man-in-the-middle (ovvero quando l'attaccante è in grado di intercettare tutto il traffico trasmesso sulla rete). Questa situazione è particolarmente pericolosa perché permette all’hacker, che assume una identità IP arbitraria di intercettare i pacchetti di ritorno prodotti dalla stazione destinazione, target dell’attacco. L’eliminazione fisica dei datagrammi IP di ritorno è sufficiente per mascherare la presenza dell’attaccante alle stazioni che posseggono l’identità oggetto di spoofing.
La forma più complessa di IP spoofing prevede invece un attaccante non in grado di intercettare i pacchetti di ritorno. In questo scenario l’attaccante viene definito "cieco" e la tecnica condotta viene indicata come Blind IP Spoofing. Pur procedendo alla cieca, la conoscenza dettagliata dei protocolli e degli applicativi utilizzati dagli utenti legittimi per la fruizione di un dato servizio può consentire all’hacker di creare un flusso di pacchetti coerente con le risposte prodotte dal server (risposte che non è in grado di intercettare).
Indipendentemente dalla tecnica utilizzata, la conduzione di IP spoofing compromette la possibilità di validare l'identità della sorgente dei datagrammi IP.
Pertanto, in tutti quei casi in cui, su una rete aziendale, risulta necessario poter stabilire "oltre ogni ragionevole dubbio" l'identità di una stazione attestata alla rete occorre abbandonare le limitate possibilità di "validazione" intrinsecamente offerte dal protocollo IP, per adottare un qualche protocollo di trasporto più evoluto, in grado di assicurare funzioni di "Autenticazione" e "Integrità Dati" ad ogni pacchetto trasmesso.
La soluzione stato dell'arte maggiormente diffusa è quella di ricorrere alla Suite di protocolli noti come IPSec. IPSec opera allo stesso livello del modello ISO/OSI a cui opera il protocollo IP, di conseguenza non richiede una esplicita modifica delle applicazioni per poter essere introdotto in azienda.
Una soluzione alternativa è invece ricorrere alle funzioni di "Sicurezza" incluse nel protocollo TLS, validando i soggetti coinvolti direttamente a livello di Sessione applicativa. In questo secondo caso è generalmente richiesta la modifica/upgrade delle componenti Client e Server coinvolte nel servizio.
Iscriviti a:
Post (Atom)