Bundesamt für Sicherheit in der Informationstechnik

M 4.360 Sichere Konfiguration eines Webservers

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Nachdem ein Webserver-Dienst auf einem Webserver installiert wurde, muss eine sichere Grundkonfiguration vorgenommen werden. Dies betrifft beispielsweise, wie zusätzliche Module eingebunden werden können und wie auf Verzeichnisse innerhalb und außerhalb des Dateisystembereichs mit den veröffentlichten Informationen zugegriffen werden kann, aber auch Einstellungen, die auf die Performance des Servers Einfluss haben.

Zuordnung zu einem unprivilegierten Benutzer

Wird eine Webserver-Anwendung gestartet, erhält sie in der Regel die gleichen Zugriffsrechte wie der Benutzer, der die Anwendung aufgerufen hat. Startet beispielsweise ein Administrator, der alle Informationen im Dateisystem des IT-Systems lesen und schreiben darf, die Anwendung, kann der Webserver-Prozess auf diese Informationen ebenfalls lesend und schreibend zugreifen. Daher sollte der Webserver-Prozess einem unprivilegierten Benutzerkonto zugewiesen werden. Die Zugriffsrechte im Dateisystem des IT-Systems sollten restriktiv vergeben werden, so dass dieses Benutzerkonto und somit der Webserver-Prozess nur auf benötigte Informationen zugreifen darf.

Dennoch ist es oft nötig, den Webserver-Dienst als privilegierten Benutzer ("root") zu starten. In diesem Fall sollte, wenn möglich, der Prozess nachträglich einem unprivilegierten Benutzer zugeordnet werden. Beim Apache-Webserver kann beispielsweise mit einer User-Direktive in der Konfigurationsdatei eine Benutzerkennung angegeben werden, unter der der Serverprozess als unprivilegierter Benutzer ausgeführt wird.

Server-Verzeichnisse

Je nach eingesetzter Webserver-Anwendung müssen die Dateisystempfade angegeben werden, auf die der Webserver zugreifen darf. Dazu gehört beispielsweise der Dateisystempfad zu dem Verzeichnis mit den Informationen, die der Webserver den Clients zur Verfügung stellen soll (" WWW -Wurzelverzeichnis") und der Pfad zu den Protokollierungsdateien.

Wird das WWW-Wurzelverzeichnis festgelegt, ist darauf zu achten, dass sich innerhalb des Verzeichnisses nur Informationen befinden, die allen potentiellen Benutzern zur Verfügung gestellt werden sollen. Der Zugriffsbereich für Benutzer des Webservers sollte nicht zu groß gewählt werden. Beispielsweise sollten Benutzer keinen Zugriff auf das Root-Verzeichnis ("/") eines Unix-Systems oder die System-Partition eines Windows-Systems erhalten. Das Verzeichnis, in dem die abrufbaren Dateien gespeichert sind, sollte sich auf einer eigenen Partition oder Slice einer Festplatte befinden, um eine leichtere Wiederherstellung nach einem Festplattenschaden zu ermöglichen.

Der Webserver-Dienst sollte generell nur auf Informationen zugreifen dürfen, die sich innerhalb des WWW-Wurzelverzeichnisses befinden. Der lesende und insbesondere schreibende Zugriff auf Informationen außerhalb des WWW-Wurzelverzeichnisses sollte verhindert werden. Daher sollte auf Dateisystemverweise ("Links") auf Bereiche außerhalb des WWW-Wurzelverzeichnisses verzichtet werden. Wenn möglich, sollte der Webserver-Dienst so konfiguriert werden, dass nicht auf Informationen außerhalb des WWW-Wurzelverzeichnisses zugegriffen werden kann, beispielsweise durch einen Limit-Abschnitt beim Apache-Webserver.

Schreibrechte

Der Prozess des ausgeführten Webserver-Dienstes sollte nur über jene Rechte verfügen, die für den Betrieb erforderlich sind. Die Zugriffsrechte eines Webserver-Prozesses werden in der Regel von den Zugriffsrechten des Benutzers, der den Webserver-Prozess gestartet hat, abgeleitet. Normalerweise benötigt ein Webserver-Prozess keine Schreibrechte im Betriebssystem und sollte deshalb diese auch nicht besitzen. Werden Protokollierungsdateien an einen dedizierten Protokollierungsserver übermittelt, sind hierfür in dem Dateisystem des IT-Systems, auf dem der Webserver aufgerufen wurde, keine lokalen Schreibrechte notwendig (Ausnahme: Informationen müssen zwischengespeichert werden, wenn der Protokollierungsserver nicht erreichbar ist). Alle Dateien, die nicht mehr verändert werden sollen, wie beispielsweise statische HTML-Seiten, sollten mit einem Schreibschutz versehen werden. Falls der Webserver-Dienst automatische Verzeichnislisten generieren kann, sollte diese Funktion deaktiviert werden.

Einschränken der Prozesse

Ein Webserver-Dienst sollte in einer einer eingeschränkten Prozessumgebung betrieben werden, z. B. mittels "chroot" bei Unix-Systemen. Bei einer chroot-Umgebungen handelt es sich um einen abgeschotteten Bereich innerhalb des Computersystems, wie eine sogenannte Sandbox, die es einem Angreifer erschwert, nach der Kompromittierung des Webservers-Dienstes Zugriff auf das gesamte System zu erlangen. Vertiefende Informationen hierzu sind in M 4.198 Installation einer Applikation in einem chroot Käfig zu finden.

Informationen über den Server

Standard-Fehlermeldungen bergen oft die Gefahr in sich, zu viel Information preiszugeben. Aus den HTTP -Header-Zeilen von Antworten auf Anfragen oder von Fehlermeldungen können Angreifer oft Informationen über die Version der eingesetzten Server-Software und andere Details gewinnen. Diese Informationen können dann eventuell dazu genutzt werden, um bestimmte Angriffsmethoden auszuwählen und so schneller den Server zu kompromittieren. Daher sollten auf diesen "Seitenkanälen" so wenig Informationen wie möglich geliefert werden, indem eigene Fehlermeldungen konfiguriert werden, die die Benutzer über einen aufgetretenen Fehler informieren, aber keine Details dazu preisgeben.

Authentisierung

Um Zugriffsbeschränkungen auf Webservern oder für einzelne Bereiche des Webangebots einzurichten, gibt es verschiedene Möglichkeiten, die teilweise bereits im Webserver-Dienst selbst implementiert sind oder über Erweiterungsmodule eingebunden werden können. Oft wird der Zugriff gesteuert, indem der Zugriff auf bestimmte IP-Adressbereiche oder Domains (beispielsweise im Intranet) beschränkt wird oder indem sich Benutzer vor dem Zugriff auf bestimmte Ressourcen authentisieren müssen, z. B. über Benutzernamen und Passwort (siehe auch M 4.176 Auswahl einer Authentisierungsmethode für Webangebote ).

In Abhängigkeit der Anwender (z. B. nur eigene Mitarbeiter, Kunden oder Benutzer, die sich vorher zwar registrieren müssen, aber ansonsten unbekannt sind), die auf den Webserver zugreifen dürfen und des Schutzbedarfs der bereitgestellten Informationen, sollten die Zugriffsrechte auf ein Minimum beschränkt werden. Generell sollten die Benutzer nur auf die erforderlichen Informationen zugreifen dürfen. Eine Ausnahme sind öffentliche Webserver, auf dessen WWW-Inhalte oft jeder interessierte Anwender zugreifen darf, wie beispielsweise ein öffentlicher Webserver im Internet.

Verschlüsselung der Datenübertragung

In der Regel werden die Informationen zwischen einem Webserver-Dienst und den Clients über HTTP übertragen. Bei HTTP handelt es sich um ein Klartextprotokoll, bei dem alle übertragenen Daten, wie Passwörter und Webinhalte, von einem möglichen Angreifer mitgelesen werden können. Daher wird dringend empfohlen, die Integrität und Vertraulichkeit von sensiblen Informationen zwischen Webserver-Dienst und Client zu schützen, beispielsweise indem Verschlüsselungsprotokolle wie Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) verwendet werden. Vertiefende Informationen sind unter M 5.66 Clientseitige Verwendung von SSL/TLS zu finden.

Administration

Webserver-Dienste werden oft mittels Konfigurationsdateien oder über graphische Oberflächen administriert, lokal oder über eine Netzverbindung. Wird das IT-System mit dem Webserver-Dienst über eine Netzverbindung administriert, ist der Netzzugang und der Informationsaustausch zwischen dem Webserver und dem IT-System, von dem aus der Webserver administriert wird, zu schützen. Dazu gehört, dass der Administrationszugang beschränkt werden sollte, beispielsweise indem durch Paketfilter alle Verbindungsanfragen außer von definierten IT -Systemen der Administratoren auf die Portnummer des Fernadministrationsdienstes abgewiesen werden (siehe M 4.238 Einsatz eines lokalen Paketfilters ). Damit der Informationsaustausch nicht abgehört oder geändert werden kann, muss dieser verschlüsselt werden, beispielsweise über SSH (siehe M 5.64 Secure Shell ).

Werden Applikationen oder Weboberflächen eingesetzt, die die Konfiguration erleichtern, sind diese ebenfalls vor dem Zugriff von unberechtigten Personen zu schützen.

Deaktivierung von unnötigen Diensten

Die Standardinstallation eines Webservers-Dienstes kann eine Reihe von Netzdiensten umfassen, die nicht immer benötigt werden und die gerade deswegen eine Quelle von Sicherheitslücken sein können. Ein Beispiel ist eine Weboberfläche zur Webserver-Konfiguration, die nicht benötigt wird, wenn der Webserver-Dienst über andere Mechanismen konfiguriert wird. Daher sollte überprüft werden, welche Netzdienste auf dem IT-System mit dem Webserver-Dienst installiert und aktiviert sind. Nicht benötigte Netzdienste sollten deaktiviert oder ganz deinstalliert werden.

Beschränkung der Konnektivität

Obwohl es sich in der Regel bei Webservern um IT-Systeme handelt, auf die viele Benutzer zugreifen dürfen, sollte dennoch die Kommunikation nur so restriktiv wie möglich erlaubt werden. Werden Netzdienste auf dem Server betrieben, die nur von ausgewählten IT-Systemen mit festen IP-Adressbereichen genutzt werden sollen, empfiehlt es sich, den Zugriff auf bestimmte IP-Adressen mit Paketfiltern zu beschränken. Der Zugriff auf Administrationszugänge sollte generell durch Paketfilter auf die IT-Systeme der Administratoren beschränkt werden. Werden Datenbanken oder Applikationsserver eingesetzt, ist diese Kommunikation ebenfalls zu beschränken. Vertiefende Informationen zu Paketfiltern sind unter M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken und M 4.238 Einsatz eines lokalen Paketfilters zu finden.

Sollen die Webserver nur von internen Mitarbeiter genutzt werden dürfen, sollten die Webserver in einem Netzsegment betrieben werden, auf das nur aus dem LAN zugegriffen werden kann. Sollen auch externe, beziehungsweise fremde Benutzer Informationen vom Webserver abrufen können, empfiehlt es sich, den Webserver in einer demilitarisierten Zone zu betreiben.

Protokollierung

Zugriffe auf den Webserver-Dienst und das IT-System, auf dem der Webserver-Dienst installiert ist, sollten in dem Umfang protokolliert werden, wie es nötig ist, um Angriffe, Angriffsversuche und Sicherheitsverletzungen zeitnah erkennen und gegebenenfalls verfolgen zu können. Daher ist zu entscheiden, welche Informationen protokolliert werden sollen, wie und zu welchen Zeitpunkten die Protokolldaten auszuwerten sind und wann diese zu löschen sind. Der Webserver-Dienst und das IT-System sind entsprechend zu konfigurieren. Personenbezogene Daten dürfen nur in dem Umfang mitprotokolliert werden, in dem dies gesetzlich zulässig ist. Um abzuklären, was hier zulässig ist, sollte daher der Datenschutzbeauftragte beteiligt werden.

Löschen von Beispieldokumenten

Oft werden bei der Installation von Webservern Beispieldokumente mit installiert. So kann beispielsweise der Administrator direkt nach der Installation mit einem Browser auf den Webserver zugreifen, ohne vorher eigene Webinhalte entworfen zu haben. Wird eine vorhandene Beispiel-Index-Datei angezeigt, kann der Administrator auf den ersten Blick sehen, ob der Webserver korrekt installiert wurde. Oft beinhaltet die Beispiel-Index-Datei auch Informationen zu dem eingesetzten Webserver, wie die Versionsnummer.

Oft gibt es auch serverseitige Programme ( CGI -, Perl- oder PHP-Skripte), die ebenfalls mit installiert werden. Aktiviert der Administrator die entsprechenden Module, die es ermöglichen, diese Skripte auszuführen, kann er direkt überprüfen, ob das Modul einwandfrei funktioniert.

Alle Beispiel-Dokumente und -Skripte sollten nach der Installation entfernt werden.

Erweiterung mit Modulen

Der Funktionsumfang von einigen Webserver-Diensten kann durch sogenannte Module erweitert werden. Funktionen, die von den Entwicklern der Webserver-Dienste nicht vorgesehen wurden, können so nachträglich hinzugefügt werden. Beispielsweise können über Erweiterungsmodule Applikationen direkt auf dem Webserver ausgeführt werden und so Seiteninhalte dynamisch erzeugt werden. Beispiele hierfür sind PHP und Perl, bei denen im Gegensatz zu "Aktiven Inhalten" die Applikationen nicht auf den Client des Benutzers ausgeführt werden (siehe auch M 5.69 Schutz vor aktiven Inhalten ).

Wird die Funktionalität des Webserver-Dienstes mit Hilfe von Modulen erweitert, so müssen diese denselben Anforderungen wie der Webserver-Dienst selbst genügen. Zudem müssen Module nach dem Minimalprinzip ausgewählt werden. Module, die als Beispiele vom Webserver mit installiert werden und nicht benötigt werden, sollten gelöscht werden.

Sowohl Webserverdienste als auch die Module werden in der Regel permanent weiterentwickelt und als eigene Versionen veröffentlicht. Eine Version eines Moduls, das vorher auf einer konkreten Version eines Webserver-Dienstes fehlerfrei ausgeführt werden konnte, kann unter einer späteren Version des Webserver-Dienstes zu Problemen führen. Auch eine aktuellere Version eines Moduls kann anderes als eine ältere Version auf einem Webserver-Dienst reagieren. Daher muss neben der Version des Serverdienstes, die eingesetzt werden soll, auch die konkrete Version des Moduls getestet werden.

Für manche Webserver-Dienste gibt es spezielle Sicherheitsrahmenwerke (z. B. mod_security für Apache), mit denen verschiedene Sicherheitsfunktionen implementiert werden können, um beispielsweise Eingaben zu filtern. Einzelne Sicherheitsfunktionen lassen sich zum Teil auch mit anderen Erweiterungen für Webserver-Diensten realisieren. So kann beispielsweise mit dem Modul mod_rewrite Anfragen regelbasiert weitergeleitet und somit gefiltert werden. Es ist zu entscheiden, ob und welche Sicherheitsrahmenwerke eingesetzt werden sollen.

Aktive Inhalte

Interaktive Funktionen in Web-Angeboten können auch durch Aktive Inhalte umgesetzt werden, die auf dem Client-System ausgeführt werden. Soweit es möglich ist, sollten diese Funktionalitäten mit dynamischen oder statischen Inhalten bereitgestellt werden.

Die verschiedenen Techniken, die unter dem Oberbegriff "Aktive Inhalte" zusammengefasst werden, unterscheiden sich unter anderem durch die Art, wie sie in eine HTML-Seite integriert werden. Code von Skriptsprachen wie JavaScript, JScript oder VBScript wird im Textformat direkt in den HTML -Code eingefügt oder in einer aus dem HTML-Code aufgerufenen Datei abgelegt. Als weitere Möglichkeit kann ausführbarer Code in eine HTML-Seite integriert werden, indem er im HTML-Code referenziert und über vorkompilierte Programm-Module wie Java-Applets oder Active-X-Controls aufgerufen wird.

Eine neue Technik im Bereich der Aktiven Inhalte ist AJAX (Asynchronous JavaScript and XML), das auf JavaScript und XML -basiert. Häufig wird auch Flash zu den Aktiven Inhalten gezählt, da in den neueren Versionen der Funktionsumfang von Flash über die Darstellung reiner Animationen hinausgeht und es damit nicht mehr nur als Plug-In betrachtet werden kann.

Aktive Inhalte bringen dadurch, dass auf dem Client-System "fremder" Code ausgeführt wird, eine Reihe von Sicherheitsproblemen mit sich. Browser-Hersteller und Anbieter von Plug-Ins versuchen zwar, diese Probleme durch Maßnahmen wie eingeschränkte Rechte für Java-Applets, Active-X Controls oder andere Plug-Ins zu begrenzen, trotzdem zählen Bedrohungen im Zusammenhang mit Aktiven Inhalten derzeit zu den häufigsten. Diese Bedrohungen sollten ein Webseiten-Anbieter im Blick behalten, wenn er in seinem Angebot Aktive Inhalte benutzt.

Betriebssystem

Eine sichere Konfiguration des Betriebssystems, auf dem der Webserver-Dienst installiert wurde, ist eine Grundvoraussetzung, um Informationen auf Webservern sicher bereitstellen zu können. Grundsätzlich sollten auf einem IT-System nur jene Dienste und Applikationen installiert sein, die für den Betrieb erforderlich sind. Dies bedeutet, dass eine Vielzahl nicht benötigter Applikationen (wie beispielsweise Compiler oder Editoren) entfernt werden sollten. Nach außen sollten auch nur die Dienste sichtbar sein, die für den Betrieb unbedingt benötigt werden (siehe M 5.95 Sicherer E-Commerce bei der Nutzung von Internet-PCs ).

Um möglichst wenig Information über das Betriebssystem und die darauf befindlichen Dienste preiszugeben, kann Banner-Spoofing verwendet werden. Dabei liefern die auf dem Server betriebenen Dienste nicht ihre korrekte Programmbezeichnung und Versionsnummer zurück, sondern ersetzen diese durch Falschinformationen. Dadurch ist es für einen Angreifer schwieriger, Rückschlüsse auf die tatsächlich vom System verwendeten Programme zu ziehen. Auch müssen alle Standard-Benutzerkonten entfernt beziehungsweise umbenannt werden. Ein Beispiel dafür ist das unter Windows-Betriebssystemen oftmals vorhandene Gastkonto. Privilegierte Benutzerkonten, wie "Administrator" oder "root", sollten deaktiviert und stattdessen eigene Benutzer mit den notwendigen administrativen Rechten angelegt werden.

Prüffragen:

  • Wurde auf dem Webserver eine sichere Grundkonfiguration hergestellt?

  • Kann der Webserver nur auf Informationen zugreifen, die sich innerhalb des WWW -Wurzelverzeichnisses befinden?

  • Kann der Webserver nur lesend auf die abgelegten Informationen zugreifen?

  • Werden die Administrationszugänge zum Webserver geschützt, so dass nur berechtige Administratoren hierauf zugreifen können?

  • Wurde überprüft, welche Netzdienste, Applikationen und Webservermodule auf dem Webserver installiert und aktiviert sind und wurden alle nicht benötigten Dienste, Applikationen und Module deaktiviert oder ganz deinstalliert?

  • Wird in Abhängigkeit der berechtigten Anwender und des Schutzbedarfs der Informationen der Zugriff auf ein Minimum beschränkt?

  • Wird die Integrität und Vertraulichkeit der zwischen Webserver und Client übertragenen Informationen geschützt?

Stand: 12. EL Stand 2011

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK