Applocker verbessert und kontrolliert Zugriffsschutz

Sicherheit wird bei Microsoft in der Zwischenzeit sehr groß geschrieben, so konnten dann auch bereits Windows Vista und der Windows Server 2003 mit dem Bitlocker ein neues Sicherheitsfeature aufweisen. Mit Windows 7 und dem Server in der 2008-R2-Version kam eine weitere Möglichkeit für der Administrator hinzu, das System zu sichern: der Applocker.

 Der Windows Server 2008 und Windows Vista wurden bereits standardmäßig mit einer integrierten Sicherheitslösung ausgeliefert, mit deren Hilfe Festplatten transparent sowohl für die Benutzer als auch für die Anwender verschlüsselt werden konnten: Diese Software trägt den Namen Bitlocker und wurde mit dem Erscheinen von Windows 7 deutlich erweitert. Einen entsprechenden Artikel mit dem Titel „Windows 7 erweitert Bitlocker-Funktionalität“ steht hier auf Nt4admins bereit.

Mit dem Erscheinen der R2-Version des Servers und der Verfügbarkeit von Windows 7 haben die Microsoft-Ingenieure dann aber noch ein weiteres Sicherheitsfeature in die Betriebssysteme integriert, das nun den Namen Applocker trägt. Mit Hilfe dieser Software wird es für den Systemverwalter möglich, durch den Einsatz von Regeln festzulegen, welche Anwender und Gruppen genau spezifizierte Anwendungen auf den Client- und Server-Systemen der Firma ausführen dürfen und welche Anwendungen beispielsweise auf den Systemen nicht eingesetzt werden dürfen.

Softwareeinschränkungen und die verschiedenen Richtlinien.

Es handelt sich bei dieser Technik um eine deutlich erweiterte und verbesserte Versionen einer Funktionalität, die Microsoft bereits auf dem Windows Server 2003 unter der Bezeichnung Softwareeinschränkungsrichtlinien zur Verfügung gestellt hat. Beide Techniken wurden mit dem Ziel entwickelt, grundsätzlich die Ausführung von Schadcode und bösartigen Programmen auf den Windows-Plattformen aktiv zu verhindern. Der Administrator kann aber die Softwareeinschränkungsrichtlinien und den Applocker beispielsweise ebenfalls dazu einsetzen, seinen Anwendern den Zugriff auf Spiele wie Minesweeper zu untersagen. Auch der Einsatz eines Browser oder einer Browser-Version, die laut Firmenrichtlinien nicht verwendet werden soll, kann mit Hilfe dieses Features wirkungsvoll unterbunden werden.

Unser Autor Jan de Clercq vergleicht in diesem Artikel die Möglichkeiten der Richtlinien zu Softwareeinschränkung mit denen, die der Applocker anzubieten hat. Dabei stellt er auch die Probleme und Fallstricke vor, mit denen sich der Systemverwalter beim Einsatz dieser Technik beschäftigen muss.

Die Tabelle auf dieser Seite gibt einen ersten Überblick darüber, wo sich diese beiden Techniken unterscheiden und welche Gemeinsamkeiten sie teilen.
Wie diese Übersicht sehr schön zeigt, war es auch unter den Betriebssystemversionen Windows Server 2003 und Windows Vista/XP für Administratoren möglich, ihre Anwender am Einsatz bestimmter Programme zu hindern. Dies konnten sie dann durch das Ausrollen sollen Richtlinien im Firmennetz erreichen. Eine feine und genaue Einstellung der Einschränkungen konnten sie auf diese Weise allerdings nicht erreichen: So bezog sich der Geltungsbereich der Regeln immer auf alle Anwender im eigenen Netz, die praktische Anwendung einer solchen Maßnahme ist dadurch schon einmal stark einschränkte. Die fehlende Skripting-Unterstützung der Softwareeinschränkungsrichtlinien durch die Powershell tat ein weiteres hinzu, diese Möglichkeit als wenig praktisch einzustufen.

Wie wird grundsätzlich die Ausführung von Schadprogrammen verhindert? Die meisten Antivirus- und Antispyware-Lösungen verwenden dazu in der Regel eine Technik, die als Blacklisting bezeichnet wird. Damit erlauben die Programme grundsätzlich die Installation und den Betrieb jeder Software auf einem System, so lange sie nicht auf einer Blacklist mit potenziell gefährlichen Programmen auftauchen. Finden diese Schutzprogramme dann eine Anwendung, die infiziert ist, so löschen sie dieses Programm oder verschieben es in einen geschützten Quarantäne-Bereich. Es ist aber eine andere Technik, die im Moment in vielen Bereichen der IT wieder mehr an Bedeutung gewinnt: das sogenannte Whitelisting.

Bei dieser Vorgehensweise wird der zuvor geschildert Ansatz umgekehrt: Das Schutzprogramm blockiert grundsätzlich alle Anwendungen mit Ausnahmen von jenen, die auch dieser „guten“ Liste aufgeführt werden. Diese Vorgehensweise erinnert dabei sicherlich viele IT-Profis an frühere Zeiten. So war es in der Firmennetzen noch in der neunziger Jahren durchaus üblich, dass dort nur und ausschließlich die Programme verwendet werden durften und konnten, die von der IT installiert und freigegeben wurden. Grundsätzlich ist dies eindeutig der bessere Weg, wenn die Systembetreuer ihre Systeme und Netze vor Schadsoftware schützen wollen: Wird dadurch doch ihre Aufgabe deutlich erleichtert. Schließlich ist es in der heutigen Zeit der vernetzten Systeme und des permanenten Kontakts zum Internet für die IT-Verantwortlichen kaum möglich zu kontrollieren, welche Programme die Anwender herunterladen und dann auf den Systemen installieren –eine konsequent durchgesetzte Politik des Whitelistings kann dies wirkungsvoll unterbinden.

Gefahren & Probleme: Selbstaussperren und Arbeitsverhinderung…

Allerdings sollte man nicht außer Acht lassen, dass der Einsatz einer derartigen Whitelisting-Technologie auch Risiken bergen kann: So ist es für den Systemverwalter beim Einsatz dieser Technik ein Leichtes, sich selbst vom System auszuschließen. Dazu muss er nur vergessen seine Administrations-Tools mit auf die Liste zu setzen und dann die entsprechende Erzwingung der Regeln scharf schalten. Ein weiteres Problem entsteht dann, wenn beispielsweise eine Abteilung ohne Wissen der IT eine neue geschäftskritische Anwendung einführt – wird ein entsprechendes Whitelisting durchgesetzt, kann es so passieren, dass diese gesamte Abteilung nicht mehr arbeiten kann.

Sowohl die Softwareeinschränkungsrichtlinien als auch das Applocker-Feature der neuen Systeme sind dazu in der Lage, neben dem Black– auch mit dem Whitelisting-Verfahren umzugehen. Wie aber schon unsere Aufstellung in der Tabelle auf der ersten Seite zeigt, unterscheiden sich die beiden Features darin, wie sie standardmäßig vorgehen, wenn der Systemverwalter selbst keine speziellen Einstellungen wählt: Grundsätzlich verweigert der aktivierte Applocker den Einsatz aller Anwendungen, die er nicht auf seiner Liste findet. Ein Systembetreuer muss hier also explizit festlegen, welche Anwendungen auf den Systemen in seinem Netz laufen dürfen.

Die Richtlinien zur Softwareeinschränkung arbeiten hingegen grundsätzlich mit einem Blacklisting-Ansatz. Es ist jedoch auch möglich, sie mit einigem Aufwand so zu konfigurieren, dass sie standardmäßig ein Whitelisting anwenden. Dieser Aufwand und die damit verbundene umständlichere Konfiguration waren dann wohl auch ein Grund dafür, dass die meisten Systemverwalter die Richtlinien nur mit einer Blacklist eingesetzt haben. So war es dann in der Regel den Anwendern auch weiterhin erlaubt, zunächst einmal alle Programme auf den Systemen zu installieren und einzusetzen, was dem grundsätzlichem Sicherheitsgedanken direkt zuwider lief.

In der Praxis: Die Regeln und das Erstellen der Listen

Will ein Administrator den Applocker auf seinen Systemen einsetzen, so benötigt er Wege, die entsprechenden Regeln schnell und einfach zu erstellen und durchzusetzen. Dazu kann er, wie schon bei den Softwareeinschränkungsrichtlinien, auch hier die Einstellungen eines Gruppenrichtlinien-Objekts (GPO – Group Policy Object) verwenden. Weiterhin ist es beim Applocker im Gegensatz zu dem alten Ansatz auch möglich, diese Einstellungen mittels PowerShell-Cmdlets vorzunehmen. Die Erläuterungen zur Verwaltung der Applocker-Einstellungen via Powershell würden aber den Umfang dieses Artikels deutlich übersteigen, so dass wir Interessierte auf einen entsprechenden Blog-Eintrag im MSDN-Bereich der Microsoft verweisen möchten: Der Artikel trägt den Titel „Getting startet with Applocker management using PowerShell“ und ist hier zu finden.

Sowohl unter Windows 7 (wie in unserem Bild 1 zu sehen) als auch dem Windows Server 2008 R2, muss der Systemverwalter dazu zunächst einmal den Editor für lokale Gruppenrichtlinien aufrufen. Dies geschieht mit „Ausführen“ (Windows-Taste und „R“) und anschließender Eingabe des Begriffs „gpedit.msc“. Innerhalb der MMC-Oberfläche (Microsoft Management Consolte) muss er dann den folgenden Pfad auswählen:

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Anwendungssteuerungsrichtlinien\Applocker

Der Weg zu diesen Einstellungen ist ebenfalls in Bild 1 zu sehen.

Der Administrator kann an dieser Stelle auch weiterhin die alten Softwareeinschränkungsrichtlinien konfigurieren und verwenden, da beide Techniken nebeneinander eingesetzt werden können. Das ist besonders dann von großem Vorteil, wenn im Netzwerk noch älteren Systeme unter Windows XP oder Windows Server 2003 im Einsatz sind, da der Einsatz von Applocker nur auf Systemen unter Windows 7 und Windows Server 2008 R2 möglich ist. Eine automatische Migration der alten Regeln auf die neuen Applocker-Einstellungen, die sich Systemverwalter beispielsweise bei einem Update des Servers von der 2008- auf die 2008-R2-Version wünschen würden, bietet Microsoft aufgrund der großen Unterschiede in den Richtlinien der beiden Verfahren leider nicht an. Das Applocker-Feature unterstützt auf den Windows-Systemen drei unterschiedliche Regeltypen:

•    ausführbare Regeln,

•    Windows-Installer- und

•    Skript-Regeln,

wie ebenfalls in Bild 1 zu sehen. Diese Regeln werden vom System in Gruppen von Regelsammlungen zusammengefasst und sind in den Eigenschaften des Applocker-Containers zu finden. Welche Auswirkungen haben nun diese Regeln?

•    Die ausführbaren Regeln sind in der Lage, *exe- und *.com-Dateien an der Ausführung zu hindern.

•    Die „Windows-Installer“-Regeln können zudem die *msi-Dateien (die vom Windows-Installationsprogramm verwendet werden) und die *.msp-Dateien (Windows Installer Patching) stoppen.

•    Schließlich stehen noch die Skript-Regeln zur Verfügung, mit deren Hilfe der Systemverwalter die Ausführung diverser Skripting-Dateien wie *.ps1, *.bat,*.cmd, *.vbs oder *.js wirkungsvoll unterbinden kann.

Ein Rechtsklick auf diese Container stellt dem Systemverwalter drei Optionen bei der Erstellung der Regeln zur Verfügung: „Neue Regel erstellen“, „Regeln automatisch generieren“ und „Standardregeln erstellen“.

Die Erstellung von Standardregeln: Systembetreuer, die zum ersten Mal mit diesen Regeln arbeiten, sollten sich zunächst einmal mit diesen sogenannten Standardregeln beschäftigen. Standardregeln werden vom System automatisch
generiert. Der Applocker legt diese Regel dabei im Grundsatz so anlegt, dass ein Windows-System problemlos funktionieren und der Administrator ungestört seine Arbeit tun kann. Das ist deshalb besonders wichtig, weil dieses Feature wie bereits erläutert, standardmäßig einen Whitelisting-Ansatz verfolgt, was schnell zum Selbstaussperren führen kann. Als weitere Sicherheitsmaßnahme wird der Administrator von Applocker auch darauf hingewiesen, zunächst einmal die Standardregeln entsprechend definieren, wenn er sofort und ohne Standardregeln eine neue Regel definieren möchte.

Der Autor empfiehlt aus seiner eigenen Erfahrung, eine derartige Liste auf einer „Muster-Maschine“ im Netz zu erstellen. Danach kann der Administrator die Richtlinien einfach exportieren und dann auf den anderen Maschinen in seinem Netz leicht wieder importieren. Dies ist – wie ebenfalls in Bild 1 zu sehen – durch einen einfachen Rechtsklick auf den Container Applocker in der MMC möglich.Ein bewährter Best-Practice-Ansatz für dieses Feature besteht zudem darin, zunächst einmal Standardregeln zu entwerfen, die der Administrator dann nach und nach durch den Einsatz restriktiverer Regeln, die er manuell anlegt, verfeinern und ausbauen kann. Dabei kann der Systemverwalter für alle drei Regeltypen entsprechende Standardregeln getrennt voneinander definieren.

Assistent hilft, automatisch generierte Regeln richtig anzulegen.

Die Erstellung automatisch generierter Regeln: Will ein Administrator automatisch generierte Regeln verwenden, so erstellt Applocker eine Whitelist für den Systemverwalter. Hier steht, wie bei den anderen Regeln auch, ein Assistent zur Verfügung, in dem angegeben werden kann, in welchem Verzeichnis die Dateien liegen, für die ein Regelsatz erstellt werden soll (Bild 2). Der Applocker schlägt dann einen entsprechenden Regelsatz für die
Dateien in diesem Ordner vor. Das ist gerade am Anfang eine große Arbeitserleichterung bei der Erstellung einer Whitelist. Dabei kann der Administrator unter anderem auch entscheiden, auf welche Art und Weise die Regeln die Programmdateien identifizieren: Dazu kann einfach der Pfad einer ausführbaren Datei oder ein Hash-Wert zum Einsatz kommen. Dabei ist der Einsatz eines eindeutigen Hash-Werts für eine Datei sicher der Weg, den die meisten Administratoren vorziehen werden. Allerdings besitzt der Einsatz dieses „Fingerabdrucks“ einer Datei auch einige Nachteile: Die Regel muss einem Update unterzogen werden, wenn beispielsweise eine gepatchte oder
neue Version des entsprechenden Programms eingespielt wird. Weiterhin kann sich der Einsatz der Hash-Wert an dieser Stelle negativ auf die Performance des Systems auswirken.

Zum Anschluss der Aktion kann sich der Administrator dann noch einmal die komplette Liste der erstellten Regeln vom Assistenten anzeigen lassen (Bild 3). Dabei kann er nicht nur nach einer bestimmten Regel suchen, sondern beispielsweise auch manuell eine Regel für eine bestimmte Datei wieder außer Kraft setzen.

Die Erstellung neuer Regeln: Der dritte Weg besteht schließlich darin, über den Eintrag „Neue Regel erstellen“ ebenfalls mittels eines Assistenten eine komplett neue Regel für das System zu erstellen. Im Normalfall wird ein Systemverwalter diese Option als letzten Schritt ausführen, um die zuvor erstellten Regeln zu erweitern und zu verfeinern. Der Assistent stellt hier die Möglichkeit zur Verfügung, „Erlauben“- oder „Verweigern“-Regeln für Dateien selbst anzulegen. Weiter bietet es der „Wizard“ an, den Anwender beziehungsweise eine Gruppe von Anwendern auszuwählen, für die diese neue Regel dann gelten soll. Auch wie Applocker eine Datei identifiziert, kann hier selbst festgelegt werden. Zur Auswahl stehen dabei die Möglichkeiten einer Identifizierung über den Hash-Wert, über den Pfad (also über den Ort, an dem die Datei im Dateisystem abgespeichert wird) über den Herausgeber eines Programms beziehungsweise einer Datei.

Diese Unterscheidungen werden vom Applocker als sogenannte Primärbedingungen bezeichnet. Der Systemverwalter kann die Bedingungen nach dieser Auswahl noch genauer spezifizieren, indem er in einem nächsten Schritt innerhalb des Assistenten dann Ausnahmen zu dieser Primärbedingung festlegt. Hat er beispielsweise die Unterscheidung über den Herausgeber als Kriterium ausgewählt, dann wird Applocker die entsprechende Datei anhand diese durch die digitale Signatur identifizieren, die der Herausgeber (also in der Regel die Softwarefirma, die das Programm zur Verfügung stellt) dem Programm als Teil des Signatur-Prozesses mitgegeben hat.

Im Bild 4 sind die unterschiedlichen Möglichkeiten zu sehen, die dem Administrator bei der Herausgeber-basierten Erkennung zur Verfügung stehen. Der Schieberegler, der ebenfalls in Bild 4 zu sehen ist, erlaubt es dem Administrator dabei, die Einstellung entsprechend zu verschärfen: Er kann dabei von einer ganz allgemeinen (nur der Name des Herausgebers ist entscheidend) bis hin zur sehr genauen Erkennung auswählen, bei der beispielsweise nur eine ganz bestimmte Unterversion der Datei zugelassen wird.

Ein Unterschied zu den Softwareeinschränkungsrichtlinien besteht darin, dass der Applocker keine sogenannte Netzwerk- oder Internetzone zur Identifizierung von Dateien mehr zur Verfügung stellt, mit deren Hilfe die Internet-Zone der Webseite, von der ein Programm heruntergeladen wurde, als Merkmal zur Erkennung verwendet werden konnte.

Das Durchsetzen der Regeln in der Praxis

Genau wie die Softwareeinschränkungsrichtlinien unter Windows Server 2003 ist auch das Applocker-Feature standardmäßig nicht eingeschaltet. Selbst wenn der Administrator bereits entsprechende Regeln angelegt und abgespeichert hat, wird der Applocker sie nicht automatisch bei den Client-Systemen durchsetzen. Ein erster Schritt, um diese nun erstellten Regel „scharf“ zu schalten, besteht für den Administrator darin zu entscheiden, ob er die Regeln nur zur Überwachung (Auditing) oder zur Erzwingung der vorgegebenen Einschränkungen einsetzen will. Die ebenfalls mit dem Applocker neu hinzugekommene Option, die Regel nur zu überwachen gibt dem Administrator eine gute Möglichkeit, damit festzustellen, ob die von ihm durchgeführten Konfiguration den Live-Test bestehen: Wird diese Option eingestellt, werden die Regeln aus der jeweiligen Sammlung nicht erzwungen.

Aber jedes Mal, wenn ein Anwender ein Programm ausführt, dass von einer der erstellten Regeln betroffen ist, wird eine entsprechende Information in das Ereignisprotokoll des Applocker geschrieben. So verhindert ein Administrator nicht nur, dass er sich versehentlich selbst „aussperrt“, sondern kann seine Regeln auf eventuell auftretende Seiteneffekte überprüfen. Eine weitere Einstellung, die dem Administrator bei den Eigenschaften der Container schnell auffallen wird, ist ein zweiter Reiter mit der Aufschrift „Erweitert“: An dieser Stelle kann eine vierte Sammlung von Applocker-Regeln eingeschaltet werden: die DLL-Regelsammlung. Damit werden Dateien mit den Dateiendungen *.dll und *.ocx überprüft. Die Microsoft-Entwickler haben diese Sammlung aber aus einem guten Grund auf diesen Extra-Reiter verbannt: Das Einschalten dieser Überprüfung kann sich sehr deutlich auf die Performance des entsprechenden Systems auswirken.

Zudem wird durch diesen Überprüfungsprozess ein ziemlich aufwändiger administrativer Overhead auf dem System in Betrieb gesetzt, der laut Systemdokumentation durchaus auch „unerwartetes Verhalten“ des Betriebssystems verursachen kann. Wer also nicht in Firmen arbeitet, die wie militärische Einrichtungen extreme Sicherheitsvorschriften durchsetzen müssen, sollte davon absehen, diese Überprüfungsoption in seinem Netzwerk zu verwenden.

In einem zweiten Schritt muss dann Systemverwalter dann schließlich noch sicherstellen, dass auf allen Systemen, auf denen die Regeln zum Einsatz kommen sollen, auch der Anwendungsidentitätsdienst aktiv ist. Dieser Dienst ist auf den Windows Server 2008 R2 und den Windows 7 Systemen standardmäßig so eingestellt, dass ein manueller Start ausgeführt werden muss, damit er auf den entsprechenden Systemen aktiv ist. Der Applocker warnt den Administrator durch eine entsprechende Meldung in der MMC, dass erst die Inbetriebnahme dieses Dienstes ein Durchsetzen der Regeln auf den Zielsystemen ermöglicht.

Jan DeClercq/ fms