Sicherheit des Apache-Webservers

Nachdem der a href="../0205/43.htm">erste Teil dieses Beitrags in Heft 2002/5 den sicheren Bezug, die Installation sowie grundlegende Sicherungen behandelt hat, folgen nunmehr Überlegungen zur sicheren Konfiguration, der Gewährleistung eines sicheren Betriebs und zum Einsatz zusätzlicher serverseitiger Software.

Ist der Apache-Webserver installiert, muss er noch den Vorgaben entsprechend konfiguriert werden. Die zentrale Konfigurationsdatei ist die Datei httpd.conf im conf-Verzeichnis. Aus historischen Gründen gibt es noch zwei weitere Dateien namens access.conf und srm.conf, die aber ab Version 2.0 des Apache-Webservers standardmäßig ignoriert werden (und auch schon in der Version 1.3 nicht mehr für den Betrieb nötig waren).

Sichere Konfiguration

Eine auch nur halbwegs detaillierte Beschreibung der vielfältigen Konfigurationsmöglichkeiten würde den Rahmen dieses Artikels bei weitem sprengen. Daher soll nur auf einige wichtige Konfigurationsmöglichkeiten eingegangen werden (beim Apache-Webserver Direktiven genannt), die auch sicherheitsrelevant sind. Die Datei httpd.conf aus der Apache-Distribution ist sehr ausführlich kommentiert und viele Direktiven sind weitgehend selbsterklärend.

Der Grundkonfiguration des Apache-Webservers dienen unter anderem folgende Direktiven:

In httpd.conf wird außerdem festgelegt, wie die Zuordnung von Dateiendungen zu verschiedenen MIME-Types erfolgt. Die Vorgabewerte, die bei der Installation des Apache-Webservers eingetragen werden, können hierbei meist übernommen werden.

Ressourcenzuordnung

Neben der Angabe des Wurzelverzeichnisses für den WWW-Dokumentenbaum über die DocumentRoot-Direktive können andere Verzeichnisse, die sich nicht innerhalb dieses Bereiches befinden, in den WWW-Dokumentenbaum "eingeblendet" werden. Dies geschieht über die Direktive Alias. Beispielsweise kann durch Alias /documents /public/documents das Verzeichnis /public/documents, das sich außerhalb des WWW-Dokumentenbaums befindet, unter dem URL http://servername/documents/ erreichbar gemacht werden. Natürlich muss dazu der für den Apache-Webserver eingerichtete User ausreichende Rechte besitzen, um Dateien aus dem Verzeichnis /public/documents lesen zu dürfen.

Diese Möglichkeit der "Einblendung" von Verzeichnissen macht es einerseits einfacher, die Pflege des Webangebots auf verschiedene Verantwortungsbereiche zu verteilen. Auf der anderen Seite erfordert es eine gewisse Sorgfalt, da über diesen Mechanismus auch irrtümlich Daten öffentlich zugänglich werden können, die eigentlich nicht für die Veröffentlichung bestimmt sind. Außerdem erfordert die Bedingung, dass der "Apache-User" für das Verzeichnis eine Leseberechtigung haben muss, eine "Öffnung" des betreffenden Verzeichnisses und eventuell auch der darüber liegenden Verzeichnisse, die unter Umständen unerwünscht ist. Vor der Einrichtung eines Alias muss daher geprüft werden, ob dies aus Sicht der Datensicherheit beziehungsweise Vertraulichkeit akzeptabel ist.

Neben der Möglichkeit, normale Verzeichnisse über einen Alias einzublenden, existiert noch die Möglichkeit, über die Direktive ScriptAlias dem Apache-Webserver mitzuteilen, dass in einem bestimmten Verzeichnis Programme (oder Skripte) stehen, an die über die CGI-Schnittstelle [3] Daten übergeben werden sollen. Das Thema Sicherheit ist bei CGI-Programmen von sehr großer Bedeutung.

Zugriffskontrolle

