Windows Server: Sicherheit Webserver – IIS

Der Webserver Microsofts wird seit jeher belächelt, und das völlig zu Unrecht. Seit den Anfangsversionen hat sich viel getan. Sowohl in puncto Sicherheit als auch Performance. Er ist nicht ohne Grund unter den Top 3 der weltweit eingesetzten Webservern. Im zweiten Teil des Workshop “Sicherheit Webserver”, werden relevante Technologien des Internet Information Services (IIS), aktuell in Version 10, angesprochen und mit Beispielen näher gebracht, um den IIS abzusichern (Hardening).

Um die Sicherheit des Servers zu gewährleisten, ist es wichtig, seine Funktionsweise zu verstehen. Die grundlegenden Komponenten sind Sites und die Anwendungspools (kurz App Pool). HTTP-Anfragen werden über eine Verwaltungseinheit an die Webseite weitergeleitet, an die diese Anfrage gerichtet ist. Jede bestehende Webanwendung läuft innerhalb eines App Pools.

Webseiten mit einem gemeinsam verwendeten und einem dedizierten App Pool.

Ein Anwendungspool stellt wiederum einen oder mehrere Arbeitsprozesse (Worker Process) zur Ausführung der Webanwendung bereit. Das sorgt für eine prozesstechnische Trennung von Webseiten.

Jede Webanwendung durch dedizierte App Pools isolieren.

Wenn jede Webseite in einem eigenen App Pool läuft, sind die Auswirkungen fehlerhafter Webanwendungen auf die Sites beschränkt, die diesen App Pool nutzen. Jede Webseite sollte daher mit einem eigenen App Pool konfiguriert werden.

 

Nach dem Erstellen eines neuen App Pools, weist man diesen der entsprechenden Site über die Basic Settings zu.

Seit IIS 7 läuft jeder App Pool standardmäßig mit eigener Identität, einem Sicherheitsprinzipal (IIS APPPOOL\<AppPoolName>). Diesem Prinzipal kann man Rechte auf NTFS-Ebene und der lokalen Gruppenrichtlinie (GPO) erteilen. Beim Anlegen eines App Pools wird die Identität automatisch der lokalen GPO hinzugefügt und diversen Privilegien – bspw. Anmelden als Dienst – zugewiesen. Zusätzlich ist sie automatisch Mitglied der Sicherheitsgruppe IIS_IUSRS. Das stellt den Zugriff auf notwendige Systemressourcen sicher.

Des Weiteren kann diese Identität für den Zugriff auf das Webseiten-Verzeichnis verwendet werden. Standardmäßig wird der IUSR-Account für anonyme Zugriffe verwendet. Damit ist aber auch der Zugriff auf die Verzeichnisse anderer Webanwendungen möglich. Die Änderung erfolgt über das Authentifizierungsmodul der jeweiligen Webseite.

Ist alles korrekt konfiguriert, prüft man abschließend über den Taskmanager den vom Worker Process verwendeten Benutzernamen. Im folgenden Screenshot sieht man ferner, dass der PHP Prozess über den Worker Prozess und dessen Sicherheitsprinzipal gestartet wurde. Ist kein Worker Process zu sehen, rufe die Webseite auf, damit er geladen wird.

Eine weitere Empfehlung ist die Verlagerung das Webseiten-Verzeichnis auf einen separaten Datenträger. Sollte es wider Erwarten gelingen auf das Dateisystem zuzugreifen, kann man sich davor schützen, dass wichtige Systemdateien durch schadhafte Kopien ersetzt werden, wenngleich das Risiko in den neuesten Server Versionen praktisch nicht vorhanden ist. Aber auch das blinde Vollschreiben des Laufwerks hat dadurch keine Auswirkung auf den Serverbetrieb. Die Webseite funktioniert möglicherweise nur eingeschränkt, aber der Webserver läuft problemlos weiter. Der Pfad wird über die Eigenschaften der Webseite angepasst.

