Difesa dagli attacchi
La figura seguente mostra i componenti di virtualizzazione che compongono l'ambiente di esecuzione di Oracle VM Server per SPARC. Questi componenti non sono rigorosamente separati. La configurazione più semplice consiste nel combinare tutte queste funzioni in un singolo dominio. Il dominio di controllo può fungere anche da dominio I/O e da dominio di servizio per altri domini.
Figura 1-3 Componenti dell'ambiente di esecuzione
Si supponga che un intruso tenti di violare l'isolamento del sistema e di manipolare quindi l'hypervisor o un altro componente dell'ambiente di esecuzione per raggiungere un dominio guest. È necessario proteggere ciascun dominio guest come se si trattasse di un server standalone.
Nella parte restante di questo capitolo sono illustrate le possibili minacce e le diverse misure che è possibile intraprendere per respingerle. Ciascuno di questi attacchi è volto a vincere o eliminare l'isolamento dei diversi domini in esecuzione in una singola piattaforma. Nelle sezioni successive sono descritte le minacce a ciascuna parte di un sistema Oracle VM Server per SPARC.
Ambiente operativo
L'ambiente operativo include sistemi fisici e relativi componenti, responsabili dell'architettura dei centri dati, amministratori e membri dell'organizzazione IT. Una violazione della sicurezza può verificarsi in qualsiasi componente dell'ambiente operativo.
La virtualizzazione inserisce un livello software tra l'hardware effettivo e i domini guest su cui sono in esecuzione i servizi di produzione, per aumentare la complessità. È pertanto necessario pianificare e configurare con estrema attenzione il sistema virtuale e cercare di evitare l'errore umano. Cercare anche di evitare i tentativi degli intrusi di ottenere l'accesso all'ambiente operativo utilizzando il "social engineering".
Nelle sezioni seguenti sono descritte le diverse minacce che è possibile respingere a livello di ambiente operativo.
Minaccia: errore di configurazione involontario
La preoccupazione principale correlata alla sicurezza per un ambiente virtualizzato consiste nel mantenere l'isolamento del server separando i segmenti di rete, isolando l'accesso amministrativo e implementando i server in classi di sicurezza, ossia gruppi di domini con gli stessi requisiti e privilegi di sicurezza.
Creazione di canali di comunicazione non necessari tra domini guest di produzione e ambiente di esecuzione
Creazione di accesso non necessario ai segmenti di rete
Creazione di connessioni involontarie tra classi di sicurezza discrete
Migrazione involontaria di un dominio guest alla classe di sicurezza errata
Allocazione di hardware insufficiente, che può portare a sovraccarico imprevisto delle risorse
Assegnazione di dischi o dispositivi I/O al dominio errato
Configurare con attenzione le risorse virtuali per evitare alcuni degli errori elencati di seguito.
Contromisura: creazione di linee guida operative
Gestione di patch per tutti i componenti dell'ambiente
Abilitazione dell'implementazione sicura, ben definita e riscontrabile delle modifiche
Controllo dei file di log a intervalli regolari
Monitoraggio dell'integrità e della disponibilità dell'ambiente
Prima di iniziare, definire attentamente le linee guida operative per l'ambiente Oracle VM Server per SPARC. In queste linee guida sono descritte le attività riportate di seguito e le relative modalità di esecuzione.
Eseguire regolarmente i controlli per accertarsi che queste linee guida rimangano aggiornate e adeguate e per verificare che vengano seguite nelle operazioni quotidiane.
Oltre a queste linee guida, è possibile intraprendere diverse altre misure tecniche per ridurre il rischio di azioni involontarie. Vedere Logical Domains Manager.
Minaccia: errori nell'architettura dell'ambiente virtuale
Quando si sposta un sistema fisico in un ambiente virtualizzato, in genere è possibile lasciare invariata la configurazione riutilizzando i LUN originali. È tuttavia necessario adattare la configurazione di rete all'ambiente virtualizzato e l'architettura risultante potrebbe essere notevolmente diversa rispetto a quella utilizzata nel sistema fisico.
È necessario considerare come mantenere l'isolamento delle classi di sicurezza discrete e le relative esigenze. Considerare inoltre l'hardware condiviso della piattaforma e i componenti condivisi come i switch di rete e i switch SAN.
Per ottimizzare la sicurezza dell'ambiente, accertarsi di mantenere l'isolamento dei domini guest e delle classi di sicurezza. Quando si progetta l'architettura, prevedere i possibili errori e attacchi e implementare le opportune linee di difesa. Un buon progetto consente di limitare i potenziali problemi di sicurezza e di gestire complessità e costi.
Contromisura: assegnazione attenta di guest a piattaforme hardware
Utilizzare le classi di sicurezza, ossia gruppi di domini caratterizzati dagli stessi requisiti e privilegi di sicurezza, per isolare i singoli domini gli uni dagli altri. Se si assegnano domini guest inclusi nella stessa classe di sicurezza a una determinata piattaforma hardware, anche in caso di violazione dell'isolamento l'attacco non potrà penetrare in un'altra classe di sicurezza.
Contromisura: pianificazione di una migrazione al dominio Oracle VM Server per SPARC
La funzione di migrazione del dominio in tempo reale ha il potenziale di rompere l'isolamento qualora venga inavvertitamente eseguita la migrazione di un dominio guest a una piattaforma assegnata a una classe di sicurezza diversa, come mostra la figura seguente. Pianificare pertanto con attenzione la migrazione del dominio guest in modo da accertarsi che non sia consentita una migrazione che superi i confini delle classi di sicurezza.
Figura 1-4 Migrazione del dominio che supera i confini di sicurezza
Per ridurre o eliminare il problema della vulnerabilità della sicurezza posto dall'operazione di migrazione, è necessario eseguire manualmente lo scambio e installare i certificati host generati con il comando ldmd fuori banda all'interno di ogni coppia costituita da sistema di origine e sistema di destinazione. Per informazioni su come configurare i certificati SSL, vedere Configuring SSL Certificates for Migration in Oracle VM Server for SPARC 3.3 Administration Guide .
Contromisura: configurazione corretta delle connessioni virtuali
Se si perde traccia di tutte le connessioni di rete virtuali, è possibile che un dominio ottenga erroneamente l'accesso a un segmento di rete. Tale accesso potrebbe ad esempio eludere il firewall o una classe di sicurezza.
Per ridurre il rischio di errori di implementazione, pianificare e documentare attentamente tutte le connessioni virtuali e fisiche nell'ambiente. Ottimizzare il piano di connessione del dominio in modo da garantire semplicità e facilità di gestione. Documentare in modo chiaro il piano e verificare l'esattezza dell'implementazione a fronte del piano prima di passare alla produzione. Anche dopo avere avviato la produzione dell'ambiente virtuale, verificare l'implementazione a fronte del piano a intervalli regolari.
Contromisura: uso di tag della VLAN
È possibile utilizzare i tag della VLAN per consolidare più segmenti Ethernet in una singola rete fisica. Questa funzione è disponibile anche per gli switch virtuali. Per ridurre i rischi impliciti negli errori software che si verificano durante l'implementazione degli switch virtuali, configurare uno switch virtuale per ciascun NIC fisico e VLAN. Come ulteriore protezione dagli errori del driver Ethernet, evitare di utilizzare VLAN con tag. La probabilità che si verifichino questi errori è tuttavia ridotta in quanto la vulnerabilità della VLAN con tag è ben nota. I test di intrusione sulla piattaforma Sun SPARC T-Series di Oracle con il software Oracle VM Server per SPARC non hanno mostrato questa vulnerabilità.
Contromisura: uso di appliance di sicurezza virtuali
Le appliance di sicurezza come i filtri pacchetti e i firewall sono strumenti di isolamento e proteggono l'isolamento delle classi di sicurezza. Poiché queste appliance sono soggette alle stesse minacce di tutti gli altri domini guest, il relativo utilizzo non garantisce una protezione completa da una violazione dell'isolamento. Considerare pertanto attentamente tutti gli aspetti di rischio e sicurezza prima di decidere di virtualizzare un servizio di questo tipo.
Minaccia: effetti collaterali della condivisione delle risorse
La condivisione delle risorse in un ambiente virtualizzato può portare ad attacchi di negazione del servizio (DoS, Denial of Service), che determinano il sovraccarico di una risorsa fino a ottenere un effetto negativo su un altro componente, ad esempio un altro dominio.
Tramite allocazione delle aree della cache condivise tra settori e assegnate a due domini guest
Tramite sovraccarico della larghezza di banda della memoria
In un ambiente Oracle VM Server per SPARC un attacco DoS può avere effetto solo su alcune risorse. Le risorse di CPU e memoria vengono assegnate in modo esclusivo a ciascun dominio guest, per impedire la maggior parte degli attacchi DoS. Persino l'assegnazione esclusiva di queste risorse può rallentare un dominio guest nei modi indicati di seguito.
A differenza delle risorse di CPU e memoria, i servizi di rete e su disco vengono in genere condivisi tra domini guest. Questi servizi vengono forniti ai domini guest da uno o più domini di servizio. Considerare attentamente come assegnare e distribuire queste risorse ai domini guest. Tenere presente che tutte le configurazioni che offrono massime prestazioni e utilizzo delle risorse riducono al contempo il rischio di effetti collaterali.
Valutazione: effetti collaterali dovuti alle risorse condivise
È possibile che un collegamento di rete diventi saturo o che un disco venga sovraccaricato, indipendentemente dal fatto che sia assegnato a un dominio o condiviso tra più domini. Ciò incide negativamente sulla disponibilità di un servizio per tutta la durata dell'attacco. L'obiettivo dell'attacco non viene compromesso e non si verifica alcuna perdita di dati. È possibile ridurre gli effetti di questa minaccia, ma è necessario tenerla presente anche se si limita alle risorse di rete e su disco di Oracle VM Server per SPARC.
Contromisura: assegnazione attenta di risorse hardware
Accertarsi di assegnare solo le risorse hardware necessarie ai domini guest. Annullare l'assegnazione di una risorsa inutilizzata quando questa non è più necessaria, ad esempio, una porta di rete o un'unità DVD necessaria solo durante un'installazione. Questa pratica consente di ridurre il numero di possibili punti di accesso per un attacco.
Contromisura: assegnazione attenta di risorse condivise
Le risorse hardware condivise, come le porte di rete fisiche, costituiscono un obiettivo possibile per gli attacchi DoS. Per limitare l'impatto degli attacchi DoS a un solo gruppo di domini guest, determinare attentamente i domini guest e le risorse hardware da questi condivise.
I domini guest che condividono risorse hardware, ad esempio, possono essere raggruppati in base alla disponibilità o ai requisiti di sicurezza comuni. Oltre al raggruppamento, è possibile applicare diversi tipi di controlli delle risorse.
È necessario considerare come condividere le risorse su disco e di rete. È possibile ridurre i problemi separando l'accesso al disco tramite percorsi di accesso fisico dedicati o servizi su disco virtuali dedicati.
Riepilogo: effetti collaterali dovuti alle risorse condivise
Tutte le contromisure descritte in questa sezione richiedono la comprensione dei dettagli tecnici dell'implementazione e le relative implicazioni in termini di sicurezza. Eseguire con attenzione le operazioni di pianificazione e documentazione e creare un'architettura il più semplice possibile. Accertarsi di comprendere le implicazioni dell'hardware virtualizzato in modo da prepararsi a un'implementazione sicura del software Oracle VM Server per SPARC.
I domini logici sono resistenti agli effetti della condivisione di CPU e memoria, in quanto richiedono una condivisione effettiva ridotta. Ciò nonostante, è preferibile applicare controlli delle risorse come la gestione delle risorse Solaris all'interno dei domini guest. Questi controlli offrono protezione da comportamenti errati dell'applicazione, sia per un ambiente virtuale che per un ambiente non virtualizzato.
Ambiente di esecuzione
La Figure 1–3 mostra i componenti dell'ambiente di esecuzione. Ciascun componente fornisce determinati servizi, che insieme compongono la piattaforma generale su cui eseguire i domini guest di produzione. Una configurazione corretta dei componenti è di vitale importanza per l'integrità del sistema.
Tutti i componenti dell'ambiente di esecuzione sono potenziali obiettivi di attacco. In questa sezione sono descritte le minacce a cui può essere esposto ciascun componente nell'ambiente di esecuzione. Alcune minacce e contromisure possono interessare più componenti.
Minaccia: manipolazione dell'ambiente di esecuzione
La manipolazione dell'ambiente di esecuzione offre molti modi per ottenere il controllo. È possibile, ad esempio, installare il firmware manipolato in ILOM per esaminare tutti gli I/O del dominio guest da un dominio I/O. Con questo tipo di attacco è possibile accedere alla configurazione del sistema e modificarla. Un intruso che assume il controllo del dominio di controllo di Oracle VM Server per SPARC può riconfigurare il sistema in qualsiasi modo, mentre un intruso che assume il controllo di un dominio I/O può apportare modifiche ai dispositivi di memorizzazione collegati, come i dischi di boot.
Valutazione: manipolazione dell'ambiente di esecuzione
Un intruso che riesce a violare ILOM o qualsiasi altro dominio nell'ambiente di esecuzione può leggere e manipolare tutti i dati disponibili per tale dominio. Questo accesso può avvenire dalla rete o mediante un errore nello stack di virtualizzazione. Questo tipo di attacco è difficile da eseguire in quanto in genere ILOM e i domini non possono essere attaccati direttamente.
Le contromisure per la protezione dalla manipolazione dell'ambiente di esecuzione sono pratiche di sicurezza standard e devono essere implementate in ogni sistema. Le pratiche di sicurezza standard offrono un livello di protezione aggiuntivo attorno all'ambiente di esecuzione che riduce ulteriormente il rischio di intrusione e manipolazione.
Contromisura: protezione dei percorsi di accesso interattivi
Accertarsi di creare solo gli account necessari per le applicazioni in esecuzione sul sistema.
Accertarsi che gli account necessari per l'amministrazione siano protetti utilizzando l'autenticazione basata su chiave o password sicure. Tali chiavi o password non devono essere condivise tra domini diversi. Considerare anche la possibilità di implementare l'autenticazione a due fattori o una "regola dei due operatori" per eseguire determinate azioni.
Non utilizzare login anonimi per account come l'account root in modo da garantire la completa tracciabilità e responsabilità dell'esecuzione dei comandi nel sistema. Utilizzare piuttosto i diritti per concedere ai singoli amministratori solo l'accesso alle funzioni che sono autorizzati a eseguire. Accertarsi che l'accesso amministrativo alla rete utilizzi sempre una cifratura come SSH e che la workstation di un amministratore sia considerata un sistema ad elevata sicurezza.
Contromisura: riduzione di SO Oracle Solaris
Poiché qualsiasi componente software installato in un sistema può essere compromesso, accertarsi di installare solo il software necessario, per ridurre la possibilità di violazioni.
Contromisura: rafforzamento di SO Oracle Solaris
Oltre a installare una versione ridotta di SO Oracle Solaris, configurare pacchetti software finalizzati al rafforzamento del software contro gli attacchi. Eseguire in primo luogo un numero limitato di servizi di rete per disabilitare in modo efficace tutti i servizi di rete ad eccezione di SSH. Questo criterio corrisponde al comportamento predefinito nei sistemi Oracle Solaris 11. Per informazioni su come proteggere SO Oracle Solaris, vedere Oracle Solaris 10 Security Guidelines e Oracle Solaris 11 Security Guidelines .
Contromisura: uso della separazione dei ruoli e dell'isolamento dell'applicazione
Le applicazioni di produzione sono necessariamente collegate ad altri sistemi e sono pertanto più esposte agli attacchi esterni. Non implementare applicazioni di produzione in un dominio incluso nell'ambiente di esecuzione. Accertarsi piuttosto di implementarle solo nei domini guest privi di ulteriori privilegi.
L'ambiente di produzione deve fornire solo l'infrastruttura necessaria per questi domini guest. La separazione dell'ambiente di esecuzione dalle applicazioni di produzione consente di implementare la granularità nei privilegi di amministrazione. L'amministratore di un dominio guest di produzione non ha bisogno dell'accesso all'ambiente di esecuzione e l'amministratore di un ambiente di esecuzione non ha bisogno dell'accesso ai domini guest di produzione. Se possibile, assegnare i diversi ruoli dell'ambiente di esecuzione, come il dominio di controllo e il dominio I/O, a domini diversi. Questo tipo di configurazione riduce la quantità di danni che possono essere causati in caso di compromissione di uno qualsiasi di questi domini.
È anche possibile estendere la separazione dei ruoli all'ambiente di rete utilizzato per collegare i diversi server.
Contromisura: configurazione di una rete di gestione dedicata
Collegare tutti i server dotati di processori di servizio (SP) a una rete di gestione dedicata. Questa configurazione è consigliata anche per i domini dell'ambiente di esecuzione. Se questi domini sono in rete, ubicarli nella propria rete dedicata. Non collegare i domini dell'ambiente di esecuzione direttamente alle reti assegnate ai domini di produzione. Sebbene sia possibile eseguire tutte le attività di amministrazione tramite la singola connessione alla console disponibile dall'SP ILOM, questa configurazione rende l'amministrazione talmente scomoda da risultare impraticabile. La separazione della rete di produzione da quella di amministrazione offre protezione dalle intercettazioni e dalle manipolazioni. Questo tipo di separazione elimina anche la possibilità di attacco nell'ambiente di esecuzione dai domini guest della rete condivisa.
Figura 1-5 Rete di gestione dedicata
ILOM
Gestione di controlli ambientali di base come la velocità della ventola e l'alimentazione dello chassis
Abilitazione di aggiornamenti firmware
Disponibilità della console di sistema per il dominio di controllo
Tutti i sistemi SPARC Oracle correnti includono un controller di sistema incorporato (ILOM), dotato delle funzionalità elencate di seguito.
È possibile accedere a ILOM tramite una connessione seriale o da una porta di rete mediante SSH, HTTP, HTTPS, SNMP o IPMI. I Server Fujitsu M10 utilizzano XSCF anziché ILOM per eseguire funzioni simili.
Minaccia: negazione del servizio del sistema completo
Disattivazione di tutti i domini guest in esecuzione
Installazione di firmware manipolato per ottenere l'accesso ad almeno un dominio guest
Un intruso che assume il controllo di ILOM può compromettere il sistema in molti modi, inclusi quelli elencati di seguito.
Questi scenari possono verificarsi in qualsiasi sistema dotato di un dispositivo di controllo di questo tipo. In un ambiente virtualizzato il danno può essere notevolmente maggiore rispetto a un ambiente fisico in quanto molti domini ospitati nello stesso system enclosure sono a rischio.
Allo stesso modo, un intruso che assume il controllo del dominio di controllo o di un dominio I/O può facilmente disabilitare tutti i domini guest dipendenti arrestando i servizi I/O corrispondenti.
Valutazione: negazione del servizio del sistema completo
Sebbene ILOM sia in genere collegato a una rete amministrativa, è possibile accedervi anche dal dominio di controllo utilizzando IPMI con il modulo di accesso BMC. È pertanto importante che entrambi questi tipi di connessione siano ben protetti e isolati dalle reti di produzione normali.
Allo stesso modo, un intruso può violare un dominio di servizio dalla rete o tramite un errore nello stack di virtualizzazione, quindi bloccare gli I/O guest o eseguire un arresto di sistema. Sebbene il danno sia limitato in quanto non comporta perdita né compromissione dei dati, esso può avere un effetto negativo su molti domini guest. Garantire pertanto la protezione dalla possibilità di questa minaccia per limitare il danno potenziale.
Contromisura: protezione di ILOM
Posizionamento della porta di rete di ILOM in un segmento di rete separato dalla rete amministrativa, utilizzata per i domini nell'ambiente di esecuzione.
Disabilitazione di tutti i servizi non necessari per il funzionamento, come HTTP, IPMI, SNMP, HTTPS e SSH.
Configurazione di account dedicati e personali degli amministratori per concedere solo i diritti necessari. Per massimizzare la responsabilità delle azioni eseguite dagli amministratori, accertarsi di creare account personali per gli amministratori. Questo tipo di accesso è particolarmente importante per l'accesso della console, gli aggiornamenti firmware e la gestione delle configurazioni di avvio.
In qualità di processore di servizio del sistema, ILOM controlla funzioni critiche quali l'alimentazione dello chassis, le configurazioni di avvio di Oracle VM Server per SPARC e l'accesso della console al dominio di controllo. Le misure elencate di seguito consentono di proteggere ILOM.
Hypervisor
Hypervisor effettivo, implementato nel firmware e supportato dalle CPU del sistema.
Moduli kernel eseguiti nel dominio di controllo per la configurazione dell'hypervisor.
Moduli kernel e daemon eseguiti nei domini I/O e nei domini di servizio per fornire l'I/O virtualizzato, nonché moduli kernel che comunicano mediante Logical Domain Channel (LDC).
Moduli kernel e driver di dispositivi in esecuzione nei domini guest per l'accesso ai dispositivi I/O virtualizzati, nonché moduli kernel che comunicano mediante LDC.
L'hypervisor è il livello di firmware per l'implementazione e il controllo della virtualizzazione dell'hardware effettivo. L'hypervisor include i componenti elencati di seguito.
Minaccia: violazione dell'isolamento
Un intruso può eseguire l'hijack dei domini guest o dell'intero sistema violando l'ambiente runtime isolato offerto dall'hypervisor. Potenzialmente, questa minaccia può causare il danno più grave a un sistema.
Valutazione: violazione dell'isolamento
La struttura di un sistema modulare può migliorare l'isolamento concedendo livelli diversi di privilegi a domini guest, all'hypervisor e al dominio di controllo. Ciascun modulo funzionale viene implementato in un modulo kernel, driver di dispositivo o daemon separato e configurabile. Questa modularità richiede API chiare e protocolli di comunicazione semplici per ridurre il rischio generale di errori.
Anche se lo sfruttamento di un errore sembra improbabile, il danno potenziale può portare al controllo dell'intero sistema da parte dell'intruso.
Contromisura: convalida di firme software e firmware
Sebbene sia possibile scaricare le patch del firmware di sistema e del SO direttamente da un sito Web Oracle, tali patch possono essere manipolate. Prima di installare il software, verificare i checksum MD5 dei pacchetti software. I checksum di tutti i componenti software scaricabili sono pubblicati da Oracle.
Contromisura: convalida dei moduli kernel
Oracle VM Server per SPARC utilizza diversi driver e moduli kernel per implementare il sistema di virtualizzazione generale. Tutti i moduli kernel e la maggior parte dei binari distribuiti con SO Oracle Solaris sono dotati di una firma digitale. Utilizzare la utility elfsign per controllare la firma digitale di ciascun modulo kernel e driver. È possibile utilizzare il comando pkg verify di Oracle Solaris 11 per controllare l'integrità del binario di Oracle Solaris. Vedere https://blogs.oracle.com/cmt/entry/solaris_fingerprint_database_how_it.
È necessario in primo luogo stabilire l'integrità della utility elfsign. Utilizzare lo strumento di audit e reporting di base (BART, Basic Audit and Reporting Tool) per automatizzare il processo di verifica della firma digitale. In Integrating BART and the Solaris Fingerprint Database in the Solaris 10 Operating System viene descritto come combinare lo strumento BART e Solaris Fingerprint Database per eseguire automaticamente controlli dell'integrità simili. Sebbene Fingerprint Database non sia più in produzione, i concetti descritti in questo documento possono essere adottati per un uso simile di elfsign e BART.
Dominio di controllo
Il dominio di controllo, che spesso svolge il ruolo di un dominio I/O e di un dominio di servizio, deve essere protetto in quanto può modificare la configurazione dell'hypervisor, che controlla tutte le risorse hardware collegate.
Minaccia: negazione del servizio del dominio di controllo
L'arresto del dominio di controllo può determinare la negazione di servizio degli strumenti di configurazione. Poiché i domini di controllo sono necessari solo per le modifiche alla configurazione, i domini guest non sono coinvolti se dispongono dell'accesso alla rete e alle risorse su disco tramite altri domini di servizio.
Valutazione: negazione del servizio del dominio di controllo
L'attacco al dominio di controllo mediante la rete è equivalente all'attacco di qualsiasi altra istanza di SO Oracle Solaris protetta in modo appropriato. Il danno derivante da un arresto o da una simile negazione di servizio del dominio di controllo è relativamente ridotto. I domini guest rimangono tuttavia coinvolti se il dominio di controllo funge anche da dominio di servizio per tali domini guest.
Contromisura: protezione dell'accesso della console
Evitare di configurare l'accesso della rete amministrativa ai domini dell'ambiente di esecuzione. Questo scenario richiede l'uso del servizio console di ILOM nel dominio di controllo per eseguire tutte le attività di amministrazione. L'accesso della console a tutti gli altri domini è comunque possibile utilizzando il servizio vntsd in esecuzione nel dominio di controllo.
Considerare attentamente questa opzione. Sebbene questa opzione riduca il rischio di attacco tramite la rete amministrativa, l'accesso alla console sarà consentito a un solo amministratore alla volta.
Per informazioni sulla configurazione sicura di vntsd, vedere How to Enable the Virtual Network Terminal Server Daemon in Oracle VM Server for SPARC 3.3 Administration Guide .
Logical Domains Manager
Logical Domains Manager viene eseguito nel dominio di controllo e consente di configurare l'hypervisor, nonché di creare e configurare tutti i domini e le relative risorse hardware. Accertarsi che l'uso di Logical Domains Manager sia protetto da login e sia monitorato.
Minaccia: uso non autorizzato delle utility di configurazione
Un intruso potrebbe assumere il controllo dell'ID utente di un amministratore oppure un amministratore di un gruppo diverso potrebbe ottenere l'accesso non autorizzato a un altro sistema.
Valutazione: uso non autorizzato delle utility di configurazione
Per accertarsi che a un amministratore non sia concesso l'accesso superfluo a un sistema, implementare un'efficace gestione delle identità. Implementare anche un controllo dell'accesso rigido e specifico e altre misure come la regola dei due operatori.
Contromisura: applicazione della regola dei due operatori
Considerare la possibilità di implementare la regola dei due operatori per Logical Domains Manager e per altri strumenti amministrativi utilizzando i diritti. Applicazione di una regola dei due operatori utilizzando Solaris 10 RBAC. Questa regola protegge da attacchi di social engineering, compromissione degli account amministrativi ed errori umani.
Contromisura: uso dei diritti per Logical Domains Manager
L'uso dei diritti per il comando ldm consente di implementare un controllo dell'accesso specifico e di mantenere una tracciabilità completa. Per informazioni sulla configurazione dei diritti, vedere Oracle VM Server for SPARC 3.3 Administration Guide . L'uso dei diritti facilita la tutela dagli errori umani in quanto consente di scegliere le funzioni del comando ldm da rendere disponibili e gli amministratori autorizzati a utilizzarle.
Contromisura: rafforzamento di Logical Domains Manager
Disabilitare i servizi di gestione dei domini non necessari. Logical Domains Manager offre servizi di rete per l'accesso, il monitoraggio e la migrazione dei domini. La disabilitazione dei servizi di rete riduce i punti di vulnerabilità agli attacchi di Logical Domains Manager al minimo necessario per un funzionamento normale. Questo scenario consente di contrastare gli attacchi di negazione del servizio e altri tentativi di uso improprio dei servizi di rete.
Nota - Sebbene la disabilitazione dei servizi di gestione dei domini aiuti a ridurre i punti di vulnerabilità agli attacchi, non è possibile conoscere preventivamente tutti gli effetti collaterali di questa operazione nelle diverse configurazioni specifiche.
Servizio di migrazione sulla porta TCP 8101
Per disabilitare questo servizio, vedere la descrizione delle proprietà ldmd/incoming_migration_enabled e ldmd/outgoing_migration_enabled nella pagina man ldmd(1M).
Supporto del protocollo XMPP (Extensible Messaging and Presence Protocol) sulla porta TCP 6482
Per informazioni su come disabilitare questo servizio, vedere XML Transport in Oracle VM Server for SPARC 3.3 Administration Guide .
La disabilitazione di XMPP impedisce il funzionamento di alcuni strumenti di gestione e funzioni chiave di Oracle VM Server per SPARC. Vedere Interfaccia XML di Oracle VM Server per SPARC.
Protocollo SNMP (Simple Network Management Protocol) sulla porta UDP 161
Abilitare il servizio SNMP per utilizzare MIB di Oracle VM Server per SPARC. Installare in modo sicuro MIB di Oracle VM Server per SPARC. Vedere How to Install the Oracle VM Server for SPARC MIB Software Package in Oracle VM Server for SPARC 3.3 Administration Guide e Managing Security in Oracle VM Server for SPARC 3.3 Administration Guide .
Disabilitare il servizio SNMP. Per informazioni su come disabilitare questo servizio, vedere How to Remove the Oracle VM Server for SPARC MIB Software Package in Oracle VM Server for SPARC 3.3 Administration Guide .
Determinare se si desidera utilizzare MIB (Management Information Base) di Oracle VM Server per SPARC per osservare i domini. Questa funzione richiede l'abilitazione del servizio SNMP. In base alla decisione presa, effettuare una delle operazioni indicate di seguito.
Servizio di ricerca su un indirizzo multicast 239.129.9.27 e sulla porta 64535
Nota - Tenere presente che questo meccanismo di ricerca viene utilizzato anche dal daemon ldmd per rilevare eventuali conflitti durante l'assegnazione automatica degli indirizzi MAC. Se si disabilita il servizio di ricerca, il rilevamento dei conflitti tra indirizzi MAC non verrà eseguito e, di conseguenza, l'allocazione automatica dell'indirizzo MAC non funzionerà correttamente.Non è possibile disabilitare questo servizio mentre il daemon di Logical Domains Manager, ldmd, è in esecuzione. Utilizzare piuttosto la funzionalità di filtro IP di Oracle Solaris per bloccare l'accesso a questo servizio, allo scopo di ridurre i punti di vulnerabilità agli attacchi di Logical Domains Manager. Il blocco dell'accesso impedisce l'uso non autorizzato della utility e contrasta in modo efficace gli attacchi di negazione del servizio e altri tentativi di uso improprio di questi servizi di rete. Vedere Capitolo 20, IP Filter in Oracle Solaris (Overview) in Oracle Solaris Administration: IP Services e Using IP Filter Rule Sets in Oracle Solaris Administration: IP Services .
Disabilitare i servizi di rete elencati di seguito quando non vengono utilizzati.
Vedere anche Contromisura: protezione di ILOM.
Dominio di servizio
Un dominio di servizio fornisce alcuni servizi virtuali ai domini guest nel sistema. Tali servizi possono includere servizi di switch virtuale, disco virtuale o console virtuale.
La Figure 1–6 mostra un esempio di dominio di servizio che offre servizi di console. Il dominio di controllo spesso ospita i servizi di console, assumendo in tal modo la funzionalità di un dominio di servizio. I domini dell'ambiente di esecuzione spesso combinano le funzioni di un dominio di controllo, un dominio I/O e un dominio di servizio in uno o due domini.
Minaccia: manipolazione di un dominio di servizio
Un intruso che assume il controllo di un dominio di servizio può manipolare i dati o intercettare qualsiasi comunicazione eseguita tramite i servizi offerti. Questo controllo può includere l'accesso della console ai domini guest, l'accesso ai servizi di rete o l'accesso ai servizi su disco.
Valutazione: manipolazione di un dominio di servizio
Sebbene le strategie di attacco siano le stesse di un attacco al dominio di controllo, i danni possibili sono inferiori in quanto l'intruso non può modificare la configurazione del sistema. Il danno risultante potrebbe includere il furto o la manipolazione di dati offerti dal dominio di servizio, ma non la manipolazione di alcuna sorgente di dati. A seconda del servizio, è possibile che un intruso debba scambiare i moduli kernel.
Figura 1-6 Esempio di dominio di servizio
Contromisura: isolamento dei domini di servizio tramite granularità
Se possibile, fare in modo che ciascun dominio di servizio offra solo un servizio ai client. Questa configurazione garantisce che, in caso di violazione di un dominio di servizio, venga compromesso un solo servizio. Accertarsi tuttavia di valutare l'importanza di questo tipo di configurazione a fronte della complessità aggiuntiva. Tenere presente che la presenza di domini I/O ridondanti è altamente consigliata.
Contromisura: isolamento dei domini di servizio e dei domini guest
Accertarsi che il dominio di servizio e il dominio guest non condividano la stessa porta di rete. Evitare inoltre di attivare (plumb) qualsiasi interfaccia dello switch virtuale nel dominio di servizio. Per i domini di servizio di Oracle Solaris 11, evitare di attivare (plumb) qualsiasi VNIC sulle porte fisiche utilizzate per gli switch virtuali.
Qualora sia necessario utilizzare la stessa porta di rete sia per il SO Oracle Solaris 10 che per Oracle Solaris 11, situare il traffico del dominio I/O in una VLAN non utilizzata dai domini guest.
Qualora non sia possibile implementare alcuna delle soluzioni precedenti, evitare di attivare (plumb) lo switch virtuale nel SO Oracle Solaris 10 e applicare i filtri IP nel SO Oracle Solaris 11.
È possibile isolare i domini di servizio sia di Oracle Solaris 10 che di Oracle Solaris 11 rispetto ai domini guest. Le soluzioni riportate di seguito sono elencate nell'ordine di implementazione preferito.
Contromisura: limitazione dell'accesso alle console virtuali
Accertarsi che l'accesso alle singole console virtuali sia limitato solo agli utenti che hanno necessità di accedervi. Questa configurazione garantisce che nessun singolo amministratore possa accedere a tutte le console e impedire in tal modo l'accesso a tutte le console non assegnate a un account compromesso. Vedere How to Create Default Services in Oracle VM Server for SPARC 3.3 Administration Guide .
Dominio I/O
Qualsiasi dominio con accesso diretto ai dispositivi I/O fisici, come porte di rete o dischi, è un dominio I/O. Per informazioni sulla configurazione dei domini I/O, vedere Capitolo 5, Configuring I/O Domains in Oracle VM Server for SPARC 3.3 Administration Guide .
Un dominio I/O può fungere anche da dominio di servizio se fornisce servizi I/O a domini guest, concedendo in tal modo ai domini l'accesso all'hardware.
Minaccia: negazione del servizio di un dominio I/O o di un dominio di servizio
Un attacco che blocca i servizi I/O di un dominio I/O garantisce un blocco equivalente in tutti i domini guest dipendenti. Un attacco DoS può essere portato a termine con successo tramite il sovraccarico della rete di back-end o dell'infrastruttura del disco mediante l'inserimento di un errore nel dominio. Entrambi gli attacchi possono forzare la sospensione o un errore grave del dominio. Allo stesso modo, un attacco che determina la sospensione dei servizi di un dominio di servizio causa la sospensione immediata di tutti i domini guest che dipendono da tali servizi. In caso di sospensione del dominio guest, le operazioni verranno riprese quando verrà ripristinato il servizio I/O.
Valutazione: negazione del servizio di un dominio I/O o di un dominio di servizio
Gli attacchi DoS vengono in genere eseguiti in rete. È possibile che questo tipo di attacco abbia successo in quanto le porte di rete sono aperte per la comunicazione e possono essere sovraccariche a causa del traffico di rete. La perdita di servizio risultante determina il blocco dei domini guest dipendenti. Un attacco simile alle risorse su disco può essere eseguito mediante l'infrastruttura SAN o il dominio I/O. L'unico danno è un arresto temporaneo di tutti i domini guest dipendenti. Sebbene l'impatto delle attività DoS possa essere considerevole, i dati non vengono compromessi né persi e la configurazione del sistema rimane intatta.
Contromisura: configurazione granulare dei domini I/O
La configurazione di più domini I/O riduce l'impatto causato dall'errore o dalla compromissione di un singolo dominio. È possibile assegnare singoli slot PCIe a un dominio guest per conferirgli le funzionalità di dominio I/O. In caso di crash del dominio radice proprietario del bus PCIe, il bus viene reimpostato, con conseguente crash del dominio assegnato al singolo slot. Questa funzione non elimina completamente la necessità di utilizzare due domini radice, ciascuno proprietario di un bus PCIe separato.
Contromisura: configurazione di hardware e domini radice ridondanti
L'alta disponibilità contribuisce anche a una maggiore sicurezza in quanto garantisce che i servizi possano resistere agli attacchi di negazione del servizio. Oracle VM Server per SPARC implementa metodologie di alta disponibilità come l'uso di risorse su disco e in rete ridondanti in domini I/O ridondanti. Questa opzione di configurazione consente di eseguire gli aggiornamenti senza interruzioni dei domini I/O e protegge dall'impatto di un errore in un dominio I/O dovuto a un attacco DoS riuscito. Con l'avvento di SR-IOV, i domini guest sono dotati di accesso diretto ai singoli dispositivi I/O. Quando tuttavia non è possibile utilizzare SR-IOV, considerare la possibilità di creare domini I/O ridondanti. Vedere Contromisura: isolamento dei domini di servizio tramite granularità.
Minaccia: manipolazione di un dominio I/O
Un dominio I/O è dotato di accesso diretto ai dispositivi di back-end, in genere dischi, che virtualizza e in seguito offre ai domini guest. Un attacco riuscito comporta l'accesso completo a questi dispositivi e la lettura dei dati sensibili o la manipolazione del software nei dischi di boot dei domini guest.
Valutazione: manipolazione di un dominio I/O
L'attacco a un dominio I/O è verosimile quanto un attacco riuscito a un dominio di servizio o al dominio di controllo. Il dominio I/O è un obiettivo interessante in quanto offre potenziale accesso a un numero elevato di dispositivi su disco. Considerare pertanto questa minaccia quando si gestiscono dati sensibili in un dominio guest in esecuzione su dischi virtualizzati.
Contromisura: protezione dei dischi virtualizzati
Quando un dominio I/O è compromesso, l'intruso dispone di accesso completo ai dischi virtuali del dominio guest.
Cifratura del contenuto dei dischi virtuali. Nei sistemi Oracle Solaris 10 è necessario utilizzare un'applicazione in grado di cifrare i propri dati, come pgp/gpg o le tablespace cifrate di Oracle 11g. Nei sistemi Oracle Solaris 11 è necessario utilizzare i set di dati cifrati ZFS per fornire una cifratura trasparente di tutti i dati archiviati nel file system.
Distribuzione dei dati in più dischi virtuali in diversi domini I/O. Un dominio guest deve creare un volume con striping (RAID 1/RAID 5) che esegue lo striping di più dischi virtuali ottenuti da due domini I/O. Se uno di questi domini I/O è compromesso, l'intruso avrà difficoltà nell'utilizzare la parte di dati disponibile.
Proteggere il contenuto dei dischi virtuali effettuando le operazioni elencate di seguito.
Domini guest
Sebbene non facciano parte dell'ambiente di esecuzione, i domini guest costituiscono l'obiettivo più probabile di un attacco in quanto sono collegati alla rete. Un intruso che viola un sistema virtualizzato può attaccare l'ambiente di esecuzione.
Contromisura: protezione del SO del dominio guest
Il sistema operativo del dominio guest costituisce spesso la prima linea di difesa da qualsiasi attacco. Ad eccezione degli attacchi che hanno origine in un centro dati, un intruso deve violare un dominio guest dotato di connessioni esterne prima di tentare di violare l'isolamento del dominio guest e acquisire l'ambiente completo. È pertanto necessario rafforzare il SO di un dominio guest.
Per rafforzare ulteriormente il SO, è possibile implementare l'applicazione in Solaris Zones, aggiungendo un ulteriore livello di isolamento tra il servizio di rete dell'applicazione e il sistema operativo del dominio guest. Un attacco riuscito al servizio compromette solo la zona e non il sistema operativo sottostante, impedendo all'intruso di espandere il controllo oltre le risorse allocate alla zona. L'eventuale violazione dell'isolamento del dominio guest risulterà pertanto più difficile. Per ulteriori informazioni sulla protezione del SO del dominio guest, vedere Oracle Solaris 10 Security Guidelines e Oracle Solaris 11 Security Guidelines .