Zielgruppe BetriebVersion: GSB10.1Webserver

Damit ist der Webserver prinzipiell für Angreifer aus dem Internet erreichbar und muss gegen deren unterschiedlichen Attacken abgesichert werden. Eine Begrenzung des Risikos, dass der Webserver durch einen Angreifer kompromittiert wird, lässt sich durch konsequente Absicherung des Webservers, durch Konfiguration als Minimalsystem sowie durch ständige Überwachung und Aktualisierung der darauf verwendeten Software erreichen.

Die sichere Konfiguration eines Apache-Webservers umfasst unterschiedliche Themenstellungen. Hierzu zählen zum Einen die Absicherung der Apache-Software selbst, wobei u. a. die Aspekte

• Konfiguration des Apache-Webservers in httpd.conf,
• Vergabe von Dateiberechtigungen im Betriebssystem und
• vom Apache-Webserver genutzte Benutzerkonten

behandelt werden. Eine wesentliche Rolle spielt allerdings auch die Konfiguration der Betriebssystemplattform, auf der der Apache-Webserver aufsetzt. Hier gilt es, die Anzahl der auf dem System ablaufenden zusätzlichen Dienste und Programme und somit die Anzahl der Angriffspunkte zu minimieren.

Der Apache-Webserver - genauer gesagt der Rechner, auf dem der Apache-Webserver abläuft - sollte zudem auf der Netzebene geschützt werden, indem er in ein Firewall-Konzept eingebunden wird.

Härtung des Betriebssystems

Unter einer Härtung des Betriebssystems wird im Folgenden eine Installation und Konfiguration eines Betriebssystems verstanden, bei der das Ziel verfolgt wurde, nur die für den Betrieb des Apache-Webservers notwendigen Funktionalitäten und Programme zur Verfügung zu stellen. Alle zusätzlichen Dienste, insbesondere solche, die über das Netz zur Verfügung stehen, sollten möglichst deaktiviert werden.

Hinweise und Maßnahmen

Prinzipiell ist es empfehlenswert, die Grundinstallation des jeweiligen Betriebssystems ohne Netzanbindung durchzuführen. Anschließend sollte eine entsprechende Absicherung in der Systemkonfiguration vorgenommen werden („Hardening“ des Systems) und die jeweils aktuellen Patches des Betriebssystemherstellers bzw. –distributors sind einzuspielen. Erst dann sollte das System an das Intra- oder Internet angeschlossen werden.

Weiterhin sollten alle Updates oder Patches, die von den entsprechenden Websites der Hersteller heruntergeladen werden, soweit möglich mit Hilfe von Prüfsummen oder elektronischen Signaturen überprüft werden, um sicher zu gehen, dass es sich wirklich um die Originalpakete handelt.

Absicherung des Webservers: Hinweise und Maßnahmen

In den folgenden Kapiteln befinden sich Hinweise und Maßnahmen zum sicheren Betrieb des Webservers Apache auf verschiedenen Betriebssystemplattformen. Diese Hinweise sind weitestgehend aus der „Apache Webserver Sicherheitsstudie“ des Bundesamtes für Sicherheit in der Informationstechnik (BSI) entnommen (vergleiche Veröffentlichungen).

Eingeschränkte Benutzerkennung

Der Webserver sollte mit einer eigenen Benutzer- und Gruppenkennung laufen, falls nicht besondere Gründe dagegen sprechen. Bei UNIX-Standardinstallationen wird dafür oft nobody verwendet. Davon ist im Allgemeinen jedoch abzuraten, da nobody auch für viele andere Dienste verwendet wird. Zum Einen würden diese Dienste bei einem erfolgreichen Angriff auf den Webserver unnötig kompromittiert werden und zum Anderen könnten diese Dienste dann selbst als Ausgangspunkt für einen Angriff auf den Webserver dienen.

Kann der Apache-Server mit einem nicht-privilegierten Port arbeiten, dann kann der Prozess sofort unter der eigenen Benutzer- und Gruppenkennung gestartet werden. Falls der Apache-Webserver den vorgesehenen Standard-Port 80 benutzen soll, muss der Apache-Webserver mit root-Berechtigung gestartet werden. Da für den Apache-Webserver jedoch ein eigenes Benutzerkonto und eine eigene Gruppe angelegt bzw. verwendet werden sollte, muss der Webserver in diesem Fall (mittels der Direktiven User und Group) nach dem Start in diesen Sicherheitskontext wechseln.

Werden virtuelle Hosts im Zusammenhang mit externen Programmen verwendet, sollten entsprechende Benutzerkonten für jeden einzelnen virtuellen Host angelegt werden. Die Directive SuexecUserGroup mit den Argumenten User und Group (in der beim GSB eingesetzten Version 2.0 des Apache-Webservers) sollten mit diesen Konten in jedem VirtualHost Abschnitt eingesetzt werden.

Zugriffsrechte auf Dateien

Bei der Konfiguration der Dateizugriffsrechte sollte darauf geachtet werden, dass das Apache-Verzeichnis und alle darüber liegenden Verzeichnisse dem Benutzer root und einer entsprechenden Systemgruppe gehören. Nur der Systemadministrator darf Schreibzugriff auf diese Verzeichnisse haben.

Gleiches gilt für die Unterverzeichnisse des Apache-Verzeichnisses, die Binärdateien, Konfigurations- oder Logdateien enthalten. In der Installation einer Quellcode-Distribution sind dies bin, conf und logs. Auch die Binärdateien selbst sollten nur von root geschrieben werden können.

Geladene Module

Prinzipiell sollten nur diejenigen Module im Server aktiviert werden, die für den Betrieb des Webservers benötigt werden. Der Grund hierfür ist der Gleiche wie bei der Absicherung des Betriebssystems: Systeme sollten stets möglichst minimal konfiguriert werden, um so das Risiko des Vorhandenseins einer Sicherheitslücke zu minimieren.

Die Module mod_status und mod_info sollten nach Möglichkeit deaktiviert werden, da bei Verwendung dieser Module der Apache-Webserver eine Reihe von Statusinformationen über den Webserver mittels der HTTP-Schnittstelle bereitstellt. Andernfalls ist es eventuell möglich, von außen Details über die Konfiguration des Webservers in Erfahrung zu bringen, die dann als Grundlage für Einbruchsversuche verwendet werden könnten. Wird der Zugriff auf die Statusinformationen aus wichtigen Gründen benötigt, so sollte zumindest eine sehr restriktive Zugangsbeschränkung über entsprechende <location> Direktiven vorgenommen werden.

Basiskonfiguration

Der Zugriff auf alle Dateien des lokalen Rechners über die HTTP-Schnittstelle sollte in der Apache-Konfigurationsdatei über einen Limit Abschnitt für das Wurzelverzeichnis / verhindert werden.

Lediglich der Zugriff auf das Verzeichnis mit den Webdokumenten (z.B. /usr/local/apache/htdocs) sollte wieder mittels eines entsprechenden Limit Abschnitts für eingehende HTTP-Requests wie GET oder HEAD geöffnet werden.

Die Erstellung automatischer Listings durch den Webserver für den Fall, dass kein Verzeichnisindex als HTML-Datei verfügbar ist, sollte abgeschaltet werden (mod_autoindex). Anderenfalls besteht die Gefahr, dass Dateien in einem Webverzeichnis, die nicht zur Veröffentlichung bestimmt sind (etwa temporäre Dateien von Editoren, alte Versionen von Dateien) auf diese Weise zugänglich werden. Ebenso sollte die Option FollowSymLinks des Webservers ausgeschaltet werden, da sonst über symbolische Links Dateien von außerhalb der DocumentRoot über den Web-Dokumentenbaum zugreifbar werden können.

Unter Umständen kann stattdessen die Option SymLinksIfOwnerMatch verwendet werden. Das Überschreiben der Konfigurationseinstellungen durch Einträge in den .htaccess-Dateien sollte so weit eingeschränkt werden, wie dies die Anforderungen des Apache-Einsatzes zulassen.

Apache-Installation in einem chroot-Behälter

Eine Möglichkeit, Serversoftware unter Linux bzw. Unix-Systemen abzusichern, besteht in der Verwendung eines chroot-Behälters. chroot ist ein Systemaufruf, der ein Programm in seinem Zugriff auf einen Teil des Dateibaums beschränkt.

Dies geschieht dadurch, dass alle Zugriffe, die dieses Programm (und die von ihm aufgerufenen Programme) auf das Dateisystem durchführt, relativ zu dem Verzeichnis erfolgen, das beim Aufruf der Funktion chroot angegeben wurde.

Dieses Verzeichnis wird so zur Wurzel eines virtuellen Dateibaums, der als chroot-Behälter oder chroot jail bezeichnet wird.

Neben dem Systemaufruf chroot steht auch ein ausführbares Programm des gleichen Namens zur Verfügung, das zum Start beliebiger Programme in einem solchen chroot-Behälter genutzt werden kann.

Der chroot-Mechanismus bietet eine zusätzliche Sicherheit, die auch dann noch wirksam ist, wenn die im Apache-Webserver implementierten Sicherheitsmechanismen versagen: Durch eine (nach heutigem Kenntnisstand für die aktuelle Version des Apache-Webservers hypothetische) Sicherheitslücke könnte es einem Angreifer gelingen,

• den Apache-Webserver dazu zu bringen, Daten auszuliefern, die dieser entsprechend seiner Konfigurationsanweisungen nicht ausliefern dürfte,
• oder sogar eigenen Programmcode im Prozessraum des Webservers auszuführen.

In diesen Fällen begrenzt der chroot-Behälter den potentiellen Schaden, da der Angreifer in beiden Fällen nur Zugriff innerhalb des chroot-Behälters erhält.

Ein zweiter Vorteil des chroot-Mechanismus besteht in einem zusätzlichen Schutz gegen eine Fehlkonfiguration des Apache-Webservers. Wenn Benutzern des Apache-Webservers zu weitgehende Zugriffsrechte eingeräumt wurden, bietet der chroot-Behälter eine zusätzliche Sicherheit: Der Apache-Webserver kann nur solche Dateien ausliefern, die sich innerhalb des ihm zugänglichen Verzeichnisbaums befinden, der hier auf den chroot-Behälter begrenzt ist.

Hinweis

Die Einrichtung einer chroot-Umgebung ist mit zusätzlichem Aufwand verbunden. Alle für den Betrieb des Webservers benötigten Dateien, einschließlich der benutzten Bibliotheken und der von diesen Bibliotheken benutzten Konfigurationsdateien, müssen in den chroot-Behälter kopiert werden. Zum einen muss ermittelt werden, welche Dateien für den Betrieb des Webservers notwendig sind, zum anderen reicht es nicht aus, diese Dateien einmal in den chroot-Behälter zu kopieren: Bei jeder Änderung des Betriebssystems durch Update oder Konfiguration müssen u. U. auch davon betroffene Dateien im chroot-Behälter angepasst werden.

Auswerten der Log-Dateien

In den Log-Dateien lassen sich Angriffe auf den Webserver feststellen, wenn sie über die HTTP-Schnittstelle erfolgen. Angriffe bzw. Angriffsversuche über andere TCP-Ports und Dienste, die auf demselben Rechner ablaufen, werden in der Regel nicht in den Log-Dateien des Webservers auftauchen.

Angriffsversuche über die HTTP-Schnittstelle erfolgen entweder durch den Aufruf von Skripten bzw. sonstigen externen Programmen oder durch das Senden speziell konstruierter URLs an den Webserver, die bei der Verarbeitung einen Buffer-Overflow erzeugen oder den Webserver in anderer Weise manipulieren sollen.

Schutz auf Netzwerkebene

Auf dem Webserver selbst sollten nur die wirklich benötigten Netzverbindungen möglich sein.

Hinweise und Maßnahmen

Eine Beschränkung der möglichen Netzverbindungen lässt sich auf drei Ebenen erreichen:

• Es kann unterbunden werden, dass auf dem jeweiligen TCP- bzw. UDPPort Dienstprogramme auf eingehende Verbindungen warten.
• Auf dem lokalen Rechner kann ein Paketfilter für die externe Netzschnittstelle so konfiguriert werden, dass IP-Pakete, die an einen bestimmten Port gerichtet sind, nicht angenommen werden.
• IP-Pakete dieser Art können bereits an der Netzschnittstelle eines anderen Rechners vor dem Webserver herausgefiltert werden. Eine Kombination von mehreren dieser Möglichkeiten erhöht die Stabilität der Konfiguration, da gefährliche Pakete dann auch bei einer Fehlkonfiguration einer der Komponenten nicht ans Ziel gelangen.

Die Verwendung eines Paketfilters für die externe Netzschnittstelle des Webservers ist empfehlenswert, da auf dem Webserver mit dem Applikationsserver Tomcat ein lokaler Dienst genutzt wird, der über offene TCP/IP-Sockets kommuniziert. Die Paketfilter des lokalen Rechners müssen dabei so konfiguriert werden, dass zumindest eingehende HTTP-Verbindungen entgegengenommen werden. Weitere TCP- bzw. UDP-Ports müssen bei Bedarf freigeschaltet werden. (Hinweis: Lokale Services kann man prinzipiell auch an die Adresse 127.0.0.1 binden. Da diese Adresse im Internet nicht geroutet wird, könnte so ein zusätzlicher offener, vom Internet her sichtbarer TCP/IP-Socket vermieden werden.)

Sinnvoll ist dabei die Freischaltung der Ports für

• ausgehende Syslog-Daten, falls ein externer Log-Host verwendet wird
• DNS-Abfragen des Webservers,
• Verbindungen zur Zeitsynchronisation über NTP, falls die Systemzeit über NTP aktualisiert wird,
• eingehende SSH-Verbindungen, falls eine Fernadministration des Rechners über SSH vorgenommen wird. (Hinweis: In der Vergangenheit wurden Schwachstellen in SSH wiederholt ausgenutzt, um missbräuchlich administrativen Zugang zu (Web-) Servern zu erhalten. Daher hat die Aktualität der SSH-Konfiguration für die Absicherung des Servers eine besondere Bedeutung).

Die sinnvolle Integration des Apache-Webservers in ein vorhandenes Netz hängt von den spezifischen Anforderungen ab. Ein Webserver, der HTTP-Anfragen aus dem Internet verarbeitet, wird typischerweise in einer so genannten demilitarisierten Zone (DMZ) zwischen zwei Firewalls angesiedelt. In einer solchen Konfiguration kann das Intranet vollständig von Zugriffen aus dem Internet abgeschirmt und Zugriffe aus dem Internet auf den Webserver auf HTTP- / bzw. HTTPS-Ports beschränkt werden.

Datenübertragungen zum Webserver (z. B. zum Hochladen von Dateien) und der Zugang etwa mit Hilfe von SSH können per Paketfilter und in der Apache- Konfiguration auf das Intranet beschränkt bleiben. Zusätzlich ist es in dieser Konfiguration auch möglich, Zugriffe vom Webserver aus auf das Intranet zu unterbinden. Dies bietet einen Schutz für den Fall, dass der Webserver trotz aller Sicherheitsmaßnahmen erfolgreich von außen angegriffen wird.

Ergänzende Maßnahmen

Eine sinnvolle Maßnahme zur zusätzlichen Absicherung von Webanwendungen stellen Application Level Firewalls (auch "Web Shields" genannt) und Intrusion-Detection-Systeme dar.

Intrusion-Detection-Systeme

Intrusion-Detection-Systeme (IDS) verfolgen das Ziel, Angriffe auf Netzressourcen zu entdecken und die jeweiligen Administratoren auf Angriffe oder Angriffsversuche aufmerksam zu machen.

Es lassen sich dabei hostbasierte und netzbasierte Verfahren unterscheiden:

Beim ersten Verfahren überwacht eine auf dem jeweiligen Server installierte Software dessen Konfiguration, Veränderungen an Dateien, eingehende Netzpakete usw. Die Software hat prinzipiell also Zugang zu allen Daten, die den lokalen Host betreffen können. Da die Software allerdings auf dem gleichen System betrieben wird wie die eigentliche Server-Anwendung, kann sie ebenso von einem Angriff betroffen sein wie jede andere auf dem Rechner installierte Software. Im Extremfall kann ein solches Sicherheitssystem sogar eine zusätzliche Sicherheitslücke in die Konfiguration des Servers reißen. Denn wie jede Software kann natürlich auch ein Intrusion-Detection-System Fehler und sicherheitsrelevante Schwachstellen enthalten.

Netzbasierte Intrusion-Detection-Systeme analysieren im Gegensatz dazu nur den IP-Netzverkehr zwischen dem Server und anderen Rechnern. Sie laufen auf speziell für diesen Zweck ins Netz eingegliederten Rechnern. Solchen netzbasierten Intrusion-Detection-Systemen stehen zur Analyse natürlich weniger Daten zur Verfügung als hostbasierten Systemen. Ein Vorteil netzbasierter Systeme ist jedoch die vollständige Trennung zwischen dem Anwendungsserver und dem Intrusion-Detection-System.

Application Level Firewalls

Application Level Firewalls filtern den Datenstrom zwischen Browser und Webanwendung. Tritt ein als unzulässig eingestuftes Eingabemuster auf, wird der Transfer unterbrochen oder auf eine andere, vorher festgelegte Weise reagiert. Eine Application Level Firewalls arbeitet als Proxy im Datenstrom und kennt somit das Protokoll der Anwendung. Grundsätzlich filtern Application Level Firewalls die vom Browser an den Webserver übertragenen Daten. Die Filterung verfolgt dabei das Ziel bei der Datenübertragung die Übermittlung von schadhaftem Code zu verhindern.

mod_security

Im GSB- bzw. Apache-Umfeld ist die frei verfügbare Application Level Firewall mod_security beachtenswert.

Die Application-Level-Firewall mod_security integriert sich als Apache-Modul direkt in den Apache-Webserver. Dadurch hat mod_security „ungestörten“ Zugriff auf alle Komponenten des HTTP-Protokolls.

mod_security ist ein Input-Filter, der mit Regeln ausgestattet werden kann. In den verarbeiteten Verbindungen lässt sich so beispielsweise nach IP-Adressen filtern oder etwa in Variablen-Parametern von PHP-Skripten, Cookie-Namen und Informationen in HTTP-Headern suchen. Auf diese Weise kann mod_security XSS, SQL-Injection, Null-Byte oder Path Traversal erkennen und entsprechend reagieren. Mit den "Advanced Filtering" genannten Techniken kann selektiv auf bestimmte URLs oder auf bestimmte Werte im HTTP-Header reagiert werden.

Der Hersteller ThinkingStone hat den Quellcode unter GPL veröffentlicht, weshalb mod_security bereits Teil der meisten Linux-Distributionen ist, die den Apache-Webserver mitbringen. ThinkingStone selbst bietet den Quellcode als tar.gz-Archiv an. Der Quellcode lässt sich entweder als Dynamic Shared Object (DSO), was einem selbstständigen Apache-Modul entspricht, oder als so genannte Inline-Installation kompilieren, bei der die Quellen von mod_security direkt in die Apache-Quellen integriert werden. Details zu diesem Vorgehen sind in der englischen Dokumentation auf der Website von mod_security zu finden (

Der Performanceverlust durch das Filtern mit mod_security hängt sehr stark vom eingesetzten Regelwerk ab, konkrete Zahlen können nur eigene Tests liefern. Erfahrungsberichte im Web sprechen von einer um rund 10 Prozent erhöhten Systemlast. In der Praxis lässt sich die Performance-Einbuße von mod_security noch verringern, indem statische Anfragen, beispielsweise nach reinen HTML-Dateien, Stylesheets und Bildern mit

SecFilterEngine DynamicOnly

grundsätzlich von der Filterung durch mod_security ausgeschlossen werden