Whitepaper - Architettura Ubiquity

Transcript

Nota Tecnica
TN0015
Whitepaper - Architettura
Ubiquity
Introduzione
Il documento contiene una descrizione generale dell’architettura della piattaforma
per la teleassistenza Ubiquity e una discussione puntuale di tutti gli aspetti che
coinvolgono la sicurezza.
Versione
Descrizione
Data
1
Prima emissione
02/12/2013
2
Aggiunti dettagli architettura
07/04/2014
3
Corretto valore porta custom
06/06/2014
4
Risk assesment
20/09/2014
Disclaimer
Le informazioni fornite nella documentazione sono soggette a cambiamenti senza preavviso e non
rappresentano nessun obbligo da parte di ASEM S.p.A.
ASEM S.p.A. non è responsabile per errori tecnici o altre omissioni e declina ogni responsabilità
risultante dal suo uso.
ASEM S.p.A. non sarà responsabile per perdite di profitti o danni, diretti o indiretti, di qualsiasi genere
(ivi comprese la perdita o il danneggiamento di dati), derivanti dall’uso delle informazioni contenute nella
documentazione.
Pagina 1 di 17
Nota Tecnica
TN0015
Indice
1
2
3
4
5
6
7
8
9
Cenni sull’architettura di Ubiquity ............................................................................................................... 3
Architettura dei componenti ........................................................................................................................ 3
Collegamento tra Control Center e Runtime .............................................................................................. 4
3.1
Discoverability .................................................................................................................................... 5
3.2
Raggiungibilità ................................................................................................................................... 6
3.3
Autenticazione ................................................................................................................................... 7
3.4
Controllo di accesso .......................................................................................................................... 8
Scalabilità, disponibilità, sicurezza ............................................................................................................. 8
Requisiti per la connessione ...................................................................................................................... 9
Sicurezza del livello di trasporto ................................................................................................................. 9
La tecnologia VPN di Ubiquity .................................................................................................................... 9
7.1
L’architettura di rete ........................................................................................................................... 9
7.2
Tecnologia di incapsulamento ......................................................................................................... 11
7.3
Assegnazione IP al PC con Control Center ..................................................................................... 13
7.4
Broadcast e supporto per comunicazione con dispositivi non inizializzati ...................................... 13
7.5
Risoluzione conflitto degli indirizzi IP ............................................................................................... 13
7.6
Connessioni multiple concorrenti ..................................................................................................... 13
7.7
Firewall............................................................................................................................................. 14
Esempio di collegamento tipico, con VPN alla sottorete LAN del PC remoto.......................................... 14
Risk assesment ........................................................................................................................................ 15
9.1
PC remoto infettato da virus ............................................................................................................ 15
9.1.1 Precondizioni per l’attacco ........................................................................................................... 15
9.1.2 Soluzione 1: firewall su PC locale di supervisione ...................................................................... 15
9.1.3 Soluzione 2: firewall integrato in Ubiquity .................................................................................... 16
9.2
Attacco man-in-the-middle ............................................................................................................... 16
9.3
Attacco di tipo brute force ................................................................................................................ 16
9.4
Furto password ................................................................................................................................ 17
Pagina 2 di 17
Nota Tecnica
TN0015
1 Cenni sull’architettura di Ubiquity
Ubiquity è una soluzione software che ha lo scopo di mettere in comunicazione un set di strumenti software
di controllo remoto (Control Center), con un componente software (Runtime) installato su un sistema inserito
in una rete privata remota. Il componente Runtime, tramite un tunnel di rete creato con Control Center,
riesce a pubblicare una serie di servizi, come il desktop remoto sulla macchina che ospita il Runtime o
l’accesso VPN alla macchina e a tutta la sottorete LAN collegata alla macchina stessa.
La creazione del tunnel sicuro tra “macchina remota” e “assistenza tecnica” è fatta automaticamente dai
client Ubiquity sfruttando una infrastruttura di server pubblici di appoggio.
Non è richiesta alcuna configurazione dell’infrastruttura di rete, né dal lato della macchina remota, né dal lato
del servizio di assistenza tecnica. Si da per scontato che entrambe le reti siano dotate di uno o più livelli di
firewall/NAT.
2 Architettura dei componenti
Le diverse funzionalità sono fornite da un insieme di componenti incorporati in Ubiquity Runtime e operanti
con relazioni di client-server. Per esempio Ubiquity Runtime esegue il server per il servizio di Remote
Desktop, mentre Control Center può connettersi come Remote Desktop client. Lo stesso vale per tutti gli altri
servizi inclusa la connessione VPN per la quale Runtime incorpora il server mentre Control Server agisce da
VPN client.
La figura seguente mostra i diversi componenti client-server.
Ubiquity remote
desktop client
Ubiquity remote
desktop server
VPN client
VPN server
Remote serial port
client
Remote serial port
server
Come mostrato dalla figura seguente, Ubiquity supporta scenari di connessioni multiple in cui lo stesso
Control Center si può connettere contemporaneamente a diversi Runtime, e analogamente uno stesso
Runtime può servire diversi Control Center.
Pagina 3 di 17
Nota Tecnica
TN0015
Control Center 1
Runtime 1
Control Center 2
Runtime 2
Control Center 3
Runtime 3
...
...
3 Collegamento tra Control Center e Runtime
L’architettura client-server per come è stata descritta sino ad ora è molto simile alla classica
implementazione degli strumenti di controllo remoto in uso nel passato nei quali un software con il ruolo di
supervisore si collega come client ad un servizio di controllo remoto operante come server.
Tale paradigma non si adatta comunque all’odierno scenario delle connettività attraverso Internet.
La topologia standard che deve oggi essere considerata è quella rappresentata dalla figura seguente.
Client component
Firewall/NAT
Firewall/NAT
Server component
Internet
Il problema fondamentale di questa configurazione è che il componente server nel sistema remoto non può
ricevere la connessione da parte del componente client, perché è di fatto installato all’interno di una rete
locale dietro un NAT. Solo le connessioni in uscita sono di solito permesse.
Aprire una connessione dall'esterno al dispositivo server richiederebbe una configurazione ad-hoc statica nel
firewall, che traduce una connessione all’IP pubblico con porta specifica ad uno specifico IP privato
all'interno della rete.
Questo non è solitamente fattibile perché:
- è complesso da implementare e richiede consulenti IT specializzati.
- ammesso che sia implementato, la connessione richiede la conoscenza da parte del client dell’IP pubblico
della rete del computer remoto. L'IP pubblico può cambiare nel tempo.
- se ci sono più macchine server all'interno della rete, sono necessarie più regole nel firewall per i diversi
indirizzi IP o porte.
La soluzione che si adotta è per entrambi, server e client, quella di effettuare connessioni dall’interno verso
l’esterno puntando quindi ad un nodo noto di una infrastruttura server pubblica che agisce come gateway.
Pagina 4 di 17
Nota Tecnica
Client component
TN0015
Firewall/NAT
Firewall/NAT
Server component
Remote access
infrastructure
L’infrastruttura server assolve i seguenti compiti:




Discoverability: grazie ai server, i Runtime possono “rendersi disponibili” e i Control Center
riescono a conoscere l’elenco dei sistemi Runtime online.
Raggiungibilità: nella fase di handshake Control Center riesce a comunicare con il Runtime
utilizzando i server come punto di rendez-vous.
Autenticazione: grazie all’utilizzo di password e certificati i server garantiscono l’identità sia dei
Control Center che dei Runtime.
Controllo di accesso: una volta che sono stati identificati sia l’utente che sta utilizzando Control
Center sia la macchina che esegue il Runtime, il collegamento tra i due avviene solo se
l’amministratore Ubiquity ha istituito una regola che permette a quel utente di operare su quella
macchina e stabilito quali operazioni può effettuare (es. solo desktop remoto oppure solo VPN ad un
IP particolare).
3.1 Discoverability
Control Center deve avere le informazioni di “disponibilità” del dei vari Runtime a prescindere dalla
configurazione della rete remota (che può anche cambiare nel tempo).
In Ubiquity la reperibilità è risolta utilizzando un server "coordinatore" usato come luogo di rendez-vous per
tutte le istanze di Control Center e Runtime. Questo server si chiama "Access Server" ed è il server che per
primo riceve una connessione sia da Control Center che da Runtime.
Control Center 1
Control Center 2
Runtime 1
Access Server
Runtime 2
Control Center 3
Runtime 3
...
...
Tutti i componenti Control Center e Runtime accedono all’Access Server passando le loro credenziali di
autenticazione.
Pagina 5 di 17
Nota Tecnica
TN0015
L’Access Server ospita i “domini” Ubiquity. Un dominio in Ubiquity è definito come una collezione gerarchica
di sistemi Runtime, di utenti, di gruppi di utenti, di permessi/regole di accesso, di regole di firewall. Attraverso
l’accesso al dominio gli utilizzatori Ubiquity usufruiscono del “servizio” sulla base dei diritti e permessi
concessi all’utente.
I sistemi Runtime comunicano al server la loro disponibilità "Io sono qui, io sono disponibile". Control Center
comunica con il server richiedendo la lista dei sistemi Runtime appartenenti al dominio a cui è connesso che
sono attivi in uno specifico momento. Dal momento che l’Access Server è il luogo di connessione comune,
esso può fornire la risposta alla domanda, insieme alle informazioni pertinenti per consentire a Control
Center di raggiungere un Runtime.
3.2 Raggiungibilità
Quando Control Center necessita ci connettersi a un Runtime specifico, esso comanda all’Access Server di
inoltrare una richiesta al Runtime per l’avvio della procedura di connessione end-to-end.
Viene avviato pertanto un semplice protocollo di handshake per fare in modo che Control Center possa
comunicare con il Runtime. Mentre in questa fase iniziale tutti i messaggi sono inoltrati dall’Access Server, lo
scopo della sessione di handshaking è di avviare una comunicazione diretta tra Control Center e Runtime,
senza avere l’Access Server come intermediario.
Il tutto può essere riassunto nei seguenti passi:
Valutazione topologia di rete
Le impostazioni di rete lato Control Center e lato Runtime, l’eventuale NAT e la configurazione del firewall
sono valutate utilizzando un algoritmo euristico.
Questa operazione è assistita da un server specifico chiamato “Network Discovery Server”.
Tentativo di connessione diretta
Se l’esisto dell’operazione precedente è positivo, ovvero ci sono possibilità per Control Center e Runtime di
realizzare un collegamento diretto, viene effettuato un tentativo per una connessione NAT traversal. Questa
è una tecnica che permette il collegamento diretto tra Control Center e Runtime, senza alcun server di
supporto intermedio.
Server di rimbalzo (Relay Server)
Se la connessione diretta non risulta possibile viene eletto un server di rimbalzo per essere usato come
gateway.
Il server di inoltro è un'applicazione molto semplice che agisce unicamente come un ponte e permette che le
due connessioni in uscita (Control center e Runtime) si “incontrino” in un end-point pubblico comune. Il
server di inoltro non può entrare nel merito del contenuto del traffico tra Control Center e Runtime perché la
comunicazione utilizza il protocollo SSL e dei certificati. Il server di rimbalzo semplicemente opera quindi un
inoltro di messaggi cifrati.
Esistono diversi server di rimbalzo dislocati geograficamente in posizioni diverse. Il protocollo di connessione
Ubiquity è in grado di eleggere il server che garantisce la latenza di connessione più bassa tra le due parti.
Client component
Firewall/NAT
Firewall/NAT
Server component
Remote access
infrastructure
In conclusione il protocollo di raggiungibilità di Ubiquity permette a Control Center e Runtime di istanziare
una connessione virtuale cifrata che astrae dalle diverse topologie di rete e dai meccanismi di collegamento
ad Internet.
Pagina 6 di 17
Nota Tecnica
TN0015
All’interno di questo canale virtuale i componenti client-server possono a loro volta parlarsi e per quanto visto
questo canale virtuale può essere implementato attraverso una connessione peer-to-peer oppure attraverso
una connessione accoppiata da un server di rimbalzo pubblico.
Direct peer-to-peer connection
VPN client
Firewall/NAT
VPN client
Firewall/NAT
VPN server
Public relay server
VPN server
3.3 Autenticazione
L’infrastruttura server di Ubiquity risolve il problema dell’identificazione, che è l’azione di confermare l’identità
di una persona, l’utente Control Center, o quella di un programma, Ubiquity Runtime sul sistema remoto.
Pagina 7 di 17
Nota Tecnica
TN0015
Il problema è risolto in modo diverso per Control Center e Runtime.
Control Center
Gli utenti Control Center sono autenticati attraverso la richiesta di inserire il nome del dominio, il nome utente
e la password. Le credenziali sono passate al server che le valida in base ai dati archiviati nel database.
Si noti che le password non sono di fatto memorizzate sul database del server. L’oggetto della
memorizzazione è l’hash della password che viene a sua volta confrontato con l’hash della password fornita
dall’utente.
Inoltre, la password non è mai salvata a livello di Control Center ed è quindi impossibile estrapolarla.
Runtime
Quando un Runtime è associato a un dominio, ovvero gli viene dato un nome ed una relazione di
appartenenza ad un determinato account, viene generato un certificato cifrato da parte dell’Access Server e
inviato al Runtime. Ogni volta che il Runtime si connette all’Access Server esso invia il certificato al server
come autenticazione. Il certificato può essere decifrato solo dal server e contiene le informazioni sull’identità
del Runtime e del sistema dove esso è in esecuzione.
Il certificato è generato in modo da essere univoco rispetto all’hardware su cui è in esecuzione il Runtime.
3.4 Controllo di accesso
Per ogni utente di Control Center il controllo di accesso permette la selezione e la restrizione di accesso a
un determinato servizio esposto da un certo Runtime.
Il controllo di accesso in Ubiquity è eseguito confrontando le credenziali fornite dall’utente Control Center e
l’identità del Runtime con un insieme di regole gerarchiche contenute nel dominio Ubiquity e gestite
dall’amministratore di dominio. Se l’azione richiesta da parte dell’utente corrisponde a una regola
dell’insieme, allora l’autorizzazione è concessa a Control Center di effettuare tale operazione su quel
Runtime.
L’interfaccia utente di Control Center provvede tutti gli strumenti necessari alla configurazione e applicazione
delle regole attraverso la creazione di gruppi, utenti e assegnazione gerarchica dei permessi, compresa la
gestione delle eccezioni (allow/deny).
La granularità dei permessi permette la completa e dettagliata profilazione di gruppi e utenti.
4 Scalabilità, disponibilità, sicurezza
Per scalabilità si intende la capacità di mantenere il desiderato livello di prestazioni e tempi di risposta al
crescere del numero degli utilizzatori.
Per disponibilità si intende la porzione di tempo in cui l’infrastruttura è in condizioni di funzionamento. La
disponibilità per Ubiquity è attestata essere maggiore del 99,99%.
Per sicurezza si intende lo stato di essere “sicuro”, ovvero la condizione di essere protetti contro le
conseguenze di un malfunzionamento, danneggiamento, errore, incidente, danno o qualsiasi altro evento
che si possa considerare non desiderato.
La scalabilità, la disponibilità e la sicurezza in Ubiquity sono ottenute replicando tutte le parti vitali
dell’infrastruttura.
Sono mantenute diverse repliche dei database in server geograficamente lontani allo scopo di rendere
statisticamente impossibile la perdita di dati rilevanti. In aggiunta sono eseguite copie di backup su base
giornaliera mantenute offline in postazioni sicure.
Sono attivi diversi Access Server allo scopo di mantenere attivo l’accesso al servizio anche in caso la
connettività Internet di uno di questi venga meno.
Sono mantenuti svariati server di rimbalzo in posizioni geograficamente distanti e distribuite su tutto il globo.
Nel caso in cui il server di rimbalzo sai richiesto per la realizzazione della connessione, è sempre garantita la
disponibilità di uno di essi e viene automaticamente scelto il migliore in grado di fornire le migliori prestazioni
misurabili in ridotti tempi di latenza e ridotto jitter.
Pagina 8 di 17
Nota Tecnica
TN0015
5 Requisiti per la connessione
Ubiquity Control Center e Ubiquity Runtime richiedono di potersi connettere all’infrastruttura server
attraverso l’utilizzo di almeno una delle seguenti porte TCP: 80, 443 oppure 5935.
Le porte UDP 80, 443 oppure 5935 eventualmente aperte sono automaticamente utilizzate per migliorare le
prestazioni. Control Center e Runtime rilevano automaticamente le porte uscenti disponibili per la
connessione Internet e utilizzano la prima porta che si connette con successo.
6 Sicurezza del livello di trasporto
La connessione con il server è resa sicura grazie all’utilizzo del protocollo SSL/TLS, indipendentemente dal
numero di porta effettivamente utilizzato.
L’identità del server è garantita dall’utilizzo di certificato SSL controfirmato da una certification authority
conosciuta. Se Control Center non riconosce l’identità del server, viene fornita indicazione all’utente, che può
scegliere se proseguire comunque o abortire la connessione.
Il protocollo SSL/TLS assicura inoltre la riservatezza dei dati scambiati.
Ubiquity Runtime si identifica con il server grazie all’utilizzo di un certificato digitale crittografato che è stato
generato al momento della prima associazione del dispositivo con il server stesso e che è univoco rispetto
all’hardware su cui è in esecuzione il Runtime. La validazione del certificato da parte del server assicura che
il software non è stato copiato su un altro dispositivo e che l’hardware è esattamente quello del momento
dell’associazione.
L’utente di Control Center infine si autentica utilizzando nome dominio, nome utente e password. La
password non è salvata localmente al PC, né salvata nel server, che registra solamente un hash univoco
ottenuto dalla password, e dal quale non è possibile risalire alla password in chiaro.
7 La tecnologia VPN di Ubiquity
7.1 L’architettura di rete
La VPN di Ubiquity è implementata come topologia di tipo client-server.
Il server VPN è un servizio esposto da Ubiquity Runtime e il client VPN è un servizio esposto da Ubiquity
Control Center.
Pagina 9 di 17
Nota Tecnica
VPN client
TN0015
Firewall/NAT
VPN server
Internet
VPN client
Firewall/NAT
VPN client
Firewall/NAT
La figura precedente mostra la topologia logica tra i client VPN e i server VPN.
Mentre la topologia della VPN rispetta il paradigma client-server, il livello di trasporto è ottenuto attraverso un
collegamento diretto punto-punto oppure attraverso un server pubblico di rimbalzo.
La figura seguente mostra una rappresentazione semplificata dei livelli.
VPN layer
(Client)
Level 2
encapsulation
VPN layer
(Server)
Peer-to-peer
connectivity layer
Ubiquity virtual
connectivity layer
Peer-to-peer
connectivity layer
Control Center
Server
Runtime
Il livello virtuale di connettività si preoccupa di connettere Control Center e Runtime a prescindere dalle loro
specifiche configurazioni di rete e firewall.
Il livello VPN può quindi lavorare in una modalità molto efficiente ed isolata in topologia client-server.
Questo approccio differisce rispetto ad altre soluzioni tipicamente basate su un server VPN pubblico.
Pagina 10 di 17
Nota Tecnica
TN0015
VPN server
VPN client
Firewall/NAT
VPN client
In una situazione come quella raffigurata nello schema precedente, la rappresentazione semplificata dello
stack di protocollo è la seguente:
VPN layer
(Client)
Level 3
encapsulation
VPN layer
(Server)
Supervisor software
Level 3
encapsulation
Server
VPN layer
(Client)
Remote software
In questo caso la connessione VPN è utilizzata per risolvere il problema di connettività: i clients devono
necessariamente connettersi a un server pubblico e così pure per la virtualizzazione degli indirizzi di rete. Il
server VPN deve essere installato in un server pubblico in modo da essere raggiungibile da entrambi i client
e questo comporta una modificazione fondamentale del paradigma di funzionamento della VPN.
La connessione VPN non è più virtuale end-to-end ma una combinazione di due connessioni VPN realizzate
tra i due client con il server centrale. Il server VPN centrale permette ai due client di comunicare tra di loro
attraverso l’applicazione di regole di routing.
Quali sono i vantaggi principali dell’implementazione client-server della VPN di Ubiquity?
Sicurezza. Ubiquity è una reale VPN end-to-end. Il server di rimbalzo, quando usato, non è un partecipante
attivo della connessione. Esso semplicemente esegue il rimbalzo di pacchetti cifrati che non è in grado di
decifrare.
Protocollo leggero e veloce. Permette connessione diretta se possibile.
Nessun collo di bottiglia. I server di rimbalzo sono installati su un gruppo distribuito di macchine in
configurazione load balance. Non esiste un singolo concentratore per la connessione VPN che gestisce tutte
le connessioni VPN, ma ogni sistema remoto utilizza il suo server VPN locale.
7.2 Tecnologia di incapsulamento
In telecomunicazioni e informatica l'Open Systems Interconnection (meglio conosciuto come modello
ISO/OSI) è uno standard de iure per reti di calcolatori stabilito nel 1978 dall'International Organization for
Standardization (ISO), il principale ente di standardizzazione internazionale, che stabilisce per l'architettura
logica di rete una struttura a strati composta da una pila di protocolli di comunicazione suddivisa in 7 livelli, i
quali insieme espletano in maniera logico-gerarchica tutte le funzionalità della rete.
Wikipedia
Pagina 11 di 17
Nota Tecnica
TN0015
OSI Model
Layer
7. Application
Host
layers
6. Presentation
Function
Network process to application
Data representation, encryption and decryption, convert machine dependent data to machine independent
data
5. Session
Interhost communication, managing sessions between applications
4. Transport
End-to-end connections, reliability and flow control
3. Network
Path determination and logical addressing
Media
2. Data link
layers
1. Physical
Physical addressing
Media, signal and binary transmission
La VPN di Ubiquity lavora incapsulando e virtualizzando il livello 2, il data link layer.
Control Center e Runtime installano e gestiscono entrambi un’interfaccia Ethernet virtuale. Il canale di
comunicazione virtuale end-to-end è utilizzato per connettere l’interfaccia virtuale Ubiquity VPN di Control
Center con l’interfaccia VPN del Runtime.
La VPN di Ubiquity, operante con topologia punto-punto e nella quale Control Center può connettersi solo al
dispositivo Runtime, lavora come se le due interfacce fossero collegate attraverso un cavo Ethernet
incrociato.
Ubiquity supporta inoltre lo scenario in cui l’interfaccia VPN del Runtime è configurata in modo bridge con
l’interfaccia fisica del sistema ospite. Il bridge implica che a livello 3 le interfacce fisica e virtuale diventano
un unico nodo.
3. Network (bridged)
(Runtime device IP address)
2. Data link
(Physical Adapter)
2. Data link
(VPN Adapter)
1. Physical
1. Physical
In questo scenario il sistema che ospita il Runtime mantiene il suo indirizzo IP originale ed entrambe le
interfacce, fisica e virtuale, condividono lo stesso livello 3 (IP).
Questo significa che quando la connessione VPN è attiva, tutto ciò che interessa il MAC dell’interfaccia fisica
è catturato dal MAC dell’interfaccia virtuale ed inviato attraverso il canale end-to-end all’interfaccia VPN
virtuale di Control Center.
Quanto è inviato da Control Center all’interfaccia virtuale VPN del Runtime viene anche scritto sull’interfaccia
fisica del sistema che ospita il Runtime realizzando per Control Center una comunicazione bidirezionale con
l’intera sottorete a cui è collegato il dispositivo con il Runtime.
Pagina 12 di 17
Nota Tecnica
TN0015
Il dispositivo con il Runtime e tutti i dispositivi connessi sulla sottorete vedono il PC su cui è in esecuzione
Control Center come se fosse fisicamente connesso ad uno switch locale.
7.3 Assegnazione IP al PC con Control Center
Si è visto come la VPN di Ubiquity è in grado di realizzare una connessione virtuale assimilabile a un cavo
tra il PC con Control Center e lo switch della LAN a cui è connesso il Runtime.
Il PC con Control Center, nello specifico l’adattatore virtuale Ubiquity VPN, ha comunque bisogno di
acquisire un indirizzo IP per utilizzare i protocolli TCP e UDP verso gli indirizzi IP della sottorete remota.
Ubiquity Runtime implementa un semplice meccanismo euristico che gli permette di individuare nella
sottorete cui esso è connesso un indirizzo IP libero, comunicarlo a Control Center e fare quindi in modo che
esso lo assegni all’adattatore virtuale. Questa operazione è svolta in modo trasparente all’utente ad ogni
attivazione della VPN.
Si noti che il PC con Control Center acquisirà un indirizzo IP appartenente alla stessa sottorete cui Ubiquity
Runtime è connesso. Non ci sono regole di IP routing.
Un vantaggio importante di questo approccio sta nel fatto che la configurazione di rete di tutti i sistemi
connessi alla sottorete remota non necessita di includere, come gateway, l’indirizzo IP del sistema con
Ubiquity Runtime.
7.4 Broadcast e supporto per comunicazione con dispositivi non
inizializzati
La tecnologia di incapsulamento utilizzata dalla VPN di Ubiquity permette di supportare i messaggi
broadcast.
I messaggi di tipo UDP broadcast sono tipicamente utilizzati per la comunicazione con dispositivi non ancora
configurati o comunque aventi indirizzo IP al di fuori della sottorete/maschera del PC con l’ambiente di
configurazione.
7.5 Risoluzione conflitto degli indirizzi IP
Una caratteristica peculiare di Ubiquity è quella di realizzare una connessione VPN con bridge anche nel
caso in cui la sottorete del sistema remoto è la medesima di quella del PC su cui è installato Control Center.
Questa situazione causa di norma potenziali ambiguità e conflitti.
Ubiquity è in grado di risolvere l’ambiguità assegnando automaticamente una priorità più elevata
all’interfaccia virtuale VPN.
Il caso pratico è quello per esempio in cui si voglia connettersi ad un PLC con indirizzo IP1 e lo stesso
indirizzo IP1 è assegnato ad un PC nella sottorete a cui appartiene Control Center.
Poiché l’interfaccia Ubiquity VPN ha priorità più alta rispetto all’interfaccia fisica sul PC, il sistema operativo
del PC con Control Center invierà i messaggi attraverso l’interfaccia Ubiquity VPN invece che attraverso
l’interfaccia fisica. Tutti gli indirizzi IP della sottorete remota in potenziale conflitto con uguali indirizzi sulla
sottorete di Control Center saranno accessibili a scapito di quelli locali.
Nel caso particolare il cui l’indirizzo IP del PLC da raggiungere sia lo stesso dell’indirizzo IP del gateway
della sottorete LAN in cui è inserito Control Center, il conflitto è risolto tenendo in considerazione che il
gateway deve ricevere messaggi destinati a sottoreti “esterne” mentre il messaggio da inviare al PLC
prevede come “destinazione” un IP della sottorete. A livello di sistema operativo, un messaggio destinato
alla rete esterna viene quindi inviato al gateway, un messaggio diretto all’IP del gateway viene istradato
sull’interfaccia Ubiquity VPN.
7.6 Connessioni multiple concorrenti
Ubiquity Runtime supporta connessioni multiple VPN con diversi sistemi Control Center.
Tutte le interfacce virtuali dei diversi Control Center ricevono in questo scenario un indirizzo IP compatibile
con la sottorete del Runtime e diventano a tutti gli effetti parte della sottorete remota. Ubiquity implementa i
necessari meccanismi di sicurezza in modo che i diversi Control Center non possono colloquiare tra di loro a
prescindere dal fatto che le loro interfacce virtuali hanno IP appartenenti alla medesima sottorete.
Pagina 13 di 17
Nota Tecnica
TN0015
Not allowed
Control Center 1 : 10.20.0.180
VPN connection
Ubiquity Runtime : 10.20.0.10
PLC : 10.20.0.11
PLC : 10.20.0.12
Not allowed
7.7 Firewall
La VPN di Ubiquity integra un firewall che opera direttamente sui datagram Ethernet al livello 2. Il firewall
permette di definire e applicare regole basate sull’intero contenuto del frame definito dal livello data-link ed è
quindi compatibile con tutti i diversi tipi di protocolli Ethernet e quindi anche con quelli diversi dai protocolli
basati su IP.
8 Esempio di collegamento tipico, con VPN alla sottorete LAN
del PC remoto
PC locale con Ubiquity
Control Center
IP su Ethernet
fisica:
172.18.0.130
PC remoto con Ubiquity Runtime
NAT/Gateway
172.18.0.1
Internet
IP su WAN fisica:
192.168.0.14
Rete WAN PC:
192.168.0.0/255.255.255.0
LAN del supervisore: 172.18.0.0/255.255.0.0
IP su LAN fisica:
10.20.0.1
(con bridge VPN)
LAN di Automazione
10.20.0.0/255.255.0.0
IP virtuale temporaneo su
Ethernet virtuale:
10.20.0.180
PLC
10.20.0.100
Connessione VPN
Pagina 14 di 17
Nota Tecnica
TN0015
Come si vede dalla figura, il PC di teleassistenza con Ubiquity Control Center è dotato di due interfacce di
rete: una scheda fisica (172.18.0.130) per collegarsi alla rete aziendale e una scheda virtuale (10.20.0.180)
per collegarsi alla VPN.
Questa scheda virtuale “riceve” in automatico, nel momento della connessione VPN, un IP (10.20.0.180)
appartenente alla stessa sottorete “LAN” remota (10.20.0.0). Questo permette agli applicativi in esecuzione
sul PC di supervisione di raggiungere tutti gli IP remoti.
La LAN remota è configurata in bridge con la scheda VPN di Ubiquity, che diventano una unica interfaccia
con un solo IP (10.20.0.1).
9 Risk assesment
9.1 PC remoto infettato da virus
Se ipotizziamo che il PC remoto sia infettato da virus, e con collegamento VPN attivo, è in teoria possibile
che un potenziale virus in esecuzione sul PC remoto possa contattare servizi server in esecuzione sulla
macchina di assistenza (172.18.0.130). Nell’ipotesi ad esempio che il PC di assistenza non sia aggiornato
alle ultime patch di sicurezza, il virus potrebbe utilizzare falle conosciute per effettuare attacchi di tipo buffer
overflow e prendere il controllo della macchina.
L’infezione del PC remoto può avere le origini e le motivazioni più disparate. Ubiquity Runtime mantiene
aperta una connessione puntuale SSL con l’infrastruttura server ma non espone alcun servizio attaccabile.
L’intromissione di un qualsiasi elemento esterno in un tunnel SSL non è uno scenario realistico. La presenza
invece di servizi in ascolto su una determinata porta e la contemporanea presenza di falle nel sistema
operativo possono invece rappresentare l’origine del punto di attacco del virus.
Alla luce di queste considerazioni il PC remoto sull’impianto può essere protetto attraverso l’adozione di
alcuni semplici accorgimenti:
 le porte 80 e 443 potrebbero essere mantenute chiuse; Ubiquity utilizzerà la porta custom 5935.