Die Zugriffskontrolle und die Authentifizierung von Benutzern und Benutzergruppen ist beim Apache-Webserver über verschiedene Mechanismen möglich. Die Authentifizierung ist dabei direkt mit der Vergabe von Zugriffsrechten verzahnt: Die gewährten Rechte ergeben sich aus den Ergebnissen einer oder aller dieser Authentifizierungsmethoden. Implementiert ist dies im Modul mod_access, das auf jeden Fall in den Apache-Webserver einkompiliert oder als dynamisches Modul eingebunden werden muss, damit eine Zugriffskontrolle durchgeführt werden kann. Die Authentifizierung von Clients über das Modul mod_access hat ihr Haupteinsatzgebiet darin, bestimmte Ressourcen nur Benutzern aus einem lokalen Intranet zur Verfügung zu stellen. Anhand des Hostnamens oder der IP-Adresse des zugreifenden internen Clients kann – bei entsprechender Abschottung gegenüber externen Netzen – der Apache-Webserver zuverlässig ermitteln, ob der Zugriff aus dem lokalen Intranet kam oder nicht.

Die Zugangssteuerung und die Vergabe von Zugriffsrechten wird durch die Angabe verschiedener Abschnitte (Umgebungen) in der Datei httpd.conf vorgenommen. Vorgesehen sind die Abschnitte <Directory> für die Angabe von Verzeichnissen im lokalen Dateisystem und <Location> für bestimmte "URL-Bereiche". Dabei können die Standard-Jokerzeichen "*" und "?" verwendet werden (Wildcards), um mehrere Bereiche auf einmal anzugeben. Als Erweiterungen existieren <DirectoryMatch> und <LocationMatch>, bei denen die Familien von Verzeichnissen oder URL-Bereichen über reguläre Ausdrücke angegeben werden können. Entsprechend funktionieren <Files> und <FilesMatch>, mit denen der Zugriff für einzelne Dateien oder Gruppen von Dateien gesteuert werden kann.

Neben der Vergabe von Zugriffsrechten kann in den <Directory>-Abschnitten eine Reihe weiterer Einstellungen vorgenommen werden, die teilweise ebenfalls sicherheitsrelevant sind – beispielsweise, ob der Apache-Webserver symbolischen Links im betreffenden Verzeichnis folgen soll. Normalerweise sollte diese Option abgeschaltet werden, da ansonsten wieder Dateien, die eigentlich nicht für die Veröffentlichung bestimmt sind, durch symbolische Links in den WWW-Dokumentenbaum eingeblendet werden können. Des Weiteren kann festgelegt werden, ob der Apache-Webserver für Verzeichnisse, die keine Index-Datei enthalten, automatisch generierte Inhaltsverzeichnisse anzeigen soll, wenn er einen entsprechenden HTTP-Request erhält. Da dies ebenfalls dazu führen kann, dass nicht zur Veröffentlichung bestimmte Dateien, beispielsweise ältere Versionen von Dokumenten oder temporäre Dateien von HTML-Editoren, an die Öffentlichkeit gelangen, sollte auch diese Option normalerweise nicht aktiviert sein.

Die getroffenen Einstellungen "vererben" sich entlang der Verzeichnishierarchie, wobei spätere Einstellungen die Einstellungen aus den höheren Verzeichnissen überschreiben können. Daher ist es sinnvoll, für das Wurzelverzeichnis sehr restriktive Einstellungen zu wählen und nur bei Bedarf für einzelne Unterverzeichnisse gewisse Optionen zu aktivieren, wenn sie dort benötigt werden. Bei der Festlegung der Optionen kann in der Datei httpd.conf auch angegeben werden, welche dieser Einstellungen von benutzerdefinierten Einstellungen überschrieben werdern dürfen.

Der Apache-Webserver erlaubt die Vergabe von Zugriffsrechten auf Verzeichnisse oder URL-Bereiche auf der Basis der IP-Adresse und des Hostnamens des zugreifenden Clients. Die Konfiguration der Zugriffsrechte geschieht durch die Direktiven Allow und Deny zusammen mit der Direktive Order. Die Auswertung der Anweisungen zur Zugriffskontrolle werden entsprechend der Hierarchie im Dateisystem beziehungsweise dem URL-Pfad ausgewertet. Später ausgewertete Direktiven überschreiben dabei die Einstellungen vorher ausgewerteter Direktiven.

Als weitere Möglichkeit der Zugriffssteuerung stehen die .htaccess-Dateien zur Verfügung. Wird in einem Verzeichnis eine solche Datei angelegt, so hat dies mehr oder weniger dieselbe Wirkung, wie wenn für dieses Verzeichnis eine entsprechende <Directory>-Umgebung in httpd.conf eingetragen wäre. Da die Auswertung einer etwa vorhandenen .htaccess-Datei nach der Anwendung der anderen Direktiven erfolgt, könnte dies dazu führen, dass Benutzer für ein WWW-Verzeichnis, in welchem sie Schreibrechte haben, eine .htaccess-Datei anlegen, durch die der Zugang zu diesem Verzeichnis "offener" wird als es der Sicherheitsrichtlinie entspricht. Würde beispielsweise in einer entsprechenden Directory-Direktive Verzeichnis-Zugriff auf das Intranet beschränkt, so könnte ein unvorsichtiger Benutzer durch Anlegen einer "offenen" .htaccess Dateien öffentlich zugänglich machen, die nicht für die Veröffentlichung im Internet bestimmt sind.

Das Überschreiben von Zugriffsbeschränkungen dieser Art lässt sich durch entsprechende Konfiguration innerhalb einer <Directory>-Umgebung mithilfe der Direktive AllowOverride je nach Bedarf erlauben oder verhindern. Die Standardeinstellung sollte dabei AllowOverride None sein, und nur bei Bedarf für ausgewählte Verzeichnisse eine andere Einstellung gewählt werden. Damit die Direktiven Allow und Deny in .htaccess-Dateien wirksam werden, muss AllowOverride Limit in der entsprechenden <Directory>-Umgebung angegeben werden.

Eine restriktive Grundkonfiguration in httpd.conf könnte demnach wie folgt aussehen:

Dabei wurde davon ausgegangen, dass das Directory /usr/local/apache/htdocs die DocumentRoot des Apache-Webservers ist und dass das Unterverzeichnis intranet Dateien enthält, die nur für Besucher aus dem lokalen Intranet zugänglich sein sollen, für das "private" IP-Adressen aus dem Bereich 10.0.0.x verwendet werden. Hier wird zunächst für das Wurzelverzeichnis des Servers jeglicher Zugriff verboten und alle Optionen wie die automatische Indexerstellung oder das Verfolgen symbolischer Links erst einmal abgeschaltet. Für das Intranet-Verzeichnis wurde die automatische Indexerstellung dann wieder aktiviert.

Außerdem wurde festgelegt, dass .htaccess-Dateien keine der getroffenen Einstellungen überschreiben dürfen. Diese Festlegung hat auch einen positiven Effekt auf die Performance, denn bei dieser Einstellung sucht der Apache-Webserver gar nicht erst nach .htaccess-Dateien. Erst wenn für ein "tieferliegendes" Verzeichnis AllowOverride für bestimmte Einstellungen freigegeben wurde, wird in diesem Verzeichnis und seinen Unterverzeichnissen wieder nach entsprechenden Dateien gesucht. Für das DocumentRoot-Verzeichnis wird anschließend im Beispiel der Zugriff erlaubt, wobei die Einschränkungen der Optionen weiter bestehen bleiben. Für den normalen Betrieb eines Webservers mit statischen HTML-Seiten sind diese Einstellungen ausreichend.

Als weiteres Beispiel soll ein Verzeichnis dienen, das als eine Art Downloadverzeichnis ähnlich einem FTP-Server genutzt werden soll, und in dem Benutzer eigene Unterverzeichnisse bekommen sollen, in denen sie Dateien zum Download ablegen können. Dabei sollen die Benutzer auch eigene Zugriffsbeschränkungen über .htaccess festlegen können:

Dabei aktiviert Options Indexes die automatische Anzeige von Verzeichnisinhalten, und AllowOverride Limit teilt dem Apache-Webserver mit, dass er entsprechende Anweisungen aus .htaccess-Dateien akzeptieren soll. Andere Anweisungen in .htaccess-Dateien werden in diesem Fall aber dennoch ignoriert.

Authentifizierung

