Gruppenrichtlinien kontrollieren das Ausführen von Anwendungen

Die Richtlinie für Softwareeinschränkung (SRP, Software Restriction Policy) stellt für die Administratoren ein wichtiges Werkzeug dar, um zu kontrollieren, welche Applikationen die Benutzer auf Windows-Plattformen ausführen. Es besteht sogar die Möglichkeit, eine Art von Blacklist zu erstellen, um bestimmte Anwendungen zu unterbinden. Im Gegensatz dazu gibt es auch Whitelists, die explizit vorgeben, welche Applikationen erlaubt sind. Speziell für die Blacklists empfiehlt sich der Einsatz von Hash-Regeln. Mit Pfadregeln – einschließlich der Pfadregeln für die Registry – lässt sich eine Vielzahl von Applikationen kontrollieren.

So ziemlich jeder Administrator kann ein Lied davon singen: Die lieben Anwender laden immer wieder Applikationen aus dem Internet und starten sie – selbst wenn sie das eigentlich nicht erlaubt bekommen. Das Ergebnis lautet dann in vielen Fällen: Malware macht sich auf den Systemen breit und gelangt so in das Netzwerk der Unternehmen. Es erweist sich in der Praxis als erstaunlich schwierig, eine komplette Kontrolle über die Applikationen zu erlangen, die Benutzer auf ihren Systemen installieren oder starten – zumindest in der Windows-Welt.
Der erste Schritt, um diese Problemstellung zu lösen, lautet lapidar: Anwender dürfen nur mit den minimal notwendigen Rechten am System arbeiten. Also nicht mit Administrator-Status (und sei es auch nur für ihr lokales System) und auch nicht als Power User. Der zweite Schritt bezieht sich dann auf die Kontrolle, welche Programme die Benutzer auf ihren Systemen ausführen dürfen.

Black- oder Whitelisting

Es gibt einige Lösungen von Drittherstellern, die ein White-oder Blacklisting von Applikationen erlauben. Dabei werden einzelne Anwendungen in der so genannten Whitelist eingetragen oder aber die nicht erlaubten in der Blacklist. Damit wird es den Anwendern erschwert, Code auszuführen, die über unschöne Begleiteffekte – sprich Malware – verfügt.
Doch es besteht auf den Windows-Plattformen auch die Option, diese Funktionalität mit Hilfe der SRP zu realisieren. Wenn auch die SRP einige Aspekte außen vor lassen, die die Lösungen der Dritthersteller offerieren (wie vordefinierte Katalog von Signaturen der Applikationen, um sie zu erlauben oder zu blockieren), so verfügen die SRP über einige nette Features, die in vielen IT-Abteilungen bislang nicht eingesetzt wurden.
Mit dem Release 2 seines Windows Server 2008 und im Zusammenspiel mit Windows 7 kommt noch die Funktion Applocker ins Spiel. Sie ersetzt und erweitert die SRP in gewisser Weise. Dabei steht vor allem die Vereinfachung der Anwendung im Vordergrund. Das erledigt Applocker über vorgegebene Standardregeln: Alle Benutzer dürfen aus dem Default-Programm-Verzeichnis oder/und durch das Windows Betriebssystem signierte Applikationen starten. Administratoren dürfen alle Programme starten. Mehr dazu in einem weiteren Beitrag auf www.nt4admins.de.

So arbeiten die SRP

Die SRP sind in den gängigen Versionen der Client- und Server-Betriebssysteme aus dem Haus Microsoft verfügbar. Dazu zählen Windows Server 2008, Windows Vista, Windows Server 2003 sowie Windows XP. Mit Hilfe des Gruppenrichtlinienobjekt-Editors (GPE, Group Policy Editor) sind sie entweder unter

\Computer Configuration\ Windows Settings\Security Settings (auf einem englischen System) beziehungsweise unter
Computerkonfiguration\ Windows- Einstellungen\Sicherheitseinstellungen und
User Configuration\ Windows  Settings\Security Settings beziehungsweise
Benutzerkonfiguration\Windows- Einstellungen\Sicherheitseinstellungen zu finden.

Generell stehen die SRP sowohl für die lokalen Gruppenrichtlinienobjekte (GPO, Group Policy Objects) als auch für die Domänen-basierten GPOs zur Verfügung. Doch die lokalen GPO sind nur auf Basis eines Computers verfügbar. Die wahre Funktionalität der SRP kommt aber erst dann ins Spiel, wenn man Domänen-basierte GPOs verwendet, die dann für eine Vielzahl von Systemen gelten.
Die SRP erlauben es dem Administrator innerhalb eines GPO die Einschränkungsregeln für Applikationen vorzugeben. Diese Regeln werden danach im Rahmen der Verarbeitung der normalen Gruppenrichtlinien an das Clientsystem verteilt. Windows legt die Regeln in der Registry ab und prüft sie jedes Mal, wenn ein Prozess ausgeführt wird. Tritt eine Übereinstimmung mit einer Regel auf, wird die Anwendung entweder erlaubt oder abgewiesen. Das ist jeweils abhängig davon, ob sie auf der Whitelist oder der Blacklist steht. Die SRP greifen allerdings nicht in bereits laufende Applikationen ein – selbst wenn die Gruppenrichtlinien die Regeln hinzugenommen haben. Das wird sich immer erst bei einem erneuten Start der Applikation dann auswirken.

Aufsetzen der SRP

Der beste Weg, um den Einsatz der SRP zu zeigen, führt über ein typisches Beispiel. Angenommen ein Anwender im Unternehmen arbeitet mit Microsoft Office und einigen Fachbereichsanwendungen. Dabei möchte der Administrator genau kontrollieren, was der Benutzer ausführen darf. Daher empfiehlt sich dabei der Aufbau einer Whitelist mit den SRP.
Als ein sinnvoller Weg empfiehlt sich das Anlegen der SRP-Einstellungen in einem eigenen GPO. Damit hat der Administrator die Möglichkeit, ganz schnell Änderungen an den Einschränkungen auszuführen. Dabei ist zu entscheiden, ob man die Restriktionen pro Benutzer oder pro Computer vorgeben möchte. Die Einschränkungen in Bezug auf Applikationen pro Computer treffen dann auf jedermann zu, der sich an dem betreffenden System – im Active Directory (AD) – anmeldet. Dieser Ansatz erweist sich in den Fällen als zielführend, wenn sie im Zusammenhang mit Terminalservern zum Einsatz kommen. Die Einschränkungen auf der Basis von Benutzern zielen dagegen mehr darauf ab, eine bestimmten Satz von Benutzerobjekten im AD zu fokussieren und die Einschränkungen folgen dabei den Benutzern überall hin – ganz egal wo sie sich an einem System (im AD) anmelden.
Nachdem die Entscheidung gefallen ist, wie die Richtlinien eingesetzt werden sollen – für Benutzer oder auf Basis der Computer – lautet der nächste Schritt: Die Richtlinien sind zu konfigurieren. Dazu eignet sich die Gruppenrichtlinienverwaltungs-Konsole (GPMC, Group Policy Management Console). Zuerst ist eine neue GPO (etwa mit der Bezeichnung SRP_Whitelist_all) mit diesem Tool zu erzeugen. Dann ist auf dieses neu angelegt GPO mit einem rechten Mausklick zu gehen, um die Einstellungen zu editieren/bearbeiten. Damit wird der Gruppenrichtlinien-Editor (GPE, Group Policy Editor) aufgerufen, mit dem sich dann die Einstellungen für diese GPO angeben lassen (siehe Abbildung 2).
Hier muss der Administrator dann zum Knoten Richtlinien für Softwareeinschränkungen unter dem Knoten Computerkonfiguration gehen, um die Vorgaben für das System zu machen oder unter Benutzerkonfiguration, um sie auf den Benutzer zu Recht zu schneiden. Mit einem rechten Mausklick auf den Knoten Richtlinien für Softwareeinschränkungen kommt ein Kontextmenü zum Vorschein, in dem der Punkt „Neue Richtlinien für Softwareeinschränkungen“ aufgeführt ist.
Darauf erscheint in der rechten Bildschirmfläche ein Satz von Ordnern und Richtlinieneinträgen (siehe auch Abbildung 1). Es kann beim Windows Server 2008 auch eine Nachricht kommen, die besagt, dass man einen Neustartausführen muss, ehe die Richtlinien in Kraft treten. Doch das ist missverständlich – denn ein Neustart ist nicht zwingend nötig – weder auf dem Server noch auf den betreffenden Clients. Die Richtlinien werden in der Domäne in regelmäßigen Abständen übernommen – und das ist natürlich auch beim Neustart der Fall, aber eben nicht nur beim Neustart.
Die nächste Entscheidung ist dann nötig, denn man muss angeben, ob eine Whitelist oder eine Blacklist zu erstellen ist. Hier im Beispiel soll eine Whitelist Verwendung finden. Der Vorteil dieses Ansatzes: Es wird eine sichere Umgebung geschaffen, denn nur die erlaubten Applikationen dürfen starten. Dagegen bedeutet diese Whitelist auch mehr Verwaltungsaufwand – etwa wenn immer wieder neue Applikationen erlaubt sein müssen. Das kann sich in einigen Umgebungen recht häufig ändern.
Mit einem Doppelklick auf das Verzeichnis Sicherheitsstufen im rechten Darstellungsbereich im GPE erscheinen die Inhalte dieses Ordners: Bei Windows Server 2003 und Windows XP sind das die Punkte „Nicht erlaubt“ (disallowed) und „Nicht eingeschränkt“ (Unrestricted). Bei Windows Server 2008 und Windows Vista kommt jeweils noch ein Punkt dazu: Er lautet „Standardbenutzer“ (Basic User).
Der Punkt „Nicht eingeschränkt“ liefert die Blacklist und wird als Standardeintrag verwendet (das verdeutlicht der kleine haken im Icon). Um den Whitelist-Modus zu starten, ist ein Doppelklick auf „Nicht erlaubt“ nötig (siehe Abbildung 3). Hier ist der Schalter „Als Standard“ anzuklicken. Danach muss man die Warnung des Systems nochmals abhaken und dann kann der Administrator die Dialogbox schließen und mit der Konfiguration weitermachen.
Die Version des Standardbenutzers bei Vista und Windows Server 2008 bringt eine Besonderheit ins Spiel. In diesem Modus werden bei Benutzern, die über Administratorrechte auf ihren Arbeitsplatzsystemen oder innerhalb der AD-Domäne verfügen, die administrativen Token von allen Applikationen, die auf ihrem System laufen, entfernt.
Damit wird verhindert, dass sie irgendwelche Applikationen mit Administratorrechten ausführen. Dazu modifizieren die SRP den Prozess-Token einer jeden Applikation, die von den Benutzern aufgerufen wird und fügt die Berechtigung „Deny“ (Abweisen) für die folgenden Sicherheitsgruppen hinzu:

• Administratoren,
• Zertifikats-Administratoren,
• Schema-Administratoren,
• Enterprise-Administratoren und
• Domänen-Administratoren.

Diese Funktionalität ist für sensible Computer (etwa mit bestimmten Kundendaten) sinnvoll, an denen sich Administratoren ab und zu einmal anmelden müssen. Damit lässt sich vermeiden, dass Benutzer Applikationen mit den höheren Zugriffsrechten eines Administrators starten.

Einstellen der Optionen für SRP

Im folgenden Schritt steht das Einstellen der allgemeinen Optionen auf dem Plan. Wenn er Administrator wieder auf die oberste Ordnerebene in der Richtlinie zurück geht, sind drei Einträge zu sehen:

Erzwingen,Designierte Dateitypen undVertrauenswürdigen Herausgebern.

Mit einem Doppelklick auf den Knoten Erzwingen, wird der zugehörige Dialog geöffnet (siehe Abbildung 4). Hier kann der Administrator angeben, wie die SRP die entsprechenden Regeln erzwingen.
Die erste Option bezieht sich auf die Frage, ob die SRP die Regeln gegen die Applikationen oder gegen die Applikationen plus die zugehörigen DLLs anwendet. Die Standardeinstellung bezieht sich auf die aufrufende Applikation und nicht auf die zugehörigen DLLs. Der Grund ist in der Systemperformance zu suchen. Wer aber befürchtet, dass sich Angriffe auch gegen die DLLs richten, der kann hier die strengere Variante (Alle Softwaredateien) wählen.
Der zweite Bereich in diesem Dialog legt fest, ob sich die definierte SRP in diesem GPO auf alle Benutzer (der Standardeintrag) auswirken soll oder auf alle Benutzer mit Ausnahme der lokalen Administratoren. Die Standardvorgabe schließt die lokalen Administratoren (das ist in Form einer Gruppe abgebildet) aus. Dies sollte so beibehalten werden, es sei denn man möchte für die lokalen Admins eine besondere Behandlung haben.
Ein anderer Dialog bezieht sich auf die designierten Dateitypen (siehe Abbildung 5). Hier kann der Administrator angeben, welche ausführbaren Dateitypen dazu gehören sollen. Dazu listet das System alle Dateierweiterungen wie .exe, .bat, .msi und so weiter auf. Hier lassen sich andere Dateierweiterungen eintragen oder bestehende aus der Liste entfernen. Wenn aber bereits gesetzt ist, dass man auf einem System Excel nicht ausführen darf, dann braucht der Administrator hier den Dateityp .xls nicht mehr angeben.
Die dritte Option im SRP-Knoten bezieht sich auf die Vertrauenswürdigen Herausgeber. Mit diesem Punkt lassen sich Activex-Controls einbeziehen. Es ist hiermit möglich, anzugeben, ob Benutzer den Herausgeber eines Activex-Controls als Vertrauenswürdig einstufen dürfen. Wenn das ein normaler Benutzer machen darf, besitzt man im Endeffekt keinerlei Kontrolle darüber, welche Herausgeber zu den vertrauenswürdigen zählen.

Regeltypen für die Kontrolle der Applikationsausführung

Im nächsten Schritt geht es in die Innereien der SRP, sprich um die Regeln, die die eigentliche Ausführung der Applikation kontrollieren. Dazu verwendet die SRP vier Regeltypen:

• Hash-Regeln,
• Pfadregeln,
• Zertifikatregeln und
• Internetzonenregeln.

In 99 Prozent aller Fälle wird man mi den Hash- oder Pfadregeln auskommen. Die Zertifikatregeln kommen zum Einsatz, wenn man die Ausführung des Codes von der Signatur eines bestimmten Herausgebers abhängig macht. Leider signieren viele Applikationen den Code nicht, daher hilft dieser Ansatz oftmals nicht weiter.
Die Internetzonenregeln setzen bei den Windows-Installer-Dateien an. Dabei kann der Administrator vorgeben, aus welchen Internetzonen ein Benutzer .msi-Dateien ausführen darf. Da die meiste Malware nicht in Form einer Windows-Installer-Datei kommt, hilft dieses Feature nicht besonders. Doch wer aus welchen Gründen auch immer das Installieren von .msi-Dateien unterbinden will, der wird auf diese Regel schwören.

Die Hashregel

Indem hier angedachten Whitelisting-Szenario werden alle ausführbaren Dateien gehindert zu starten, solange nicht Ausnahmen definiert sind. Es gibt verschiedene Wege, um die erlaubten ausführbaren Dateien anzugeben.
Eine Hashregel identifiziert eine Applikation mit Hilfe eines einzigartigen Hashwerts, der von den SRP erzeugt wird. Microsoft hat ursprünglich den Algorithmus MD-5 dazu verwendet, doch ab Windows Vista kommt der neuere Algorithmus SHA-256 ins Spiel. Wenn der Administrator bei Windows Vista oder Windows Server 2008 einen Hashwert erzeugt, legt das System beide Versionen des Hashwerts ab – aus Gründen der Rückwärtskompatibilität.
Die Hashregeln sind besonders in Blacklist-Ansätzen nützlich. Angenommen man möchte, dass ein bestimmter Benutzer auf seinem XP-System nicht mehr Solitär (sol.exe) spielen darf. Dann braucht der Administrator nur eine neue Hashregel im GPE anlegen. Dazu muss er den Knoten Zusätzliche Regel anklicken. Dann ist im rechten Darstellungsbereich ein rechter Mausklick auszuführen und aus dem Kontextmenü der Punkt „Neue Hashregel“ auszuwählen.
Dabei erscheint ein Dialog, wie ihn Abbildung 6 zeigt. Hier kann der Admin mit einem Klick auf Durchsuchen zu C:\Windows\System32\sol.exe gehen und dann auf OK klicken. Daraufhin erzeugt das System den Hashwert. Dann ist noch die Sicherheitsstufe anzugeben (Nicht erlaubt)und schon kann der Benutzer diese Applikation nicht mehr laufen lassen.
Selbst wenn ein Benutzer sol.exe an einen anderen Ort verschiebt oder die ausführbare Datei umbenennt: Die Hashregel stellt sicher, dass die Einschränkung bestehen bleibt. Der Nachteil der Hashregel: Wenn eine Applikation häufig geändert (zum Beispiel gepatched) wird, muss die Hashregel erneuert werden.

Die Pfadregeln

Der mächtigste und nützlichste SRP-Regeltypus ist die Pfadregel. Wie es der Name schon vermuten lässt, lässt sich dabei ein Pfad vorgeben, der erlaubt oder verweigert (oder auf Standardbenutzer gesetzt werden) kann. Damit kommen alle Applikationen in diesem Pfad unter die Kontrolle der SRP. Das Erzeugen der Pfadregel erfolgt über einen rechten Mausklick in den rechten Darstellungsbereich unter den „Zusätzlichen Regeln“. Dann muss man aus dem Kontextmenü den Punkt Neue Pfadregel selektieren. Darauf erscheint der Dialog, wie er in Abbildung 7 gezeigt ist.
Das Besondere an diesen Pfadregeln ist, dass sie in vielen Ausprägungen auftreten können. Eine Pfadregel könnte so einfach aussehen wie:
Sol.exe oder Sol.* oder s*.*
Mit allen drei Formen würden die Benutzer nicht mehr Solitär starten können – allerdings wären bei der letztgenannten Version auch alle anderen Programme verboten, die mit einem „s“ beginnen.
Es besteht aber auch die Möglichkeit, dass eine Pfadregel den aktuellen Pfad enthalten kann – wie etwa C:\Program Files\Microsoft Office. Damit würde man alle Applikationen, die Im Microsoft-Office-Verzeichnis (einschließlich aller untergeordneten Verzeichnisse) liegen, in das Muster passen. Aber auch Pfadnamen nach der UNC-Konvention (wie \\MyServer\Apps) passen hier rein.
Die aber vielleicht stärkste Funktionalität kommt bei den Pfadregeln ins Spiel, wenn Registry-Pfade einbezogen werden. In vielen Fällen weiß man gar nicht, wo eine bestimmte Applikation installiert ist. Zum Beispiel würde der Yahoo! Messenger sich unter C:\Program Files\Yahoo\Messenger aufgespielt werden – doch die Benutzer können ganz andere Verzeichnisse vorgeben. Um nun sämtliche Plätze im Dateisystem anzugeben, an denen eine Applikation installiert werden kann, kommen die Registry-Pfade ins Spiel.
Dabei handelt es sich um einen Ort in der Registry, der auf einen Pfad im Dateisystem verweist. Beim bespiel des Messengers von Yahoo wird ein Registry-Wert angelegt (unter HKEY_LOCAL_MACHINE\SOFTWARE\Yahoo\Essentials, der MainDir heißt und der die Pfadangabe enthält, an der der Messenger im Dateisystem liegt. Dies kann man in der Pfadregel angeben (siehe Abbildung 7). Wichtig ist hier die Angabe des Prozentzeichens vor und nach dem eigentlichen Pfadnamen.
Besonders nützlich erweisen sich die Registry-Pfadregeln, wenn man Code von der Ausführung ausschließen möchte, der als A über einen Webbrowser geladen wurde. Angenommen der Administrator möchte unterbinden, dass Anwender im Internet Explorer Applikationen ausführen, ehe sie diese Dateien zuerst lokal gespeichert haben.
Wenn ein Benutzer in der Download-Dialog-Box auf Öffnen klickt, verwendet der IE den Pfad zum temporären Download-Verzeichnis HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths\Directory. Wenn der Administrator eine Registry-Pfadregel auf diesen Ort anlegt, und dann ein Nicht erlaubt vergibt, kann keine Applikationstyp, der über die designierten Dateitypen angegeben ist, von diesem Öffnen-Prompt ausgeführt werden.
Vorgefertigte PfadregelnWer das erste Mal eine SRP in einem GPO erzeugt, der wird sehen, dass Windows automatisch Registry-Pfadregeln unter dem Knoten „Zusätzliche Regeln“ innerhalb des GPE anlegt. Sie beziehen sich auf die Ordner C:\Windows und C:\Program Files (oder auf welche Pfad auch immer, in dem diese Verzeichnisse liegen) und setzen sie auf nicht eingeschränkt. Scheinbar möchte Microsoft so sicherstellen, dass man nicht mit dem ersten Anlegen einer Whitelist sich selbst ins Bein schießt und die Betriebssystem-Komponenten sozusagen ausschließt.

Vorgefertigte Pfadregeln

Wer das erste Mal eine SRP in einem GPO erzeugt, der wird sehen, dass Windows automatisch Registry-Pfadregeln unter dem Knoten „Zusätzliche Regeln“ innerhalb des GPE anlegt. Sie beziehen sich auf die Ordner C:\Windows und C:\Program Files (oder auf welche Pfad auch immer, in dem diese Verzeichnisse liegen) und setzen sie auf nicht eingeschränkt. Scheinbar möchte Microsoft so sicherstellen, dass man nicht mit dem ersten Anlegen einer Whitelist sich selbst ins Bein schießt und die Betriebssystem-Komponenten sozusagen ausschließt.

Bei den SRP handelt es sich um einen mächtigen Mechanismus, um die Ausführung von Applikationen auf Windows-Plattformen zu kontrollieren. Dazu muss der Administrator nicht auf teure Lösungen von Drittherstellern zurückgreifen. Es ist zwar etwas Aufwand nötig, um sich in diese Materie einzuarbeiten, doch wer diese Aufgabe nicht scheut, wird mit einer deutlich sichereren Umgebung belohnt, in der die Anwender mit ihrer Unbekümmertheit weniger Unfug anstellen können.
Darren Mar-Elia/Rainer Huttenloher