Grundlegendes zu Richtlinienregeln und Dateiregeln für Windows Defender Anwendungssteuerung (Application Control, WDAC)

Hinweis

Einige Funktionen von Windows Defender Anwendungssteuerung sind nur in bestimmten Windows-Versionen verfügbar. Erfahren Sie mehr über die Verfügbarkeit von WDAC-Features.

Windows Defender Anwendungssteuerung (WDAC) kann steuern, was auf Ihren Windows-Geräten ausgeführt wird, indem Richtlinien festgelegt werden, die angeben, ob ein Treiber oder eine Anwendung vertrauenswürdig ist. Eine Richtlinie enthält Richtlinienregeln, die Optionen wie den Überwachungsmodus steuern, und Dateiregeln (oder Dateiregelebenen), die angeben, wie Anwendungen identifiziert werden, denen Ihre organization vertrauen.

Bereitstellen der Windows Defender-Anwendungssteuerungsrichtlinien

Verwenden Sie zum Ändern der Richtlinienregeloptionen einer vorhandenen WDAC-Richtlinien-XML den WDAC-Richtlinien-Assistenten oder das PowerShell-Cmdlet Set-RuleOption .

Sie können verschiedene Regeloptionen in einer WDAC-Richtlinie festlegen. Tabelle 1 beschreibt jede Regeloption und gibt an, ob zusätzliche Richtlinien sie festlegen können. Einige Regeloptionen sind für zukünftige Arbeiten reserviert oder werden nicht unterstützt.

Hinweis

Es wird empfohlen, zuerst Aktiviert: Überwachungsmodus zu verwenden, da Sie damit neue WDAC-Richtlinien testen können, bevor Sie sie erzwingen. Im Überwachungsmodus werden Anwendungen normal ausgeführt, aber WDAC protokolliert Ereignisse, wenn eine Datei ausgeführt wird, die von der Richtlinie nicht zulässig ist. Um diese Dateien zuzulassen, können Sie die Richtlinieninformationen aus dem Ereignisprotokoll erfassen und diese Informationen dann mit der vorhandenen Richtlinie zusammenführen. Wenn Aktiviert:Überwachungsmodus gelöscht wird, wird die Richtlinie im erzwungenen Modus ausgeführt.

Einige Apps verhalten sich möglicherweise anders, auch wenn sich Ihre Richtlinie im Überwachungsmodus befindet. Wenn eine Option das Verhalten im Überwachungsmodus ändern kann, ist dies in Tabelle 1 angegeben. Sie sollten Ihre Apps immer gründlich testen, wenn Sie wichtige Updates für Ihre WDAC-Richtlinien bereitstellen.

Tabelle 1: Bereitstellen der Windows Defender-Anwendungssteuerung – Richtlinienregeloptionen

Regeloption Beschreibung Gültige Zusatzoption
0 Enabled:UMCI WDAC-Richtlinien schränken die Binärdateien für den Kernel- und den Benutzermodus. Standardmäßig sind nur die Binärdateien des Kernelmodus eingeschränkt. Durch das Aktivieren dieser Regeloption, werden die ausführbaren Dateien und Skripts des Benutzermodus überprüft. Nein
1 Enabled:Boot Menu Protection Diese Option wird derzeit nicht unterstützt. Nein
2 Required:WHQL Kerneltreiber, die nicht mit Windows Hardware Quality Labs (WHQL) signiert sind, dürfen standardmäßig ausgeführt werden. Zum Aktivieren dieser Regel ist es erforderlich, dass jeder Treiber WHQL-signiert ist und die Legacytreiberunterstützung entfernt wird. Für Windows 10 erstellte Kerneltreiber sollten WHQL-zertifiziert sein. Nein
3 Enabled:Audit Mode (Default) Weist WDAC an, Informationen zu Anwendungen, Binärdateien und Skripts zu protokollieren, die bei einem Erzwingen der Richtlinie blockiert worden wären. Sie können diese Option verwenden, um die potenziellen Auswirkungen Ihrer WDAC-Richtlinie zu identifizieren, und die Überwachungsereignisse verwenden, um die Richtlinie vor der Erzwingung zu verfeinern. Löschen Sie diese Option, um eine WDAC-Richtlinie zu erzwingen. Nein
4 Disabled:Flight Signing Wenn diese Option aktiviert ist, werden Binärdateien aus Windows-Insider-Builds nicht als vertrauenswürdig eingestuft. Diese Option ist nützlich für Organisationen, die nur veröffentlichte Binärdateien ausführen möchten, nicht Vorabversionen von Windows-Builds. Nein
5 Enabled:Inherit Default Policy Diese Option ist für die zukünftige Verwendung reserviert, und hat derzeit keine Auswirkungen. Ja
6 Enabled:Unsigned System Integrity Policy (Default) Ermöglicht der Richtlinie, nicht signiert zu bleiben. Wenn diese Option entfernt wird, muss die Richtlinie signiert werden, und alle zusätzlichen Richtlinien müssen ebenfalls signiert werden. Die Zertifikate, die für zukünftige Richtlinienupdates vertrauenswürdig sind, müssen im Abschnitt „UpdatePolicySigners“ identifiziert werden. Zertifikate, die für zusätzliche Richtlinien vertrauenswürdig sind, müssen im Abschnitt SupplementalPolicySigners identifiziert werden. Nein
7 Allowed:Debug Policy Augmented Diese Option wird derzeit nicht unterstützt. Ja
8 Required:EV Signers Diese Option wird derzeit nicht unterstützt. Nein
9 Enabled:Advanced Boot Options Menu Das F8-Menü vor dem Start ist standardmäßig für alle WDAC-Richtlinien deaktiviert. Durch das Festlegen dieser Regeloption kann das F8-Menü physisch anwesenden Benutzern angezeigt werden. Nein
10 Enabled:Boot Audit on Failure Wird verwendet, wenn die WDAC-Richtlinie sich im Erzwingungsmodus befindet. Wenn ein startkritischer Treiber während des Startvorgangs ausfällt, wird die WDAC-Richtlinie in den Überwachungsmodus versetzt, sodass Windows geladen wird. Administratoren können die Fehlerursache im Ereignisprotokoll „CodeIntegrity“ überprüfen. Nein
11 Disabled:Script Enforcement Mit dieser Option werden Optionen zur Skripterzwingung deaktiviert, die PowerShell, Windows-basierter Skripthost (wscript.exe), Windows-konsolenbasierter Skripthost (cscript.exe), HTA-Dateien, die in Microsoft HTML-Anwendungshost (mshta.exe) ausgeführt werden, und MSXML abdecken. Einige Skripthosts verhalten sich möglicherweise anders, auch wenn sich Ihre Richtlinie im Überwachungsmodus befindet. Weitere Informationen zur Skripterzwingung finden Sie unter Skripterzwingung mit WDAC.
HINWEIS: Diese Option wird unter Windows Server 2016 oder Windows 10 1607 LTSB nicht unterstützt und sollte unter diesen Betriebssystemen nicht verwendet werden.		 Nein
12 Required:Enforce Store Applications Wenn diese Regeloption aktiviert ist, gelten WDAC-Richtlinien auch für universelle Windows-Anwendungen. Nein
13 Enabled:Managed Installer Verwenden Sie diese Option, um von einem verwalteten Installationsprogramm installierte Anwendungen automatisch zuzulassen. Weitere Informationen finden Sie unter Autorisieren von Apps, die mit einem von WDAC verwalteten Installationsprogramm bereitgestellt wurden Ja
14 Enabled:Intelligent Security Graph Authorization Verwenden Sie diese Option, um Anwendungen mit einem "bekannten guten" Ruf gemäß Der Definition von Microsoft Intelligent Security Graph (ISG) automatisch zuzulassen. Ja
15 Enabled:Invalidate EAs on Reboot Wenn die Option Intelligent Security Graph (14) verwendet wird, legt WDAC ein erweitertes Dateiattribut fest, das angibt, dass die Ausführung der Datei autorisiert wurde. Diese Option bewirkt, dass WDAC den Ruf für Dateien, die zuvor von der ISG autorisiert wurden, in regelmäßigen Abständen erneut überprüft. Nein
16 Enabled:Update Policy No Reboot Verwenden Sie diese Option, um zukünftige WDAC-Richtlinienupdates ohne einen Neustart des Systems anzuwenden.
HINWEIS: Diese Option wird nur unter Windows 10, Version 1709 und höher, oder Windows Server 2019 und höher unterstützt.		 Nein
17 Aktiviert:Zusatzrichtlinien zulassen Verwenden Sie diese Option für eine Basisrichtlinie, um es ergänzenden Richtlinien zu ermöglichen, sie zu erweitern.
HINWEIS: Diese Option wird nur unter Windows 10, Version 1903 und höher, oder Windows Server 2022 und höher unterstützt.		 Nein
18 Deaktiviert:Laufzeit-Dateipfadregelschutz Diese Option deaktiviert die standardmäßige Laufzeitüberprüfung, die nur FilePath-Regeln für Pfade zulässt, die nur von einem Administrator geschrieben werden können.
HINWEIS: Diese Option wird nur unter Windows 10, Version 1903 und höher, oder Windows Server 2022 und höher unterstützt.		 Ja
19 Aktiviert:Sicherheit für dynamischen Code Aktiviert die Richtlinienerzwingung für .NET-Anwendungen und dynamisch geladene Bibliotheken.
HINWEIS: Diese Option wird nur unter Windows 10, Version 1803 und höher, oder Windows Server 2019 und höher unterstützt.
HINWEIS: Diese Option wird immer erzwungen, wenn eine WDAC-UMCI-Richtlinie sie aktiviert. Es gibt keinen Überwachungsmodus für die .NET-Sicherheitshärtung für dynamischen Code.		 Nein
20 Aktiviert:Widerrufen als nicht signiert ablaufen Verwenden Sie diese Option, um Binärdateien, die mit gesperrten Zertifikaten signiert wurden, oder abgelaufene Zertifikate mit der Lifetime Signing-EKU für die Signatur als "Nicht signierte Binärdateien" für Prozesse/Komponenten im Benutzermodus unter Unternehmenssignaturszenarien zu behandeln. Nein
Aktiviert:Dynamische Codevertrauensstellung im Entwicklermodus Verwenden Sie diese Option, um UWP-Apps zu vertrauen, die in Visual Studio gedebuggt oder über das Geräteportal bereitgestellt werden, wenn der Entwicklermodus auf dem System aktiviert ist. Nein

Dateiregelebenen der Windows Defender-Anwendungssteuerung

Anhand von Regelebenen können Administratoren die Ebene angeben, auf der Sie ihren Anwendungen vertrauen möchten. Diese Vertrauensebene kann so präzise sein wie der Hash jeder Binärdatei oder so allgemein wie ein Zertifizierungsstellenzertifikat. Sie geben Dateiregelebenen an, wenn Sie den WDAC-Assistenten oder WDAC PowerShell-Cmdlets zum Erstellen und Ändern von Richtlinien verwenden.

Jede Dateiregelebene hat Vor- und Nachteile. Verwenden Sie Tabelle 2, um die geeignete Schutzebene für Ihre verfügbaren Verwaltungsressourcen und das WDAC-Bereitstellungsszenario auszuwählen.

Hinweis

WDAC-auf Signierern basierende Regeln funktionieren nur mit RSA-Kryptografie. ECC-Algorithmen wie ECDSA werden nicht unterstützt. Wenn Sie versuchen, Dateien anhand von ECC-Signaturen zuzulassen, wird VerificationError = 23 für die entsprechenden 3089-Signaturinformationsereignisse angezeigt. Dateien können stattdessen durch Hash- oder Dateiattributeregeln oder mithilfe anderer Signaturgeberregeln zugelassen werden, wenn die Datei auch mit Signaturen mit RSA signiert ist.

