INFORMATION SECURITY

Private Cloud Security

Eine Private Cloud (on premises) Lösung wie Dell/EMC/VMware vSphere V6 umfasst folgende Module:

vSphere V6 Features:

Die primäre Security einer vSphere Datacenter Installation besteht -wie ülich bei verteilten Systemen- zunächst in der Absicherung der einzelnen Komponenten. Dazu müssen diese Komponenten gesichert werden:

Securing ESXi Hosts

In der Regel erfolgt der administrative Zugriff auf ESXI Hosts indirekt ├╝ber vCenter Server, somit sollte standardmässig der direkte Host Zugriff (via vSphere Client, SSH bzw. DCUI) unterbunden werden. Um ESXi Boot- oder Konfigurations Probleme zu handeln können Hosts an Terminalserver angeschlossen werden. User Authentisierung sollte auf Basis Active Directory erfolgen, eine dezentrale lokale ESXi Host Authentisierung ist nur als administrativer Notfallprozess mit einem singulären Account zu installieren.

ESXi enthält eine rudimentäre Firewall, die sowohl eingehenden - als auch ausgehenden Traffic kontrollieren kann, der vSphere Client umfasst ein entsprechendes Security Profile f├╝r die Firewall Rulebase.

Mit Hilfe des VMware Update Managers (VUM) lassen sich Patch- und Upgrade Baselines f├╝r ESXi Hosts vollständig automatisieren. Via VUM lassen sich ausserdem VMware Tools und VM Hardware auf den aktuellen Stand anheben.

Sowohl vCenter Server als auch ESXi Hosts implementieren Role-Based Access Control (RBAC). Damit können Roles, Privileges und Permissions auf Users und Groups allokiert werden, dh, ein standardmässiger Authorization Prozess steht für die Vergabe von Rechten zur Verfügung.

Eine Host Logging Facility ist erforderlich, um alle Kommandos, Events, Errors und Stati des Host und seiner VMs zu erfassen (dies verlangen nicht nur Audit, Security und Operations, sondern auch Compliance). Der auf einem ESXi Host zur Verfügung stehende syslog Daemon ist hierzu kaum geeignet, da die Daten entweder nur auf einer lokalen Disk oder sogar nur im Memory (beim Einsatz von Auto Deploy) gespeichert werden. VMware vSphere bietet daher einen syslog Collector in Form eines Windows-installierbaren Services, in Form eines Services auf der vCenter Virtual Appliance und als Teil des vMA (vSphere Management Assistant) built-in syslog Daemons.

Ferner sollten diese ergänzenden Sicherheitsmassnahmen getroffen werden:

Securing vCenter Server

vCenter liegt in zwei Editionen vor: die herkömmliche Edition nutzt Windows Server, die vCenter Virtual Appliance (VCVA) Edition verwendet SuSE Linux. Im Falle VCVA ist das SuSE Betriebssystem vorkonfiguriert und kann kaum signifikant verändert bzw. gehärtet werden. Bei der Windows Edition kommt eine standardmässige W2K8 Härtung zum Einsatz.

Der (bzw. die) vCenter Server spielen die zentrale Management Rolle in einem VMware vSphere Datacenter. Es ist daher ganz wesentlich diese Server zentral zu schützen, da ansonsten nicht nur die Verwaltungskontrolle über die ESXi Hosts, sondern auch deren betriebliche Integrität verloren geht, da essentielle vSphere Datacenter Produkte und Features wie beispielsweise vSphere vMotion, DRS, HA, FT oder VUM ohne vCenter Server nicht mehr oder nur noch marginal arbeiten. Deshalb sollten vCenter Server in einer durch reguläre Firewall vom Corporate Network (CN) separierten Area installiert werden.

Die vCenter zugeordnete relationale Datenbank (Microsoft SQL Server oder Oracle) sollte folgende Sicherheitsanforderungen erfüllen:

vCenter User sollten zentral gegen das Active Directory authentisiert werden, dies ist sowohl f├╝r die Windows- als auch f├╝r die VCVA Edition m├Âglich. Die diesen Usern zugeordneten Roles und Permissions werden auf den vCenter Servern eingerichtet, nicht etwa auf den Target ESXi Hosts. F├╝r die Vermittlung zwischen vCenter Server und ESXi Hosts wird ein Proxy Account (vpxuser) verwendet, der auf vCenter Server und ESXi Hosts installiert wird. Es ist auch sichergestellt, dass das Account Password f├╝r jeden ESXi Host verschieden ist. Somit erhalten vCenter Administratoren keinen direkten Zugriff auf ESXi Hosts, sondern erstellen lediglich Tasks, die dann von vCenter Server mittels Proxy Accounts auf den ESXi Hosts implementiert werden.

vCenter stellt folgende default Roles bereit. Eine Firma sollte aber der eigenen Organisation angepasste propriet├Ąre Roles erstellen (eine umfassende Liste von vSphere Privileges erlaubt die Generierung neuer Roles):

Es ist zu beachten, dass ein User häufig Mitglied in mehreren Groups ist. In einem solchen Fall setzt sich ihre effektive Permission aus den kumulierten Permissions der einzelnen Group Memberships zusammen. Daher ist auch bei der Vergabe von Group Memberships unbedingt auf das Prinzip der minimalen Rechtevergabe zu achten.

Securing Auto Deploy

Mit Auto Deploy stellt vSphere eine Methode bereit, ESXi nicht mehr statisch zu installieren sondern als Stream beim Booten direkt in das Host Memory zu laden. Auto Deploy verwendet Deployment Rules um zu entscheiden, welches ESXi Image einem Host zugeordnet wird. Damit kann bei jedem Host Reboot per Deployment Rule ├änderung konfiguriert werden, welches ESXi Image zum Einsatz kommt; Dies erh├Âht erheblich die operative Flexibilit├Ąt des Host Provisionings. ├ťblicherweise werden Hosts damit auch ohne lokale Disks betrieben, dh, selbst Image und Swap werden ins FC- oder iSCSI-SAN verlagert. Dies erh├Âht die Sicherheit, da das Host Image seine lokale Basis verliert und bei FC-SANs nur per non-IP Storage Protocol erreichbar ist. Die vSphere Auto Deploy Infrastruktur setzt sich aus folgenden Komponenten zusammen:

Beim Booten publiziert der DHCP Server -als Teil der Corporate Netzwerkinfrastruktur- auch die IP Adresse des TFTP Servers. Der ESXi Host bezieht ├╝ber den TFTP Server sowohl gPXE Boot File alsauch eine zugeh├Ârige Bootstrap Konfiguration. W├Ąhrend der gPXE Ausf├╝hrung initiiert der Host einen HTTP Boot Request an den Auto Deploy Server inklusive Informationen ├╝ber Host Details. Daraufhin vergleicht der Auto Deploy Server die Host Daten mit seinen Deployment Rules, selektiert das korrekte ESXi Image und streamt dieses Image dann per CN an den Host. Parallel dazu konfiguriert der Auto Deploy Server die vCenter Mitgliedschaft des ESXi Host und allokiert ein Host Profile (falls vCenter die entsprechende Lizenz umfasst).

In diesem Scenario ist der Auto Deploy Server besonders sch├╝tzenswert, da dieser ├╝ber das zu installierende Image entscheidet und auch Daten des vCenter Server ├Ąndert. Ferner sind TFTP Server notorisch unsicher, da wesentliche Security Features wie beispielsweise Authentisierung oder Vertraulichkeit fehlen. Wird der TFTP Server manipuliert, kann ein Fake Auto Deploy Server operativ eingebunden werden. Es ist deshalb notwendig, sowohl TFTP- als auch Auto Deploy Server per Firewall vom CN zu trennen. Zus├Ątzlich sollten beide Servertypen Malware Scanner und Host-IPS Funktionen erhalten.

Securing VUM

Der VMware Update Manager (VUM) umfasst keine Funktionen für das Patching von Guest OS mehr. Die Wartung der VM Gast-Betriebssysteme liegt damit bei non-VMware 3rd Party Produkten. VUM Server sind 1-zu-1 vCenter Servern zugeordnet, dh, ein VUM Server bedient nur ein vCenter. Ferner ist jedem VUM Server ein eigener Datenbank Server zugeteilt. VUM installiert in enger Kooperation mit vCenter:

Falls VUM Server (samt ihrem DB Server) anstatt hinter einer Firewall direkt im CN angeschlossen werden, sollten sie neben der standardm├Ąssigen Windows H├Ąrtung mit einem Malware Scanner und IPS-Host Funktionen ausgestattet sein. Aus Sicherheitsgr├╝nden wird dringend abgeraten, VUM Server direkt mit vmware.com zum Downloading der Updates/Upgrades kommunizieren zu lassen; Dies w├Ąre auch bzgl. Internet Bandbreite ineffizient. Statt dessen sollte ein ausfallsicherer Update Manager Download Service (UMDS) auf einem DMZ Server installiert werden, der als Proxy f├╝r die vmware.com Kommunikation aller VUM Server im CN dient.

Securing Virtual Machines

Die Sicherung der einzelnen VMs (auf ESXi Hosts) basiert im wesentlichen auf:

Die Absicherung des Gast-Betriebssystems erfolgt über OS Hardening und striktes OS Patching/Upgrading. Die Überwachung übernimmt SIEM Einbettung. Auch für die Anwendung(en) gelten die spezifischen Application Hardening Guides bzw. Best Practices.

Securing Virtual Networks

VMware bietet innerhalb eines ESXi Host einen vSphere Standard Switch (vSwitch), ein software-basierter Switch, der Traffic Management für lokale VMs und den VMkernel erbringt. Für das Traffic Management über mehrere ESXi Hosts hinweg gibt es den software-basierten vSphere Distributed Switch (dvSwitch). vSwitches weisen im Vergleich zu herkömmlichen physischen Switches Ähnlichkeiten und Unterschiede auf:

Cisco Nexus 1000V vSphere Distributed Switch

Cisco liefert mit Nexus 1000V einen 3rd Party Distributed Switch (dvSwitch) für vSphere. Nexus 1000V ist ein Virtual Software Switch, der in vSphere integriert ist und die folgenden Komponenten besitzt:

Das VSM Module -in einer ESXi Host VM laufend- nutzt ein externes, physisches Netzwerk für die Kommunikation mit den VEMs der beteiligten ESXi Hosts. Die physischen NICs der ESXi Hosts fungieren als Uplinks zum externen Netzwerk. Auf VSM laufen die Control Plane Protokolle, die auch die States der VEMs kontrollieren, jedoch ist VSM nicht am VEM Packet Forwarding beteiligt. Ein einziges VSM kann 64 VEMs bedienen, deshalb wird ein Nexus 1000V auch als 64+2 Ports modularer Switch betrachtet. Bei der VSM Installation wird eine eindeutige Domain ID f├╝r jeden Nexus 1000V Switch generiert, die auch bei der VSM-VEM Kommunikation verwendet wird; Diese Domain ID ist vor MITM Angriffen zu sch├╝tzen. VSM und VEMs ben├Âtigen eine gemeinsame Layer 2 Domain, der vCenter Server kann per Layer 3 Routing angebunden werden.

VSM ist eng mit dem vCenter Server integriert, die auf VSM konfigurierten Port Profiles (System-, Uplink-, Data-) erscheinen auf vCenter Server automatisch als dvPort Groups. Somit ist bei Nexus 1000V auch die fr├╝here strikte Trennung zwischen Network- und Server Engineering wieder hergestellt: Network Engineering konfiguriert auf der VSM Virtual Machine alle System|Uplink|Data Profiles, die dann auf vCenter Server als dvPort Groups durch Server Engineering konsumiert -aber nicht modifiziert- werden k├Ânnen.

Nexus 1000V verwendet drei spezielle VLANs: ein Management-VLAN f├╝r die Kommunikation mit Network Admins und mit vCenter Server, ein Packet-VLAN f├╝r Control Protokolle wie CDP, LACP und IGMP, sowie ein Control-VLAN f├╝r die VSM-VEMs Kommunikation (Commands, Notifications, NetFlow). Der Absicherung dieser VLANs kommt grosse Bedeutung zu, inbesondere d├╝rfen diese drei VLANs keinefalls f├╝r non-Control-Plane-Traffic wie etwa Payload Data verwendet werden.

VMware vShield Zones

VMware vShield Zones ist als einziges Produkt der Produktfamilie VMware vShield integraler Teil von vSphere. vShield Zones ermöglicht es, Network Traffic von/zu Host vSwitches und zwischen den VMs eines Hosts zu kontrollieren; Es ist eine virtuelle Netzwerk Firewall mit eingebauter vCenter Server Integration.

vShield Zones besteht aus:

vShield Zones extrahiert aus den überwachten Traffic Flows die Betriebssystem IDs, Anwendungen und offene Ports der VM GuestOS und pflegt diese Daten in einer Bestandsdatenbank. Basierend auf diesem Inventory fungiert die Firewall als Security Layer zwischen Hypervisor und den VMs. Firewall Rulebase Management erfolgt auf der Datacenter und Cluster Ebene, um konsistente Rules ├╝ber multiple vShields hinweg zu garantieren. Firewall Rules k├Ânnen auf Layer 2/3 und auf Layer 4 definiert werden, eine Grundmenge an default Rules kann allerdings nicht modifiziert werden. Eine wichtige Funktion des vShield Managers besteht auch in der F├Ąhigkeit, selektiv Inter-VM zu blockieren.

VMware vShield Edge

VMware vShield Edge ist eine Edge Security Lösung für Virtual Datacenter. vShield Edge ist als Virtual Appliance implementiert und umfasst eine (Stateful Inspection) Network Firewall, site-2-site VPN Gateway, Web Load Balancer, NAT- und DHCP Services; Mit diesen Komponenten kann eine virtuelle Sicherung für ein mandanten-basiertes virtuelles Datacenter errichtet werden. Cisco bietet mit Cisco Virtual Security Gateway (VSG) eine ähnliche Lösung basierend auf Nexus 1000V (oder Nexus 1010 Appliance) an.

VMware vShield App

vShield App ist eine hypervisor-basierte application-aware Firewall für virtuelle Datacenter. Im Gegensatz zu vShield Zones nutzt vShield App nicht nur das klassische 5-Tupel (Src- und Dst IP, Src- und Dst Port, Protokoll) Sockets Template für die Traffic Analyse, sondern auch Security Groups (Resource Pools, Folders, Containers und weitere vSphere Gruppen). Damit lässt sich Compliance zu regulatorischen IT- und Daten Anforderungen nachweisen.

Die application-aware Firewall arbeitet auf vNIC Ebene der einzelnen VMs und unterstützt eine breite Palette von Protokollen wie Oracle, Sun RPC, Microsoft RPC, LDAP, SMTP, etc. Die eingebaute Flow Monitoring Utility dient neben Audit und Compliance auch der Granularisierung der Firewall Rulebase.

VMware vShield Endpoint

Shield Endpoint vereinfacht sehr stark die bisherige Methode der Bekämpfung von Malware auf den GuestOS der VMs. Bis dato müssen alle GuestOS mit einem eigenen Malware Scanner ausgestattet werden. vShield Endpoint hingegen erm&oum;glicht die Auslagerung des Malware Scannings von jeder Virtual Machine auf eine dedizierte Virtual Appliance (VA). Diese VA integriert eine Virus Scanning Engine und aktuelle Antivirus Signaturen. Somit wird in jeder VM der Antivirus Agent Footprint eliminiert.

Solche 3rd Party Antivirus Virtual Appliances nutzen sichere Introspection Funktionen des vSphere ESXi Hypervisors. Die von VMware bereitgestellten Hypervisor APIs können aber nicht nur für File Scanning, sondern auch für Memory- und Process Scanning eingesetzt werden.