[English]Falls jemand aus der Leserschaft Software Restriction Policies oder SAFER zur Einschränkung der ausführbaren Programme verwendet (um z.B. Ransomware zuverlässig zu verhindern), eine kurze Information. Software Restriction Policies und SAFER funktionieren unter Windows 11 22H2 out-of-the-box nicht mehr. Ursache sind Registry-Einträge, die Windows 11 glauben lassen, dass AppLocker aktiv wäre. Das lässt sich aber mit einem kleinen Eingriff in die Registrierung korrigieren. Hier mal ein kleiner Überblick über das Thema samt den Hack, um SAFER weiter nutzen zu können.
Anzeige
Software Restriction Policies (SRP)
Unter Windows gibt es die sogenannten Software Restriction Policies (SRP), mit denen sich sich festlegen lässt, welche Programme unter Windows ausgeführt (Whitelisting) bzw. nicht ausgeführt (Blacklisting) werden dürfen. Administratoren können in Windows über Richtlinien festlegen, welches Software im Betriebssystem ausgeführt werden darf. Die Software Restriction Policies sind bereits seit Windows Server 2003 verfügbar und stehen aktuell (laut dieser Microsoft Seite) noch unter folgenden Server-Varianten zur Verfügung:
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
Zudem werden Software Restriction Policies in Windows-Clients (Windows 7, Windows 8.1, Windows 10, Windows 11 21H1) unterstützt. Allerdings ist es so, dass Microsoft die Software Restriction Policies (SRP) bereits im Juni 2020 abgekündigt hat (siehe meinen Blog-Beitrag Windows 10 Version 2004: Veraltete/entfernte Features). Im Blog-Beitrag Windows 11 22H2 unterstützt keine Software Restriction Policies (SRP) mehr hatte ich darauf hingewiesen, dass die Software Restriction Policies (SRP) nicht mehr unterstützt würden.
SAFER, SRP für den kleinen Mann
Gruppenrichtlinien stehen nur für die Pro- und Enterprise-Versionen von Windows bereit – und seit Microsoft in Windows 10 Pro die Möglichkeiten der Gruppenrichtlinien kastriert hat, ist man im Grunde auf Windows Enterprise-Editionen angewiesen. Man kann diese Software-Restriktionen aber auch durch Registry-Einträge setzen.
Von Stefan Kanthak wurde daher SAFER propagiert, um Anwendern unter Windows (z.B. auch Home) die Systeme gegen Ransomware und andere Schadprogramme zu härten. Über eine .inf-Datei werden schlicht die erforderlichen Software-Einschränkungen in der Registrierung gesetzt. Stefan Kanthak stellt die erforderlichen Informationen samt Installations-INF auf seiner Webseite Stop Malware with Software Restriction Policies alias SAFER bereit. Christoph Schneegans propagierte SAVER mit einer deutschen Beschreibung auf dieser Webseite zur Absicherung gegen Schadprogramme (auch Ransomware). Auf der Webseite von Christop Schneegans heißt es aber inzwischen:
Anzeige
Ab Windows 11 22H2 funktioniert SAFER nicht mehr. Als Alternative bietet sich Windows Defender Application Control (WDAC) an, das in allen Versionen von Windows 10 und 11 funktioniert.
Sieht ja – zusammen mit meinen Ausführungen im Artikel Windows 11 22H2 unterstützt keine Software Restriction Policies (SRP) mehr – wie ein Abschied aus?
Windows 11: SAFER funktioniert noch
Stefan Kanthak hat mich nun per Mail kontaktiert, um mich darauf hinzuweisen, dass die Software Restriction Policies und auch SAFER unter Windows 11 22H2 weiterhin eingesetzt werden können. Er schrieb dazu:
Ursache des von Will Dormann beobachteten Verhaltens ist die übliche Schlamperei in Redmond: Die liefern Windows 11 mit Registry-Einträgen aus, "dank" derer es glaubt, AppLocker wäre aktiv – was (wie dokumentiert) SAFER übersteuert bzw. deaktiviert.
Das angesprochene, von Will Dormann beobachteten Verhalten hatte ich im Beitrag Windows 11 22H2 unterstützt keine Software Restriction Policies (SRP) mehr über nachfolgenden Tweet dokumentiert.
Bereits dort hatte Kanthak diesen Kommentar hinterlassen, in dem er auf die ursächlichen Registrierungseinträge verweist, die den Schlamassel auslösen. Stefan Kanthak führt in seiner Mail einen einfachen Workaround an, den er im Februar 2023 bereits auf seclists.org dokumentiert hat (siehe auch), um dieses Verhalten wieder in geordnete Bahnen zu lenken, und SAFER respektive die Software Restriction Policies wieder unter Windows 11 22H2 verwenden zu können:
Nach Löschen der Registry-Einträge:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000002
"LastWriteTime"=hex(b):01,00,00,00,00,00,00,00funktioniert SAFER wieder wie gewohnt. Kanthak merkt an, dass der Zeitstempel 100ns nach dem 1.1.1601 ist, also grottenfalsch sei, und dass die Regelzahl 2 (bei RuleCount) auch nicht stimmt!
Kanthak hat daher seine Datei NTX_SAFER.INF so angepasst, dass diese Korrekturen automatisch durchgeführt werden. Vielleicht für dein einen oder anderen Blog-Leser, der auch mit den Software Restriction Policies unter Windows 11 22H2 scheiterte, von Interesse.
Ergänzung: Es gibt eine Rückmeldung von Andy Ful im englischen Blog mit folgendem Text.
The Kanthak correction to restore SRP functionality on Windows 11 ver. 22H2, works only when Smart App Control is OFF. If it is in Evaluate or ON mode, then the invalid registry values are automatically restored after restarting Windows.
To restore SRP on all SAC modes, one should not delete registry values but simply set the "RuleCount" value to 0:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000000Windows restart is required.
Regards:
@Andy Ful (developer of Hard_Configurator)
Ähnliche Artikel:
Windows 10 Version 2004: Veraltete/entfernte Features
Windows 11 22H2 unterstützt keine Software Restriction Policies (SRP) mehr
Anzeige
Ganz alleine habe ich das nicht gemacht: Christoph Schneegans hat geholfen und die (diesmal vor Ostern) geplante "Wiederauferstehung" von SRPv1 alias SAFER bestätigt.
SAFER habe auch nicht ich erfunden: das ist der von M$FT seit Windows 2000 für den Unterbau der SRP benutzte Bezeichner.
Es gab schon diverse Threads dazu und dennoch der Hinweis: warum noch SRP, wenn doch seit 22H2 Applocker auch auf Pro funktioniert? Kann es wohl ein Zufall sein, dass Applocker angefangen hat zu funktionieren, wo SRP aufgehört hat? Applocker ist zwar weiterhin offiziell laut Microsoft nicht funktional auf Pro, praktisch funktioniert es aber.
Oder würdest Du, Stefan, SAFER vorziehen?
SELBSTVERSTÄNDLICH ziehe ich SAFER vor!
Wie ich bereits im November schrob betrachte ich AppLocker als viel zu klompizierte(!) und von zu vielen anderen Komponenten abhängige Kopf^WMissgeburt, deren Konfiguration ebenfalls VIEL zu klompiziert(!).ist.
Wenn Dir SAFER nicht mehr gefällt: WDAC existiert, ist einfacher als AppLocker zu konfigurieren und (hoffentlich) zukunftssicher..
Gut, das hast Du deutlich ausgedrückt, aber was nun kompliziert etc. ist, sagst Du nicht, auch nicht wovon es abhängt und was an der Konfiguration nun verglichen mit Safer komplizierter ist. Ich finde in deinem langen https://skanthak.homepage.t-online.de/SAFER.html auch keinen Vergleich, der dieses Fazit begründet.
Hast Du noch den Link zu deinem Novemberschrob?
https://www.borncity.com/blog/2022/11/08/windows-11-22h2-untersttzt-keine-software-restriction-policies-srp-mehr/#comment-143181 ist ein Blogeintrag von November, aber auch dort keine Details zu Nachteilen von Applocker.
Ich bevorzuge generell auch simple Mechanismen, gerade bei Sicherheitskomponenten, deshalb interessiert mich ein begründetes Urteil weiterhin.
Meine SAFER-Seite beschreibt mit voller Absicht SAFER und nicht AppLocker. Ein Vergleich ist daher nicht nötig.
AppLocker: https://www.microsoftpressstore.com/articles/article.aspx?p=2228450&seqNum=11
"AppLocker rules depend upon conditional ACEs and attributes defined by AppID."
Es benotigt einen laufenden AppID-Dienst;
"AppLocker rules are stored in multiple locations within the registry: […] The rules are stored in XML format."
Alleine wegen des XML sollten sie sich in Redmond schämen!
"(%SystemRoot%\System32\AppIdPolicyConverter.exe) […] (%SystemRoot%\System32\AppIdCertStoreCheck.exe) […] kernel-mode driver (%SystemRoot%\System32\drivers\AppId.sys)"
"The implementations of AppID, AppLocker, and SRP are somewhat blurred and violate strict layering, …"
SAFER: https://www.microsoftpressstore.com/articles/article.aspx?p=2228450&seqNum=12
Wenn man SRP/SAFER erstmal verstanden hat, ist der Sprung zu Applocker nicht mehr weit. Man kann das Basis-Regelset, welches man für SRP entwickelt hat, quais 1:1 als Grundlage für Applocker übernehmen. Aber Applocker ist viel granularer steuerbar, weil man Regeln auch User/Gruppenmitgliedschaftsabhängig machen kann (xy darf z.exe ausführen, andere nicht). Man kann auch Ausnahmen definieren wie "c:\windows\system32\xyz.exe" darf ausführen, aber nur wenn sie nicht jenen Hashwert hat. Es unterscheidet auch zwischen normalen ausführbaren Dateien, Installern, Scripten und den "Modern Apps". Und neben Pfadregeln kann man auch mit Hashes und Signaturen arbeiten. Das ist VIEL besser. Aber man bekommt das mit Hacken in der Registry nicht mehr gebacken, man muss hier das Gruppenrichtlinien-Handwerk beherrschen.
Passend dazu ist anscheinend seit mehreren Monaten der Applocker Editions-Check aufgehoben. Damit steht dann einer Nutzung von Applocker unter Windows Pro nichts mehr im Wege.
https://support.microsoft.com/en-us/topic/kb5024351-removal-of-windows-edition-checks-for-applocker-e3a763c9-6a3e-4d9c-8623-0ffe69046470
Yeah :-) bin auch gerade darüber gestolpert, das ist mal eine gute Nachricht.
Applocker-Konfiguration per GPOs geht zwar seit ein paar Monaten für die Windows Pro-Editionen, aber man war sich nie sicher ob das "intended" war.
Jetzt also offiziell :-)
Das ist sehr positiv, denn dann kann ich meine SRP-Regeln "abbauen" und brauche diese Basis-Regeln nicht mehr zu pflegen, denn jeder neu installierte PC bekommt nicht automatisch sofort die Enterprise-Lizenz zugewiesen, das dauert manchmal. Und dann sind die solange mit SRP gelaufen.
Inwiefern soll denn "Microsoft in Windows 10 Pro die Möglichkeiten der Gruppenrichtlinien kastriert" haben, so dass "man im Grunde auf Windows Enterprise-Editionen angewiesen" wäre?
Ich habe ausschließlich Win 10/11 Pro im Einsatz und nutze Gruppenrichtlinien exzessiv.
Ja, ich erinnere mich an einen Fall, dass mal GPOs in Pro entfernt wurden, das war aber minimal.
Die Geschichte mit SRP ist schon uralt.
Schon bei Windows 95 gab es da eine ähnliche Funktionalität, über die man bestimmen konnte, welche Programme erlaubt und nicht erlaubt sind.
Ging damals aber nicht über Gruppenrichtlinien, denn die werden von Windows 95 noch nicht unterstützt, sondern über lokale Richtlinien.
Das zugehörige Programm nannte sich Poledit (Policy Editor).
Wenn ich SRP richtig verstanden habe (zugegeben: ohne tief in die Einzelheiten eingetaucht zu sein), dann kann ein Standardbenutzer lediglich Programm aus den Ordner C:\Program Files und C:\Program Files (x86) starten.
Wir haben hier zwei Anwendungen (Lohn-/Gehaltsabrechnung, Fakturierung), deren Hersteller auf der Installation in Verzeichnissen jeweils direkt auf C:\ bestehen, d.h. nicht in den oben genannten Verzeichnissen. Kann man bei SRP Ausnahmen bzw. zusätzliche Verzeichnisse definieren?
Hallo Carsten
SRP ermöglicht Dir Regeln zu definieren, was und wo ausgeführt werden darf.
Damit Windows funktioniert, muss
– C:\Windows\…
– C:\Program Files\…
– C:\Program Files (x86)\…
freigegeben sein.
Du kannst beliebige zusätzliche Regeln definieren.
Z.B. braucht Windows Defender für das Update eine zusätzliche Regel.
Programme die sich im Profile einnisten wie Chrome, Teams, … brauchen auch zusätzliche Regeln. Nur dann kann der Benutzer alles in diesen Ordnern ausführen.
Zuerst muss Du den Benutzern die Administrativen Berechtigungen wegnehmen. Sonst können Sie die SRP umgehen.
Ich würde die Ordner aufteilen in
– wo darf ein Benutzer Daten bearbeiten und dafür keine Programme ausführen
– wo darf ein Benutzer Programme ausführen und keine Daten bearbeiten.
Nur so hast du unter Kontrolle, dass ein Benutzer nichts ausführt, dass der Administrator nicht in einen freigegeben Order installiert hat.
I.d.R bestehen Programme auf eigene Ordner, weil sie in diesen Ordnern alle Rechte haben und auch Einstellungen speichern können.
Solche Programme kannst Du kaum mit SRP absichern.
HTH
Reto
Danke für die Informationen, Reto!
Bei dem einen Programm ist es tatsächlich so, dass es laufend Dateien in seinem Programm-Ordner und dessen Unterordnern anlegt oder ändert. Diesen Programm-Ordner könnte ich dann wohl nicht mit SRP absichern, wodurch vermutlich SRP auf diesen PCs gar nicht eingesetzt werden kann.
Er kommt immer darauf an, vor was Du dich schützen willst.
Soll der Schutz vor Deinen Anwendern sein kann es genügen das Ausführen auf ein paar Ordner einzuschränken. Möglicherweise kannst du die zusätzlichen Ordner verstecken und 0815 User werden sie nicht finden. Ein versierter User kann immer die Disk ausbauen und in einem anderen System als Administrator beliebige Apps nach C:\Windows\System32 kopieren. Davor schützt z.B. BitLocker oder wie unten aufgeführt HASH Regeln.
Ein Schutz vor Schadsoftware ist SRP in jedem Fall.
Schadsoftware wird i.d.R. ins Profile des Benutzers geladen und wenn dies geblockt wird, kann sie nicht ausgeführt werden.
Ich setzte SRP seit Windows XP ein an (> 100 Client) und hatte noch keine unerwünschte App bemerkt.
Pfadregeln auf User-Profil-Ordner sind böse, denn die Dateien dort können vom User ausgetauscht werden. Besser eine Signatur-Regel mit Applocker bauen, welche Vendor/Product und Minimalversion (die gerade aktuell ausgerollte Version) erlaubt. Oder wenigstens Hash-Wert, wenn die Shcrottapplikation nicht signiert ist, bedeutet aber regelmäßig Arbeit wenn es mal ein Softwareupdate gibt.
Reddox hat da schon seit längerem eine Gui/Programm dazu gebastelt das das ganze etwas komfortabel macht
https://www.reddoxx.com/produkte/anti-ransom/
Hallo Günther,
darf ich dich bitten nicht von white- und blacklisten zu sprechen sondern lieber von Erlaubt- bzw Verbotslisten? habe ich meinen Vorträgen zu Applocker auch geändert und ist sprachlich auch einfach schöner.
Restric'tor der c't nutzt ja auch SRP samt Dateilogging falls gewünscht. Applocker hat halt die Eventlogeinträge in einem eigenständigen Eventlog, finde ich etwas schöner aber ist sicherlich Geschmackssache.
Danke Sascha
Ich kenne den Hintergrund für diesen Wunsch – und habe über bestimmte Sachen – auch das Gendern – im Hinblick auf die Verwendung in den Blogs länger nachgedacht. Am Ende des Tages stand für mich die klare Sprache im Vordergrund.
Ich möchte diese Nomenklatur definitiv beibehalten, denn wir sind in hier in der Technik, und da geht es nicht um Diskriminierung (die liegt mir fern). Aber seit ich denken kann, stehen diese Begriffe fest (ähnlich wie das Master-Slave-Prinzip, welches als Bezeichnung nun auch verpönt sein soll).
Spätestens, wenn die ersten technischen Geräte ausfallen, weil jemand mit der neuen Nomenklatur was verwechselt, macht alles große Augen. Ich kenne es noch aus meiner Zeit als Entwickler – ist lange her. Damals gab es Dokumentation von Siemens in "normiertem Siemens"-Deutsch, sowie Dokumentation von Intel auf Englisch. Ich habe mir das Siemens-Zeugs Stunden durchgelesen und musste immer alles rückübersetzen – irgendwann habe ich die Kollegen gefragt, ob es das auch auf englisch gäbe – worauf die die entsprechende Dokumentation rausgerückt haben und die offenen Fragen waren für mich meist in wenigen Minuten geklärt, weil saubere technisch feststehende Begriffe verwendet wurden.
verstehe ich aber allow und deny sind ja doch eher gebräuchlich als black and white daher finde ich es hier eben doch unpassend
Black/White/Grey-Lists sind fest stehende, unmissverständliche, technische Begriffe.
Restrictor ist leider veraltet, das damit erzeugte Standardregelwerk verhindert die Ausführung wichtiger Windows-Funktionen. Sollte man nicht mehr verwenden.
Ich nutze seit über einem Jahr das hier:
https://github.com/hazelfazel/tuersteher