Ich verwende in meiner Infrastruktur einen Windows Server 2019 für mein Monitoring. Dort laufen verschiedene Dienste, welche Informationen sammeln und aufbereiten. Bei Bedarf informiert mich das System per Mail oder mit Push-Notifications über Anomalien. Und natürlich kann ich die Informationen auch historisch analysieren, um beispielsweise Trends zu erkennen.

Heute habe ich festgestellt, dass es schon länger keine Warnmeldungen mehr vom Server gab. Das ist durchaus wünschenswert, aber in meinem Fall nicht normal. Denn den Server habe ich so eingestellt, dass er sich mindestens einmal am Tag per Mail meldet und eine Zusammenfassung sendet. Und diese blieb aus.

Das Problem war schnell gefunden: Der Server ist komplett ausgelastet. Im Taskmanager ist der verantwortliche Prozess deutlich erkennbar:

Hier möchte ich aufzeigen, wie man das Problem im Detail auf seine Ursache untersuchen kann.

Für jedes TroubleShooting sind zusätzliche Informationen erforderlich.

System-Informationen

• Der Server heißt WS-MON und ist Mitglied meiner Active Directory Domain.
• Er läuft mit Windows Server 2019 und der Desktop Experience.
• Das System ist eine VM in einem Hyper-V-Server.

Welche Dienste laufen auf dem Server?

• Der Server sammelt von allen anderen Servern die weitergeleiteten Ereignisse in einem zentralen Eventlog. Dafür nutze ich das Windows Eventlog Forwarding (WEF). Dieses habe ich über eine Gruppenrichtlinie „quell-initiiert“ eingerichtet. Die anderen Server senden also die gefilterten Informationen an meinen WS-MON. Die Last sollte daher recht gering sein.
• Dazu ist ein KIWI-SYSLOG-Server installiert. Hier senden meine PFSense-Systeme (Firewall, IPS) ihre Logfiles her. Der SYSLOG-Server speichert die Daten in Textdateien.
• Auf WS-MON habe ich eine PRTG-Instanz installiert. Diese überwacht mit der freien Edition bis zu 100 Sensoren. In meinem Fall habe ich damit diverse Dienste und Komponenten meiner Infrastruktur agentfrei im Blick.
• Zudem laufen einige Scripte über geplante Aufgaben, mit denen ich Informationen sammle und analysiere.

Was wurde zuvor verändert?

• Das System installiert Windows Updates vollautomatisch.
• PRTG darf sich ebenfalls automatisch Updates herunterladen und installieren.
• Die Belastungen auf dem System sollten sich eigentlich nicht verändern: Weder hat sich das Volumen der Eventlogs noch das der PFSense-Logfiles verändert.

Systemabsicherung

• Der Server wird durch verschiedene Gruppenrichtlinien für die Sicherheit gehärtet. Dazu gehört auch die Absicherung durch den Credential Guard.

Sonstiges

• Das System lief fehlerfrei seit der Installation vor einigen Monaten.

Wie geht man nun an die Thematik heran? Zu den Ausgangsinformationen benötige ich Daten des aktuellen Systems. Glücklicherweise konnte ich mich auf dem Server noch anmelden. Alternativ wäre auch ein PowerShell-Remoting denkbar, denn diese Form der Verbindung benötigt nur sehr wenige Ressourcen.

Sollte eine Anmeldung nicht (mehr) möglich sein, dann könnte ein Neustart helfen. Ebenso könnte ich die ausgelastete Ressource (in meinem Fall der Arbeitsspeicher) nach oben skalieren. Aber auch ein Start im guten, alten abgesicherten Modus ist denkbar. Dann bleiben die ganzen Zusatzdienste aus – potentiell also auch die Problem-Komponente.

Einen Neustart hatte ich vor einigen Tagen schon durchgeführt. Das Problem konnte damit also nicht gelöst werden. Bei mir starten die Tools gerade noch, daher verzichte ich auf einen weiteren Neustart. Dieser könnte wertvolle Spuren verwischen. Ich erkenne deutlich den Prozess, der den Arbeitsspeicher bindet. LSAISO ist der „Isolated Local Security Authority“-Prozess. In diesem sind zur Laufzeit die „Geheimnisse“ des Betriebssystems – also Passwörter, Hashes und dergleichen – gespeichert. Normalerweise übernimmt diese Aufgabe der LSASS-Prozess. Dieser stellt die eigentliche „Local Security Authority“ dar. Durch den Credential Guard, der seit Windows Server 2016 und Windows 10 verwendet werden kann, werden die sensiblen Informationen noch einmal zusätzlich abgesichert.

Ich arbeite schon sehr lange mit dem Credential Guard. Er ist auch allen von meinen Servern und Clients aktiv. Doch diese Auslastung kenne ich so nicht:

Und wie zu erwarten war, begnügt sich der Prozess nicht mit dem physikalisch zugesicherten Speicher. Er lässt auch großzügig in die Auslagerungsdatei schreiben:

Dabei verdrängt er als systemkritischer Prozess andere Dienste und Anwendungen. In der Folge erhalte ich z.B. keine Informationen mehr vom Monitoring. Denn dieses hat selber keine Ressourcen mehr. Im Eventlog schreit der Server um Hilfe. Leider wäre für die Weiterleitung dieses Hilferufs mein Monitoring zuständig gewesen, das auf dem betroffenen Server läuft …

Im Anwendungs-Eventlog finde ich weitere Events, die der Auslastung vorangehen:

Und hier finde ich auch durch eine Filterung die Eventlogs, die mein PRTG-Monitoring kurz vor der Abschaltung schreibt:

Ich vergleiche gerne das betroffene System mit anderen, um nach Gemeinsamkeiten und Unterschieden zu suchen. Ist ein anderes System nicht betroffen und hat dieses beispielsweise die gleichen Updates installiert, dann liegt die Vermutung nahe, dass es nicht an den Updates liegt. Wobei das keinesfalls ausgeschlossen werden sollte. Vergleicht hier bitte immer artgleiche Server. Einen Domain Controller mit einem SQL-Server zu vergleichen ist sinnbefreit.

In meiner Infrastruktur sind alle anderen Server im Normalbetrieb. Daher schließe ich vorsichtig das Betriebssystem aus.

Vielleicht hat sich die Belastung schrittweise erhöht und der Server benötigt einfach mehr Power? Dazu ist eine Trendanalyse sinnvoll. Leider ist diese in meinem Fall im PRTG-Server gespeichert. Und dieser läuft auf dem ausgelasteten Server. Die Information werde ich daher später analysieren. Aus der Erfahrung mit meinem Server kann ich aber bestätigen, dass die konfigurierte Menge an Arbeitsspeicher immer ausgereicht hat. Wäre diese langsam auf dieses Maß gestiegen, dann hätte PRTG einen Hilferuf abgesetzt. Die Belastung muss also recht schnell aufgebaut worden sein.

So fällt mein Verdacht auf die installierten Anwendungen und Dienste. Mit dem Ausschlussverfahren kann ich recht schnell die Ursache eingrenzen.

Für den Beweis meiner These „Es ist eine installierte Anwendung bzw. ein Dienst“ deaktiviere ich den PRTG, den SYSLOG-Server und das Eventlog-Forwarding. Anschließend starte ich den Server neu.

Nach der Anmeldung kontrolliere ich die Systemauslastung. Der LSAISO-Prozess nimmt sich den gewohnten Anteil am Arbeitsspeicher. Die Zahl verändert sich nur im KB-Bereich. Die Ursache ist also eine der installierten Komponenten!

Für einen echten Beweis und für die Feindiagnose schalte ich nun eine Funktion nach der nächsten wieder ein. Wenn die Belastung mit dem Hochfahren eines Service wieder steigt, dann kenne ich den Verursacher.

Ich beginne mit dem SYSLOG-Service. Auch nach mehreren Minuten Betrieb verändert sich die Belastung des LSAISO-Prozesses nicht. Der KIWI-SYSLOG-Service ist es wohl nicht:

Jetzt aktiviere ich das Eventlog-Forwarding wieder. Die Aktion dauert etwas, da die anderen Server erst verzögert mit der Zustellung der Events beginnen. Daher warte ich einige Minuten ab und kontrolliere den Status der WEF-Clients:

Jetzt sind fast aller Server wieder online:

Und der Problem-Prozess? Der begnügt sich mit seinen Ressourcen:

Daher kann ich das Eventlog-Forwarding auch ausschließen.

Es bleibt der Monitoring-Service PRTG über. Dieser besteht aus 2 Diensten. Zuerst starte ich den Core-Service. Dabei beobachte ich wieder die Auslastung des Prozesses LSAISO. Der Wert bleibt nahezu statisch.

