Virtualisierung

IPFire – Der (unterschätzte) kleine Bruder von OPNSense und Pfsense

von

Ich verwende die OSS-Firewall „IPFire“ schon lange für meine Projekte und wundere mich jedesmal wieder darüber, dass in den meisten Fällen OPNSense und PfSense den Vortritt bekommt. Natürlich ist mir klar, dass es immer auf den jeweiligen Anwendungsfall ankommt, welche Werkzeuge man dafür einsetzt.

So oder so, möchte ich IPFire eine kleine Videoserie widmen.

Teil 1 – Installation mit 3 Netzwerkzonen in Proxmox

Teil 2 – Clienteinbindung und erste Schritte in der WebGUI

Teil 3: DMZ, Firewallregeln & Geo-IP-Filter

Teil 4: IP Blocking, Geolocation Blocking, IPS

Teil 4

Auswirkungen VMWARE ESXI Spectre & Meltdown VMkernel.Boot.hyperthreadingMitigation

von

Für alle, die sich fragen, welchen Impact das Aktivieren des ESXI Parameters VMkernel.Boot.hyperthreadingMitigation haben kann, 2 Diagramme (Readytime), aus der VCenter-Überwachung. Wichtig hierbei ist, dass der Wert so niedrig wie möglich sein sollte und möglichst nicht über rund 1500ms.

 

Wie oben ersichtlich, liegen wir bei einem Host mit 2 CPUs, je 8 Cores  – in Summe also 16-Cores, ohne Hyperthreading bei einem Wert von teilweise !!! 15.000ms !!! Dies hatte massive Auswirkungen auf die Performance des Hosts, auf dem 12VMs laufen. Insgesamt sind 38vCpus zugeordnet.

Der gleiche Host, mit deaktivierter Option „VMkernel.Boot.hyperthreadingMitigation“ und aktivem Hyperthreading:

Nicht täuschen lassen! Die Kurve scheint optisch extremer, aber schaut mal nach links zur Legende. Hier haben wir jetzt eine Wert von „nur“ noch max. 1.750ms. Danach pendelt sich der Wert ein. Dies hatte zur Folge, dass der Host und die darauf installierten VMs wieder normal liefen.

Hier wird man aufgrund der Situation dann zwangsläufig mit der Frage / Entscheidung konfrontiert, ob Sicherheit oder Leistung wichtig ist. In dem Fall habe ich mich (aufgrund der Begleitumstände, dass die Systeme in einer recht sicheren Umgebung laufen) für die Leistung entschieden. Allerdings hätte ich mir nie gedacht, dass der Parameter derartige Auswirkungen hat. Anzumerken ist auch, dass es sich hierbei um relativ alte CPUs handelte, nämlich: Intel(R) Xeon(R) Silver 4110 CPU @ 2.10GHz (Marktstart: 3. Quartal 2017)

Xenserver 7: Sicherheit erhöhen – Rootserverbetrieb

von

Wenn der Xenserver auf einem Rootserver im Internet installiert wird, ist dieser über die ihm zugeordnete offizielle IP Adresse erreichbar. Dies bedeutet, dass das Managementnetzwerk / Managementinterface grundsätzlich von jedem aufrufbar ist.

Um dieser Problematik etwas entgegenzuwirken, kann man die iptablesfirewall umkonfigurieren bzw. den SSH-Port verschieben.

Mir ist bewusst, dass das nur ein Tropfen auf den heißen Stein ist, jedoch jedenfalls besser wie nichts.

SSH Port verlegen

Per XenCenter Serverkonsole sind folgende Anpassungen durchzuführen.

Im Verzeichnis /etc/ssh/sshd_config wird der Port verlegt. Standardmäßig läuft SSH auf Port 22. Dies verlegt man z.B. auf Port 2232.

Iptables anpassen

Nun muss natürlich die Firewall angepasst werden, damit Verbindungen auf Port 2232 erlaubt werden.

Das anzupassende File namens iptables findet sich im Ordner /etc/sysconfig. Es beinhaltet bereits einige Regeln. Unter anderem findet sich auch die Regel für den Standardport (22) in dieser Datei. Diese wird entsprechend angepasst, sodass sie dem „neuen“ SSH-Port entspricht.

Schließlich ist die Datei noch zu speichern und iptables und sshd neu zu starten.

service iptables restart && service sshd restart

hosts.deny und hosts allow einsetzen

Genaugenommen eigentlich ein MUSS in einer solchen Netzwerkkonstellation.

Sofern der PC, mit dem man auf den Xenserver einsteigt, mit einer statischen offiziellen IP-Adesse ins Internet geht, gibt es eine elegante Methode, den Zugriff auf den Xenserver einzuschränken.

In der Datei /etc/hosts.allow wird definiert, welche IPs auf den Server zugreifen dürfen. Die anzuführenden IPs sind neben der localhost IP (127.0.0), auch noch die statische IP, von der aus man den Xenserver managed.

Der Eintrag kann z.B. so aussehen:

ALL: 127.0.0 89.163.225.17

D.h. diese IPs dürfen sämtliche Services auf dem Xenserver nutzen.

Nun muss in /etc/hosts.deny noch für alle anderen ALLES verboten werden. Dieser Eintrag ist recht simpel gehalten und sieht folgendermaßen aus:

ALL: ALL

Durch diese Einstellungen wird jedem Client der Zugriff verweigert, solange nicht die Ausnahmeregelung in den hosts.allow greift.

Nachteil

Natürlich bedingt dies, dass man immer mit den angeführten IP Adressen auf den Xenserver zugreift. Blöd nur, wenn man gerade „irgendwo“ ist und man nicht von seiner gewohnten IP-Adresse aus aufs Internet zugreift.

Workaround

Sollte neben dem Dedicated Root(Xen)Server noch ein weiterer Server mit statischer offizieller IP im (Inter)net aktiv sein, kann man diese IP ebenso in die hosts.allow eintragen. Schließlich könnte dann der Umweg über den zusätzlichen Server genommen werden.

Sprich also:

Client mit dynamischer IP -> ssh zu zusätzlichem Rootserver (IP steht am Xen in den hosts.allow) -> ssh zu Xenserver.

 

 

 

Xenserver 7: NFS ISO-Store von Synology NAS einrichten

von

XENSERVER auf einem dedicated Rootserver

Ich möchte hier kurz beschreiben, wie man ein NFS-Share von einer Synology NAS, die in einem lokalen Netzwerk steht, einem XENSERVER (dedicated Rootserver), zur Verfügung stellt.

Die ISO-Dateien werden von einem beliebigen PC im lokalen Netzwerk auf das Share abgelegt und stehen dem Xenserver, nach Einbindung des ISO-Repositories zur Verfügung.

Ports (Virtual Server)

Da die Synology-NAS in meinem internen Netzwerk steht und ich aus dem Internet heraus (vom dedicated Rootserver) auf die NFS-Freigabe zugreifen will, muss eine entsprechende Portweiterleitung erfolgen.

Auf meinem TP-Link Router nennt sich dies „Virtual Server“.

Die Weiterleitungen sind folgende:

NFS-Server (Synology NAS)

Als NFS-Server fungiert meine Synology NAS mit DSM 6.0.1-7393 Update 2.

Damit NFS überhaupt funktioniert, muss in der Systemsteuerung der Synology unter Dateidienste NFS aktiviert werden. Optimalerweise setzt man auch gleich das Häkchen bei „NFSv4-Unterstützung“ aktivieren.

Nachdem das  NFS-Service nun „scharf geschaltet“ ist, muss noch eine Freigabe erstellt werden. Zu diesem Zweck, wechselt man in der Synology Systemsteuerung zu den Gemeinsamen Ordnern.

Über den Button „Erstellen“ erfolgt die Konfiguration der Freigabe.

Im Folgefenster können Berechtigungen für lokale Benutzer gesetzt werden. Da man mit einem PC (z.B. SMB-Share) auf die Freigabe zugreift, um ISO-Files abzulegen, muss hier ein User mit entsprechenden Berechtigungen gewählt / oder zuvor angelegt und die Berechtigungen entsprechend gesetzt werden.

Wichtig ist jedoch vor allem der Reiter „NFS-Berechtigungen“, denn dort wird definiert, welche IP-Adressen auf den NFS-Server (die Freigabe) zugreifen dürfen.

In das Feld Hostname oder IP wird die Adresse des NFS-Client eingetragen. (Somit darf nur von dieser IP aus auf NFS zugegriffen werden!) Der NFS-Client ist in diesem Fall der XenServer. Die Privilegien müssen auf Lesen/Schreiben gesetzt sein.

Somit ergeben sich folgende Einstellungen.

Ganz unten im Fenster sieht man den Mountpfad, welcher in dieser Konfiguration: /volume1/NFS_ISO lautet. Der Pfad wird später für die Einbindung der Freigabe auf dem Xenserver verwendet.

Somit sind alle Vorarbeiten auf dem NAS abgeschlossen.

ISO Repository auf dem Xenserver einbinden

Für die Verwaltung des Servers, verwende ich OpenXenManager.

Die Serververbindung ist bereits aufgebaut. Nach einem Rechtsklick auf den Server, welcher auf der linken Seite des OpenXenManager aufgeführt wird, wählt man „New Storage Repository“.

Im Folgefenster wird „ISO Library – NFS ISO“ gewählt. (Aufgrund meiner hohen Auflösung und dem angepassten Skalierung sind die Screenshots leider unschön.)

Im Feld „Share Name“ ist die öffentliche IP des NFS-Servers gefolgt vom lokalen Mountpfad des NFS-Share (in diesem Falle /volume1/NFS_ISO) einzutragen.

Genaugenommen also z.B.: 123.456.789.001:/volume1/NFS_ISO

Wobei es sich bei oben angeführter IP nur um eine fiktive Adresse handelt, die durch die korrekte öffentliche IP – über die die Synology NAS anzusprechen ist- zu ersetzen ist.

Das Ergebnis der Übung – ein NFS ISO Store ist eingebunden.

Download und ablegen des ISO Files

Auf dem lokalen PC kann man sich aufgrund dessen, dass auch eine normale SMB Freigabe erstellt wurde, mit dem Share verbinden und legt dort beispielsweise den Debian Netinstaller (ISO) ab.

Eine VM installieren

Nach Ablage des ISO Files im NFS-Share, muss am Xenserver ein Rescan des ISO-Repositories erfolgen.

Danach kann eine neue VM angelegt werden und die zu installierende ISO-Datei vom NFS-Share aus gewählt werden.

Nach dem Start der VM, präsentiert sich der Debian Installer. Die Daten kommen hierbei dann von der ISO Datei, die per NFS-Share eingebunden wurde.

 

 

 

 

Xenserver 7 auf einem dedicated Rootserver

von

Meine bisherigen Virtualisierungserfahrungen habe ich einerseits auf Microsofts Hyper-V und andererseits auf VMWARE ESXI gemacht. Den Xenserver hatte ich bislang komplett aussen vor gelassen.

Grund genug also, den Xenserver zu testen. Für den Test habe ich einen dedicated Rootserver mit 32GB Ram, 1TB Festplattenspeicher und einem I7 Prozessor verwendet.  Verbaut ist ausserdem eine Realtek-NIC (r8169).

Installation

Für die Installation bestelle ich einen kostenpflichtigen Remotemanagement Zugang (KVM Spider). Die ISO Datei des Xenserver lade ich auf meinen lokalen PC. Die Remotekonsole basiert auf Java, weshalb am PC die aktuelle Version des Java Runtime Environment installiert sein muss.

Da die Sicherheitsmechanismes des JRE mittlerweile sehr strikt sind, muss für die IP, oder auch für die Adresse, die für das Remotemanagment verwendet wird, eine Ausnahme erstellt werden.

Java Konfigurieren – Reiter Sicherheit – Ausnahmeliste – Siteliste bearbeiten…

Nun sollte sich die Remotekonsole öffnen lassen.

KVM Spider Probleme mit dem Keyboard

Nachdem das ISO File im Remotemanagement gemountet war, hoffte ich nun auf eine problemlose Installation. Wäre da nicht das Problem mit dem Keyboard gewesen. Ich kannte das schon von einem anderen Hoster. Das Keyboard funktioniert anfangs, nach dem Restart dann jedoch u.U. nicht, oder vielleicht doch… So kann ich jedenfalls nicht vom eingebundenen ISO booten. Ich komme nicht in das Bootmenü des Bios.

Nach mehreren erfolglosen Versuchen, die Sachlage mit dem Support zu klären und endlich ein funktionierendes Remotemanagement zur Verfügung gestellt zu bekommen, begebe ich mich selbst auf Ursachenforschung- Schließlich übermittle ich dem Support einige Settings, die man wohl im Bios (USB Einstellungen) vornehmen muss, damit KVM funktioniert.

Endlich, das Setup läuft

Das ISO-File ist eingebunden und das Setup läuft. Da es so geradlinig und selbsterklärend ist, verzichte ich auf Screenshots. Sämtliche Hardware wird out-of-the-box erkannt. Einzig die zu verwendende Festplatte, der Servername, die Netzwerkeinstellungen und das Rootpasswort sind zu konfigurieren bzw. auszuwählen.

Management per XenCenter

Um den Server managen zu können, benötigt man XenCenter, welches – wie der XenServer – kostenlos zur Verfügung steht. Nach der Installation muss der XenServer (Host) noch in XenCenter hinzugefügt werden.

Wenn man will, kann ein Masterpasswort für das XenCenter gesetzt werden. Dies ist allerdings nur dann sinnvoll, wenn man mehrere Hosts betreibt, da die Passwörter aller Hosts im Center gespeichert werden können und die Entsperrung aller Server aufeinmal dann mit dem Masterpasswort geschieht.

Im Funktionsumfang nicht beschnitten

Obwohl es sich bei Xenserver um die kostenlose Version (ohne Support) handelt, ist sie im Funktionsumfang in keinster Weise beschnitten. VMs können migriert, kopiert, verschoben, exportiert, importiert, konvertiert usw. werden.

Festplattenmanager / Storage Repository

Was mir fehlt, ist das Verwalten von lokal am Server installierten Festplatten. Will man eine weitere Festplatte als Storage-Repository einbinden, kann dies nur per Konsole erfolgen.

Verwaltung per Web-Gui  „Xen Orchestra“

Wenn man den Xenserver gerne per Webgui administrieren will, kann man auf Xen Orchestra zurückgreifen. Eine gute Installationsanleitung findet sich auf der Website von tecmind.com.

Fazit

Meiner Ansicht nach stellt Xenserver eine ernstzunehmende Alternative zu den anderen Virtualisierungsplattformen dar. Einzig bei einigen Verwaltungsfunktionen hätte ich gerne eine etwas komfortablere Bedienung per GUI. Soweit von mir bislang korrekt interpretiert, gibt es eine eher geringere Anzahl von Drittanbieter „Backup-/Restoresoftware“.

Ansonsten ist Xenserver ein tolles Produkt!