Tabelle 2 Dateiregelebenen der Windows Defender-Anwendungssteuerungsrichtlinie – Dateiregelebenen

Regelebene Beschreibung
Hash Gibt einzelne Authenticode/PE-Bildhashwerte für jede ermittelte Binärdatei an. Diese Ebene ist die spezifischste Ebene und erfordert mehr Aufwand, um die Hashwerte der aktuellen Produktversionen zu verwalten. Nach jedem Aktualisieren einer Binärdatei wird der Hashwert geändert, wodurch eine Richtlinienaktualisierung erforderlich wird.
FileName Gibt den ursprünglichen Dateinamen für jede Binärdatei an. Auch wenn die Hashwerte für eine Anwendung geändert werden, wenn sie aktualisiert wird, ist dies für gewöhnlich bei den Dateinamen nicht der Fall. Diese Ebene bietet eine weniger spezifische Sicherheit als die Hashebene, erfordert aber in der Regel keine Richtlinienaktualisierung, wenn eine Binärdatei geändert wird. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName.
FilePath Ab Windows 10, Version 1903, ermöglicht diese Ebene die Ausführung von Binärdateien von bestimmten Dateipfadspeicherorten. FilePath-Regeln gelten nur für Binärdateien im Benutzermodus und können nicht verwendet werden, um Kernelmodustreiber zuzulassen. Weitere Informationen zu Regeln auf FilePath-Ebene finden Sie weiter unten in diesem Artikel.
SignedVersion Bei dieser Ebene wird die Herausgeberregel mit einer Versionsnummer kombiniert. Sie ermöglicht die Ausführung aller Versionen des angegebenen Herausgebers mit einer Version, die mindestens der angegebenen Versionsnummer entspricht.
Herausgeber Diese Ebene kombiniert die PcaCertificate-Ebene (normalerweise ein Zertifikat unter der Wurzel) und den allgemeinen Namen (CN) des untergeordneten Zertifikats. Sie können diese Regelebene verwenden, um einem Zertifikat zu vertrauen, das von einer bestimmten Zertifizierungsstelle ausgestellt und an ein bestimmtes Unternehmen ausgestellt wurde, dem Sie vertrauen (z. B. Intel für Gerätetreiber).
FilePublisher Diese Ebene kombiniert das Attribut "FileName" der signierten Datei plus "Publisher" (PCA-Zertifikat mit CN of leaf) sowie eine Mindestversionsnummer. Mit dieser Option werden bestimmte Dateien vom angegebenen Herausgeber mit einer Dateiversion, die mindestens der angegebenen Versionsnummer entspricht, als vertrauenswürdig eingestuft. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName.
LeafCertificate Fügt vertrauenswürdige Signaturgeber auf der einzelnen Signaturzertifikatsebene hinzu. Der Vorteil der Verwendung dieser Ebene gegenüber der einzelnen Hashebene besteht darin, dass neue Versionen des Produkts unterschiedliche Hashwerte haben, aber in der Regel dasselbe Signaturzertifikat. Wenn diese Ebene verwendet wird, wäre keine Richtlinienaktualisierung erforderlich, um die neue Version der Anwendung auszuführen. Blattzertifikate haben jedoch in der Regel kürzere Gültigkeitsdauern als andere Zertifikatebenen, sodass die WDAC-Richtlinie aktualisiert werden muss, wenn sich diese Zertifikate ändern.
PcaCertificate Fügt den Signaturgebern das höchste verfügbare Zertifikat in der angegebenen Zertifikatskette hinzu. Bei dieser Ebene handelt es sich in der Regel um ein Zertifikat unterhalb des Stamms, da die Überprüfung nicht die vollständige Zertifikatkette über die lokalen Stammspeicher oder eine Onlineüberprüfung auflöst.
RootCertificate Nicht unterstützt
WHQL Vertrauen nur Binärdateien, die an Microsoft übermittelt und vom Windows Hardware Qualification Lab (WHQL) signiert wurden. Diese Ebene ist hauptsächlich für Kernel-Binärdateien vorgesehen.
WHQLPublisher Diese Ebene kombiniert die WHQL-Ebene und den CN im untergeordneten Zertifikat und ist in erster Linie für Kernelbinärdateien vorgesehen.
WHQLFilePublisher Diese Ebene kombiniert das Attribut "FileName" der signierten Datei sowie "WHQLPublisher" sowie eine Mindestversionsnummer. Diese Ebene ist hauptsächlich für Kernel-Binärdateien vorgesehen. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName.

Hinweis

Wenn Sie WDAC-Richtlinien mit New-CIPolicyerstellen, können Sie eine primäre Dateiregelebene angeben, indem Sie den Parameter -Level einschließen. Verwenden Sie für ermittelte Binärdateien, denen anhand der primären Dateiregelkriterien nicht vertraut werden kann, den Parameter -Fallback . Wenn z. B. die primäre Dateiregelebene „PCACertificate“ ist, Sie aber auch den nicht signierten Anwendungen vertrauen möchten, werden die Hashwerte von Binärdateien, die nicht über ein Signaturzertifikat verfügen, mithilfe der Hashregelebene als Fallback hinzugefügt,.

Hinweis

  • WDAC unterstützt nur Signaturgeberregeln für RSA-Zertifikatsignaturschlüssel mit maximal 4096 Bits.
  • Der Code verwendet CN für die Felder „CertSubject“ und „CertIssuer“ in der Richtlinie. Sie können das Posteingangszertifikat verwenden, um das zugrunde liegende Format zu überprüfen, um sicherzustellen, dass UTF-8 nicht für den CN verwendet wird. Sie können beispielsweise eine druckbare Zeichenfolge, IA5 oder BMP verwenden.

Hinweis

Falls zutreffend, werden die Mindest- und Höchstversionsnummern in einer Dateiregel im Richtlinien-XML als MinimumFileVersion bzw. MaximumFileVersion referenziert.

  • MinimumFileVersion und MaximumFileVersion angegeben: Für Allow-Regeln sind Dateien mit einer Version zulässig, die größer oder gleich MinimumFileVersion und kleiner oder gleich MaximumFileVersion ist. Bei Deny-Regeln werden Dateien mit einer Version verweigert, die größer oder gleich MinimumFileVersion und kleiner oder gleich MaximumFileVersion ist.
  • MinimumFileVersion ohne MaximumFileVersion angegeben: Für Zulassungsregeln dürfen Dateien mit einer Version ausgeführt werden, die größer oder gleich der angegebenen Version ist. Bei Deny-Regeln werden Dateien mit einer Version blockiert, die kleiner oder gleich der angegebenen Version ist.
  • MaximumFileVersion ohne MinimumFileVersion angegeben: Für Zulassungsregeln dürfen Dateien mit einer Version ausgeführt werden, die kleiner oder gleich der angegebenen Version ist. Bei Deny-Regeln werden Dateien mit einer Version blockiert, die größer oder gleich der angegebenen Version ist.

Beispiel für die Verwendung von Dateiregelebenen

Stellen Sie sich beispielsweise einen IT-Experten in einer Abteilung vor, die viele Server ausführt. Sie möchten nur Software ausführen, die von den Unternehmen signiert wurde, die ihre Hardware, ihr Betriebssystem, Antivirensoftware und andere wichtige Software bereitstellen. Die Mitarbeiter wissen, dass auf den Servern auch eine intern programmierte, unsignierte Anwendung ausgeführt wird, die jedoch nur selten aktualisiert wird. Die Ausführung dieser Anwendung soll zugelassen werden.

Zur Erstellung der WDAC-Richtlinie wird ein Referenzserver auf Basis der Standardhardware erstellt, auf dem die gesamte Software installiert wird, die gewöhnlich auf den Servern ausgeführt werden darf. Anschließend wird New-CIPolicy mit -Level Publisher ausgeführt (um Software von Softwareanbietern (den „Anbietern“) zuzulassen, und -Fallback Hash (um die interne, unsignierte Anwendung zuzulassen). Sie stellen die Richtlinie im Überwachungsmodus bereit, um die potenziellen Auswirkungen der Erzwingung der Richtlinie zu ermitteln. Mit Hilfe der Überwachungsdaten aktualisieren sie ihre WDAC-Richtlinien, um jede andere Software einzuschließen, die sie ausführen möchten. Anschließend wird die WDAC-Richtlinie im erzwungenen Modus für die Server aktiviert.

Im Rahmen des normalen Betriebs werden schließlich Softwareupdates installiert oder möglicherweise Software derselben Softwareanbieter hinzugefügt. Da der "Herausgeber" für diese Updates und Software unverändert bleibt, muss die WDAC-Richtlinie nicht aktualisiert werden. Wenn die nicht signierte interne Anwendung aktualisiert wird, müssen sie auch die WDAC-Richtlinie aktualisieren, um die neue Version zuzulassen.

Rangfolge der Dateiregel

WDAC verfügt über eine integrierte Logik für Dateiregelkonflikte, die in die Rangfolge übersetzt wird. Zunächst werden alle gefundenen expliziten Ablehnungsregeln verarbeitet. Anschließend werden alle expliziten Zulassungsregeln verarbeitet. Wenn keine Verweigerungs- oder Zulassungsregel vorhanden ist, sucht WDAC nach einem Managed Installer-Anspruch , wenn die Richtlinie dies zulässt. Schließlich greift WDAC auf die ISG zurück, wenn die Richtlinie dies zulässt.

Hinweis

Um die Argumentation ihrer WDAC-Richtlinien zu vereinfachen, empfiehlt es sich, für Windows-Versionen, die mehrere WDAC-Richtlinien unterstützen, separate ALLOW- und DENY-Richtlinien zu verwalten.

Verwenden von -SpecificFileNameLevel mit Regeln auf FileName-, FilePublisher- oder WHQLFilePublisher-Ebene

Standardmäßig verwenden die Regelebenen FileName, FilePublisher und WHQLFilePublisher das OriginalFileName-Attribut aus dem Ressourcenheader der Datei. Sie können ein alternatives Ressourcenheader-Attribut für Ihre Regeln verwenden, indem Sie -SpecificFileNameLevel festlegen. Für instance kann ein Softwareentwickler denselben ProductName für alle Binärdateien verwenden, die Teil einer App sind. Mit -SpecificFileNameLevel können Sie eine einzelne Regel erstellen, um alle Binärdateien in Ihrer Richtlinie abzudecken, anstatt einzelne Regeln für jede Datei.

Tabelle 3 beschreibt die verfügbaren Optionen für Ressourcenheaderattribute, die Sie mit -SpecificFileNameLevel festlegen können.

Tabelle 3. -SpecificFileNameLevel-Optionen

SpecificFileNameLevel-Wert Beschreibung
FileDescription Gibt die vom Entwickler der Binärdatei bereitgestellte Dateibeschreibung an.
InternalName Gibt den internen Namen der Binärdatei an.
OriginalFileName Gibt den ursprünglichen Dateinamen der Binärdatei oder den Namen an, mit dem die Datei zuerst erstellt wurde.
PackageFamilyName Gibt den Paketfamiliennamen der Binärdatei an. Der Paketfamilienname besteht aus zwei Teilen: dem Namen der Datei und der Herausgeber-ID.
Productname Gibt den Namen des Produkts an, mit dem die Binärdatei ausgeliefert wird.
Filepath Gibt den Dateipfad der Binärdatei an.

Weitere Informationen zu Dateipfadregeln

Dateipfadregeln bieten nicht dieselben Sicherheitsgarantien wie explizite Signaturgeberregeln, da sie auf änderbaren Zugriffsberechtigungen basieren. Dateipfadregeln eignen sich am besten für Umgebungen, in denen die meisten Benutzer als Standard und nicht als Administrator ausgeführt werden. Pfadregeln eignen sich am besten, um Pfade zuzulassen, von denen Sie erwarten, dass sie nur vom Administrator schreibbar bleiben. Sie sollten Pfadregeln für Verzeichnisse vermeiden, in denen Standardbenutzer ACLs für den Ordner ändern können.

Beschreibbare Dateipfade

Standardmäßig führt WDAC zur Laufzeit eine Überprüfung der Beschreibbarkeit durch, die sicherstellt, dass die aktuellen Berechtigungen für den angegebenen Dateipfad nur Schreibzugriff für Administratorbenutzer zulassen.

Es gibt eine definierte Liste von SIDs, die WDAC als Administratoren erkennt. Wenn ein Dateipfad Schreibberechtigungen für eine SID zulässt, die nicht in dieser Liste enthalten ist, gilt der Dateipfad als vom Benutzer beschreibbar, auch wenn die SID einem benutzerdefinierten Administratorbenutzer zugeordnet ist. Um diese Sonderfälle zu behandeln, können Sie die vom Administrator beschreibbare Überprüfung der WDAC-Laufzeit mit der zuvor beschriebenen Option Disabled:Runtime FilePath Rule Protection überschreiben.

Die Liste der bekannten Administrator-SIDs von WDAC sind:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Wenn Dateipfadregeln mit New-CIPolicy generiert werden, wird für jede Datei, die in den gescannten Pfaden ermittelt wird, eine eindeutige, vollqualifizierte Pfadregel generiert. Um Regeln zu erstellen, die stattdessen alle Dateien unter einem angegebenen Ordnerpfad zulassen, verwenden Sie New-CIPolicyRule zum Definieren von Regeln, die Platzhalter enthalten, unter Verwendung des Switches -FilePathRules.

Verwenden von Wildcards in WDAC-Dateipfadregeln

Die folgenden Wildcards können in WDAC-Dateipfadregeln verwendet werden:

Platzhalterzeichen Bedeutung Unterstützte Betriebssysteme
* Entspricht null oder mehr Zeichen. Windows 11, Windows 10 und Windows Server 2022
? Entspricht einem einzelnen Zeichen. Nur Windows 11

Sie können auch die folgenden Makros verwenden, wenn die genaue Anzahl variieren kann: %OSDRIVE%, %WINDIR%, %SYSTEM32%. Diese Makros können in Kombination mit den oben genannten Wildcards verwendet werden.

Hinweis

Auf Windows 11 können Sie einen oder mehrere Wildcards überall innerhalb einer Dateipfadregel verwenden.

In allen anderen Windows- und Windows Server-Versionen ist nur ein Einziger -Wildcard pro Pfadregel zulässig und muss sich am Anfang oder Ende einer Pfadregel befinden.

Beispiel für Dateipfadregeln mit Wildcards

Beispiele Beschreibung Unterstützte Betriebssysteme
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Platzhalter, die am Ende eines Pfads platziert werden, autorisieren alle Dateien im unmittelbaren Pfad und die zugehörigen Unterverzeichnisse rekursiv. Windows 11, Windows 10 und Windows Server 2022
*\bar.exe Platzhalter, die am Anfang eines Pfads platziert werden, lassen den genau angegebenen Dateinamen an einem beliebigen Speicherort zu. Windows 11, Windows 10 und Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 In der Mitte eines Pfads verwendete Wildcards lassen alle Dateien zu, die diesem Muster entsprechen. Berücksichtigen Sie sorgfältig alle möglichen Übereinstimmungen, insbesondere wenn Ihre Richtlinie die überprüfung vom Administrator beschreibbar mit der Option Disabled:Runtime FilePath Rule Protection deaktiviert. In diesem Beispiel würden beide hypothetischen Pfade übereinstimmen:
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 Nur Windows 11

Ohne einen Wildcard lässt die Dateipfadregel nur eine bestimmte Datei zu (z. B. C:\foo\bar.exe).

Hinweis

Beim Erstellen von WDAC-Richtlinien mit Configuration Manager gibt es eine Option zum Erstellen von Regeln für angegebene Dateien und Ordner. Diese Regeln sind keine WDAC-Dateipfadregeln. Stattdessen führt Configuration Manager eine einmalige Überprüfung der angegebenen Dateien und Ordner durch und erstellt Regeln für alle Binärdateien, die zum Zeitpunkt der Überprüfung an diesen Speicherorten gefunden wurden. Dateiänderungen an den angegebenen Dateien und Ordnern nach dieser Überprüfung sind nur zulässig, wenn die Configuration Manager Richtlinie erneut angewendet wird.

Weitere Informationen zu Hashes

WDAC verwendet den Authenticode/PE-Bildhashalgorithmus beim Berechnen des Hash einer Datei. Im Gegensatz zum häufiger bekannten Flatfile-Hash werden bei der Authenticode-Hashberechnung die Prüfsumme der Datei, die Zertifikattabelle und die Attributzertifikattabelle weggelassen. Daher ändert sich der Authenticode-Hash einer Datei nicht, wenn die Signaturen und Zeitstempel der Datei geändert werden oder wenn eine digitale Signatur aus der Datei entfernt wird. Mit der Hilfe des Authenticode-Hash bietet WDAC zusätzliche Sicherheit und weniger Verwaltungsaufwand, sodass Kunden die Hashregeln für Richtlinien nicht überarbeiten müssen, wenn die digitale Signatur in der Datei aktualisiert wird.

Der Authenticode/PE-Imagehash kann für digital signierte und nicht signierte Dateien berechnet werden.

Warum erstellt die Überprüfung vier Hash-Regeln pro XML-Datei?

Das PowerShell-Cmdlet erzeugt einen Authenticode Sha1-Hash, einen Sha256-Hash, einen Sha1-Seitenhash, einen Sha256-Seitenhash. Während der Überprüfung wählt WDAC aus, welche Hashes basierend auf der Signatur der Datei und dem Szenario, in dem die Datei verwendet wird, berechnet werden. Wenn die Datei beispielsweise seitenhashsigniert ist, überprüft WDAC jede Seite der Datei und vermeidet das Laden der gesamten Datei im Arbeitsspeicher, um den vollständigen sha256 authenticode-Hash zu berechnen.

Anstatt vorherzusagen, welcher Hash verwendet wird, berechnen und verwenden wir in den Cmdlets die vier Hashes (sha1/sha2 authenticode und sha1/sha2 der ersten Seite). Diese Methode ist auch resilient gegenüber Änderungen an der Art und Weise, wie die Datei signiert wird, da Ihre WDAC-Richtlinie bereits mehr als einen Hash für die Datei zur Verfügung hat.

Warum erstellt die Überprüfung acht Hashregeln für bestimmte Dateien?

Für UMCI und KMCI werden separate Regeln erstellt. Wenn die Cmdlets nicht feststellen können, dass eine Datei nur im Benutzermodus oder im Kernel ausgeführt wird, werden Aus vorsichtshalber Regeln für beide Signierungsszenarien erstellt. Wenn Sie wissen, dass eine bestimmte Datei nur im Benutzermodus oder Kernel geladen wird, können Sie die zusätzlichen Regeln sicher entfernen.

Wann verwendet WDAC den Flatfile-Hashwert?

Es gibt einige seltene Fälle, in denen das Format einer Datei nicht der Authenticode-Spezifikation entspricht, sodass WDAC auf die Verwendung des Flatfile-Hash zurück greift. Dieses Verhalten kann aus vielen Gründen auftreten, z. B. wenn zur Laufzeit Änderungen an der In-Memory-Version der Datei vorgenommen werden. In solchen Fällen sehen Sie, dass der im korrelierten 3089-Signaturinformationsereignis angezeigte Hash mit dem Flatfile-Hash aus dem Blockereignis 3076/3077 übereinstimmt. Um Regeln für Dateien mit einem ungültigen Format zu erstellen, können Sie hashregeln zur Richtlinie für den Flatfile-Hash hinzufügen, indem Sie den WDAC-Assistenten verwenden oder die Richtlinien-XML direkt bearbeiten.