Zuletzt starte ich den zweiten Service „PRTG-Probes“. Jetzt belegt der LSAISO-Prozess mehr Speicher. Ich merke mir dazu die aktuelle Uhrzeit:

Nach 5 Minuten sind weitere 9 MB allokiert:

Das klingt nach nichts. Aber der Server soll 24/7 laufen. Und rein rechnerisch sind das unter der Annahme der linearen Steigerung 1,6MB je Minute. Das würde dann von jetzt bis 20:00 so aussehen:

In 24 Stunden wären mehr als 2GB Arbeitsspeicher belegt…

Jetzt kenne ich die Komponenten, die das Problem verursachen: ein PRTG-Service auf einem Windows Server 2019 mit aktivem Credential Guard.

Ich benötige aber für die Fehlerbehebung weitere Informationen. Daher prüfe ich nun verschiedene Einstellungen im PRTG und beobachte deren Auswirkungen auf den LSAISO-Prozess.

Mein PRTG überwacht neben den Windows-Servern auch andere Geräte und Dienste. Ich habe einen Verdach, dass mein Problem durch die Windows Sensoren verursacht wird. Daher pausiere ich alle Sensoren, die für meine Windows Services gedacht sind:

Interessant: Seit der Pausierung stagniert der Hunger nach mehr Arbeitsspeicher vom LSAISO-Prozess wieder. Die Vermutung scheint richtig zu sein:

Ich schalte einzelne Sensoren wieder ein. Mit jedem aktiven Windows-Sensor steigt der Arbeitsspeicherkonsum leicht an. Da habe ich mit meiner freien PRTG-Lizenz und max. 100 Sensoren durchaus Glück gehabt.

Vielleicht liegt es an der Kennung, die mein PRTG für den Remotezugriff verwendet? Diese ist ein Active Directory Benutzer, den ich als Service Account verwende. Ich konfiguriere einen anderen Benutzer-Account in den Sensoren. Durch die Vererbung der Einstellungen geht das recht schnell. Dann starte ich die Sensoren wieder. Leider nimmt sich der Credential Guard wieder mehr Speicher. Das Problem wird nicht durch den Service Account verursacht.

Vielleicht ist es gar nicht die PRTG-Konfiguration? Ich probiere die Deaktivierung des Device Guards. Dieser stellt auch den Credential Guard bereit. Die Aktivierung dieser Schutzkomponente übernimmt eine Gruppenrichtlinie:

Ich nehme den Server aus deren Wirkungsbereich heraus, aktualisiere die Gruppenrichtlinienverarbeitung durch ein gpupdate und starte ihn neu. Da ich die Einstellung mit UEFI-Sperre aktiviert habe, wird das aber nicht genügen. Dazu ist etwas Hintergrundwissen hilfreich:

• Der Device Guard soll das System auch vor Schadprogrammen schützen, die selber im Systemkontext laufen. Der LSAISO-Prozess kann im laufenden Betrieb nicht beendet werden. Zur Laufzeit ist das System also sicher. Aber ein Angreifer könnte die Einstellung für den Start des Device Guards verändern und das System neu starten. Dann wäre der Prozess nach dem Neustart aus und die Geheimnisse des Betriebssystems könnten abgegriffen werden.
• Und genau hier greift die UEFI-Sperre. Die GPO erzeugt im UEFI eine Variable für den Device Guard Startmodus. Diese Variable wird auf ReadOnly konfiguriert. Sie kann also auch vom System selber nicht mehr zur Laufzeit verändert werden. Bei jedem Neustart prüft der LSASS-Prozess den Inhalt der Variable. Ist sie vorhanden und auf einen aktiven Device Guard konfiguriert, dann wird der LSAISO-Prozess gestartet – unabhängig davon, was die lokale Registry dazu sagt. Damit bleibt ein Device Guard auch nach dem Neustart aktiv – egal, welche Rechte ein Angreifer erbeutet hat.

Dieses hohe Schutzniveau behindert aber nicht nur Angreifer. Ich als Administrator muss jetzt zusätzliche Schritte unternehmen, um den Device Guard zu deaktivieren. Das einfache Entfernen der GPO wird nicht genügen, denn darin wird ja auch nur der Registry-Key verändert. Die UEFI-Variable kann das System ja selber nicht mehr verändern.