Questo impedisce eventuale navigazione web con browser potenziamente non sicuri.
 se il PC è in rete con altri dispositivi considerabili “meno sicuri” o potenzialmente pericolosi, oltre al
firewall esterno, utilizzare un firewall software sul PC per impedire qualsiasi comunicazione entrante
e uscente (che non provenga dal software Ubiquity)
 chiudere qualsiasi servizio server di sistema non necessario: condivisione di file, remote desktop,
FTP server, VNC server, ecc. Ubiquity include già tutte le più comuni funzioni per operare da remoto
 rimuovere anche qualsiasi applicazione client non necessaria
 eseguire eventuali software HMI/SCADA come utenti Windows limitati; questo impedisce a priori alla
maggior parte dei malware e virus di funzionare. Il supervisore Ubiquity può comunque intervenire
come Administrator di Windows all’occorrenza
 mantenere se possibile il sistema operativo aggiornato alle ultime patch relative alla sicurezza
9.1.1 Precondizioni per l’attacco
Riassumiamo quindi i requisiti perché il virus possa propagarsi:
1.
Sistema remoto infettato
2.
PC locale con exploit conosciuti o sconosciuti e servizi server aperti (es. condivisione file di
Windows)
3.
VPN tra PC remoto e PC locale
9.1.2 Soluzione 1: firewall su PC locale di supervisione
E’ possibile configurare un firewall software sul PC di supervisione, in particolare sulla scheda virtuale
installata da Ubiquity.
Il firewall va configurato per lasciare passare solo i protocolli necessari al lavoro remoto (es. software di
programmazione di PLC) e impedendo tutto il resto (es. protocollo Netbios, condivisione file di Windows
ecc).
In questo modo cade la precondizione 3, poiché il canale VPN non diventa più sfruttabile dal virus.
Pagina 15 di 17
Nota Tecnica
TN0015
9.1.3 Soluzione 2: firewall integrato in Ubiquity
Ubiquity permette la configurazione di quali protocolli e/o indirizzi IP sono raggiungibili tramite VPN. Questa
configurazione può essere creata solo da un amministratore della sicurezza del dominio Ubiquity e può
essere anche associata in modo specifico ad alcuni utenti e/o macchine remote.
La configurazione può procedere su due fronti alternativi:
Configurazione tramite indirizzi IP
Configurazione tramite porte e protocolli
9.1.3.1 Soluzione 2.1 - Configurazione tramite indirizzi IP
Si configurano gli indirizzi IP remoti interessati alla VPN.
La parte interessante per lo scenario specifico è che pur utilizzando il sistema remoto come gateway della
VPN verso la LAN di automazione, si può configurare la VPN stessa in modo che interessi solo il PLC
(10.20.0.100) e non interessi affatto il sistema dove Ubiquity Runtime è in esecuzione (10.20.0.1).
Nell’esempio, la VPN potrebbe essere quindi solamente tra il PC locale (10.20.0.180) e il PLC remoto
(10.20.0.100).
Del PC remoto (10.20.0.1) viene sfruttato il canale fisico (collegamento Ethernet allo switch LAN), ma esso
non viene interessato all’instradamento IP nella VPN. In tal modo non può esistere comunicazione tra virus
in esecuzione su quel PC e il PC locale di supervisione.
9.1.3.2 Soluzione 2.2 - Configurazione tramite porte e protocolli
Si istruisce la VPN di Ubiquity affinché effettui la “remotazione” solo di alcuni numeri di porta o di alcuni
protocolli, ad esempio solo il numero di porta interessato alla comunicazione del software di
programmazione del PLC.
Questa configurazione ha lo stesso effetto della soluzione 1, ma elimina il problema a monte (i pacchetti
“pericolosi” non partono nemmeno dal sistema remoto) invece che a valle (i pacchetti transitano nel tunnel
VPN, ma poi non escono grazie al firewall).
Di fatto il canale VPN non diventa più una remotazione generica e trasparente della rete, ma diventa un
canale specifico dedicato solo alle applicazioni interessate alla teleassistenza.
L’approccio 2.1 è il più semplice, ma può non essere configurabile in modo uguale per tutte le installazioni,
salvo che non si utilizzino sempre PLC con gli stessi IP statici.
L’approccio 2.2 è il più generale e può essere configurato una tantum indipendentemente dalle installazioni
remote, poiché si basa sulla selezione dei protocolli invece che sugli indirizzi IP.
L’approccio 2.2 richiede di conoscere in anticipo le porte/protocolli usati dai software interessati alla
teleassistenza. Se questi non sono conosciuti, è necessaria una breve analisi con software quali Wireshark
per risalire a queste informazioni.
9.2 Attacco man-in-the-middle
I client Ubiquity comunicano con i server tramite protocollo SSL/TLS. L’identità del server è garantita da un
certificato firmato da una certification authority conosciuta dai client.
Nel caso i client non riconoscano correttamente il certificato del server (ad esempio un attaccante si è
frapposto tra client e server e si sta spacciando per il server), è segnalata l’informazione all’utente che può
decidere se collegarsi lo stesso o verificare il collegamento con il suo responsabile IT.
Nel caso che l’attaccante non stia cercando di sostituirsi al server, ma stia monitorando passivamente il
traffico, non avrebbe alcuna possibilità di decodificarne il contenuto, poiché le informazioni sono crittografate
in modo sicuro end-to-end.
9.3 Attacco di tipo brute force
Un attaccante potrebbe utilizzare Control Center o una versione “manomessa” al fine di tentare in modo
manuale o automatico di indovinare la password di accesso.
Questo attacco non è attuabile in pratica poiché l’infrastruttura server blocca tentativi di accesso con
password dopo un numero molto limitato di tentativi errati, dopo i quali occorre attendere un tempo
predeterminato di “sblocco”.
Pagina 16 di 17
Nota Tecnica
TN0015
9.4 Furto password
L’autenticazione tramite utente e password è utilizzata per verificare l’identità dell’utente di Control Center.
Per limitare il rischio di furto delle credenziali di accesso, sono adottate le seguenti contromisure:
 L’infrastruttura server obbliga all’utilizzo di una password con lunghezza minima.
 La password non è salvata localmente sul PC con Control Center. Da un lato è più scomodo dovere
reinserire la password ad ogni accesso, ma dall’altro non si corre il rischio di fare conoscere la
password a chi possa ottenere l’accesso fisico del PC.
 La password in chiaro non è salvata nemmeno sui server: è conservata una versione trasformata
della password con un algoritmo di hashing. La metodologia di gestione di questi hash è dotata
anche di protezione contro gli attacchi di tipo rainbow table.
Pagina 17 di 17

Whitepaper - Architettura Ubiquity

Transcript

Documenti analoghi

VPN acronimo di Virtual Privat Network. VPN, che

La VPN SSL di Juniper in 6 slide

TAVOLA DEGLI SVILUPPI DI TAYLOR DELLE FUNZIONI

ubiquity 4

la condivisione online degli archivi contabili su pc remoto

Scarica la scheda tecnica

Reason 442: Failed to enable Virtual Adapter Cisco VPN Client su

MODALITA` DI CONFIGURAZIONE DI UNA VPN IN AMBIENTE MAC