SRP - Software Restriction Policies

Verfasser Florian Frommherz
Kleine Anpassungen von Mark Heitbrink

Fast jeder IT-Administrator wird schon mal den Tag verflucht haben, an dem Mitarbeitern der Zugriff auf das Internet gewährt wurde. Oder spätestens den Tag, an dem der USB-Stick erfunden wurde. Wohl mit genau diesen Tagen wird die Vorherrschaft der IT-Administration auf den Rechnern in den Arbeitsplätzen beendet worden sein, denn Benutzer bedienen sich der Möglichkeit, Software vom Internet oder vom USB-Stick von zu Hause auf den Arbeitsplatzrechner zu spielen; dass die mitgebrachte oder im Internet besorgte Software nicht zwingend zur Produktivität der Mitarbeiter beiträgt, leuchtet wird den meisten von uns klar sein.

Wenn man Administrator eines Unternehmens ist, das nach Microsoft Best-Practice arbeiten kann und den Mitarbeitern auf den Arbeitsplatzmaschinen die lokalen Administratorrechte verwehrt, hat man schon viel gewonnen: das Installieren der allermeisten Software aus dem Internet oder das Kopieren von Daten in das Windows-Verzeichnis kann so unterbunden werden. Zumindest lässt sich die Software nicht mehr installieren, die Schreibzugriffe auf das Windowsverzeichnis und Teile des HKEY_LOCAL_MACHINE-Registry-Hives benötigt.

Natürlich kommt nicht immer nur "gute" Software auf die Maschinen der Mitarbeiter, möglicherweise auch Trojaner, Viren und andere Schadsoftware, die "versehentlich" mitgeschleppt und ausgeführt wurde. Als Nicht-Administratoren haben diese Schädlinge nur eine begrenzte Auswirkung für lokale Administratoren könnte das das Ende der Vertrauenswürdigkeit der betroffenen Maschine bedeuten!

Wie sichert man sich nun gegen ungewollte Software auf Arbeitsplatzstationen ab?
Wie lässt sich vorgeben, was "gute" und somit erlaubte, und was "böse", somit unerwünschte Software ist?

Hilfe bieten die Software Restriction Policies/Softwareeinschränkungsrichtlinien.

Auf einer einfachen Basis erklärt, ermöglichen Software Restriction Policies den Administratoren zu bestimmen, welche Software auf Arbeitsplatzstationen ausgeführt werden darf und welche nicht. Beispielsweise kann das Ausführen von VBS-Skriptdateien ganz verboten oder das Ausführen von ausführbaren Programmen (.EXE-Dateien) von bestimmten Dateiservern vom Netzwerk aus beschränkt werden.

Software Restriction Policies funktionieren nach einem bestimmten Regelwerk. Prinzipiell gibt es erstmal zwei Standardregeln, die je nach Philosophie des Administrators angewandt werden können.

Unter
"Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies"
bzw. "User Configuration\Windows Settings\Security Settings\Software Restriction Policies"
lässt sich, nach einem Rechtsklick eine neue Richtlinie erstellen.

Unter Sicherheitsstufen (Security Levels) wählt man das Regelwerk seiner Wahl. "Nicht erlaubt" (Disallowed) verbietet das Ausführen von jeglicher Software, die nicht durch eine weitere Regel als "erlaubt" gekennzeichnet wird, während "Nicht eingeschränkt" (Unrestricted) das Ausführen jeglicher Software erlaubt; die nicht explizit ausgeschlossen wurde.




Welches Standardregelwerk man letztlich wählt, hängt von der Umgebung ab, in der die Arbeitsplatzcomputer stehen. In einem Netzwerk, das hohen Sicherheitsanforderungen entsprechen muss, wird man eher zur "Disallowed" ("nichts ist erlaubt ausser das, was ich explizit durch andere Regeln freischalte") greifen, während man in anderen Umgebungen jegliche Software "unrestricted" laufen lassen wird und nur unerwünschte Programme (wie zum Beispiel Peer-to-Peer-Filesharing Tools oder ähnliches) zu unterbinden.

Wie bereits erwähnt, ist es mit dem Standardregelwerk noch nicht getan. Natürlich möchte man nicht jegliche Software in einem Netzwerk erlauben oder verbieten, man möchte auch Ausnahmen definieren können. Um Ausnahmen beschreiben zu können, bieten die Software Restriction Policies vier erweiterte Regeln an, mit denen Software identifiziert und kategorisiert und das Verhalten auf Arbeitsplatzrechnern gesteuert werden kann. Das System definiert vier Standardregeln vor, die auf jeden Fall, um Windows vor Problemen zu schützen. Wenn man sich diese Regeln ansieht, stellt man fest, dass der Zugriff auf wichtige Systempfade erlaubt bleibt.
Stellt man "aus Versehen" das System auf "Nicht erlaubt" ein, dann sind zumindest die "normalen" Programme (unter C:\Windows und C:\Programme) nicht davon betroffen.




Die für Administratoren möglichen Regeln zu Definition von Ausnahmen sind die folgenden:

Die Hashregel
Mit der Hash-Regel ist es möglich, Software anhand eines Hashes zu identifizieren. Ein Hashwert ist eine mathematische Funktion, mit der die Einsen und Nullen eines Programmes zu einem eindeutigen Wert umgerechnet werden. Als Administrator gibt man die ausführbare Datei des Programmes an und erhält vom Gruppenrichtlinieneditor einen Hashwert. Zusätzlich wird noch angegeben, ob das auf den Hashwert zutreffende Programm ausgeführt werden darf oder nicht. Passt der im GRE erstellte Hashwert eines Programmes auf einem Arbeitsplatzcomputer laufenden Programm überein, wird entsprechend der erstellten Richtlinie gehandelt ("Disallowed" oder "Unrestricted").

Der Hash wird über die Datei selbst, ihre Version und ihr Erstelldatum generiert. Ausserdem wird, durch Doppelpunkte getrennt, nach dem Hashwert die Grösse der Datei in Bytes und die ID des Algorithmus angegeben, mit dem der Hash der Datei erzeugt wurde. Mit diesen Angaben ist eine Datei eindeutig identifizierbar. Was heisst das nun?

Zum einen heisst das, dass ein Benutzer eine Datei beliebig umbenennen und an einen anderen Ort im Dateisystem schieben kann, ohne dass die Regel beeinträchtigt wird. Da der Pfad und der Dateiname nicht berücksichtigt werden, ist ein Verschieben oder Umbenennen zwecklos. Dieses Verfahren heisst aber auch weiterhin, dass eine neuere Version der Applikation (eingespielt durch ein Softwareupdate oder ein neues Release des Programmes) unsere Hashregel unwirksam macht, da sich zum einen die Version, das Erstelldatum und die Dateigrösse geändert hat.
Klassisch ist auch das Problem, dass Hashregeln, die mit Windows Server 2003 erzeugt wurden, auf Windows XP nicht funktionieren. Grund dafür ist, dass eine Applikation auf einem Windows Server 2003-System einen anderen Hash erzeugt, als sie auf dem Windows XP Rechner existiert. Das Gleiche gilt auch für Applikationen auf x86 und x64-Maschinen. Und das, obwohl die Versionen gleich sind. Hierfür muss man den leidigen Umweg gehen und mit der Group Policy Management Console (GPMC) die Hashregel auf einem Zielsystem erstellen, damit die Hashes auch wirklich übereinstimmen. Es ist sowieso ratsam, von den Typen der Gruppenrichtlinien-Zielsysteme immer eine "Adminstation" zu haben, um spezielle Richtlinien dort erstellen zu können und betriebssystemspezifische, neue Features (siehe Windows-Firewall) problemlos administrieren zu können.

Der HASH wird direkt gebildet, sobald eine Datei über "Durchsuchen" ausgewählt wird.


Die Zertifikatregel
Für die Zertifikatregel ist es erforderlich, dass ein Herstellerzertifikat angegeben wird, gegen das beim Ausführen von Programmen geprüft wird. Beispielsweise ist es möglich, alle Applikationen von Microsoft einer bestimmten Regel zu unterziehen, Applikationen von einem anderen Hersteller einer anderen. Es ist auch möglich, seine eigenen Applikationen zu signieren und sich selbst als "Vertrauenswürdigen Hersteller" anzugeben.




Die Zonenregel
Zonenregeln können einschränken, welche Software über Internet Explorer Zonen heruntergeladen werden können. Internet Explorer kategorisiert Webseiten und Netzwerkpfade anhand von Zonen. Mögliche Zonen sind "Internet", "Intranet", "Eingeschränkte Sites", "Vertraute Sites" und "Arbeitsplatz".
Leider ist die Zonenregel nicht wirklich hilfreich bei Einschränkungen für Softwareausführungen, da sie nur auf MSI-Pakete gilt.
Es ist zwar möglich, das Herunterladen von MSI-Paketen vom Internet oder eingeschränkten Sites zu verbieten, es ist aber nicht möglich, das Herunterladen von von .EXE oder anderen Dateien leider nicht.





Die Pfadregel
Die wohl in der Praxis am meisten benutzte Regel für Softwareeinschränkungen. Hier kann man als Administrator Pfade zum Dateisystem angeben, die einer bestimmten Regel unterzogen werden sollen. Auch möglich ist das Verwenden von Jokerzeichen wie dem Stern (*) für beliebig viele oder das Fragezeichen (?) für einzelne Zeichen möglich.

Hier einige valide Pfadbeispiele:

C:\Programme\meineApplikation\*.doc
diese Pfadangabe wird alle DOC-Dateien im angegebenen Ordner treffen.

\\FileServer0??\meinShare\Dateien
dieser Pfad wird alle Dokumente und Dateien auf den Maschinen "Fileserver000" bis "Fileserver099" im Ordner "Dateien" treffen (aber auch "Fileserver0a3" oder "Fileserver08D" wären möglich). Für die Fragezeichen kann jeweils ein beliebiges Zeichen eingesetzt werden.

C:\temp\evil.*
dieser Pfad wird alle Dateien im Ordner "Temp" treffen, die den Namen "evil" tragen. Hierbei sorgt der Stern dafür, dass die Dateiendung egal ist.

Selbst Umgebungsvariablen können für die Pfadregeln verwendet werden:
%WINDIR%\system32\*.vbs
alle Dateien mit der Dateieindung VBS im Ordner "%WINDIR%\system32 werden hier behandelt. %WINDIR% ist in sofern interessant, als dass Windows in verschiedennamigen Ordnern installiert worden sein kann ("Windows", "WINNT", ...). Auch %HOMEDRIVE%, %HOMEPATH% oder %PROGRAMFILES%, sowie %TEMP% funktionieren einwandfrei.




Bei der Verwendung von Pfadregeln sollte auf die Verarbeitung der Pfadregeln geachtet werden. Es könnte doch sein, dass mehrere Pfadregeln auf eine bestimmte ausführbare Datei zutreffen. Welche wird dann angewandt? Es gilt: die am spezifischsten formulierteste Regel gewinnt. Je genauer die Regel also formuliert ist, desto sicherer ist ihre Anwendung. Trifft keine Regel auf einen Pfad zu, wird natürlich unser Standardregelwerk ("Alles erlauben" <-> "Alles verbieten") angewendet.

Die Reihenfolge der Genauigkeit kann hier eingesehen werden:
C:\Ordner\Ordner2\meineDatei.ext
C:\Ordner\Ordner2\*.ext
C:\Ordner\Ordner2\filename.*
*.ext
C:\Ordner\Ordner2\

Abarbeitung
Natürlich ist es möglich, mehrere unterschiedliche Richtlinien für ein spezielles Problem oder einen bestimmten Pfad zu erstellen. Die Abarbeitung der Richtlinien ist wiederum von der Genauigkeit der Richtlinie abhängig:
Hashregeln
Zertifikatregeln
Pfadregeln
Zonenregeln

Sobald eine Regel exakt passt, wird sie angewendet, egal was danach kommt. Sollte also eine Hashregel exakt auf ein Programm passen, wird sie angewendet und die anderen Richtlinien gar nicht mehr beachtet. Trifft keine Hashregel auf die aufgerufene Applikation zu, werden die Zertifikatsregeln durchsucht. Die Reihenfolge wird eingehalten bis zum Schluss, falls keine definierte Regel zutrifft, das Standardregelwerk greift.


Die Anwendung der Softwareeinschränkungsrichtlinien
Die Verarbeitung von Software Restriction Policy-Richtlinien wird über eine eigene Client Side Extension (CSE) abgewickelt, sie können in einem Windows 2000 Active Directory eingesetzt werden, wenn eine XP Maschine zur Konfiguration der Gruppenrichtlinien dient, aber sie werden nur auf Maschinen übernommen, auf denen XP, 2003 oder Vistas, bzw. 2008 installiert ist. Auf einem 2000 Client werden die Einstelllungen ignoriert.

"How Software Restriction Policies Work"
http://technet2.microsoft.com/windowsserver/en/library/d24bc8c8-27cc-47ba-9b02-78d9d801e9371033.mspx?mfr=true

"Using Software Restriction Policies to Protect Against Unauthorized Software"
http://technet.microsoft.com/en-us/library/bb457006.aspx"

Das Verhalten von SRPs nach dem Anwenden sorgt ab und an für Konfusion, da das Verbieten oder Erlauben von Applikationen nicht von Windows selbst sondern von der Shell abhängt.

Wir sitzen an einer Windows XP Maschine. Wir haben einige Möglichkeiten, eine Applikation zu starten. Wenn wir Windows Solitär starten möchten können wir das über Start->Programme->Zubehör->Spiele->Solitär tun. Wir haben auch die Möglichkeit, über Start->Ausführen und "sol.exe" zu starten. In beiden Fällen benutzen wir die Windows Shell (explorer.exe), um das Spiel zu starten. Explorer.exe wird also für sol.exe starten und für uns bereit stellen. In der Windows XP SRP CSE gibt es keine Routine, die die Windows Shell dazu zwingt, sich die neuesten Einschränkungen einzulesen anstelle eines dynamischen einlesens werden die Neuigkeiten der SRP in die Registry geschrieben und die Shell liest sie beim Start aus. Wenn wir also an unserem Windows XP-Rechner eingeloggt sind und über "gpupdate /force" eine neue Richtlinie anwenden, die sol.exe verbietet, wird etwas merkwürdiges passieren:

Obwohl die Richtlinie angewendet worden ist und das Verbot von sol.exe in der Registry steht, sind wir in der Lage, sowohl über Start->Ausführen als auch über Start->Programme->... Solitär zu starten! Das kommt daher, dass die Explorer.exe beim unserem Login geladen wurde und von der SRP zum Verbot von sol.exe nichts mitbekommen hat. Wie soll sie auch, sie prüft ja nur einmal beim Start. Versuchen wir die CMD zu öffnen und von dort aus sol.exe zu starten, werden wir eine Fehlermeldung erhalten. Klar, wir haben die CMD geöffnet und sie hat beim Start in der Registry das Verbot von sol.exe wahrgenommen. Loggen wir uns aus und wieder ein oder starten wir den Rechner neu, wird alles so sein, wie wir es uns erhofft haben: die Explorer.exe hat nun, nach dem Logout/login oder dem Neustart das Verbot von sol.exe mitbekommen und wird Solitär, genau so wie es CMD zuvor tat, verbieten.

Dieses Verhalten ist nur in Windows XP einschliesslich Service Pack 2 gegeben Windows Server 2003 verhält sich anders. Hier wird die Shell darüber informiert, dass es neue Einschränkungen gibt und die Ausführung von Applikationen wird gemäss der Richtlinien, ohne Neustart oder Logoff/Login, ausgeführt.

(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright