M 2.174 Sicherer Betrieb eines Webservers
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
WWW-Server sind attraktive Ziele für Angreifer und müssen daher sehr sorgfältig konfiguriert werden, damit sie sicher betrieben werden können. Das Betriebssystem und die Software müssen so konfiguriert sein, dass der Rechner so gut wie möglich gegen Angriffe geschützt wird. Solange der Rechner nicht entsprechend konfiguriert ist, darf er nicht ans Netz genommen werden.
Daher sollte ein WWW-Server, der Informationen im Internet anbietet, entsprechend den folgenden Vorgaben installiert werden:
- Auf einem WWW-Server sollte nur ein Minimum an Programmen vorhanden sein, d. h. das Betriebssystem sollte auf die unbedingt erforderlichen Funktionalitäten reduziert werden und auch sonst sollten sich nur unbedingt benötigte Programme auf dem WWW-Server befinden (siehe M 4.95 Minimales Betriebssystem).
- Ein WWW-Server sollte insbesondere keine unnötigen Netzdienste enthalten, verschiedene Dienste gehören auf verschiedene Rechner (siehe M 4.97 Ein Dienst pro Server).
- Der Zugriff auf Dateien oder Verzeichnisse muss geschützt werden (siehe M 4.94 Schutz der WWW-Dateien).
- Die Kommunikation mit dem WWW-Server sollte durch einen Paketfilter auf ein Minimum beschränkt werden (siehe M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken).
- Die Administration des WWW-Servers darf nur über eine sichere Verbindung erfolgen, d. h. die Administration sollte an der Konsole direkt, nach starker Authentisierung (bei Zugriff aus dem LAN) oder über eine verschlüsselte Verbindung (bei Zugriff aus dem Internet) erfolgen.
- Weiterhin sollte der WWW-Server vor dem Internet durch einen Firewall-Proxy oder aber zumindest durch einen Paketfilter (siehe M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken) abgesichert werden. Er darf sich nicht zwischen Firewall und internem Netz befinden, da ein Fehler auf dem WWW-Server sonst Zugriffe auf interne Daten ermöglichen könnte.
Je nach Art des WWW-Servers bieten sich unterschiedliche Möglichkeiten zum Schutz an. Allen diesen Möglichkeiten gemeinsam ist allerdings, dass der eigentliche Serverprozeß des WWW-Servers, der sogenannte http-Daemon oder http-Dienst, nur mit eingeschränkten Rechten ausgestattet sein sollte. Nicht alle Webserver-Produkte ermöglichen es, den Prozess direkt mit sehr eingeschränkten Rechten zu starten. Je nach eingesetztem Produkt muss daher individuell geprüft werden, wie ein minimales Rechteprofil realisiert werden kann.
Der Webserver-Prozess sollte, wenn möglich, nur auf einen Teil des Dateibaumes zugreifen können. Unter Unix kann dies z. B. mit dem chroot-Programm realisiert werden. Kann ein Angreifer nun eine Schwachstelle über den Webserver-Prozess ausnutzen, so hat er trotzdem keinen Zugriff zum eigentlichen Betriebssystem.
Außerdem sollten vom Hersteller mitgelieferte cgi-Skripte, asp-Dateien oder sonstige serverseitige Programme, die meist nur Beispielcharakter haben, vollständig entfernt werden, da sie oft Schwachstellen enthalten.
Das Verzeichnis, in dem die abrufbaren Dateien gespeichert sind, sollte auf einer eigenen Partition einer Festplatte liegen, um eine leichtere Wiederherstellung nach einem Festplattenschaden zu ermöglichen. Außerdem sollten die Unterverzeichnisse und Dateien einem speziellen Benutzer gehören (zum Beispiel wwwadmin) und durch minimale Zugriffsrechte vor unbefugtem Zugriff geschützt werden.
Bei der Konfiguration der Webserver-Anwendung sollten, unabhängig von der eingesetzten Webserveranwendung, einige grundlegende Aspekte berücksichtigt werden. Wie diese im einzelnen konfiguriert werden, hängt von der Webserver-Anwendung ab.
Meist existieren Optionen, mit denen festgelegt werden kann, ob bei einer HTTP-Anfrage nach einem Verzeichnis (also ohne Angabe eines konkreten Dateinamens), der Inhalt des betreffenden Verzeichnisses aufgelistet werden soll, oder ob stattdessen bestimmte Dateien (beispielsweise index.html) zurückgegeben werden sollen. Dies sollte folgendermaßen konfiguriert werden:
- Falls eine Index-Datei existiert, wird diese zurückgeliefert.
- Falls nicht, wird eine entsprechende Fehlermeldung zurückgegeben.
Falls festgelegt werden kann, dass Programme oder cgi-Skripte nur in bestimmten Verzeichnissen ausgeführt werden dürfen, so sollte diese Option auf jeden Fall sehr eng eingestellt werden. Keinesfalls sollte die Ausführung von Programmen für den gesamten WWW-Bereich freigegeben werden. Es ist empfehlenswert, wenn möglich für Programme und Skripte ein eigenes Verzeichnis anzulegen und die Ausführung nur in diesem Verzeichnis zu gestatten.
Oft kann festgelegt werden, ob Dateien oder Verzeichnisse, die mittels eines symbolischen Links (Unix) oder einer Verknüpfung (Windows) in den WWW-Dateibaum "eingeblendet" wurden, angezeigt werden sollen. Dies sollte möglichst unterbunden werden, da auf diese Weise leicht Dateien zugreifbar werden können, die eigentlich nicht veröffentlicht werden sollen.
Folgende Checkliste wird empfohlen:
- Sind nur die benötigten Komponenten installiert?
- Ist die Webserver-Anwendung so restriktiv wie möglich konfiguriert? Beispielsweise sollten cgi-Programme entweder ganz gesperrt werden oder aber die cgi-Programme auf ein eigenes Verzeichnis beschränkt sein. Der Dateizugriff des Webserver-Prozesses sollte auf einen Teil des Verzeichnisbaums eingeschränkt sein. Für Administration und Betrieb des Servers sollten eigene unprivilegierte Benutzerkennungen verwendet werden.
- Sind alle überflüssigen cgi-Programme, asp-Seiten, sonstige Demo-Anwendungen und WWW-Seiten gelöscht?
- Sind nur die unbedingt nötigen Ports zugänglich (siehe auch M 4.97 Ein Dienst pro Server)? Auf einem Webserver wird der HTTP-Dienst üblicherweise über Port 80 angesprochen. Falls die Administration des Servers oder die Pflege der WWW-Dateien über das Netz erfolgt, können noch weitere Dienste erforderlich sein. In diesem Fall sollte aber der Zugriff auf diese Dienste so restriktiv wie möglich geregelt werden (siehe auch M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken).
- Ist eine angemessene regelmäßige Sicherung des Datenbestandes gewährleistet (siehe Baustein B 1.4 Datensicherungskonzept)?
- Falls cgi-Programme genutzt werden, sind diese ausreichend sicher programmiert? Es dürfen keine Eingabewerte ungeprüft übernommen werden. Es muss sichergestellt sein, dass Buffer-Overflows und Race-Conditions ausgeschlossen sind. In allen Perl-Skripten sollte der Taint-Check aktiviert sein.
- Gibt es eine funktionierende Routine für einen regelmäßigen Integritätscheck (z. B. Tripwire, siehe M 4.93 Regelmäßige Integritätsprüfung)?
- Wird die Konfiguration regelmäßig überprüft? Werden Konfigurationsänderungen dokumentiert?
Beispiel: Aufbau eines einfachen WWW-Servers
Als einfacher WWW-Server wird ein Server betrachtet, bei dem sich die Inhalte einzelner Seiten nur selten ändern, keine cgi-Programme verwendet werden und es keinen besonderen Zugriffsschutz gibt. Die einzelnen WWW-Dokumente werden über einen Datenträger auf den WWW-Server eingespielt. Bei einem solchen Server können alle Systemdateien und auch alle HTML-Seiten mit einem Schreibschutz versehen werden. Ein Angreifer kann bei einem solchen Aufbau zwar noch temporäre Dateien und Protokolleinträge abändern, das System selber aber nicht mehr. Ein solcher Zugriffsschutz sollte durch ein physikalisch schreibgeschütztes Medium realisiert werden, z. B. eine oder mehrere CD-ROMs oder eine schreibgeschützte Wechselplatte. Zumindest aber sollten regelmäßige Integritätsprüfungen (siehe M 4.93 Regelmäßige Integritätsprüfung.
In dem http-Daemon sollten die nicht benötigten Funktionalitäten abgeschaltet werden, wie z. B. die Möglichkeit zum Ausführen von cgi-Skripten. Auf jeden Fall sollten mitgelieferte cgi-Programme entfernt werden.
Bei einer häufig vorkommenden Variante eines einfachen Webservers können die Dokumente mit entsprechenden Berechtigungen auf dem WWW-Server interaktiv abgeändert werden. In diesem Fall ist der Schutz vor unbefugten Veränderungen und eine regelmäßige Integritätsprüfung in kurzen Intervallen besonders wichtig.