Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03529.jsonl.gz/77

HardeningKitty Score
Michael Schneider
Für den Area41-Workshop habe ich von unserem IT-Admin einen Server erhalten, den wir bisher für interne Testzwecke eingesetzt haben. Darauf war VMware ESXi 6.0 installiert und die Uptime des Servers betrug 220 Tage. Ich entschied mich für ein Upgrade auf vSphere 6.5, installierte alle Updates und begann dann meine bestehenden virtuellen Maschinen (VM) hochzuladen.
Durch den Hardwarewechsel ist die Windows Evaluation License der Windows 10 Clients nicht mehr gültig. Da unter Windows 10 die Lizenzverlängerung mit
slmgr /rearm nicht mehr funktioniert, kann ich die Clients so nicht weiterverwenden. Das ist kein grosse Problem, ein Client kann leicht ersetzt werden, da dieser grösstenteils über Gruppenrichtlinien konfiguriert wird.
Ein grösseres Problem stellte die Performance des Servers dar, wenn alle VMs gleichzeitig liefen. Die Auslastung der Disks war so hoch, dass es beim Arbeiten in der VM nur noch schleppend voran ging. Ich ging also zurück zum IT-Admin, um eine SSD zu erschnorren.
Nach dem Einbau überlegte ich beim Initialisieren, ob ich die SDD mit VMFS6 formatieren sollte, oder mit VMFS5 wie die anderen beiden Disks. Nach längerem Zögern entschied ich mich für VMFS6.
Mit der SDD erwartete ich einen Leistungsschub, wurde aber enttäuscht. Das System agierte noch schwerfälliger als zuvor. Mittlerweile war das Arbeiten mit den VMs nicht mehr möglich, diese reagierten nur noch mit grossen Verzögerungen und brauchten eine Viertelstunde nur zum Starten. Es stellte sich heraus, dass VMware mit vSphere 6.5 einen neuen AHCI-Treiber (vmw_ahci) entwickelt hatte, welcher bei einigen Controllern zu Performance-Problemen führt. In der Auswertung der Disk-Performance war zu sehen, wie der Read- und Write-I/O kurz nach Start einbrach und dann auf wenigen KBps verblieb:
Über SSH kann der AHCI-Treiber durch den Befehl
esxcli system module set --enabled=false --module=vmw_ahci deaktiviert werden. Der Rollback zum Legacy-Treiber und/oder das Update zum Build 5969303 scheint das Problem bei einigen anderen zu beheben. Bei meinem System blieb die Performance jedoch bescheiden. Auch das Durchprobieren von verschiedenen Einstellungen im BIOS führte nicht zu einer Verbesserung.
Ich entschied mich für einen Downgrade auf ESXi 6.0. Während dem Downgrade stellte ich jedoch fest, dass ESXi 6.0 VMFS6 formatierte Partitionen nicht lesen kann. Auch das Tool vmfs-tools unterstützt VMFS6 (noch) nicht.
Auf der SSD waren natürlich die meisten meiner VMs gespeichert. Da ich aber bis zum dem Zeitpunkt mit den VMs aufgrund der Performance-Problemen noch nicht viel arbeiten konnte und somit meine lokalen VMs noch aktuell waren, entschied ich mich, die SSD neu zu formatieren. Doch auch unter ESXi 6.0 bestand das Performance-Problem. Es schien zumindest nicht am neuen AHCI-Treiber zu liegen. Nach Diskussionen mit dem IT-Admin entschieden wir uns auf den Einsatz von XenServer.
Zur Migration auf XenServer können VMware-VMs in das OVF-Format exportiert werden, welches dann mittels XenCenter direkt importiert werden kann. Zu meiner Überraschung funktionierte der Export/Import-Vorgang problemlos. Unter XenServer gab es dann auch keine Performance-Probleme mit der SSD. Nur die Windows 2000 VM konnte aufgrund eines Bluescreens während dem Boot-Vorgang nicht mehr gestartet werden – dazu später mehr.
Nach der Umstellung begann ich auf allen VMs die VMware Tools zu de- und die XenServer Tools zu installieren. Das klappte auf allen Systemen soweit, bis auf einer Windows Server 2016 Core VM. Ich fand keine Möglichkeit die VMware Tools zu deinstallieren. VMware selber empfiehlt diese per Programs and Features zu deinstallieren, oder das VMware Tools Setup zu verwenden. Ein andere Möglichkeit schien es nicht zu geben. Die Option Programs and Features ist unter Windows Server Core aber nicht vorhanden und das VMware Tools Setupprogramm wollte ich nicht extra auf die VM kopieren. Falls jemand weiss, wie man die VMware Tools einfach deinstallieren kann, Tipps sind willkommen.
Ich deaktivierte fürs erste den VMware Tools Service und startete mit der Installation der XenServer Tools, welche als MSI-Paket vorliegen. Die Installation wurde jedoch von einer Software Policy geblockt. Da ich einige Hardening-Einstellungen bei diesem Server vorgenommen hatte, war ich nicht sonderlich überrascht. Aber auch nach stundenlangen Durchgehen der AppLocker Policy, Software Restrictions und diversen Registry-Keys konnte ich die Ursache nicht finden. Am Ende stellte sich heraus, dass die Installation mittels
msiexec /i ohne weiteres funktioniert hätte.
Durch das Hin- und Herschieben und Starten der VMs gab es nun eine Inkonsistenz der AD-Replikation der beiden Domain-Controller. Der Secondary-DC hat zuerst 60min Zeitunterschied zum Primary-DC, was sich aber noch beheben liess. Nach einem Neustart begann sich jedoch das Event-Log mit Kerberos-Fehlermeldungen zu füllen. Ein schlechtes Zeichen. Auch hier verbrachte ich einige Zeit mit Analyse und diversen Workarounds zur Problembehebung. Schlussendlich half es den Maschinen-Account des Secondary-Domain-Controllers zurückzusetzen. Die beiden Domain Controller replizierten nun wieder. Bei den Member-Servern gab es glücklicherweise keine weiteren Probleme. Bis auf die Windows 2000 Maschine konnte die Migration also erfolgreich abgeschlossen werden.
Die Windows 2000 Maschine ist eine der Challenges für den Area 41 Workshop, dementsprechend war ich interessiert daran diese wieder zum Laufen zu bringen. Der Bluescreen trat während des Boot-Prozesses auf, da Windows 2000 die Boot-Partition nicht finden konnte. Ursache dafür war vermutlich, dass Windows 2000 keinen Treiber für den Disk-Controller hatte. Als Workaround liess ich die VM nochmals unter VMware Workstation laufen, installierte dort die XenServer Tools 5.5 und migrierte die VM danach nochmals. Mit Erfolg, Windows 2000 startete nun:
Eine neuere Version der XenServer Tools kann unter Windows 2000 aber nicht installiert werden, da diese vom .NET-Framework abhängig ist. Es gibt zumindest eine Anleitung, wie das .NET-Framework 3.0 und 3.5 auch unter Windows 2000 installiert werden kann. Nachdem meine VM aber soweit ohne Probleme lief, verzichtete ich auf weitere Experimente.
Nebenbei stellte ich fest, dass das Windows Update unter Windows 2000 nicht mehr funktioniert. Möglicherweise sind die Anforderungen der TLS/SSL-Konfiguration der Windows-Update-Server zu hoch, sodass der Windows Update-Client keine Verbindung mehr aufbauen kann. Immerhin sind die meisten der Updates für Windows 2000 noch im Internet auffindbar – auf der Download-Seite von Microsoft verweisen die Download-Links jedoch ins Leere. Tipp für all diejenigen, die nun aus Nostalgie wieder einmal ein Windows 2000 starten möchten, benutzt die Windows 2000 JSLinux VM von Fabrice Bellard.
Die Migration der AD-Testumgebung auf XenServer ist schlussendlich geglückt, hatte mich aber mehr Aufwand gekostet wie ursprünglich gedacht. Mein temporärer Rollenwechsel vom Red Team zum Sysadmin hat mir wieder einmal gezeigt, wie viel Wissen, Aufwand und “Schmerzen” es benötigt, eine IT-Infrastruktur aufzubauen und am Laufen zu halten. Nicht umsonst gibt es den System Administrator Appreciation Day am letzten Freitag im Juli! Die Basis für den Area41-Workshop ist nun gelegt, die verbleibende Zeit verwende ich nun, um zusätzliche Systeme aufzusetzen, Schwachstellen zu präparieren und ein Monitoring zusammen mit unserem Blue Team aufzubauen. Bis bald an der Area41!
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv