Molti di noi stanno lavorando con i firewall virtuali. Ho fatto un precedente posto per quanto riguarda i punti di forza e di debolezza di sicurezza all'interno del mondo virtuale , ma oggi voglio parlare delle possibilità di firewalling con VMware. C'è stato un sacco di emozioni per quanto riguarda VMware relativamente nuova API VMsafe . In particolare, tutti fa fatica a creare / installare firewall percorso veloce. Ma sono tutte le implementazioni percorso veloce creati uguali? Ci sono problemi di sicurezza con l'andare con una soluzione di tracciato veloce? Tuffiamoci a vedere.
Ripartizione delle VMsafe
Con il rilascio della cauzione API VMsafe, VMware ha aumentato le opzioni disponibili per implementare la sicurezza in un ambiente vSphere, consentendo ai produttori di collegare direttamente l'hypervisor a ring 0. VMsafe costituito da tre componenti:
- VDDK - ispezione blocco del disco. API è stata rilasciata pubblicamente.
- vCompute - API CPU e memoria. Non è stato rilasciato pubblicamente. Unknown parti che terzi abbiano accesso, se esiste.
- vNetwork - API di controllo / filtro tra l'vNIC e switch virtuale. Non è stato rilasciato pubblicamente. Per quanto a mia conoscenza, solo Altor Networks e sistemi reflex hanno accesso (due fornitori che hanno contribuito allo sviluppo della API).
In particolare, voglio parlare con l'API vNetwork. Quando si controlla il flusso del traffico di rete all'interno di un host ESX, ci sono due attuazione possibile, "percorso lento" e "percorso veloce".
Percorso lento
Percorso lento è la più semplice attuazione e quello che abbiamo usato per anni. In effetti questo è solo un ospite VM, simile a qualsiasi altra guest VM, in esecuzione sul host ESX. Tipicamente ogni ospite è collegato ad uno switch virtuale univoco, e ciascuno di questi switch virtuali è collegata ad un unico vNIC sul firewall. Questo è simile a una configurazione di firewall legacy, ma attuate in modo virtuale. Il vantaggio di eseguire nel percorso lento è che è possibile eseguire un sistema operativo completo di colpo con tutte le librerie o servizi necessari per sostenere il firewall.
Fast Path
Percorso veloce è effettivamente un driver 0 anello che si collega direttamente alla hypervisor kernel. Questo permette un fornitore terzo di sfruttare l'hypervisor per l'inserimento tra ogni vNIC / switch virtuale connessione. Perché un pilota veloce percorso è in esecuzione nel contesto di kernel, aggiunge un overhead minimo per il sistema. Il risultato è l'esecuzione di codice all'interno di percorso veloce è sostanzialmente più veloce lo stesso codice in esecuzione nel percorso lento (e quindi la convenzione di denominazione VMware per ogni contesto). Caricare sul host ESX è ridotto al minimo, in modo che il risultato finale è possibile eseguire gli ospiti molto più virtuali.
Veloce Vs Lento
Così suona come si vorrebbe fare tutto quanto in via più veloce, ma ci sono una serie di questioni. Percorso veloce è un driver del kernel di collegare in un hypervisor, non ridotta a icona, un sistema operativo completo colpo. Ciò limita le biblioteche ei servizi del firewall ha a disposizione per controllare il flusso del traffico. Inoltre, stiamo inserendo in un driver kernel quindi ci deve essere assicurato che non si gonfiano l'hypervisor, aumentare la superficie di attacco o interferire con altri hypervisor funzioni. VMware esegue una revisione del codice su tutti i driver via più veloce prima del rilascio. Quindi, se ho potuto teoricamente implementare tutto il codice in cammino veloce, avrei bisogno di approvazione VMware prima di ogni patch o funzione di rilascio.
Con questo in mente, un fornitore sostenendo "fast path" il supporto è in realtà va a finire l'attuazione di una parte del loro codice come percorso veloce, una parte come percorso lento, e quindi creare un raccordo tra i due. Quanto carico è posizionato sul sistema dipenderà da quanto di questo codice è implementata nel percorso veloce e quanto di esso viene eseguito nel percorso lento.
Possibili distribuzioni Fast Path
Ad esempio, un fornitore può scegliere di scrivere un pilota veloce percorso che semplicemente tunnel tutti i pacchetti di ritorno in un percorso lento firewall implementato. Il codice percorso lento quindi determina se il traffico dovrebbe essere passato o cadere, con i pacchetti trasmessi vengono inviati indietro al codice via più veloce per l'inserimento nel hypervisor canale di controllo. Anche se questo sarebbe il metodo più facile di distribuzione via più veloce, e senza dubbio il più sicuro, avrebbe fornito le prestazioni meno prestazioni. Carico del sistema non sarebbe probabilmente molto meglio di una piena attuazione percorso lento. Io vedo questa opzione come molto attraente per i fornitori di firewall legacy, in quanto richiederebbe il minor numero di modifiche al codice esistente pur essendo in grado di affermare "il supporto veloce percorso".
Un'altra opzione sarebbe quella di utilizzare lo spazio lento percorso per le funzioni amministrative con il driver percorso veloce che funge da motore di firewall. Così, per esempio l'amministratore del firewall potrebbe creare il criterio utilizzando un'interfaccia VM in esecuzione su un percorso lento, che sarebbe quindi spingere la politica verso il basso per un pilota percorso veloce. In questa configurazione il guidatore percorso veloce ha una copia della polizza in modo di controllo del traffico può essere implementato immediatamente. Il risultato è più veloce traffico di movimentazione con il carico del sistema minima. Il commercio off è più ingombrante codice a ring 0.
E 'anche possibile attuare una miscela dei due. Per esempio potrei usare il driver veloce percorso per attuare la politica del firewall, ma poi passano tutti "accettato" i pacchetti di ritorno al sistema percorso lento per il controllo delle intrusioni, la scansione dei virus, o qualsiasi altra cosa è necessaria. Accettabili i pacchetti vengono inviati indietro al driver via più veloce per l'inserimento. Quindi, in questa configurazione "caduto" tutti i pacchetti vengono gestiti attraverso un percorso veloce, mentre i pacchetti accettati interagire con un componente di tracciato lento.
Come nota a margine, è necessario mantenere le informazioni di cui sopra a mente quando si considerano tutte le implementazioni vNetwork, non solo firewall. L'API vNetwork può essere utilizzato anche per l'applicazione delle policy, QoS, la raccolta di statistiche di rete, ecc Ad esempio l'applicazione prima vNetwork era in realtà Lab Manager VMware. Questo strumento è utilizzato per il provisioning self-service e non contiene un componente firewall (questo viene attuato tramite vShield).
Riassunto
Mentre un prodotto che si integra con VMware VMsafe può assolutamente essere un "lento percorso" di attuazione, è altamente improbabile che qualsiasi prodotto può essere considerato solamente un "fast path" attuazione. Qualsiasi prodotto via più veloce è più probabile che sarà un ibrido. E 'solo una questione di quantità di codice presente nella "fast path" spazio rispetto al "lento percorso" spazio. Quando un prodotto afferma supporto veloce percorso, è necessario scavare un po 'più a fondo per analizzare l'attuazione, al fine di individuare eventuali benefici di prestazioni reali.
Related posts:
