Richtlinien für Applocker vs Software-Einschränkungen

Ziel ist es, zu verhindern, dass Benutzer unerwünschte Programme auf einem Terminalserver ausführen.

Ich habe viele Artikel von Microsoft und anderen gelesen, in denen es heißt, dass die neue Applocker-Funktion 100% besser ist als die alte Richtlinie für Softwareeinschränkungen und als Ersatz für letztere empfohlen wird.

Ich bin mir nicht sicher, welche wirklichen Vorteile Applocker neben der Ausführung im Kernelmodus bietet. Die meisten Funktionen können mit der Software Restriction Policy reproduziert werden.

Gleichzeitig hat es einen großen Nachteil, der es ziemlich nutzlos macht: Es ist nicht erweiterbar und Sie können keine benutzerdefinierten Dateierweiterungen hinzufügen, die Sie einschränken möchten.

Was sind die Vorteile von Applocker gegenüber SRP und was würden Sie für die Softwaresteuerung empfehlen?

Die Softwareeinschränkungsrichtlinie wird von Microsoft abgelehnt ( Technet behauptet effektiv, dass SRP nicht unterstützt wird ), da Windows 7 Enterprise / Ultimate AppLocker eingeführt hat.

In der Praxis weist SRP bestimmte Fallstricke auf, sowohl für falsch negative als auch für falsch positive. AppLocker hat den Vorteil, dass es weiterhin aktiv gewartet und unterstützt wird. Wenn AppLocker eine Option ist, könnte es die billigere sein - nach Berücksichtigung Ihrer Zeit und der eingegangenen Risiken. Es ist auch möglich, dass es eine geeignete Alternative von Drittanbietern gibt (diese Frage enthielt diese Option jedoch nicht :).

Hoffentlich erhalten Sie ein perfektes Verständnis für die Fallstricke von SRP, bevor Sie in eine dieser Fallstricke geraten </sarcasm>. Einige von ihnen sind in einem schönen Sicherheitsartikel von Vadims Podāns beschrieben .

Bekannte Fallstricke

