Auf dieser Seite stehen die Antworten auf einige der häufigsten Fragen zum Einsatz von Software Restriction Policies und den Konfigurationseinstellungen die sich unserer Meinung nach als am besten und sinnvollsten erwiesen haben.
Die Erklärung dazu findet sich in einem früheren Blogartikel von uns!
Die einfachste Möglichkeit ist es, eine ausführbare Datei (z.B. notepad.exe aus dem Windowsverzeichnis) an einen Speicherort zu kopieren, an dem die Ausführung eingeschränkt ist. Beim Versuch diese zu starten muss dann eine Fehlermeldung kommen. Komfortabler geht es (gerade in Domänennetzwerken) mit unserem kleinen Tool SecurityCheck, das Sie gerne per E-Mail zur eigenen Verwendung anfordern können.
Das Programm versucht Dateien aus dem Benutzerprofil des jeweiligen Users und einem weiteren (zufälligen) Speicherort auszuführen und ermittelt so die Grundeinstellung (Whitelisting oder Blacklisting), außerdem prüft es – unabhängig von UAC – auf Administratorrechte. Je nach Ergebnis gibt es dann unterschiedliche Meldungen, die teilweise auch durch den Benutzer explizit quittiert werden müssen. Wir implementieren diese Prüfung zumeist während des Anmeldevorgangs (Logonscript oder ähnlicher Mechanismus).
Generell werden Einschränkungen, die das Ausführen von Programmen verhindern, im Application-Eventlog des Systems angezeigt. Dabei werden folgende Event-IDs gelistet:
Event 865: Die Ausführung ist aufgrund der Standardsicherheitsstufe unterbunden worden
Event 866: Die Ausführung ist aufgrund einer Pfadregel unterbunden worden
Event 865: Die Ausführung ist aufgrund einer Zertifikatregelunterbunden worden
Event 865: Die Ausführung ist aufgrund einer Hashregel unterbunden worden
Reichen diese Hinweise nicht aus ein Problem einzugrenzen und weitere Regeln einzuführen, um ein Programm lauffähig zu machen, lässt sich ein erweitertes Logging aktivieren. Mittels folgendem Befehl kann man eine REG_SZ Eintrag unter
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers
setzen, der in diesem Beispiel ein Logfile unter C:\logs\ mit dem Namen srplog.txt anlegt:
reg.exe add „HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers“ /v LogFileName /d c:\logs\srplog.txt
Auf analoge Weise kann dieser Eintrag auch wieder gelöscht werden:
reg.exe delete „HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers“ /v LogFileName /f
In Domänennetzwerken präferieren wir ganz klar die Verteilung der Richtlinien auf Benutzerebene, dies hat folgende Vorteile:
Es lassen sich Benutzergruppen mit unterschiedlichen Sicherheitsstufen einrichten, so kann etwa ein Benutzer eingerichtet werden, der erweiterte Ausführungsrechte hat, etwa um Softwareupdates einspielen zu können.
Für bestimmte Benutzer (und auch Administratoren) können die Regeln ganz ausgesetzt werden. Etwas Ähnliches lässt sich auch in den Richtlinien direkt erreichen, hier gibt es eine Einstellung, die besagt, ob die Richtlinien generell auch auf Administratoren wirken sollen. Es gibt aber immer Nebeneffekte mit UAC.
Das Ausführen von Software, die generell kurzzeitig andere Rechte benötigt (wie z.B. TeamViewer) wird so relativ einfach ermöglicht, siehe dazu gleich den nächsten Punkt „Warum man trotz SRP auf Administratorrechte verzichten soll“
Neben den Erklärungen aus unserem früheren Blogartikel, hier ein ganz einfaches Beispiel: Nehmen wir an, es gibt folgenden einfache Regeln:
- Das Ausführen von Programmen im Userverzeichnis ist verboten (C:\Users nicht für Ausführung erlaubt)
- für einen Admin-Benutzer gibt es eine Ausnahme (C:\Users\Admin ist für Ausführung erlaubt)
- Für Administratoren sind die Regeln generell außer Kraft gesetzt
Aufgrund der höheren Spezifität hat die Regel (2) gegenüber der Grundregel (1) Vorrang. Nehmen wir nun eine Anwendung wie TeamViewer, der Benutzer lädt sie herunter, sie wir irgendwo im Userprofil (z.B. im Download Ordner) gespeichert. Ein Ausführen ist Aufgrund von Regel (1) nicht möglich. Bei Aktivierter UAC und eigenen Administratorrechten könnte der Benutzer das jedoch im eigenen Kontext als Administrator ausführen. Teamviewer entpackt sich daraufhin in sein Userprofil in einen temporären Ordner und versucht sich dort mit Userrechten zu starten, das scheitert aufgrund der Regel (1) jedoch erneut. Der Benutzer war nur während des Entpackens der Datei mit erhöhten Rechten ausgestattet.
Abhilfe schafft hier „Ausführen als“ oder eben einfacher keine Adminrechte für den User. In beiden Fällen gibt er zum Ausführen das Konto „Admin“ ein. Das Entpacken gelingt aufgrund (3) auch aus dem Userprofil, TeamViewer entpack sich in einen Temporären Ordner im Profil des Benutzers „Admin“ und kann dort aufgrund von Regel (2) problemlos ausgeführt werden.
Ja das geht, allerdings bringt Windows in seinen Homeversionen keine einfachen Verwaltungstools mit, daher muss ein Regelwerk auf andere Weise gepflegt werden. Einen inhaltlich recht guten Betrag dazu gibt es hier! Wir haben das ganze unter Windows 10 Home (64bit) getestet, es geht in der Tat problemlos. Die Regeln hier funktionieren jedoch nur auf Computerebene und nicht auf Benutzerebene.
Applocker ist eine „modernere Variante“ mit Vorteilen, so können Regeln anfänglich nur getestet werden und Administratoren haben es leichter Regeln ohne große Störungen des Betriebes einzuführen. Es gibt aber auch Nachteile, die aktuell aus unserer Sicht überwiegen:
Applocker ist in Wondows 7 Pro noch nicht enthalten, gerade im Firmenumfeld ist dieses Betriebssystem jedoch noch weit verbreitet.
SRPs funktionieren auch in aktuellen Systemen (Windows 10) problemlos, es gibt also keine Notwendigkeit zu wechseln, mit SRPs erreicht man aktuell jedes im Umlauf befindliche System (theoretisch auch Windows XP).
Einzelplatzsysteme und auch Homeditionen lassen sich mit SRPs im Gegensatz zu Applocker auch absichern.
Ein Vergleich von AppLocker und Software Restrictino Policies findet sich im Microsoft Technet. Allerdings ist unseren Tests nach die Tabelle dort nicht ganz korrekt, entgegen der dortigen Angaben:
Microsoft erklärt in der Tabelle bei Scope „SRP rules apply to all users on a particular computer“ Das ist nicht richtig, der Scope kann auch Benutzerrichtlinien sein, und somit auf individuelle Gruppen wirken!
Ebenso steht dort „SRP does not support rule exceptions“ Das ist nur die halbe Wahrheit! Bei mehreren Regel, die zutreffen gewinnt diejenige , die spezifischer ist. So kann ein Verzeichnis verboten sein, ein Unterverzeichnis oder bestimmte Dateien darin aber erlaubt werden. Auf diese Weise lassen sich fast alle denkbaren „Exceptions“ nachbilden.
In manchen Blogs und Webseiten taucht die Bezeichnung SAFER auf, der Registry-Zweig, in dem die SRP Regeln verwaltet werden hat auch die Bezeichnung SAFER im Pfad:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers
SAFER ist keine offizielle Bezeichnung für den SRP Mechanismus, bezeichnet aber letztendlich das gleiche.
