BSI-Forum

Sicherheit des Apache-Webservers
– Teil I

Von Thomas Haeberlen, BSI

Der Apache-Webserver ist der bei weitem am häufigsten eingesetzte WWW-Server, der laut Netcraft-Webserverstatistik [1] im August 2002 auf über 60 Prozent aller betrachteten Webserver im Einsatz war. Er ist unter der so genannten Apache Public Licence als Open Source Software frei verfügbar. Da ein Webserver per se ein öffentlich zugängliches System darstellt, ist die sichere Installation und Konfiguration des Systems und seiner Netzwerkumgebung von großer Bedeutung. Dieser Artikel beschreibt einige grundlegende Maßnahmen zur sicheren Installation und Konfiguration des Apache Webservers, um ein bestimmtes Maß an Sicherheit zu gewährleisten.

Der Apache-Webserver entstand 1995 aus dem bis dahin meistgenutzten Webserver, dem NCSA httpd, der am National Center for Supercomputing Applications (NCSA) der University of Illinois entwickelt worden war. Der bisherige Entwickler, Rob McCool, hatte das NCSA verlassen und die Entwicklung war ins Stocken geraten. Eine Gruppe von Webmastern fand sich damals zusammen, um den "verwaisten" NCSA httpd weiterzuentwickeln. Da dies zunächst in der Form von Patches und Ergänzungen zum NCSA httpd erfolgte, bekam das Produkt den Namen Apache von "A patchy server".

Ende 1995 wurde die Version 1.0 des Apache-Webservers veröffentlicht. Bereits kurze Zeit später begannen erste Diskussionen über die Version 2, die erst 1998 konkretere Formen annahmen. Die erste Alpha-Version des Apache 2 wurde auf der ApacheCon Konferenz im März 2000 vorgestellt, die erste Beta-Version ein Jahr später. Im April 2002 folgte schließlich die erste "Produktionsversion", General Availability Release genannt.

Derzeit zögern viele Webmaster noch immer mit dem endgültigen Umstieg auf die neue Version, obwohl das für Websites, die keine außergewöhnlichen Anforderungen stellen, weitgehend problemlos verlaufen dürfte. Ein möglicher Grund, noch zu warten, ist die Änderung im Modul-API, was neben dem Upgrade des Apache-Webservers selbst auch entsprechend angepasste neue Versionen der verwendeten Module nötig macht. In den verschiedenen IT-Zeitschriften sind in letzter Zeit Artikel über verschiedene Aspekte der neuen Version erschienen [2, 3].

Architektur

In Version 2 hat sich vor allem an der Architektur des Apache-Kerns einiges geändert. Bei der Entwicklung hatten die Autoren das Ziel, die Portierung auf neue Plattformen einfacher zu gestalten, und entwarfen eine modulare Architektur, in der die Apache Portable Runtime eine Abstraktionsschicht zwischen dem unterliegenden Betriebssystem und dem Apache 2.0 darstellt. Die APR stellt für die eigentlichen Apache-Module gewissermaßen ein virtuelles Betriebssystem dar, verwendet aber so weit wie möglich "native" Betriebssystemaufrufe, um eine bestmögliche Performance zu erzielen.

Der Apache 2.0 erlaubt außerdem – je nach Betriebssystem – die Auswahl zwischen verschiedenen so genannten Multiprocessing-Modulen (MPMs), die auf die Architektur des zugrunde liegenden Betriebssystems abgestimmt sind. Unter Unix hat die Administratorin jetzt die Auswahl zwischen dem bisher verwendeten Prefork-Modell, bei dem vom Apache Prozess eine festgelegte Anzahl von Kindprozessen gestartet wird, die anschließend die Bearbeitung eingehender HTTP-Requests übernehmen, und einer Reihe anderer MPMs. Ein Beispiel für ein alternatives MPM unter Unix ist das so genannte Worker-MPM mit einer variablen Anzahl von Prozessen und einer festen Anzahl von Threads pro Kindprozess. HTTP-Anfragen werden dabei von den Threads bearbeitet. Dieses Modell ist besonders für Webserver vorgesehen, die eine hohe Skalierbarkeit benötigen. Es verbraucht bei gleicher Anzahl an Anfragen aufgrund der geringeren Anzahl an Prozessen weniger Ressourcen als das Prefork-MPM (vgl. Abb.).

Prefork-Modell und Worker-MPM des Apache-Webservers

Für andere Plattformen sind entsprechend angepasste MPMs in der Entwicklung oder bereits verfügbar. Aus dem Blickwinkel der Sicherheit ist die Auswahl eines geeigneten MPMs insofern relevant, als sich die verschiedenen Modelle beispielsweise dadurch unterscheiden, was geschieht, wenn bei der Bearbeitung einer Anfrage ein Fehler auftritt. So bleibt beispielsweise ein kritischer Fehler beim Prefork-Modell auf den jeweiligen Prozess beschränkt, während er beim Worker-Modell alle anderen in demselben Prozess ablaufenden Threads mit in den Abgrund reißen kann.

Sicherheit

Der Apache-Webserver hat einen sehr guten Ruf im Bezug auf Sicherheit. Zwar wurden immer wieder Fehler entdeckt, auch solche, die mittelbar zu einer Kompromittierung des Servers führen konnten, jedoch konnten diese Fehler bisher alle in relativ kurzer Zeit behoben werden.

Die Architektur des Apache-Webservers erlaubt es zudem, unter Unix eine direkte Kompromittierung des Servers (Remote Root Compromise) weitgehend zu vermeiden, indem der Server – vereinfacht gesagt – direkt nach dem Start die root-Privilegien weitgehend abgibt und Kindprozesse startet, die in einem unprivilegierten Benutzerkontext laufen. Diese Kindprozesse übernehmen die Beantwortung der HTTP-Anfragen (Requests). Dies unterscheidet den Apache-Webserver von anderen Servern, wie etwa dem DNS-Server Berkeley Internet Name Daemon (bind) oder dem FTP-Server Washington University FTP Daemon (wu-ftpd), die eine lange Geschichte von Remote Root Compromises aufweisen. Auch unter Windows kann der Apache-Webserver analog als Dienst unter einem entsprechend eingeschränkten Benutzerkonto laufen.

Für einen sicheren Betrieb eines Apache-Webservers ist eine Reihe von Punkten relevant:

• Planung des Einsatzes,
• sichere Installation,
• sichere Konfiguration,
• Gewährleistung eines sicheren Betriebs,
• Sicherheitsaspekte beim Einsatz zusätzlicher serverseitiger Software.

Neben der Sicherheit des Servers an sich spielt bei Webservern auch die Sicherheit der angebotenen Informationen eine entscheidende Rolle. Beispielsweise muss verhindert werden, dass nicht für die Öffentlichkeit bestimmte Dokumente plötzlich im WWW eingesehen werden können, weil sie aufgrund einer fehlerhaften Konfiguration des Webservers in den WWW-Dokumentenbaum "eingeblendet" wurden. Solche "Informationslecks" stellen neben den eher technischen Gefährdungen durch Softwarefehler und Einbruchsversuche sicher die größte Gefährdung im Zusammenhang mit dem Betrieb eines WWW-Servers dar.

Das BSI hat mit externer Unterstützung eine umfangreichere Studie zu Sicherheitsaspekten des Apache Webservers [8] erstellt. Diese Studie soll in Kürze im SecuMedia-Verlag veröffentlicht werden. Der vorliegende Artikel basiert in großen Teilen auf Inhalten dieser Studie.

Einsatzplanung

Eine sorgfältige Planung des Einsatzes eines Webservers ist sehr wichtig. Dazu gehören die Festlegung einer Einsatz- und Sicherheitsstrategie und entsprechend die Schaffung entsprechender organisatorischer und technischer Strukturen. Ebenso ist eine klare Regelung der Zuständigkeiten und Prozesse im redaktionellen Bereich erforderlich, um eine hohe Qualität der angebotenen Inhalte sicherzustellen. Diese Themen sind allerdings weitgehend vom gewählten Produkt unabhängig. Näheres findet sich beispielsweise im Kapitel 7.5 des IT-Grundschutzhandbuchs [7].

Sichere Installation

Für die Sicherheit eines Webservers ist in jedem Fall auch die Sicherheit des Serverrechners und des darauf installierten Betriebssystems mit entscheidend. Daher sollten bei der Aufstellung des Serverrechners und der Installation des Betriebssystems die entsprechenden Maßnahmen aus dem IT-Grundschutzhandbuch umgesetzt werden. Dazu gehören beispielsweise die Aufstellung des Systems in einem entsprechend gesicherten Raum, die Beschränkung des Installationsumfangs des Betriebssystems, das Deaktivieren nicht benötigter Dienste, das Löschen nicht benötigter Benutzerkonten und eventuell eine zusätzliche Absicherung des Rechners durch einen lokalen Paketfilter.

Bezug der Software

Der Apache-Webserver kann entweder direkt aus den Quelltexten vom Webserver der Apache Software Foundation (ASF) [4] selbst kompiliert werden oder man kann eine vorkompilierte Binärversion verwenden. Binärversionen sind für eine große Anzahl verschiedener Plattformen direkt von der ASF erhältlich [6] und werden von vielen Betriebssystemherstellern beziehungsweise Distributoren mitgeliefert.

Jede der Installationsmethoden hat – auch aus Sicherheitssicht – ihre spezifischen Vor- und Nachteile. So bietet die Quelltext-Installation stets den aktuellsten Versionsstand, was besonders bei der Behebung von Sicherheitslücken relevant ist. Denn ein Quelltext-Patch oder eine neue Version der Quelltextdistribution ist meist die erste verfügbare Möglichkeit der Fehlerbehebung, während bis zur Erstellung von Binärversionen des Apache-Projektes normalerweise einige Zeit vergeht. Eine Ausnahme ist hierbei Microsoft Windows: Zum einen ist dies eine sehr homogene Plattform im Vergleich zur Vielzahl verfügbarer Unix-Derivate und Linux-Distributionen, zum anderen enthält die Windows-Plattform im Auslieferungszustand keinen Compiler. Es wäre daher für die Mehrzahl der Anwender mit einem großen Aufwand verbunden, den Apache-Quellcode unter Windows selbst zu kompilieren. Aus diesen Gründen wird die Binär-Distribution des Apache-Webservers für Windows von Mitgliedern des Apache-Projektes im Regelfall zeitnah zur Quellcode-Distribution erzeugt.

Was die Aktualität der verfügbaren Software angeht, schneiden die Binär-Distributionen der Hersteller am schlechtesten ab: Aufgrund des zeitlichen Vorlaufs, den eine neue Betriebssystemversion benötigt (Kompilieren und Packen der einzelnen Installationspakete, Erstellen von Dokumentationen und CD-ROM), sind diese Versionen meist etwas älter als die aktuelle Version des Quellcodes.

Die Hauptvorteile der Binär-Distributionen der Betriebssystemhersteller sind (die ersten beiden Punkte treffen dabei auch für Windows zu):

1. Die Installation ist sehr einfach und schnell möglich. Der Apache-Webserver ist gut in die jeweiligen Startvorgänge und an die Verzeichnisstruktur des Systems angepasst.
2. Man erhält eine – speziell im Zusammenspiel mit dem Betriebssystem selbst und seinen installierten Paketen – ausgetestete Installation des Servers.
3. Die Installation von der CD-ROM eines kommerziellen Anbieters bietet eine gewisse Gewähr für die Authentizität des Quellcodes beziehungsweise der Installationspakete.
4. Updates können, sobald sie verfügbar sind, leicht eingespielt werden.

Ein wichtiger Nachteil aller Binär-Distributionen ist jedoch, dass sie naturgemäß keine Auswahl der Module erlauben, die fest in den Apache-Webserver einkompiliert werden sollen. Da ein möglichst "schlanker" Server nicht nur aus Performance-, sondern auch aus Sicherheitsgründen wünschenswert ist, ist die Quelltext-Installation in dieser Hinsicht vorzuziehen. Nicht benötigte Module können dann weggelassen werden und fallen damit auch als potenzielle Sicherheitslücken weg.

Die Hauptvorteile der Quelltext-Distribution sind:

1. Hohe Aktualität der Software bei nicht allzu komplizierter Installation.
2. Flexible Konfiguration: Es kann frei entschieden werden, welche Module in welcher Form in den Apache-Webserver eingebunden werden. Nicht benötigte Module können weggelassen werden.
3. Die Quelltext-Distribution ermöglicht es, den Programmcode vor der Installation manuell zu überprüfen. Dies ist zwar sehr aufwändig, bietet aber auch eine hohe Sicherheit dafür, dass der Quellcode das tut, was er soll, und keine verborgenen Hintertüren enthält.

Integritätsprüfung

Wird die Apache-Webserver-Software nicht von den Installations-CDs eines Betriebssystemherstellers oder -distributors installiert, sondern beispielsweise vom Webserver der ASF oder einem seiner Spiegelserver heruntergeladen, so muss sichergestellt werden, dass es sich wirklich um die unverfälschten Daten handelt. Einfache Übertragungsfehler sind relativ leicht festzustellen: Dazu werden oft Prüfsummen (z. B. MD5) verwendet, deren korrekter Wert auf der entsprechenden Webseite neben den jeweiligen Dateien zur Verfügung steht. Einen wirksamen Schutz gegen Manipulation stellen solche Prüfsummen jedoch nicht dar. Wer Download-Dateien manipulieren kann, kann dies auch mit deren Prüfsumme.

Denkbar sind zum Beispiel direkte Veränderungen an den Dateien oder Manipulationen des Netzzugriffs auf den Webserver mit der Originalsoftware, etwa durch Beeinflussung eines Proxy-Servers. Noch einfacher wäre der Aufbau eines manipulierten Spiegelservers. Dass solche Szenarien nicht realitätsfremd sind, hat ein Vorfall im Mai 2001 gezeigt, bei dem ein Angreifer Zugang zum zentralen Webserver des Apache-Projekts erlangt, aber anscheinend die Software nicht manipuliert hatte [5]. Wesentlich gravierender war ein ähnlicher Vorfall im Juli 2002, bei dem auf dem FTP-Server des Betriebssystems OpenBSD die Distribution des OpenSSH-Pakets verändert wurde. Dank Prüfsummen und digitaler Signaturen wurde dies jedoch schnell bemerkt und korrigiert [6].

Auch die Apache-Entwickler nutzen schon seit längerer Zeit digitale Signaturen für ihre Softwarepakete. Zur Integritätsprüfung eines Downloads wird neben der eigentlichen Archivdatei eine weitere Datei mit deren digitaler Signatur gemäß OpenPGP-Standard bereitgestellt (<Dateiname>.asc). Die öffentlichen Schlüssel der Apache Entwickler befinden sich auf dem ASF-Server in einer Datei namens KEYS. Zur Integritätsprüfung der Distribution ist dann eine OpenPGP-kompatible Software notwendig, etwa PGP (www.pgp.com) oder GnuPG (www.gnupg.org).

~/apache_src > ls
KEYS  apache_1.3.20.tar.gz  apache_1.3.20.tar.gz.asc
~/apache_src > gpg --verify apache_1.3.20.tar.gz.asc
gpg: Unterschrift vom Die 15 Mai 2001 19:15:54 CEST, 
     RSA Schlüssel ID 10FDE075
gpg: Korrekte Unterschrift von "wrowe@covalent.net"
gpg:    alias "William A. Rowe, Jr. <wrowe@rowe-clan.net>"
gpg:    alias "wrowe@apache.org"
gpg:    alias "wrowe@lnd.com"
Für diesen Schlüssel konnte kein gültiger "Trust Path" gefunden 
werden. Mal sehen, ob wir sonst irgendwie ein paar fehlende 
"Owner trust" Werte ermitteln können.

Kein Pfad führt zu einem unserer Schlüssel.

gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, dass die Signatur wirklich dem vorgeblichen
         Besitzer gehört.
gpg: Fingerabdruck: 33 16 9B 46 FC 12 D4 01   CA 6D DB D7 DE EA 4F D7

Ein Problem dabei ist der (üblicherweise) fehlende Zertifizierungspfad (Trust Path) zu den Apache-Entwicklern. Letztlich könnte ja ein erfolgreicher Angreifer des Downloadservers auch die Schlüsseldatei austauschen. Ein Sicherheitsgewinn wird also nur dann erzielt, wenn man die Datei KEYS oder die darin enthaltenen Schlüssel aus einer anderen, unabhängigen Quelle bezieht. Hierzu bieten sich folgende Methoden – oder eine Kombination davon – an:

• Verwendung einer KEYS-Datei, die bereits vor längerer Zeit und vom zentralen Webserver des Apache-Projektes (nicht von einem Spiegelserver) heruntergeladen wurde,
• Verwendung/Vergleich von KEYS-Datein von mehreren Spiegelservern,
• Verwendung einer KEYS-Datei von CD-ROM einer (evtl. älteren) vorhandenen Version des Apache-Webservers.

Prinzipiell genügt es dabei schon, den "Fingerabdruck" (Fingerprint) des jeweiligen öffentlichen OpenPGP-Schlüssels zu vergleichen. Die Idee bei diesem Vorgehen ist, dass Manipulationen am Webserver und den abgelegten Dateien nicht über längere Zeit unbemerkt bleiben können und dass sie eventuell nur einzelne Spiegelserver betreffen beziehungsweise sich nur mit einiger Verzögerung auf mehrere Spiegelserver ausbreiten. Falls keine Unterschiede zwischen den KEYS-Datein und ihren Schlüsseln auftauchen, stellt dies zwar noch keine Garantie für die Authentizität der Schlüssel und Signaturen dar, erhöht aber immerhin die Wahrscheinlichkeit, dass keine Manipulationen vorliegen. Umgekehrt wäre natürlich das Auftreten von Diskrepanzen ein dringendes Alarmzeichen.

Grundlegende Sicherungen

Generell sollten bei der Quelltext-Installation nur die wirklich benötigten Module ausgewählt und einkompiliert werden, damit nicht ein "der Vollständigkeit halber" mit einkompiliertes, aber seither unbenutztes und daher vermutlich vergessenes Modul später eventuell für Sicherheitsprobleme sorgen kann. Die vorgenommenen Einstellungen sollte man dokumentieren, um jederzeit die aktuelle Konfiguration ermitteln und im Notfall auch schnell reproduzieren zu können.

Nach dem abschließenden "make install" des Open-Source-üblichen Installationsvorgangs könnte der kompilierte Apache-Webserver unter Unix sofort gestartet werden. Zuvor sollte man allerdings noch einige grundlegende Sicherheitsmaßnahmen treffen:

• Einrichten eines eigenen Benutzers: Damit der Apache-Webserver den für den Dienst WWW vorgesehenen Standard-Port 80 benutzen kann, muss er mit root-Berechtigung gestartet werden. Für den Apache-Webserver muss jedoch unbedingt ein eigenes Benutzerkonto und eine eigene Gruppe, beispielsweise wwwrun oder apache, angelegt werden. Der Webserver sollte nach dem Start in diesen Sicherheitskontext wechseln (mittels der Direktiven User und Group, siehe unten).
• Einschränkung der Dateizugriffsrechte (1): 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.
• Einschränkung der Dateizugriffsrechte (2): Das Verzeichnis, das die öffentlich zugänglichen Dokumente enthalten soll, ist in der Default-Installation das Verzeichnis htdocs im Installationsverzeichnis des Apache-Webservers. Auch für dieses Verzeichnis sollten die Dateizugriffsrechte so eingeschränkt werden, dass nur Benutzer, die dazu berechtigt sind, Dateien in diesem Verzeichnis ablegen können. Sollen verschiedene Bereiche des Dokumentenbaumes von unterschiedlichen Benutzern gepflegt werden, sollte eine entsprechende Unterteilung vorgenommen werden, beispielsweise durch Gruppenschreibrechte. Der Benutzer, unter dem der Apache-Webserver läuft, sollte auf diese Verzeichnisse keinen Schreibzugriff besitzen.
• Einbindung in den Startvorgang des Systems: Damit der Apache-Webserver nach einem Neustart des Systems sofort zur Verfügung steht, sollte er in den normalen Startprozess des Betriebssystems eingebunden werden. Dazu steht das Skript apachectl zur Verfügung, das neben den Standardkommandos start und stop weitere Argumente kennt, mit denen beispielsweise die korrekte Syntax der Konfigurationsdateien überprüft oder der Betriebszustand des Apache-Webservers erfragt werden kann.

Für Windows existieren selbstentpackende Installer-Archive und seit einiger Zeit auch MSI-Pakete für den in Windows 2000 und Windows XP enthaltenen Microsoft Installer. Zu allen Paketen gibt es entsprechende digitale Signaturen, die man vor der Installation überprüfen sollte. Sollen MSI Pakete unter Windows NT verwendet werden, so muss zunächst der Windows Installer von der Microsoft Website heruntergeladen und installiert werden. Die Quelltexte sind in der Binärdistribution für Windows nicht enthalten, können jedoch als eigenes Paket heruntergeladen und getrennt installiert werden.

Ein Problem bei der Binärversion des Apache 2.0.40 für Windows ist das Fehlen des Moduls mod_ssl für die SSL-Unterstützung. Die Apache Entwickler schreiben dazu, dass dies auf Grund der noch andauernden Diskussion über die Verbreitung starker Verschlüsselungsverfahren der Fall sei. Daher ist das Kompilieren des Apache-Webservers aus den Quelltexten der einzige Weg, falls ein Einsatz des Apache-Webservers in Verbindung mit SSL unter Windows gewünscht ist.

Nach der Installation muss auch unter Windows eine grundlegende Absicherung vorgenommen werden:

• Einrichten eines eigenen Benutzers: In der Voreinstellung wird der Apache-Webserver als Dienst installiert und startet automatisch bei jedem Neustart des Rechners. Der Name des Dienstes ist Apache und der Webserver läuft dabei im Benutzerkontext des lokalen Systems (Account LocalSystem). Da LocalSystem aber über nahezu uneingeschränkte Rechte auf dem eigenen Rechner verfügt, sollte man für den Webserver ein gesondertes Benutzerkonto einrichten, unter dem dann auch der Dienst Apache abläuft. Dieses Benutzerkonto muss ein Mitglied der Gruppe Benutzer sein. Zusätzlich müssen dem Benutzerkonto die Benutzerrechte Anmelden als Dienst, Sichern von Dateien und Verzeichnissen und Wiederherstellen von Dateien und Verzeichnissen zugewiesen werden, damit der Apache-Webserver als Dienst gestartet werden kann. Eventuell ist auch das Recht Als Teil des Betriebssystems handeln erforderlich.
• Einschränkung der Dateizugriffsrechte: Analog zur Situation unter Unix muss auch bei der Installation unter Windows durch entsprechende Einschränkung der Zugriffsrechte eine Absicherung durchgeführt werden. So sollten nur Administratoren Schreibzugriff auf die Installationsverzeichnisse haben, und der Zugriff auf das WWW-Verzeichnis sollte so eingeschränkt werden, dass keine unberechtigten Benutzer Dateien einstellen oder verändern können.

Im nächsten BSI-Forum geht es in der Fortsetzung dieses Beitrags um sichere Konfiguration und sicheren Betrieb des Apache-Servers.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 2002/5, Seite 43

Zurück zum Inhalt