vSphere Security Hardening

Quando si configura un cluster vSphere si ha la tendenza a tralasciare molte delle best practice suggerite da VMware, ancor meno si bada alle configurazioni più profonde del sistema ESX e della vCenter. Supponiamo di voler fare le cose per bene, cosa dovremmo prendere il considerazione?

Oltre alla documentazione ufficiale di VMware ed alle guide di implementazione, strumenti utilissimi per configurare una struttura scevra da errori di faciloneria (c’è ancora di crea cluster che tutto fanno tranne che HA), esiste un documento non ufficiale dedicato alle configurazioni da adottare per ottenere un ambiente sicuro oltre che efficiente: http://communities.vmware.com/docs/DOC-15413. In questo articolo vorrei commentare alcune delle configurazioni che ho ritenuto essere estremamente utili.

~ begin ~

Gestione dello shrinking

Le VMs con dischi Thin hanno la capacità di invocare la procedura di shrinking dei propri dischi virtuali qual’ora venisse rilevato spazio vuoto all’interno del file *.vmdk. Questa procedura ottimizza il consumo di storage del sistema ma è considerata un’operazione delicata e non sempre termina correttamente, si suggerisce quindi di disabilitare la funzione:

isolation.tools.diskWiper.disable=TRUE
isolation.tools.diskShrink.disable=TRUE

Rete di vMotion isolata

Nelle operazioni di vMotion le informazioni vengono trasmesse in chiaro tra i nodi ESX, il traffico è quindi potenzialmente intercettabile se la rete che si utilizza non è isolata. E’ quindi opportuno utilizzare una VLAN dedicata alle operazioni vMotion e non rendere accessibile questa rete neanche a livello di routing.

Accesso non autorizzato alla console

Tramite l’interfaccia del vSphere Client è possibile accedere alla console delle VMs, di default sono permessi accessi multipli alla console con una notifica che avvisa della presenza di più utenti connessi alla stessa console. Questa configurazione espone i sistemi al rischio di dare accesso amministrativo alle VMs a chi non ne ha diritto, è infatti consigliato di limitare il numero di utenti connessi ad una console ad 1:

RemoteDisplay.maxConnections=1

Nota: ovviamente dobbiamo anche abituarci ad eseguire il logoff dalle sessioni di lavoro, una banalità che il 90% degli addetti ai lavori considera superflua.

Limitare il logging delle VMs

In una configurazione di default i logfile delle VMs vengono “ruotati” ad ogni reboot della VM stessa con una conservazione di dieci file per ogni VM. E’ opportuno limitare la dimensione dei logfile in modo da essere certi che la crescita di questi dati non abbia nessun impatto sulla saturazione dei Datastore, la dimensione suggerita è 1 MB per ogni file.

log.rotateSize=1000000
log.keepOld=10

Utilizzare template ogni volta che è possibile

Con una corretta gestione del patching dei template delle VMs avremo la certezza che ciò che viene “deploiato” rispetta le policy di aggiornamento e sicurezza del nostro ambiente VMware. Questa pratica riduce notevolmente il rischio di introdurre nel sistema VMs configurate in modo errato o non aggiornate.

Tenere aggiornato il sistema

Un’altra attività banale che spesso si rimanda per non generare disservizi: gli host ESX(i) e la vCenter devono essere costantemente aggiornati. Tale operazione può essere effettuata senza impatto per la produzione se il sistema è stato ingegnerizzato correttamente.

Sicurezza nella gestione dello storage IP

Nell’usare storage di tipo NAS è opportuno configurare i sistemi in modo da avere accesso autenticato alle risorse di storage. Dare accesso indiscriminato allo storage su cui posizioniamo le nostre VMs è potenzialmente catastrofico.

E’ inoltre opportuno utilizzare una rete dedicata per il transito del traffico verso gli storage IP in modo da non andare a sovrapporti con i traffico di rete delle VMs o, peggio ancora, con il traffico generato dai nodi ESX nelle operazioni di vMotion.

Zoning della SAN

Una best practice da tener ben presente è lo zoning opportuno della SAN: deve esistere una zona per ogni coppia HBA/CONTROLLER. Ad esempio se abbiamo due server con 2 HBA l’uno (ESX1-HBA1, ESX1-HBA2 ESX2-HBA1, ESX2-HBA2) che accedono ad una SAN con due controller (C1, C2) dobbiamo creare le seguenti zone:

1. ESX1-HBA1 verso C1
2. ESX1-HBA2 verso C1
3. ESX1-HBA1 verso C2
4. ESX1-HBA2 verso C2
5. ESX2-HBA1 verso C1
6. ESX2-HBA2 verso C1
7. ESX2-HBA1 verso C2
8. ESX2-HBA2 verso C2

Utilizzare il sistema di profiling

Lavorare con il solo utente Administrator è potenzialmente pericoloso, diventa impossibile capire chi ha eseguito una certa azione e non è possibile stabilire una gerarchia di “poteri” all’interno del sistema. E’ sempre opportuno utilizzare utenti di dominio appositamente creati per la gestione dell’ambiente o, ancora più semplice, mettere in TRUST il domino utilizzato per il cluster VMware con l’eventuale dominio aziendale in modo da utilizzare la basic-authentication della propria postazione per accedere con le proprie credenziali e i propri privilegi.

~ end ~

Questi sono solo alcuni dei suggerimenti esposti nel citato documento, molti dei quali ho avuto modo di sperimentare io stesso pur non essendo a conoscenza della guida che, di fatto, è un pratico sunto delle best practice di VMware esposte in molteplici documenti.