Application Control: Windows Server gegen unerwünschte Anwendungen und Malware schützen

Diese Technik soll das Einschleusen von Schadcode verhindern, beispiels­weise nach Provozieren eines Puffer­überlaufs. Dieser VBS-Teil von Device Guard heißt nun Exploit Guard. Man kann ihn über MDM oder Gruppen­richtlinien aktivieren, wenn Rechner die not­wendigen Hardware-Voraus­setzungen erfüllen.

Die GPO-Einstellung findet sich unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard und heißt Virtualisierungs­basierte Sicherheit aktivieren. Um das System schon vor dem Laden von Hyper-V abzusichern, verlangt Exploit Guard, dass Secure Boot ein­geschaltet ist.

Whitelisting mit Application Control

Die zweite Komponente von Device Guard neben der Hypervisor-basierten Sicherheit besteht in Richtlinien für die konfigu­rierbare Code-Integrität. Sie heißt seit Windows 10 1607 und Server 2016 Windows Defender Application Control und lässt sich auf älteren oder schwächer ausge­statteten PCs unabhängig von Exploit Guard einsetzen.

Anders als die Software Restriction Policies handelt es sich um eine Lösung, die wie AppLocker alle am Rechner installierten Programme erfassen kann und nur deren Ausführung erlaubt.

Im Gegensatz zu den beiden anderen Techniken kennt es aber keine Pfadregeln, so dass man zum Beispiel nicht pauschal alle Anwendungen freigeben kann, die unter C:\Programme liegen. Daher muss man bei einem hohen Rule Level jede neu installierte Software explizit erfassen, die Richtlinie aktualisieren und neu verteilen.

Update: In Windows 10 1903 hat Microsoft WDAC um Pfadregeln ergänzt. Details und eine Übersicht über alle weiteren Neuerungen bietet dieser Beitrag.

Nicht für dynamische Umgebungen

Aus diesem Grund positioniert Microsoft dieses Feature für Umgebungen, die sich nur wenig ändern. Dazu zählen voll verwaltete Workstations, die spezi­fischen Aufgaben dienen und auf denen neue Anwendungen nur selten oder nie installiert werden.

Dieses Kriterium trifft auch auf Server zu, die kritische Infrastruktur­dienste erbringen und in der Regel keine zusätzlichen Anwendungen benötigen.

Dazu gehören Domänen-Controller oder Hyper-V-Hosts. Zusätzlich bietet sich an, auch File-Server gegen das Aus­führen von unauto­risierten Pro­grammen zu sperren, um die dort ge­speicherten Daten zu schützen.

Verschieden strenge Rule Levels

Um Programme zu identifizieren, bietet WDAC mehrere Verfahren an. FilePublisher kombiniert dafür mehrere Merkmale, nämlich das Zertifikat des Herstellers, den Dateinamen und die (minimale) Versions­nummer der Software. Daher lassen sich neuere Versionen einer autorisierten Anwendung einspielen, ohne dass man die Policy anpassen muss.

Etwas großzügiger ist Publisher, das auch jedes neu installierte Programm eines bereits per Zertifikat bekannten und erlaubten Herstellers akzeptiert.

Nicht signierte Software kann es anhand eines Hashcodes identifizieren. Dieser muss allerdings nach jedem Update einer Anwendung neu generiert werden, so dass anschließend auch die Aktualisierung der Richtlinien ansteht. Daher kann man alternativ nur den Dateinamen heranziehen, was aber eine relativ schwache Methode zur Erkennung einer Software ist.

Management mittels PowerShell

Für das Management von Regeln für Application Control steht kein GUI-Tool zur Verfügung, vielmehr dient nur ein PowerShell-Modul diesem Zweck. Eine neue Richtlinie erzeugt man mit dem Cmdlet New-CIPolicy.

Um eine Whitelist für Anwendungen auf einem Server zu generieren, der gegen Änderungen weitgehend gesperrt sein soll, könnte man so vorgehen:

New-CIPolicy -FilePath MyCIPolicy.xml -Level FilePublisher -Fallback Hash -UserPEs

Der erforderliche Parameter FilePath spezifiziert den Namen der XML-Datei, in der die Regeln gespeichert werden. Mit Level definiert man das Verfahren zur Identifizierung von Software. Auf einem kritischen Server entscheiden wir uns hier für das strenge FilePublisher.

Über FallBack kann man einen alternativen Rule Level angeben, der dann greift, wenn der primäre nicht anwendbar ist. Das gilt in unserem Beispiel für alle Programm­dateien, die nicht signiert sind. In diesem Fall würde WDAC einen Hash errechnen.

Schließlich bestimmt man mit UserPEs, dass nicht nur Code berücksichtigt wird, der auf Kernelebene läuft, sondern auch normale Anwendungen im User Mode.

Wenn man das Kommando abschickt, dann durchsucht das Cmdlet das gesamte Server-Laufwerk nach Applikationen. Je nach Anzahl der vorhandenen Dateien kann das einige Zeit in Anspruch nehmen.

Optionen verwalten

Öffnet man danach die angegebene XML-Datei in einem Texteditor, dann sieht man gleich zu Beginn eine Liste mit mehreren Optionen. Darunter findet sich Enabled:UMCI, das für User Mode Code Integrity steht und die wir mit dem Schalter UserPEs explizit aktiviert haben.

Daneben gibt es aber noch einige, die standard­mäßig eingefügt werden und die man bei Bedarf ausdrücklich entfernen muss. Dazu gehört Enabled:Unsigned System Integrity Policy, das die Verwendung unsignierter Policy-Dateien zulässt.

Löscht man diese Option und verwendet eine signierte Policy, dann kann man diese nur mit einer neuen Richtlinie aktualisieren, die mit einem in der Whitelist zugelassenen Zertifikat signiert wurde. Nicht einmal ein Admin kann diese dann entfernen.

Schließlich bewirkt Enabled:Audit Mode, dass WDAC unzulässige Anwendungen nicht blockiert, sondern dass der Aufruf eines solchen Pro­gramms nur im Eventlog aufgezeichnet wird. Der Audit Mode erlaubt somit ein Testen der Whitelist, bevor man sie scharfschaltet.

Die Einträge von WDAC finden sich in der Ereignis­anzeige unter Anwendungs- und Dienstprotokolle => Microsoft => Windows => Codeintegrity => Operational. Im Audit Mode erscheinen Aufrufe unautorisierter Programme als Information, danach im Blockier­modus als Fehler.

Möchte man den Audit Mode deaktivieren, dann muss man die XML-Datei nicht von Hand bearbeiten. Vielmehr übernimmt Set-RuleOption diese Aufgabe:

Set-RuleOption -FilePath MyPolicy.xml -Option 3 -Delete

Ohne den Schalter Delete fügt das Cmdlet die jeweilige Option hinzu. Leider verwendet Microsoft für die Optionen nur numerische Werte.

Wenn man die Zahl für eine bestimmte Option herausfinden möchte, dann zeigt

Set-RuleOption -Help

die gesamte Liste an.

CI-Richtlinien anwenden

Sobald die Policy einsatzbereit ist, muss man sie in ein binäres Format umwandeln, bevor man sie auf die Rechner verteilen kann. Dafür setzt man einen Befehl nach diesem Muster ab:

ConvertFrom-CIPolicy -XmlFilePath TestCI.xml -BinaryFilePath TestCI.p7b

Nun richtet man ein GPO ein, um das Feature zu aktivieren und die Richtlinie anzuwenden. Die dafür zuständige Einstellung heißt Windows Defender-Anwendungssteuerung bereitstellen und befindet sich ebenfalls unter Computer­konfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard. Dort gibt man den Namen der binären Policy-Datei ein.

Ein Gegenstück dazu unter Benutzer­konfiguration gibt es nicht, weil WDAC ein Feature ist, das im Unterschied zu AppLocker nur für gesamte Computer und nicht auf ausgewählte Benutzer wirkt.

Policy für neue Software aktualisieren

Ist die Richtlinie in Kraft und man steht vor der Situation, dass man eine neue Anwendung installieren muss, die aufgrund des gewählten Rule Levels nicht laufen würde, dann muss man die vorhandene Policy erweitern.

Um das Setup der Software ausführen zu können, wird man Code Integrity in den Audit Mode versetzen oder deaktivieren. Danach nutzt man New-CIPolicy für einen erneuten Scan, wobei man diesen dann auf das Verzeichnis beschränken kann, in dem sich die neue Software befindet:

New-CIPolicy -FilePath download.xml -Level FilePublisher `
-Fallback Hash -UserPEs -ScanPath .\Downloads\ `
-OmitPaths .\Downloads\NoScan\

Der Aufruf in diesem Beispiel würde das Download-Verzeichnis untersuchen, um etwa eine portable SysInternals-Anwendung zu erfassen. Das Unter­verzeichnis NoScan überspringt das Tool dabei jedoch.

Anschließend führt man die neue XML-Datei mit jener der bestehenden Policy zusammen:

Merge-CIPolicy TestCI.xml, download.xml -OutputFilePath NewTestCI.xml

Die Output-Datei konvertiert man wie gehabt mit ConvertFrom-CIPolicy und kopiert die binäre Version an den Ort, der im GPO angegeben ist. Typischer­weise handelt es sich dabei um ein Share auf einem File-Server.