Mit dem Internet Information Server 6 unter Windows Server 2003 hat Microsoft einen neuen Betriebsmodus für Anwendungen eingeführt: Den Worker Process Isolation Mode. Dieser isoliert Webanwendungen voneinander, die auf einem IIS 6 Server betrieben werden. Unter Isolierung ist dabei die Trennung von Prozessen, Daten und Benutzern der Anwendungen zu verstehen. Der Betriebsmodus soll verhindern, dass eine Anwendung auf dem Server keine Ressourcen einer anderen Anwendung erreichen und somit negativ beeinflussen kann. Die Isolation von Webanwendungen verfolgt mehrere Ziele.
Server-Konsolidierung: Da die Leistungsfähigkeit der Server-Hardware ständig zunimmt, ist es sinnvoll, mehrere Webanwendungen, die klassischerweise auf unterschiedlichen Systemen betrieben wurden, auf nur einem gemeinsamen Server laufen zu lassen. Das führt aber zu logistischen Problemen, wenn diese Anwendungen nicht strikt voneinander getrennt arbeiten, so wie das zuvor auf den getrennten Systemen der Fall war.
Sicherheit: So soll zum Beispiel bei einem ISP, der viele Webanwendungen unterschiedlicher Kunden hostet, die Anwendung von Kunde A keinen Zugriff auf die Ressourcen von Anwendung B haben.
Verfügbarkeit: Außerdem soll der Absturz einer Webanwendung nicht dazu führen, dass andere Anwendungen auf dem gleichen Webserver in Mitleidenschaft gezogen werden.
Verfahren zur Isolation
Nun bieten sich dem Administrator unterschiedliche Möglichkeiten zur Isolation von Anwendungen. Die klassische Vorgehensweise haben wir bereits angesprochen. Jede Anwendung erhält dabei ein eigenes System. Das schafft auf der einen Seite das höchstmögliche Maß an Isolation, bringt aber sowohl durch Anschaffungs- als auch durch Wartungskosten die größten Nachteile.
Eine weitere Möglichkeit der Isolation besteht aus dem Betrieb von virtuellen Maschinen mit Hilfe von Programmen wie Virtual Server oder VMware. In jeder virtuellen Maschine wird dann ein separater Webserver betrieben. Die Anwendungen sind dabei de facto völlig voneinander isoliert, laufen jedoch auf der gleichen Hardware. Dafür sinkt die Performance zum Teil deutlich ab, da der Betrieb der virtuellen Systeme an sich schon einen Teil der Server-Leistung in Anspruch nimmt. Ein anderer Nachteil besteht in der Lizenzfrage bei einer solchen Konfiguration, da ja auch die virtuellen Server-Systeme und zusätzlich die Virtualisierungs-Software beschafft werden müssen.
Die dritte Herangehensweise ist die Isolation durch Konfigurationsmaßnahmen auf dem Webserver-System. Hier kommen Prozessräume, ACLs und Namensräume im Webserver selbst zum Einsatz. Diese Form der Isolation wird durch den IIS 6 in vielfacher Weise unterstützt – und stellt momentan die kostengünstigste Form der Anwendungstrennung dar.
Anwendungstrennung beim IIS 6
Beim IIS 6 kann jede Website eine oder mehrere Anwendungen hosten. Anwendungen lassen sich dabei in einem Pool aus Prozessen betreiben. Jeder dieser so genannten „Application Pools“ wird dabei über einen Namen identifiziert. Ein gegebener Pool wird von multiplen Arbeitsprozessen betrieben, ist unabhängig von anderen Pools konfigurierbar und läuft im Kontext eines frei definierbaren Benutzer-Accounts.
Die Konfiguration der Anwendungstrennung beim IIS 6 verfolgt drei unterschiedliche Ziele, die allerdings miteinander verquickt sind.
Es geht dabei um die Verlässlichkeit, die Sicherheit und die Performance der Anwendungen. Im Rahmen der Verlässlichkeit soll sichergestellt werden, dass ein Fehlschlagen einer Anwendung die anderen Anwendungen nicht betrifft. Die Sicherheitsmechanismen sollen bewirken, dass bösartiger Code, der trotz aller Sicherungsmaßnahmen von einer Webanwendung ausgeführt wird, keine Eintrittspunkte in andere Anwendungen findet. Mit den Performance-Mechanismen des Isolationsbetriebs kann der Administrator sicherstellen, dass die Ressourcen einer Anwendung so limitiert sind, dass alle Anwendungen parallel betrieben werden können: Ein einzelne Anwendung kann also zum Beispiel nicht die komplette CPU-Leistung des Systems für sich in Anspruch nehmen.
Dieser Beitrag beschäftigt sich in erster Linie mit den sicherheitsrelevanten Aspekten der Anwendungstrennung.
Isolation zum Schutz der Anwendungen
Die wichtigsten Werkzeuge zur Konfiguration der Isolation sind die ACLs (Access Control Lists) von Windows 2003, die Authentifizierung sowie getrennte Prozesse. So können Sie mit ACLs beispielsweise einen effektiven Schutzwall aufbauen, der sicherstellt, dass eine Anwendung nicht die Dateien einer anderen erreichen kann.
Bei der Absicherung eines Servers müssen Sie vor Augen haben, dass alle Prozesse auf dem System grundsätzlich unter einem User- oder einem eingebauten Account laufen. Das bemerkt man normalerweise nicht, da Dateien in der Regel im Kontext des gerade angemeldeten Anwenders geöffnet werden. Ein Programmierer kann eine Anwendung allerdings auch so gestalten, dass das Dateisystem in einem anderen Benutzerkontext verwendet wird. Dabei existieren zwei Accounts: Der des Anwendungsbenutzers und der Account, unter dem der Vaterprozess der Webanwendung gestartet wurde.
Isolation an einem Beispiel
Einmal angenommen, ein neuer Besucher der Website startet eine Webanwendung, indem er die passende Eintrittsseite aufruft. Dabei wird der Besucher automatisch dem anonymen Account zugeordnet. Dies ist üblicherweise der Account mit dem Namen IUSR_NameDesSystems. Die von der Webanwendung angeforderte Datei wird also mit den Rechten des anonymen Users geöffnet beziehungsweise ausgeführt – natürlich nur dann, wenn der IUSR_* auch die entsprechenden Rechte hat.
Die Anwendung kann aber nun ihrerseits eine bestimmte Funktion der Win32-API verwenden: RevertToSelf(). Diese führt dazu, dass der laufende Prozess nicht mehr über die Rechte des zugeordneten Users (IUSR_*) eingeschränkt wird, sondern stattdessen die Rechte des Accounts erhält, der den Prozess ursprünglich gestartet hat. Im Fall einer Webanwendung ist das der Account „Network Service“. Dies ist ein eingebauter Account, der als Identität für die Application Pools verwendet wird.
Nun hat der „Network Service“ zwar eingeschränkte Rechte – aber alle Application Pools, die auch dessen Identität verwenden, können gegenseitig auf ihre Ressourcen zugreifen, wenn die ACLs dem Network Service diesen Zugriff erlauben. Mit anderen Worten: Der Programmierer kann durch den Aufruf von RevertToSelf() seiner Anwendung Zugriff auf die Dateien anderer Anwendungen ermöglichen, sofern alle in einem Application Pool liegen, der dieselbe Identität verwendet.
Es ist also dringend erforderlich, dass Sie Webanwendungen unterschiedlicher Kunden nicht nur in getrennten Application Pools betreiben – jeder Pool muss auch unter einer eigenen Identität betrieben werden, die nur den minimal benötigten Satz an Rechten haben sollte.
Eigenen Account anlegen und zuweisen
Wenn Sie einen neuen User-Account anlegen, den Sie als Identität für einen Application Pool verwenden wollen, dann muss dieser Account Mitglied der lokalen Gruppe IIS_WPG (Worker Process Group) sein. Diese Gruppe wird bei der Installation des IIS automatisch mit angelegt und dient in erster Linie dazu, alle benötigten Rechte für Zugriffe auf Systemressourcen zu gewährleisten, die ein Worker Process für den ordnungsgemäßen Betrieb mindestens benötigt. Zu diesen Rechten gehört auch das Recht, Application Pools zu starten.
Der Account selbst muss also Mitglied dieser Gruppe sein – gleichzeitig dürfen Sie aber dieser Gruppe keinen Zugriff auf die Ressourcen einer Anwendung geben. Wenn Sie nämlich die ACLs für die Dateien der Anwendung so definieren, dass IIS_WPG Zugriff darauf hat, erhalten automatisch alle Accounts in dieser Gruppe Zugriff auf die Dateien. Effektiv würde das also allen User-Accounts aller Application Pools Zugriff auf alle Dateien aller Application Pools geben.
Logischerweise sollten Sie als Identität für einen Application Pool auch nicht den anonymen Account oder den Benutzer-Account eines Kunden verwenden.
Richtig authentifizieren
Wenn sich ein User korrekt authentifizieren kann, ordnet das System ihm eine Identität zu. Diese verwendet das System, um den Zugriff auf Ressourcen einzuschränken. Sie müssen also sicherstellen, dass Sie die Identitäten Ihrer Anwendungen und Anwender vernünftig verwalten können. Nur so stellen Sie auch sicher, dass der Zugriff auf die unterschiedlichen Ressourcen effektiv geregelt ist.
Beim IIS 6 haben Sie die Auswahl zwischen den unterschiedlichsten Arten der Authentifizierung. Obendrein können Anwendungen eigene Authentifikationsmechanismen implementieren. Ein offensichtliches Beispiel für eine selbst implementierte Form der Authentifizierung ist die Forms-basierte Authentifizierung von ASP.Net.
Die sicherste Form der Authentifizierung besteht darin, dass der Administrator einen eindeutigen User-Account für den anonymen Zugriff auf eine Anwendung anlegt. Diesen eindeutigen Account müssen Sie im Folgenden als anonymen User in den Eigenschaften der Webanwendung zuweisen. Das erfolgt über den Reiter „Directory Security“ mit Hilfe des „Edit“-Buttons im Bereich „Authentification and access control“.
Accounts
Effektiv brauchen Sie also zwei Accounts, um sichere Grenzen zwischen den Webanwendungen aufzubauen: Zum einen den Account für den Application Pool, in dem die Anwendung betrieben wird, zum anderen die Identität für den anonymen User.
Das Anlegen der Accounts an sich reicht jedoch nicht aus: Sie müssen auch sicherstellen, dass die Benutzer gezwungen sind, sich korrekt zu authentifizieren. Damit gelangen Sie wieder zur richtigen Verwendung von ACLs, denn diese sind der primäre Mechanismus zum Erzwingen der Anmeldung. ACLs können für den Inhalt der Webseiten, für Shares, die Metabase und die Registry vergeben werden.
Am wichtigsten ist dabei die Konfiguration der ACLs für den Inhalt. Bei der Konfiguration dieser ACLs sollten Sie sich an zwei einfache Regeln halten. Zum einen sollten Sie Benutzer in Gruppen aufteilen und die ACL-Rechte basierend auf diesen Gruppen vergeben. Per ACL verbieten Sie dann grundsätzlich alle Zugriffe, die nicht ausdrücklich erlaubt sind.
Mit diesen einfachen Regeln werden Sie sich die Wartungsarbeiten und Änderungen an Zugriffsrechten auf Dauer erheblich erleichtern.
Mit ACLs auf Registry-Keys verhindern Sie zum Beispiel, dass der Programmierer einer Webanwendung per Programm ermitteln kann, welche COM-Objekte in Ihrem System installiert sind, um diese dann zu instanziieren. Details dazu finden Sie im Security Operations Guide bei Microsoft.
Caching ausschalten für mehr Sicherheit
Ein weiterer, wenn auch weniger wichtiger Aspekt der Anwendungsisolation besteht darin, dass Sie die Datei-Caches des IIS ausschalten. Sowohl IIS als auch ASP verwenden solche Caches, um die Performance des Systems zu verbessern. Konkret geht es dabei um das Static File Caching, das ASP File-Caching und die IIS Kompression.
Microsoft lässt sich zu diesem Thema nicht weiter aus, stellt aber fest, dass es unter „speziellen Bedingungen“ möglich sei, dass ein bösartiger Seitenbetreiber per Code aus einem Application Pool Zugriff auf Daten eines anderen Application Pools erlangen kann. Was diese speziellen Bedingungen ausmacht, ist unklar, vermutlich geht es dabei um bisher nicht entdeckte Sicherheitslöcher im IIS. Die Ursache des Problems ist jedoch, dass die für die Zwischenspeicher verwendeten Verzeichnisse von allen Application Pools geteilt werden.
Für einen Server mit extrem hohen Sicherheitsansprüchen sollten Sie die verschiedenen Caches also ausschalten. Die IIS Kompression schalten Sie dabei einfach über die Eigenschaften der Webseiten auf dem Service-Reiter ab. Das ASP-Caching finden Sie ebenfalls unter den Eigenschaften für Websites, dort aber im Reiter für das Home-Directory hinter dem Button „Configuration“. Das Static File Caching können Sie schließlich nur per Registry-Eintrag abklemmen: Setzen Sie dazu den Eintrag
HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters\DisableMemoryCache
(vom Typ REG_DWORD) auf 1.
In diesem Beitrag haben Sie erfahren, wie Sie Anwendungen im IIS effektiv voneinander trennen können, um die Anwendungen voreinander zu schützen. In einem späteren Beitrag geht es dann um die Anwendungstrennung für bessere Performance - und höhere Verlässlichkeit. (mha)