1. Standardmäßig ist die Ausführung aus dem \WindowsOrdner zulässig. Einige Unterordner können von Benutzern beschrieben werden. Applocker ist derselbe, aber zumindest in der offiziellen Dokumentation wird diese Einschränkung erwähnt .

   BEARBEITEN: "Um alle Ordner mit Schreibzugriff auf Benutzer aufzulisten , können Sie beispielsweise das Dienstprogramm AccessEnum aus dem Sysinternals-Paket verwenden." (oder AccessChk ).

   Technisch gesehen warnt Sie die Dokumentation auch davor, die Standardregeln zu überschreiben . BEARBEITEN: Ein NSA-Dokument enthält 16 Beispiele für Ordner, die mit SRP auf die Blacklist gesetzt werden sollen , obwohl die Registrierungspfadregeln Backslashes falsch verwenden. Sie müssen daher korrigiert werden (siehe Punkt auf den Registrierungspfaden unten) und warnen vor einem häufigen Eintrag einer zu breiten Blacklist.

   Die offensichtliche Frage ist, warum wir nicht \Windowsstattdessen einzelne Pfade sorgfältig auf die Whitelist setzen . (Einschließlich des \Windows\*.exeErbes System32\*.exeusw.). Ich habe nirgendwo Antworten darauf bemerkt :(.

2. Mit Umgebungsvariablen wie %systemroot%kann SRP von Benutzern umgangen werden, indem die Umgebungsvariable gelöscht wird. BEARBEITEN: Diese werden in den vorgeschlagenen Standardeinstellungen nicht verwendet. Sie können jedoch verlockend zu verwenden sein. Diese Fußwaffe ist in AppLocker behoben, da Umgebungsvariablen niemals berücksichtigt werden.

3. Die vorgeschlagenen Standardeinstellungen vernachlässigen es, die beiden \Program Filesbei modernen 64-Bit-Installationen verwendeten Unterschiede zu berücksichtigen. Wenn dies mithilfe der sichereren "Registrierungspfade" behoben wird, gibt es Berichte über falsche Ablehnungen in zufälligen Situationen, die beim Testen leicht übersehen werden können. Siehe z. B. Kommentare zum SpiceWorks SRP-Howto . BEARBEITEN: Dies hat mit 32-Bit-Anwendungen zu tun, die relevante Pfade aus dem WOW6432-Knoten der Registrierung lesen: Die Auflösung besteht darin, beide Pfade zu SRP hinzuzufügen , damit alle Programme auf 32-Bit- und 64-Bit-Computern als uneingeschränkt arbeiten können, unabhängig davon, ob sie gestartet wurden ein x64- oder x86-Hostprozess:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Die Standarderweiterungen verbieten es, von Windows unterstützte PowerShell-Skripts (* .PS1) zu verbieten . (Siehe Video ). Und APPX auch ... auch laut der Vergleichstabelle von Microsoft kann SRP "Gepackte Apps" in Windows 8 nicht verwalten. Ich habe keine Ahnung, was dies bedeutet.
5. Registrierungspfad Regeln müssen keine Schrägstriche haben unmittelbar nach dem letzten Prozentzeichen (trotz in Microsoft enthalten sind eigene eingebaute Regeln für XP / Server 2003) und alle Schrägstriche müssen für die Regel an die Arbeit (mit forwardslashes ersetzt werden , um 1 / 2 / 3 ).
6. Von den Quellen, die ich für SRP gefunden habe, hat keine die vollständige Liste oben für Sie zusammengestellt. Und ich habe den Artikel von Vadims Podāns nur zufällig entdeckt. Was lauert sonst noch da draußen?
7. Viele Quellen empfehlen, LNK-Dateien einfach aus der Liste zu entfernen. (Und Web-Verknüpfungen, um das Brechen von Favoriten zu vermeiden?!). Beunruhigenderweise scheinen keine Quellen LNK-Schwachstellen zu diskutieren ... oder Skriptinterpreter dazu zu bringen, Dateien mit einer unerwarteten Erweiterung auszuführen, z. B.wscript /e ... oder vielleicht genug Shellcode in einen Inline-Skriptparameter zu stecken ... usw.
8. Wenn Sie versuchen, Kompromisse einzugehen, indem Sie LNK-Dateien auf dem Desktop zulassen und Benutzern Schreibzugriff auf den Desktop gewähren, können sie Ihre Richtlinie jetzt vollständig umgehen. Wieder ein schöner Tipp von Vadims Podāns. Beachten Sie, dass die Erklärung für die Verwendung einer beliebigen Erweiterung in einer Pfadregel gilt. Microsoft präsentiert mehrere Beispiele hierfür, einschließlich *.Extensionohne Warnung. So können Sie die offizielle Dokumentation nicht trauen , und es scheint unwahrscheinlich , dass jetzt bekommen fixiert.
9. [Möglicher AppLocker-Nachteil]. Vadims Podāns berichtet, dass SRP-Einträge mit zugeordneten Laufwerken nicht funktionieren. Stattdessen muss der UNC-Pfad verwendet werden. Vielleicht würden sie dann den Zugriff über ein zugeordnetes Laufwerk beantragen? es ist nicht 100% klar. Anscheinend war AppLocker anders: Es funktionierte auch nicht mit :(. "Aus unbekannten Gründen funktionieren UNC-Pfade in Applocker nicht! Dies bedeutet, dass Sie, wenn Ihre Anwendung im Netzwerk installiert ist, entweder Hash- oder Publisher-Regeln erstellen müssen . "

Pragmatischer Ansatz

Software-Whitelisting ist möglicherweise eine sehr mächtige Verteidigung. Wenn wir zynisch werden: Genau aus diesem Grund lehnt Microsoft die günstigeren Versionen ab und erfindet komplexere.

Möglicherweise ist keine andere Option verfügbar (einschließlich Lösungen von Drittanbietern). Dann wäre es ein pragmatischer Ansatz, SRP so einfach wie möglich zu konfigurieren. Behandle es als zusätzliche Verteidigungsschicht mit bekannten Löchern. Passend zu den oben genannten Fallstricken:

1. Beginnen Sie mit den Standardregeln (aus der Zeit vor Win7 :).
2. Verwenden Sie lieber keine Umgebungsvariablen, z %systemroot%.
3. Fügen Sie Regeln hinzu, um sicherzustellen, dass beide \Program Files\Verzeichnisse auf modernen 64-Bit-Computern zulässig sind. Die zusätzlichen "Registrierungspfade", die Sie \Program Files\auf 64-Bit-Computern hinzufügen müssen, sind %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%und %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Wenn auf Registry - Pfad Regeln hinzufügen, lassen Sie jeden Backslash unmittelbar nach dem Prozentzeichen und ersetzen Sie alle weiteren Schrägstriche \mit forwardslashes /(zB %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Fügen Sie PS1 zur Liste der kontrollierten Erweiterungen hinzu.
6. Verstehen Sie, dass eine verwaltbare SRP-Konfiguration nicht sicher gegen einen Benutzer ist, der entschlossen ist, sie zu besiegen. Ziel ist es, Benutzer bei der Arbeit innerhalb der Richtlinie zu unterstützen, um sie vor Angriffen wie "Drive-by-Downloads" zu schützen.
7. LNK-Dateien zulassen. (Am besten durch Entfernen aus der Erweiterungsliste, nicht über eine Pfadregel).
8. Siehe oben :).
9. Stellen Sie sicher, dass Ihr Anmeldeskriptordner zulässig ist. Das NSA-Dokument schlägt das Hinzufügen vor \\%USERDNSDOMAIN%\Sysvol\. (Siehe Punkt 2, seufzen, dann Punkt 6).

Ich bin damit einverstanden, dass SRP einige zusätzliche Funktionen bietet, von denen AppLocker wirklich profitieren könnte.

Abgesehen davon sehe ich die großen Vorteile von AppLocker (wie durch diesen Vergleich dokumentiert ) wie folgt :

• AppLocker-Regeln können auf einen bestimmten Benutzer oder eine Gruppe von Benutzern ausgerichtet werden, während SRP auf dem gesamten Computer erzwungen wird.
• AppLocker unterstützt den Überwachungsmodus, sodass Regeln in der Produktion getestet werden können, bevor sie erzwungen werden. SRP verfügt nicht über einen entsprechenden Nur-Protokoll-Modus.

Der größte Vorteil für mich ist die Möglichkeit, signierte ausführbare Dateien vom Herausgeber auf die Whitelist zu setzen. Schauen Sie sich diese http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx an

Es gibt keine Vorteile von AppLocker, Microsoft veröffentlichte offensichtliche Lügen: 1. Gruppenrichtlinienobjekte mit SAFER-Regeln können an Benutzer und Benutzergruppen angehängt werden. 2. Windows Vista führte mehrere lokale Gruppenrichtlinienobjekte ein, die ohne Domänencontroller dasselbe Ergebnis erzielen. 3. Der Überwachungsmodus ist über die erweiterte Protokollierungsfunktion ohne Durchsetzung verfügbar.

Ich benutze Applocker in meiner Firma. Die Strategie, die wir verwenden, lautet: Verweigern Sie alles als Basis (in der Tat: die Applocker-Standardeinstellungen) und tun Sie dann, was vorgeschlagen wurde: Erstellen Sie eine Regel, die nur signierte Anwendungen zulässt (Office, Adobe, Wintools, Axe usw.). Die meisten, möglicherweise alle Malware ist nicht signierte Software, wird also nicht ausgeführt. Es ist kaum Wartung. Ich musste nur 3 zusätzliche Legacy-Apps zulassen.

Außerdem kann ich nicht bestätigen, dass man keine UNC-Pfade verwenden kann. In einigen zusätzlichen Sicherheitsverweigerungsregeln verwende ich erfolgreich UNC-Pfade. Die Gefahr besteht darin, Umgebungsvariablen zu verwenden: Sie funktionieren nicht für Applocker. Verwenden Sie * Platzhalter. Ich benutze es unter Windows 2008 R2 und Windows 2012 R2.

Ich mag es sehr: Es gibt kaum Leistungseinbußen. In der Dokumentation heißt es: Applocker verlässt sich auf den Application Identity Service (stellen Sie sicher, dass er automatisch gestartet wird).