Tags: Sicherheit, Malware, Windows Server 2019
Windows Defender Application Control (WDAC) ist Microsofts neueste Technologie für das Whitelisting von Anwendungen. Wegen ihrer umständlichen Handhabung eignet sie sich nicht für die meisten Workstations, kann aber Domain-Controller, Hyper-V-Hosts oder File-Server gegen unautorisierte Programme schützen.
Das Feature ist ein Bestandteil von Device Guard, das zusätzlich die Systemintegrität mit Hilfe von Virtualization-based Security (VBS) gewährleistet. Sie schaltet mit Hilfe der CPU-Erweiterungen Intel-VT oder AMD-V den Speicher von Software (z.B. Treiber), die im Kernel-Modus läuft, in den Nur-Lese- oder Ausführen-Status.
Exploit Guard aktivieren
Diese Technik soll das Einschleusen von Schadcode verhindern, beispielsweise nach Provozieren eines Pufferüberlaufs. Dieser VBS-Teil von Device Guard heißt nun Exploit Guard. Man kann ihn über MDM oder Gruppenrichtlinien aktivieren, wenn Rechner die notwendigen Hardware-Voraussetzungen erfüllen.
Die GPO-Einstellung findet sich unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard und heißt Virtualisierungsbasierte Sicherheit aktivieren. Um das System schon vor dem Laden von Hyper-V abzusichern, verlangt Exploit Guard, dass Secure Boot eingeschaltet ist.
Whitelisting mit Application Control
Die zweite Komponente von Device Guard neben der Hypervisor-basierten Sicherheit besteht in Richtlinien für die konfigurierbare 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 ausgestatteten 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 spezifischen Aufgaben dienen und auf denen neue Anwendungen nur selten oder nie installiert werden.
Dieses Kriterium trifft auch auf Server zu, die kritische Infrastrukturdienste 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 Ausführen von unautorisierten Programmen zu sperren, um die dort gespeicherten 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) Versionsnummer 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 Programmdateien, 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 standardmäß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 Programms 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 Ereignisanzeige unter Anwendungs- und Dienstprotokolle => Microsoft => Windows => Codeintegrity => Operational. Im Audit Mode erscheinen Aufrufe unautorisierter Programme als Information, danach im Blockiermodus 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 Computerkonfiguration => Richtlinien => Administrative Vorlagen => System => Device Guard. Dort gibt man den Namen der binären Policy-Datei ein.
Ein Gegenstück dazu unter Benutzerkonfiguration 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 Unterverzeichnis 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. Typischerweise handelt es sich dabei um ein Share auf einem File-Server.
Täglich Know-how für IT-Pros mit unserem Newsletter
Ähnliche Beiträge
- Übersicht: Die wichtigsten Features von Windows Defender
- Überwachter Ordnerzugriff: Ransomware-Schutz mit Gruppenrichtlinien und PowerShell konfigurieren
- Reduktion der Angriffsfläche in Microsoft Defender mit Gruppenrichtlinien oder PowerShell aktivieren
- Schädliche Apps und unsichere Treiber mit Microsofts WDAC-Regeln blockieren
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
Weitere Links