IIS galt einst als die Schwachstelle schlechthin in der gesamten Windows-Architektur. Bei IIS 5.0 und seinen Vorgängern kamen nicht nur laufend neue Sicherheitslecks zutage, die Server galten auch als nicht besonders zuverlässig. So konnten instabil gewordene Webanwendungen häufig das ganze System herunterreissen. Mit IIS 6.0 soll dies nun anders werden. Einerseits sorgt eine neue Architektur (siehe «IIS 6.0: Migrieren und konsolidieren» in der letzten Ausgabe) für mehr Stabilität. Andererseits haben Microsofts Leitsprüche «Security by Design» und «Security by Default» aus der Trustworthy-Computing-Initiative mittlerweile auch bei IIS 6.0 Einzug gehalten.
Anders als bei Windows 2000 und IIS 5.0 wird IIS 6.0 bei einer Neuinstallation von Windows Server 2003 nicht mehr automatisch eingerichtet. Statt dessen muss IIS 6.0 manuell via Start Menü–Programs–Administrative Tools–Manage Your Server oder über Add/Remove Windows Components im Control Panel installiert werden. Ein weiterer Unterschied: Wurden bei IIS 5.0 gleich alle möglichen Features von WebDav bis zur HTML-Administration aktiviert, sind bei IIS 6.0 nach erfolgter Installation nur die notwendigsten Komponenten freigeschaltet. Gewünschte Zusatzdienste wie ASP, ASP.Net, die FrontPage Server Extensions oder Server Side Includes müssen über die Web Service Extensions des IIS Manager manuell aktiviert werden.
Vorteile bietet IIS 6.0 auch beim Schutz vor URL-Attacken: Bei IIS 5.0 Server musste das Tool URLScan zum Verifizieren von URLs separat installiert werden, bei IIS 6.0 gehört die Prüfung der URL zum Standardumfang.
Dank diesen Konzeptänderungen wird die Angriffsfläche eines aufgesetzten IIS 6.0 Servers auf ein Minimum reduziert. Das ist allerdings kein Grund zu Übermut: Microsoft-Produkte und IIS im speziellen werden weiterhin zu den beliebtesten Zielen von Hacker-Angriffen gehören. Aus diesem Grund ist es wichtig, dass sich beim weiteren Konfigurieren und beim Aktivieren von Zusatzfunktionen keine neuen Sicherheitsrisiken auftun. Schliesslich ist jeder Webserver nur so sicher wie seine schwächste Stelle. Daher gilt es bei der Administration des IIS einige wichtige Grundsatzregeln einzuhalten (siehe Kasten IIS-6.0-Security: Best Practices).
Ausserdem ist es wichtig, Windows Server 2003 und IIS 6.0 immer mit den neuesten Sicherheits-Patches zu versorgen. Enorm praktisch ist in diesem Zusammenhang die Automatic-Update-Funktion, die sich in den drei Modi «Notifizieren ohne Download», «automatischer Download ohne Installation» und «Download mit automatischer Installation» betreiben lässt. Konfigurieren lassen sich Automatic Updates über den Eigenschaftendialog des Systems. Unter www.micro soft.com/security/bulletins kann man sich zudem regelmässig über das neueste Sicherheitspflaster informieren lassen. Generell veröffentlicht Microsoft jeden zweiten Dienstag im Monat die aktuellsten Patches zu ihren Produkten im Multipack. Diese lassen sich dann auch gleich in einem Durchgang auf das System aufspielen. Allerdings darf man sich nicht ausschliesslich auf diesen Termin verlassen: Bei kritischen Lecks kann es durchaus sein, dass der entsprechende Hotfix auch zwischen diesen Terminen veröffentlicht wird.
Wie bereits in der letzten Ausgabe im Detail beschrieben, verfügt IIS 6.0 über eine neue Architektur, die den Betrieb des Webservers nicht nur zuverlässiger, sondern auch sicherer macht. Dabei wird jede Webanwendung in einem eigenen, von den anderen Applikationen abgeschotteten Arbeitsbereich (Worker Process) abgespielt. Fehlfunktionen, die zu Abstürzen führen könnten, oder böswillige Attacken beschränken sich damit nur noch auf die betreffende Anwendung.
Zusammen mit dem neuen Worker-Process-Modell erhöhen eine Reihe von weiteren neuen Features die Zuverlässigkeit des Serverbetriebs. Dazu gehört beispielsweise das automatische Recycling von Webapplikationen. Damit lässt sich ein Applikationspool automatisch stoppen und neu starten. So wird verhindert, dass schlecht geschriebener Code oder Memory Leaks einen Worker Process nach einer gewissen Zeit bremsen oder gar einfrieren. Das Praktische daran ist, dass die übrigen Applikationspools von der Restart-Prozedur nicht betroffen sind.
Für das Auslösen des Recyclings können diverse Bedingungen gesetzt werden, so etwa, wenn eine Anzahl von Requests erreicht wurde oder ein vorgegebener Wert bezüglich des Memory-Verbrauchs überschritten wird. Ausserdem kann in regelmässigen Zeitabständen ein Neustart ausgelöst werden. Den Konfigurationsdialog für das Recycling ist über die Eigenschaft des entsprechenden Applikationspools unter Recycling zu finden.
IIS 6.0 arbeitet per Default nach dem Overlapping-Verfahren. Dabei wird vor dem Herunterfahren eines Worker Process bereits ein neuer Prozess gestartet, der neue Requests bearbeiten kann. Damit ist trotz Recycling eine lückenlose Verfügbarkeit gewährleistet.
Das Recycling von Anwendungen kann allerdings dann problematisch werden, wenn eine Webanwendung mit Session-Variablen arbeitet. Dabei handelt es sich um Daten, die während einer Browsersitzung serverseitig im Memory des Servers zwischengespeichert werden. Normalerweise wird einem Worker Process zwar während des Recycling-Vorgangs Zeit eingeräumt, um seine aktuellen Requests zu beenden, je nach dem können aber trotzdem Session-Daten verlorengehen. Um das Risiko von Datenverlusten auszuschliessen, sollten Session-Variablen Out-of-process über den ASPState Service oder in einer Datenbank (z.B. SQL Server) zwischengespeichert werden.
IIS 6.0 verfügt auch über einen Selbstheilungsmechanismus. Dieser überwacht den Zustand der laufenden Webapplikationen, indem er deren Prozesse in regelmässigen Intervallen anpingt. Gibt der angerufene Prozess innert nützlicher Frist keine Antwort, wird die Webapplikation automatisch neu gestartet und ein Eintrag im Event Log plaziert. Ausserdem können auch Startup- und Shutdown-Zeiten von Prozessen überwacht werden.
Zudem kann man IIS 6.0 auch anweisen, Applikationspools herunterzufahren, die in bestimmten Zeitabständen eine bestimmte Anzahl von Neustarts produzieren. Häufig notwendige Restarts können ein Hinweis darauf sein, dass die Website Opfer einer Attacke geworden ist oder ein anderes schwergewichtiges Problem vorliegt. Die Einstellungsmöglichkeiten für den Health-Mechanismus sind über die Eigenschaften des Applikationspools im Register Health erreichbar.
In IIS 6.0 werden alle Konfigurationsdaten in einer Metabase (neu im XML-Format) abgelegt. Dabei ist es empfehlenswert, Sicherheitskopien der Metabase anzulegen, denn damit lässt sich im Fehlerfall (z.B. bei einem Harddisk-Crash) die komplette Konfiguration des Webservers wiederherstellen. IIS 6.0 ist standardmässig so konfiguriert, dass Backups in gewissen Zeitintervallen automatisch durchgeführt und in einem History-Verzeichnis abgelegt werden. Per Restore kann man IIS 6.0 jederzeit wieder in einen früheren Konfigurationszustand versetzen. Oft ist es aber auch nützlich, Backups manuell durchzuführen, etwa wenn gerade grosse Änderungen an der Konfiguration bevorstehen und man bei Problemen den aktuellen Zustand wiederherstellen möchte. Diese Funktion lässt sich via IIS Manager über die Eigenschaften des Servers via All Tasks, Backup/Restore Configuration aufrufen. Die entsprechenden Backup-Dateien befinden sich im Verzeichnis Systemroot\System32\Inetsrv\History und setzen sich aus einem Datenfile MetaBase_*.xml und einem passenden Schema MBSchema_*.xml zusammen. Metabase-Backups lassen sich übrigens auch dazu nutzen, die komplette Konfiguration (ohne Content) eines IIS 6.0 auf ein zweites System zu duplizieren.
•
Nutzung des Admin-Kontos vermeiden: Zur Anmeldung am System sollte statt des Kontos des Administrators ein Account mit geringeren Benutzerrechten verwendet werden. Der IIS Manager kann dann mit dem ‘Run as‘-Kommando als Administrator genutzt werden.
•
Angriffsfläche klein halten: Nur Services (FTP, NNTP, SMTP) und Extensions (ASP.Net, WebDav) aktivieren, die auch tatsächlich benötigt werden.
•
NTFS verwenden: NTFS ist FAT punkto Sicherheit weit überlegen. So können mit NTFS die Zugriffsrechte auf Verzeichnis- und File-Ebene geregelt werden.
•
Hotfixes sofort aufspielen: Fixes für neu entdeckte Sicherheitslecks sollten immer so schnell wie möglich appliziert werden. Dazu wird am besten der Windows Update Client verwendet.
•
Anonyme Zugriffe einschränken: IUSR_computername ist der Account, der für anonyme Benutzerzugriffe verwendet wird. Schreibberechtigungen für IUSR_computername sollten daher so stark wie möglich eingeschränkt werden.
•
Gruppe für anonyme User einrichten: Alle Konten für anonyme Benutzerzugriffe sollten in einer Gruppe zusammengefasst werden. So können Zugriffsberechtigungen auf bestimmte Ressourcen an zentraler Stelle eingeschränkt werden.
•
Windows-Systemverzeichnis absichern: Zugriffe auf ausführbare Dateien in den Windows-Systemverzeichnissen sollten für anonyme User explizit verboten werden.
•
Ausführbare Dateien absondern: Ausführbare Dateien sollten in gesonderten Verzeichnissen gespeichert werden. So können Zugriffsberechtigungen einfacher zugewiesen werden.
•
Restriktive Berechtigungen verwenden: Immer möglichst restriktive, dem Zweck angepasste Berechtigungen verwenden. Wird eine Website nur zum Abrufen von Informationen verwendet, sollte dementsprechend auch nur die Read-Berechtigung aktiviert werden.
•
Hochladen und Ausführen von Programmen unterbinden: Berechtigungen für Write und Script source access oder Scripts and Executables sollten nur mit grösster Vorsicht vergeben werden. Diese erlauben es einem Benutzer, bösartige Programme hochzuladen und auszuführen.
•
Basic Authentication nur mit SSL verwenden: Bei der Basic Authentication wird das Passwort im Klartext übertragen. Daher sollte man diesen Authentifizierungsmechanismus nur in Zusammenhang mit SSL (Secure Sockets Layer) verwenden.