Es empfiehlt sich, die NTFS-Rechte der Identität auf das Webseiten-Verzeichnis einzuschränken. Meist reichen Leserechte aus um Webseiten auszuliefern. Ausnahmen bilden CMS mit integrierter Updatefunktion oder Plugins mit notwendigen Schreibrechten. Setze nur auf die Ordner Schreibrechte, die wirklich notwendig sind. Welche, darüber informiert meist die mitgelieferte Dokumentation. Es ist der Benutzername IIS APPPOOL\<App Pool Name> zu wählen, um die Identität der DACL hinzuzufügen.

Tipp

Mangelnde Zugriffsrechte auf dem Dateisystem sind häufig Ursache für den gefürchteten Serverfehler 500. Der PHP-Interpreter benötigt ab der obersten Dateisystemebene, in diesem Beispiel D:\ mindestens das Recht Ordner auflisten. Im Webroot-Verzeichnis, hier D:\sites\privalnetworx, erweitert man die ACL um die Read & Execute-Rolle.

Jede Webseite verfügt über mindestens eine Bindung, einem Listener, der über konfigurierte Ports angesprochen wird, typischerweise tcp/80 (HTTP) für unverschlüsselte und tcp/443 für verschlüsselte Kommunikation (HTTPS). Bei verschlüsselten Verbindungen mittels HTTPS, werden sowohl die übermittelten Daten vor Mitlesen (Datenschutz) und Veränderung (Datenintegrität) geschützt. Zudem bietet der TLS-Verbindungsaufbau die Garantie, dass es sich bei der Webseite tatsächlich um die gewünschte Webseite handelt (Authentizität).

Auch wenn man die eigenen Daten als nicht schützenswert betrachtet, so sollte man dennoch unbedingt ein Zertifikat einsetzen. Sie schützen vor Manipulation durch Man-In-The-Middle- (MITM-) Attacken, durch die bspw. Schadsoftware verteilt, auf dubiose Webseiten umgeleitet oder mit Werbung versehen werden. Kommerzielle Zertifikate müssen nicht viel kosten, zumal kostenlose Zertifikate bei bspw. Lets Encrypt erhältlich sind. Schau dir auch diesen Artikel an. Diese deutschsprachige Seite erläutert den Prozess zum Ausstellen eines Lets Encrypt-Zertifikats über das ACME-Protokoll und die Powershell.

Wurde ein Zertifikat eingebunden, so sollte man die Webanwendung ausschließlich via HTTPS ausliefern. Kommen Anfragen über unverschlüsseltes HTTP an den Server, ist eine Weiterleitung auf HTTPS sinnvoll. Dabei hilft das HTTP Redirection-Modul, welches ggf. mittels Servermanager nachinstalliert werden muss. Ein Neustart des Servers ist dafür nicht erforderlich.

Entferne die HTTP-Bindung der aktuellen Site und richte eine neue Webseite für die Umleitung ein, füge die HTTP-Bindung hinzu, wähle als Wurzelverzeichnis ein neuen Ordner aus. Nutze nicht das vorhandene Verzeichnis, da sonst die dort liegende Konfiguration angepasst wird, was sich auf die bestehende Webanwendung auswirkt.

Nicht vergessen, die anonyme Authentifizierung auf den Anwendungspool zu ändern und die Rechte des neuen Anwendungspools auf das neue Verzeichnis zu setzen.

Nun wird die Umleitung auf der neuen Webseite aktiviert.

Der Webserver liefert, neben dem sichtbaren Inhalt, über die HTTP Response Header zusätzliche Metadaten aus. Darüber übermittelt der Server dem Client zusätzliche Information. Das können Angaben über die verwendete Webseitensprache, Caching Informationen oder dem zu übermittelten Inhaltstyp (MIME-Type) sein. Ferner gibt es auch sicherheitsrelevante Header. Diese sollte man nach Möglichkeit einsetzen.

Am einfachsten zu implementieren ist HSTS (HTTP Strict Transport Security). Dieser Standard erzwingt die Verwendung verschlüsselter Verbindungen, sofern HTTPS verfügbar ist. Über den Headerwert max-age wird mitgeteilt, wie lange (in Sekunden) der Browser sich merken soll, dass HTTPS zwingend genutzt werden soll. Mit der optionalen Angabe includeSubDomains wird angegeben, dass diese Einstellung auch für Subdomänen gilt. Beachte, dass in solchen Fällen der Header-Wert für die Second-Level Domain (SLD) zu setzen ist, sprich prival.de statt www.prival.de, denn www ist bereits eine Subdomäne der SLD prival.de. Über preload kann zudem angegeben werden, dass die Preload-Liste mancher Browser-Hersteller (Google, Firefox) zu nutzen ist, damit es zu keiner einzigen unverschlüsselten HTTP-Verbindung kommt.

Ein schwierigeres Thema stellt Content Security Policy (CSP) dar. Hierüber wird angegeben, von welchen Quellen welche Art von Content (bspw. CSS, Datenobjekte, Scripte, etc.) in die Webanwendung eingebunden werden darf. Stimmen Quellen und Typen nicht mit der gesetzten Policy überein, wird das Laden des betroffenen Inhalts durch den Browser unterbunden. Alle erlaubten Ressourcen bleiben davon unberührt und werden geladen. Aufgrund der Komplexität, gehe ich in diesem Artikel nicht weiter darauf ein, es würde schlicht den Rahmen sprengen. Es gibt gute Anleitungen im Netz, bspw. dieses Tutorial oder diese Mozilla Dokumentation. Für WordPress gibt es ein paar Plugins, zu empfehlen ist WP Content Security Policy Plugin, allerdings wird es nicht mehr weiterentwickelt.

Vorausgesetzt alle Daten stammen vom selben Webserver, ist eine einfache und wirkungsvolle Policy, Content unabhängig vom Scheme (http, https…) nur vom ursprünglichen Host zu laden.

Content-Security-Policy default-src 'self'

In diesem Fall werden Daten von fremden Quellen nicht nachgeladen werden. Das wird mit Bootstrap-Frameworks oder bei CDN-Providern ausgelagerte Ressourcen zu Problemen führen. Um nur sichere Verbindungen zuzulassen, nutzt man daher:

Content-Security-Policy default-src https:

Noch besser ist allerdings, nur verschlüsselte Verbindung von der Quelle zuzulassen. In Kombination mit HSTS ist das der beste Weg.

Content-Security-Policy default-src https://www.privalnetworx.de

Der Response Header X-Content-Type-Options gibt an, dass der vom Server ausgelieferte MIME-Type gefolgt und nicht geändert werden sollte. Der Header wurde von Microsoft eingeführt und soll verhindern, das nicht ausführbarer Inhalt zu ausführbaren umgewandelt wird. Der Wert nosniff aktiviert diesen Schutzmechanismus für Skripte und Styles. Am besten setzt man den Header gleich auf Serverebene, so dass alle Webseiten diesen Wert erben.

Die Header lassen sich in jedem Browser mit eingebauten Entwicklungswerkzeugen testen. Hier ein Auszug über die IE’s F12 beim Aufruf einer durch Header geschützten Seite.

Wer sich die Response Header genauer ansieht, entdeckt, dass manch eine Information übermittelt wird, die man evtl. nicht oder nicht im Detail ins Internet schicken möchte. So übermittelt PHP in der Standardeinstellung seine aktuelle Version – darauf gehe ich im dritten Teil des Tutorials ein – oder der IIS seine Serverversion. Letzteres lässt sich über eine URL Rewrite-Regel anpassen.

<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Change RESPONSE_Server" >
        <match serverVariable="RESPONSE_Server" pattern=".+" />
        <action type="Rewrite" value="Microsoft-IIS“ />
      </rule>
    </outboundRules>
  </rewrite>
</system.webServer>

Eine Bedrohung, die den Betrieb des Webservers als solchen zum Ziel hat, sind (D)DOS-Attacken, (Distributed) Denial of Service. Also (verteilte) Angriffe auf den Webserverdienst, bis dieser den Geist aufgibt. Davor schützt man sich am besten mit dem IIS-Modul IP and Domain Restrictions, welches über den Servermanager nachinstalliert werden muss.

Damit wird es möglich, die Anfragen von Clients zu reglementieren. Das bremst zudem Brute Force-Angriffe ein, die über Wörterbuch-Attacken blind diverse Logins versuchen. Üblicherweise werden dabei die Benutzernamen admin, root, administrator, user bzw. usr, gast, oder das englische Äquivalent guest, ftp, upload, service genutzt und dem Server mit Millionen von Kombinationen aus Zeichen und Ziffern als Passwort konfrontiert. Gelegentlich sah ich in den Logs auch den Namen der Webseite in verschiedenen Kombinationen. Also, neben dem Umbenennen, oder noch besser, dem Deaktivieren des Administrator- und Gastkontos, kann durch Nutzen starker Passwörter weiter an der Sicherheitsschraube gedreht werden. Nutze Kennwortrichtlinien, um ggf. nach einer spezifischen Anzahl an fehlerhaften Login-Versuchen, das betreffende Konto zumindest vorübergehend zu sperren.

Zurück zur Konfiguration der IP and Domain Restrictions. Die Funktion kann sowohl auf Server- wie auch auf Site-Ebene aktiviert und angepasst werden. Die Standardwerte sind für eine typische Webseite ausgelegt.

Wird ein Wert überschritten, sendet der Server einen 403-Fehler (Forbidden) zurück.

Über das Request Filtering-Modul lassen sich Zugriffe auf Dateien oder bestimmten Dateitypen unterbinden. Ferner können URL-Sequenzen gesperrt werden. Um bspw. ein Directory Traversal zu unterbinden, hilft folgender Eintrag.

Der Server sollte auf unsichere Verschlüsselungsalgorithmen geprüft und deaktiviert werden. Dabei helfen spezielle Webseiten wie SSL Labs oder SSL-Tools. Zum Ändern der Protokolle und Cipher Suiten hilft das Programm IISCrypto, welches ohne großes Fachwissen auskommt und sich speziell an den IIS richtet. Sehr empfehlenswert.

Nach dem Ändern der Einstellung, muss der Server neu gestartet werden. Im Anschluss sollte der Server auf Funktion getestet und erneut über einen SSL Check geprüft werden. Es ist zu empfehlen, diesen Vorgang in unregelmäßigen Abständen zu wiederholen.

Der Webserver sollte kein Mitglied oder gar ein Domänencontroller einer Active Directory-Domäne sein. Das Betriebssystem immer aktuell zu halten, ist eine wichtige, monatlich wiederkehrende Aufgabe. Durch Deinstallation nicht verwendeter Rollenfeature, verringert man die Angriffsfläche. Dienste sind zu deaktivieren, die keine Verwendung finden. Der Sicherheit wie der Performance förderlich, ist das Deaktivieren von nicht verwendeten Modulen und Handler. Hat man zu viele gelöscht, lassen sich alle Einträge mittels „Revert to parent“ wiederherstellen.

Über Logging lassen sich ungewöhnliche Vorgänge und Angriffe erkennen, vorausgesetzt, sie werden regelmäßig gesichtet. Ich habe es mir zudem angewöhnt, die IP-Adressen, oder das ganze Subnetz eines fremdsprachigen Landes wie China oder Russland, von besonders hartnäckigen Angreifern, über eine Block-Regel in der lokalen Firewall auszusperren. Netzwerkinformationen lassen sich über einen Whois-Dienst ermitteln. Für den kommerziellen, professionellen Internetauftritt bieten sich diverse Anwendungen an, die als Web Application Firewall in den IIS integrieren werden.

Ein administrativer Fernzugriff auf den Server mag sicher ganz bequem sein, öffnet aber Tür und Tor für zwielichtigen Besuch. Optimal ist es, den administrativen Zugriff auf die lokalen Netzwerke zu beschränken. Im besten Fall kommt zudem eine Zwei-Faktor-Authentifizierung zum Einsatz.