Für die Deaktivierung gibt es eine offizielle Anleitung von Microsoft (https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage). Dabei wird für den nächsten Neustart der UEFI-Boot um eine Sequenz erweitert. In dieser muss dann vor dem Start des Betriebssystems an der Konsole des Servers die Deaktivierung vom Device Guard explizit bestätigt werden. Man benötigt also einen physikalischen Zugang.

Für die Abschaltung stellt Microsoft eine efi-Datei bereit. Diese habe ich in der passenden x64-Variante direkt auf die C-Partition gespeichert. In meinem Server führe ich diese Zeilen in einer administrativen cmd aus:

mountvol X: /s
copy C:\LSAPPLConfig.efi X:\EFI\Microsoft\Boot\LSAPPLConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\LSAPPLConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions %1
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
shutdown -r -t 0

Der Server wird jetzt neugestartet. Auf der Konsole im Hyper-V stehen nun wenige Sekunden für die Abschaltung zur Verfügung:

Anschließend startet der Server wie gewohnt. Nur eben ohne den LSAISO-Prozess des Device Guards. Mit einem Blick ins msinfo kann ich die Abschaltung überprüfen:

Die PRTG-Services starten automatisch. Den LSAISO-Prozess gibt es weiter, denn dieser wird auch für das CodeIntegrity-Enforcement benötigt. Aber er begnügt sich mit wenig Arbeitsspeicher:

Für einen echten Beweis verschiebe ich den Server wieder in den Einflussbereich der DeviceGuard GPO. Ein gpupdate und einen Neustart ist er wieder online. Msinfo zeigt die Präsens:

Und der Taskmanager zeigt den LSAISO-Prozess mit seinem Memory Leak…

Der Beweis ist erbracht: Der Credential Guard des Device Guards kann nicht mit dem PRTG Probe Service umgehen, wenn im PRTG Windows Server remote überwacht werden.

Die Ursache für das direkte Problem ist identifiziert. Aber der Auslöser ist noch nicht bekannt. Den Server betreibe ich seit Monaten problemfrei.

Für die Suche nach dem Auslöser gibt es verschiedene Strategien, die mit unterschiedlichen Fragen verfolgt werden:

• Wann trat das Problem das erste Mal auf? Ggf. wurden zu dieser Zeit Konfigurationen oder Komponenten angepasst…
• Gibt es ein Muster im Problemverlauf? Vielleicht tritt ein Problem immer zu einer bestimmten Zeit auf? Eventuell kann aber auch ein zeitunabhängiger Trigger identifiziert werden, z.B. eine Anmeldung…

Die erste Frage ist meist einfacher zu beantworten. Interessanter Weise hilft mir hier mein jetzt wieder funktionales Monitoring. Der PRTG-Service überwacht sich selber. Und die Daten werden für Trendanalysen und Blicke in die Vergangenheit gespeichert. Also rufe ich den passenden Sensor auf:

Der Text im Bild ist recht klein, aber man erkennt sehr gut den Ausfallzeitraum. Auch kann man meinen Versuch „Reboot tut gut“ nach der ersten Downtime erkennen. Und dass dieser nicht sehr lange hergehalten hat. Ebenso erkennt man, wie lange mein TroubleShooting gedauert hat. Und sehr wichtig ist auch die Aussage: Vorher gab es das Problem nicht – bis auf wenige Klicke ist der Statusgraph bei 100%.

Ich zoome etwas weiter rein:

Jetzt erkennt man deutlich den 18.12.2019 als Startzeitpunkt. Und vielleicht erklären sich jetzt auch die langen Unterbrechungen ohne meine Anteilnahme.

Mit dieser Information geht es weiter im Eventlog. Was passierte in der Früh des 18.12.? Es gab einen Neustart:

Aber warum hat sich der Server neugestartet? So viele Optionen gibt es da nicht. Ich war es nicht. Andere Administratoren gibt es bei mir noch nicht. Also war es der Server selber. Und das macht er nur bei Windows Updates. Die passenden Events finde ich ein paar Einträge weiter unten:

Und nach dem Neustart wurden die Updates als installiert markiert:

Ein Blick in den Update-Verlauf zeigt die Installation mit dem Datum an (Das Bild habe ich später neu erstellen müssen):

Es muss also in mit einem dieser beiden Updates eine Änderung vorgenommen worden sein. Im Update KB4530715 (https://support.microsoft.com/en-us/help/4530715/windows-10-update-kb4530715) sieht es in der Übersicht schon recht treffend aus. Der Device Guard ist schließlich ein Sicherheitsfeature:

Ich folge dem Link „Security Update Guide“ (https://portal.msrc.microsoft.com/en-us/security-guidance) und finde die zum KB dazugehörige CVE-Nummer heraus

Viel interessanter ist aber der Link zu den Dateien, die vom Update geändert wurden. Diesen finde ich auf der Hauptseite des KBs.

Die Datei ist wie üblich schlecht strukturiert, aber ich finde die Lsaiso.exe gelistet.

Ich sehe 2 ordentliche Möglichkeiten für die Lösung meiner Problematik:

1. Microsoft korrigiert den Fehler im Credential Guard mit einem späteren Update.
2. PRTG passt seine Anmeldeprozesse an bzw. gibt Hinweise zum Arbeiten in Umgebungen mit aktivem Credential Guard.

Beide Lösungen werden Zeit benötigen. Diese hat mein Server aber nicht. Daher werde ich bis zur finalen Lösung den Device Guard auf diesem einen Server deaktivieren. Dafür erstelle ich eine separate GPO mit der Einstellung und wende diese gefiltert auf meinen PRTG-Server an. Hier sieht man die GPO mit der Device Guard Deaktivierung. Sie wird in der Rangfolge vor der Richtlinie mit der Aktivierung angewendet. Damit „gewinnt“ ihre Einstellung:

Damit aber nur der Monitor-Server editiert wird, verwende ich einen Sicherheitsfilter:

Natürlich muss ich dafür die Prozedur mit dem UEFI-Unlock erneut ausführen.

Es sind nun einige Wochen vergangen. Der Server läuft ohne den Credential Guard wieder stabil. Zwischenzeitlich hat mein Server das Update vom Februar (2020-02) installiert:

Ein Blick ins Dateisystem verrät, dass eine LSA-DLL modifiziert wurde. Das könnte eine neue Chance für die Reaktivierung des Device Guards sein:

Ich deaktiviere die GPO, mit der ich für diesen einen Server die Abschaltung vorgenommen habe. Damit „gewinnt“ wieder die andere Richtlinie und der Credential Guard sollte reaktiviert werden:

Ich beschleunige den Vorgang durch ein gpupdate auf meinem Monitor-Server. Mit msinfo sehe ich bereits die Einstellung. Diese greift aber erst nach einem Neustart:

Also initialisiere ich den Reboot. MSInfo zeigt nun einen laufenden Credential Guard:

Und wie entwickelt sich dessen Hunger auf Arbeitsspeicher? Das soll ein keines PowerShell-Script aufzeigen:

do {
    $wert = Get-Process -Name LsaIso | 
	    Select-Object -Property `
                @{ n="Zeit" ; e={ Get-Date -Format 'HH:mm:ss' } },
                @{ n="WorkingSet [kb]" ; e={ [int] ($_.workingset / 1024) } }
    
	$wert | Export-Csv -Path .\LSAISO-Monitor.csv -Delimiter ';' -NoTypeInformation -Append
    $wert
    Start-Sleep -Seconds 15
} while ($true)

Ich starte das Script und lass den Server arbeiten:

Nach einiger Zeit hole ich mir die erzeugte CSV-Datei auf meinen Client und lasse Excel die Daten grafisch darstellen. Leider bläht sich LSAISO wieder auf:

Die beiden Updates seit dem ersten Auftreten durch den Patch 2019-12 haben das Problem leider nicht gelöst. Mir bleibt nichts anderes über, als zu dem Workaround zurück zu kehren:

1. Ich aktiviere die GPO mit der Device Guard Deaktivierung wieder.
2. Danach wende ich die Richtlinie durch ein gpupdate an und starte den Server neu.
3. Nun editiere ich den UEFI-Start und deaktiviere den UEFI-Lock des Device Guards auf der Konsole des Servers nach einem weiteren Neustart.

Es wird Zeit, den Hersteller zu informieren. Vielleicht habe ich ja einen Hinweis übersehen?

Auch wenn ich das Problem nicht zufriedenstellend lösen kann: Ich kenne nun die Ursache. Zusätzlich habe ich einen funktionalen Workaround gefunden. Zudem konnte ich ein interessantes TroubleShooting aufzeichnen. Ich werde an der Thematik dran bleiben und die Neuigkeiten hier nachtragen.

Den Artikel gibt es wie gewohnt hier als pdf zum downloaden.

Stay tuned!