Das Protokoll HTTP/1.1 sieht zwei verschiedene Methoden zur Benutzerauthentifizierung vor: Die erste Methode ist die so genannte Basic-Access-Authentifizierung. Dabei sendet der Client den Benutzernamen und das Passwort Base64-kodiert im Authorization Header des HTTP-Requests an den Server. Base64 ist eine Methode zur Kodierung von Binärdaten in 7-Bit ASCII, die hier zur Übertragung von Sonderzeichen über die HTTP-Schnittstelle genutzt wird. Das Passwort ist somit zwar nicht auf den ersten Blick ablesbar, kann aber von einem potenziellen "Lauscher" problemlos ermittelt werden, da es unverschlüsselt ist. Daher ist dieser Authentifizierungstyp allenfalls für sehr geringe Vertraulichkeitsanforderungen zu gebrauchen.

Die zweite Methode zur HTTP-Authentifizierung ist die Digest-Authentifizierung. Dabei erhält der Client vom Server einen Zufallsstring, den so genannten Challenge. Aus diesem Challenge und dem Passwort des Benutzers errechnet der Client nach einem standardisierten Verfahren einen so genannten Digest, der dann zur Authentifizierung an den Server gesandt wird. Da der Server sowohl über den von ihm generierten Zufallsstring als auch über das Passwort des Benutzers verfügt, kann er den Digest ebenfalls berechnen und so die Authentifizierung durchführen. Digest-Authentifizierung wird jedoch nicht von allen momentan gebräuchlichen Clients unterstützt. Der Microsoft Internet Explorer ab Version 5, Mozilla 1.0 und Opera 6.0 unterstützen Digest-Authentifizierung, der Netscape Navigator (Version 4.x und 6.x) dagegen noch nicht. Da bei der Digest-Authentifizierung das Passwort nicht über das Netz verschickt wird, eignet sich diese Methode für einen etwas höheren Schutzbedarf.

Ein weiteres Problem ist die Sicherheit der Passwortdaten auf dem Server selbst: Bei Verwendung der Digest-Authentifizierung müssen die Authentifizierungsdaten der Benutzer auf dem Webserver im Klartext vorhanden sein. Bei Verwendung der Basic-Authentifizierung wird dagegen nur ein Hash-Wert des Passwortes in einer Datei abgespeichert, deren Format dem einer herkömmlichen Unix-passwd-Datei entspricht. Dies ist sicherer, aber weil die entsprechenden Passwortdateien vom Apache-Webserver gelesen werden müssen, ist die Sicherheit der in ihnen gespeicherten Authentifizierungsdaten gegenüber lokalen Angreifern nur recht schwach. Die Passwortdateien für die HTTP-Authentifizierung müssen in jedem Fall außerhalb des Dokumentenverzeichnisses des Apache-Webservers abgelegt werden.

Ein zentraler Aspekt der HTTP-Authentifizierung wird nicht direkt vom Kern des Apache-Webservers abgedeckt: die Verwaltung der Benutzerpasswörter und Gruppenmitgliedschaften. Dies wird stattdessen in verschiedenen Modulen realisiert. Diese Module ermöglichen eine Speicherung der Authentifizierungsdaten für die Basic-Access-Authentifizierung in Dateien (mod_auth) oder Datenbanken (mod_auth_dbm, mod_auth_db) und Verzeichnisdiensten (mod_auth_ldap).

Neben HTTP-Authentifizierung existiert noch ein weiterer Weg, Zugriffskontrolle zu realisieren: Die Authentifizierung kann nicht über den Webserver selbst, sondern über eine serverseitige Anwendung durchgeführt werden. Dabei werden Benutzername und Passwort über normale HTML-Formulare eingegeben und von der Anwendung überprüft. Dieses Verfahren ist häufig bei Internet-Angeboten realisiert.

Es sollte jedoch stets beachtet werden, dass Passwörter und PINs, die im Klartext über das Internet übertragen werden, unter Umständen mitgeschnitten werden können. Zudem werden natürlich auch sämtliche Daten, selbst wenn sie auf authentifizierte Anfragen hin ausgeliefert werden, standardmäßig unverschlüsselt übermittelt. Deshalb sollte die Übertragung von Authentifizierungsinformationen und anderer vertraulicher Daten durch die Verwendung von SSL abgesichert werden (Secure Sockets Layer).

Secure Sockets Layer

Soll eine sichere Authentifizierung von Benutzern gegenüber dem Webserver erfolgen oder sollen vertrauliche Daten bei der Übertragung nicht im Klartext über das Netz geschickt werden, so ist die Verwendung von SSL/TLS (Transport Layer Security) zu empfehlen. SSL wurde zunächst von der Firma Netscape spezifiziert, später jedoch in den Standardisierungsprozess der Internet Engineering Taskforce (IETF) eingebracht. Im Jahr 1999 wurde die Weiterentwicklung von Netscapes SSL 3.0 unter der Bezeichnung TLS 1.0 (Transport Layer Security) von der IETF als RFC 2246 standardisiert. Trotzdem spricht man heute meist noch von SSL. SSL implementiert die Authentifizierung von Client und Server mithilfe von Zertifikaten sowie eine Verschlüsselung der Datenübertragung mithilfe verschiedener symmetrischer Verschlüsselungsalgorithmen.

Für den Apache-Webserver in der Version 1.3.x existieren zwei verschiedene Open-Source-Implementierungen von SSL/TLS: Apache-SSL und mod_ssl. Beide verwenden für die kryptographischen Algorithmen und die Realisierung des SSL-Protokolls selbst das Open-Source Paket OpenSSL [4]. Die prinzipiellen Unterschiede zwischen den beiden Implementierungen bestehen in der Integration mit dem Apache-Webserver selbst sowie in den verfügbaren Konfigurationsmöglichkeiten. Beim Apache-Webserver in der Version 2 wurde mod_ssl als Bestandteil in die Apache-Distribution aufgenommen, ist jedoch in den Binärdistributionen der ASF nicht einkompiliert.

Bei der Verwendung von SSL gibt es zwei wesentlich verschiedene Betriebsarten: Bei der ersten Variante, die heute meist verwendet wird, besitzt nur der Server ein Zertifikat. Dies dient dem Benutzer dazu, zu erkennen, dass er wirklich mit dem "richtigen" Server verbunden ist, und ermöglicht durch den Aufbau einer verschlüsselten Verbindung die sichere Übertragung von Authentifizierungsinformationen und Anwendungsdaten. Ein Server-Zertifikat enthält neben dem Namen der Zertifizierungsstelle auch den Namen des Servers, für den es gültig ist. Es kann von einer Wurzelzertifizierungsstelle (Root-CA) ausgestellt sein oder auch selbst erzeugt werden, beispielsweise mit den im OpenSSL Paket enthaltenen Tools. Zertifikate, die nicht von einer Wurzelzertifizierungsstelle ausgestellt wurden, die dem Webbrowser bekannt ist, werden vom Browser nicht ohne weiteres akzeptiert, sondern der Benutzer muss explizit bestätigen, dass das betreffende Zertifikat akzeptiert werden soll.

Bei der zweiten Variante, die noch nicht sehr weit verbreitet ist, verfügt auch der Benutzer über ein Zertifikat, das auf dem Client-Rechner vorhanden sein muss, und das der Browser zur Authentifizierung an den Server schickt. Voraussetzung dafür ist jedoch, dass die Zertifizierungsstellen, deren Zertifikate verwendet werden, "vertrauenswürdig" sind. Dass diese Art der Authentifizierung in der Praxis nicht häufiger verwendet wird, liegt an dem recht hohen Aufwand, der zur Umsetzung einer solchen Lösung erforderlich ist.

Die serverseitige Konfiguration ist noch relativ einfach: Neben der Konfiguration des Webservers für SSL muss ein SSL-Server-Zertifikat beschafft und implementiert werden. Größer ist dagegen der Aufwand, der für jeden einzelnen Benutzer zu betreiben ist: Jeder Benutzer muss über ein SSL-Client-Zertifikat verfügen, das in seinem Webbrowser installiert ist. Dies führt zu einer gewissen Einschränkung der Bequemlichkeit, da einer der großen Vorteile der normalen WWW-Nutzung gerade darin besteht, dass der Zugriff von praktisch jedem beliebigen Rechner aus erfolgen kann. Werden Client-Zertifikate zur Authentifizierung benutzt, so ist diese Flexibilität deutlich eingeschränkt, weil das Client-Zertifikat meist nicht überall vorhanden ist. Andererseits kann in bestimmten Situationen, etwa beim Einsatz eines Intranet-Webservers, genau dieser Effekt auch erwünscht sein.

Je nach der Art und Weise, wie Zugriffsrechte auf dem Webserver an die Zertifikatsinhaber vergeben werden, müssen Erlauben oder Sperren des Zugangs für einzelne Benutzer unterschiedlich realisiert werden. Wird zum Beispiel die Option FakeBasicAuthentication von mod_ssl genutzt, so müssen zur Gewährung des Zugangs die Daten jedes Client-Zertifikates (genauer der Inhalt des Feldes Subject DN) in die Passwortdatei des Webservers eingetragen werden. Um den Zugang zu sperren, reicht es aus, diese Daten wieder aus der Passwortdatei zu entfernen. Mit dieser Option ist die Verwendung von Client-Zertifikaten mit unterschiedlichen Inhalten, die auch von verschiedenen Zertifizierungsstellen stammen können, möglich. Es ist keine geschlossene Public Key Infrastructure (PKI) zur Realisierung notwendig. Der Preis dafür ist jedoch, dass in den Passwortdateien des Webservers eine Benutzerverwaltung stattfinden muss, die wie im Fall der anderen Verfahren meist eine bereits an anderer Stelle existierende Benutzerverwaltung dupliziert. Existiert dagegen eine geschlossene PKI, die an alle Personen des Benutzerkreises Client-Zertifikate ausstellt, aus deren Inhalt sich die Zugriffsrechte auf den Webserver rekonstruieren lassen, so ist eine Realisierung der SSL-Client-Authentifizierung ohne den Aufwand einer weiteren Benutzerverwaltung möglich.

Dass jedoch auch die Verwendung von SSL keine absolute Sicherheit garantiert, zeigt leider eine aktuelle Schwachstelle im Microsoft Internet Explorer: dieser Browser überprüft die Herkunft eines Zertifikats nicht korrekt, sodass es für einen Angreifer möglich wird, sich ein gefälschtes Zertifikat für einen beliebigen Server zu erzeugen. Der Angreifer muss lediglich ein gültiges Zertifikat einer Wurzelzertifizierungsstelle besitzen, mit dem er das gefälschte Zertifikat signiert. Ein solches Zertifikat wird dann vom Internet Explorer fälschlicherweise akzeptiert, was beispielsweise für Man-in-the-Middle-Angriffe verwendet werden kann. Derselbe Fehler existiert anscheinend auch in Microsoft Outlook. Mehr Informationen zu diesen Schwachstellen finden sich beispielsweise im Archiv der Bugtraq-Mailingliste sowie im Advisory von Microsoft.

Externe Programme und dynamische Inhalte

Neben der Grundfunktion, HTML-Dateien aus dem Dateisystem des Rechners auszuliefern, verfügt der Apache-Webserver auch über die Möglichkeit, auszuliefernde Daten dynamisch durch den Aufruf externer Programme zu erzeugen. Die Verwendung solcher extern gestarteter Programme (bzw. der von diesen Programmen erzeugten Daten) ermöglicht eine Vielzahl von Anwendungen, die allein mit dem Webserver nicht zu realisieren wären. Beispiele sind eine serverbasierte Volltextsuche, Datenbankabfragen über eine Webschnittstelle, Gästebücher, Benutzerforen und vieles mehr.

Der Aufruf externer Programme durch den Apache-Webserver ist durch eine Reihe unterschiedlicher Mechanismen möglich. Die folgenden Möglichkeiten bestehen im Rahmen der in der Quelltext-Distribution des Apache-Webservers selbst enthaltenen Module:

Technisch realisiert sind diese Möglichkeiten durch entsprechende Apache-Module, wie mod_cgi, mod_include (Server-Side Includes), mod_isapi (nur unter Windows) sowie andere Module wie mod_perl (dynamische Webseiten mit Perl), mod_php (dynamische Webseiten mit PHP) oder mod_jk (Servlets und Java Server Pages mit dem Tomcat Servlet Container), die in den Apache-Webserver integriert werden können. Alle diese Module haben gemeinsam, dass mit ihnen Anwendungen erstellt werden können, die auf dem Serverrechner meist im Sicherheitskontext des Apache-Webservers ablaufen. In den meisten Anwendungsfällen verarbeiten derartige Programme auch Eingaben von den Benutzern.

Werden solche Programme selbst entwickelt, so handelt es sich oft um spezielle Lösungen für einzelne Probleme, die meist nicht mit derselben Sorgfalt entwickelt werden wie eine echte "Server-Software", obwohl es sich de facto um eine solche handelt. Oft werden auch externe Module beispielsweise für Foren oder Gästebücher eingesetzt, die aus dem Internet heruntergeladen und ohne sorgfältige Prüfung installiert wurden. Daher verwundert es nicht, dass ein großer Teil der Sicherheitsprobleme, die im Zusammenhang mit Webservern auftreten, nicht direkt im Webserver selbst ihren Ursprung haben, sondern von solchen externen Programmen stammen.

Als generelle Vorsichtsmaßnahme in diesem Zusammenhang sollte jede eigene Anwendung mit besonderer Sorgfalt im Hinblick auf die sichere Verarbeitung von Benutzereingaben entwickelt werden und jede externe Anwendung sollte einer genauso sorgfältigen Überprüfung unterzogen werden wie der Webserver selbst. In der Apache Sicherheitsstudie werden einige der möglichen Probleme näher betrachtet und Möglichkeiten zu ihrer Lösung diskutiert.

Sicherer Betrieb

Nach einer sicheren Installation und Konfiguration sind auch im laufenden Betrieb Maßnahmen erforderlich, um die Sicherheit eines Webservers aufrechtzuerhalten. Dazu gehören beispielsweise:

Die Überprüfung der Logdateien kann Angriffe auf einen Apache-Webserver zwar nicht verhindern, aber potenzielle Schwachstellen aufdecken und Hinweise auf einen Angriff enthalten. Dazu gehören beispielsweise eine Häufung bestimmter Anfragen oder Fehlermeldungen, Anfragen nach "seltsamen" URLs oder ähnliches.

Zum sicheren Betrieb eines Webservers gehört aber auch die sichere Integration in das Netz. 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 Port 80 (bzw. 443, falls SSL verwendet wird) beschränkt werden. Datenübertragungen zum Webserver (z. B. zum Hochladen von Dateien) und der Zugang etwa mithilfe von Secure Shell (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.

Falls eigene dynamische Seiten oder serverseitige Programme zum Einsatz kommen, ist außerdem eine Schulung der betreffenden Webdesigner oder Entwickler dringend zu empfehlen, damit diese mit den möglichen Problemen vertraut sind und Möglichkeiten zu deren Vermeidung kennen.

Zusammenfassung

Der Apache-Webserver ist ein ausgereiftes Produkt mit einem sehr guten Ruf im Bezug auf Sicherheit. Mit der vor kurzem für den Produktionsbetrieb freigegebenen Version 2.0.40 steht eine neue Generation des Servers zur Verfügung, die eine neue, flexiblere Architektur und weitere Verbesserungen bietet. Für eine sichere Konfiguration und einen sicheren Betrieb, vor allem im Bezug auf sichere Benutzerauthentifizierung und sichere Datenübertragung sowie im Zusammenhang mit serverseitig generierten dynamischen Inhalten sind jedoch sorgfältige Planung und einige Arbeit nötig. Eine ausführlichere Diskussion dieser und anderer Themen findet sich in der demnächst erscheinenden Apache-Studie des BSI.

Literatur

[1]: Netcraft Web Server Survey Oktober 2002, www.netcraft.com/survey/
[4]: Apache Software Foundation, www.apache.org
[3]: The Common Gateway Interface (CGI), http://hoohoo.ncsa.uiuc.edu/cgi/
[4]: The OpenSSL Project, www.openssl.org

BSI-Forum

Sicherheit des Apache-Webservers – Teil II

Von Thomas Haeberlen, BSI