XENMASTER
Der Citrix XenServer ist bereits durch seine grundlegende Architektur ein sehr sicheres System. Allerdings wird oft das Zusammenspiel der einzelnen Komponenten nicht ausreichend beachtet und damit die Sicherheit einer solchen Virtualisierungsplattform falsch eingeschätzt und mögliche Sicherheitslücken in der Konfiguration unterschätzt. Mit diesem Artikel möchte ich nicht nur die einzelnen Komponenten in puncto Sicherheit betrachten, sondern auch konkrete Hinweise für die Absicherung einer XenServer Infrastruktur geben.
In einer normalen Installation besteht ein Citrix XenServer aus den folgenden Komponenten:
Für den Zugriff bwz. Kommunikation mit der XenAPI stehen mehrere Möglichkeiten zur Verfügung. Die bekannteste ist das XenCenter, einer Windows Anwendung die auf einer Management Workstation installiert wird und direkt mit der XenAPI kommuniziert. Weniger bekannt ist das Kommandozeilen Tool xe das auf der Konsole des XenServers zu finden ist und auch über SSH benutzt werden kann. Dieses Kommandozeilen Tool steht nach der Installation des XenCenters auf einem Windows Rechner auch als Windows-Version (xe.exe) zur Verfügung. Für alle die auf der Konsole des XenServers (das ist dann die virtuelle Control Domain oder Dom0) arbeiten müssen aber nicht auf eine grafische Oberfläche verzichten möchten, können die xsconsole für rudimentäre Aufgaben verwenden. All diese Möglichkeiten werden direkt von Citrix zur Verfügung gestellt, es existieren aber noch diverse Tools von Drittherstellern die unter anderem per xmlrpc mit der XenAPI kommunizieren können.
Ich denke es ist selbstverständlich das ein Serversystem nicht unter dem Schreibtisch, sondern in einem gesicherten Rechenzentrum betrieben werden sollte. Deshalb möchte ich nicht weiter auf die physikalische Sicherheit der Hardware eingehen.
Bei der Installationsroutine des XenServer werden bereits sicherheitskritische Fragen gestellt. Die natürlich offensichtlichste ist die nach dem Passwort des Systemverwalters, also das Passwort für den Benutzer „root“. Bei der Wahl dieses Passwortes sollte man sämtliche guten Ratschläge und Best Practices betreffend der Kennwortsicherheit beachten und ein möglichst kompliziertes Passwort wählen. Denn mit diesem Passwort können alle Tätigkeiten an dem Server vorgenommen werden. Mit Einrichtung der Control Domain werden in der Regel auch drei Netzwerke eingerichtet; das Management Netzwerk, das Storage Netzwerk sowie das Netzwerk für die virtuellen Maschine. Diese drei Netzwerke können alle auf ein physisches Netzwerkinterface zeigen, aus Sicherheitsgründen sollte sie aber alle über ein eigenes Netzwerkinterface mit dem entsprechenden Netzwerk verbunden werden. Wobei es in diesem Fall egal ist, ob es sich um einzelne oder verbundene (Bonding / Teaming) Netzwerkinterfaces handelt. Schauen wir uns doch mal die Funktion dieser einzelnen Netzwerk in Bezug auf die Sicherheit an.
Das Management Netzwerk wird vom XenServer für unterschiedliche Aufgaben benutzt.
Die XenAPI selbst ist in einer High-Level Sprache mit dem schönen Namen Objective CAML ( OCaml) geschrieben. Dadurch ist die XenAPI selbst fast völlig unempfindlich gegen Buffer Overflows bzw. Integer Buffer Overflows und ist sehr robust gegen Angriffe über das Netzwerk. Außerdem benutzt die XenAPI das stunnel Paket um SSLv3 Verschlüsselung zu implementieren. Obwohl die Standard XenAPI Clients von Citrix (hier speziell das XenCenter) eine Kommunikation ausschließlich über den Port 443 SSL verschlüsselt führen, lauscht die XenAPI auch auf Port 80 (PlainText). Es ist nicht auszuschließen, dass XenAPI Clients von anderen Herstellern oder der Open Source Gemeinde unverschlüsselt mit der XenAPI kommunizieren. Dies verdeutlicht auch die Ausgabe von netstat auf einem XenServer.
[root@xenserver ~]# netstat -l --numeric-ports Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State [...] tcp 0 0 xenserver.localhost:80 *:* LISTEN tcp 0 0 xenserver.localhost:443 *:* LISTEN [...]
Allerdings ist der offene Port 80 nicht völlig sinnlos, der die unverschlüsselte Kommunikation über HTTP wird von XenMotion genutzt um das Memory Image einer laufenden virtuellen Maschine auf einen anderen Host zu übertragen. Die Idee dahinter war, ein Memory-Image möglichst schnell zu übertragen, deshalb wurde hier auf den Overhead, den die Verschlüsselung erzeugen würde, verzichtet. Aus diesem Grund sollte XenMotion auch nur im LAN verwendet werden. Bei Übertragungen im WAN sollte hier IPSec benutzt werden um das Memory-Image verschlüsselt zu übertragen. Wer den Zugriff auf Port 80 unterbinden möchte, kann den Port entweder auf der Firewall vom Admin-Netzwerk zu den entsprechenden XenServer sperren oder die interne Firewall der Dom0 entsprechend konfigurieren.
Da die Control Domain im XenServer auf Linux basiert, gibt es hier auch eine IPTables Firewall. Zur Konfiguration dieser Firewall steht eine rudimentärre GUI zur Verfügung, die man mit system-config-securitylevel-tui oder einfach mit lokkit an der Konsole aufrufen kann.
Zugegeben das GUI ist nicht besonders schön, aber man kann nach Auswahl von Customize relativ einfach den Port 80 deaktivieren.
Überprüfen kann man die Firewall Rules mit dem Kommando more /etc/sysconfig/iptables.
[root@xenserver ~]# more /etc/sysconfig/iptables # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 694 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
Zu beachten ist allerdings, dass nach dem Sperren des HTTP-Ports über die IPTables Firewall das Verschieben von virtuellen Maschinen über XenMotion nicht mehr möglich ist.
Jedes Linux System und so auch die Control Domain des XenServers erzeugen bei der Installation ein eindeutiges Schlüsselpaar bestehend aus einem Public-Key welcher den Clients präsentiert wird sowie einem Private-Key der den Public-Key verifizieren kann. In der normalen Administration mit dem XenCenter werden diese Schlüssel nicht zu sehen sein. Sobald man jedoch zum ersten mal eine Kommunikation über SSH (z.b. unter Windows mit PuTTY) mit dem entsprechenden XenServer aufbauen möchte, warnt uns der SSH Client.
Das vom XenServer erzeugte Schlüsselpaar können wir mit der xsconsole überprüfen.
Der einzige Sinn dieser Schlüssel ist es, zu verifizieren das der Server mit dem man eine Verbindung aufbaut auch der ist von dem man denkt das er es ist.
Bei der Installation eines XenServers werden auch die Zertifikate für die SSL Komminikation erzeugt. Citrix empfiehlt diese durch eigene Zertifikate zu ersetzen. Prinzipiell ist das nicht nötig, aber in großen Umgebungen durchaus üblich. Wichtig hierbei ist, das die neuen Zertifikate inkl. des privaten Schlüssels in einer *.PEM Datei vorliegen müssen. Um neue Zertifikate zu installieren, sollte erstmal das vorhandene gesichert werden. Dies erledigt man mit dem CLI.
mv /etc/xensource/xapi-ssl.pem /etc/xensource/xapi-ssl.pem.alt
Danach muss lediglich das neuen Zertifikat an die richtige Stelle kopiert werden. Innerhalb einer SSH Verbindung z.B. mit SCP.
scp /neueszertifikat.pem root@xenserver:/etc/xensource/xapi-ssl.pem
Dieser Artikel wird aktuell noch weiter ergänzt und liegt noch nicht in der finalen Version vor. Die vorstehenden Informationen sind jedoch aktuell und werden nicht mehr maßgeblich verändert. Allerdings sind zusätzliche Informationen noch in der Erfassung.