Webserver-Sicherheit, Teil 1

10 Tipps zur Sicherheitsoptimierung von Apache

09.06.2009 von Sebastian Wolfgarten
Apache verwendet bereits in der Standardinstallation eine recht sichere Konfiguration. Mit zehn einfachen Regeln können Sie die Sicherheit des Apache Webservers aber nochmals deutlich steigern und sich so vor Angriffen und Ausfällen schützen.

Die folgenden Vorschläge und Anmerkungen sind Hinweise, die die Konfiguration des Apache sicherheitstechnisch optimieren sollen. Aber Achtung: Durch diese Optimierungen entsteht keineswegs eine vollkommen sichere Konfiguration. Die Tipps dienen dazu, auf Fehler und notwendige Konfigurationsarbeiten des Administrators nach der Installation des Apache sowie auf mögliche Gefahrenquellen allgemeiner Natur aufmerksam zu machen. Wie Sie Ihre Installation des Apache zusätzlich absichern, lesen Sie in den weiteren Teilen unserer neuen Artikelserie.

Vor diesem Hintergrund bieten sich zur ersten Sicherheitsoptimierung der Apache Grundkonfiguration die auf den folgenden Seiten gezeigten Möglichkeiten an. Einige Problemfälle treten in der Standardkonfiguration der aktuellen Apache-Version 2.2 nicht mehr auf, können sich dort aber durch die Übernahme der httpd.conf-Datei einer älteren Version eingeschlichen haben. Eine Überprüfung ist daher in jedem Fall sinnvoll. Beachten Sie bitte, dass die angegeben Zeilennummern für Apache 2.2 keine Gültigkeit mehr haben.

Apache Webserver 2

Dieser Beitrag basiert auf Kapitel 9 des Buchs „Apache Webserver 2 – Installation, Konfiguration, Programmierung“ von Sebastian Wolfgarten. Dieses Standardwerk über den Apache Webserver mit über 900 Seiten können Sie als eBook in unserem Partnerbuchshop Informit.de für 19,95 Euro downloaden.

Artikelserie

Apache Sicherheit Teil 1: Grundkonfiguration

Apache Sicherheit Teil 2: Noch nicht veröffentlicht

Apache Sicherheit Teil 3 Noch nicht veröffentlicht

Apache Sicherheit Teil 4: Noch nicht veröffentlicht

Tipp 1: Listen-Anweisungen

Standardmäßig lauscht der Apache nach der Installation durch die Anweisung Listen 80 (httpd.conf, Zeile 218) auf Port 80 aller verfügbaren IP-Adressen des Systems. Dadurch besteht die Gefahr, dass ein unachtsamer Administrator dafür sorgt, dass der Apache über eine IP-Adresse angesprochen werden kann, über die normalerweise kein Zugriff auf das System möglich sein sollte.

Es ist daher ratsam, die IP-Adressen, über die ein Zugriff auf das lokale System möglich sein soll, explizit durch eine Listen-Anweisung in der Konfigurationsdatei des Apache zu definieren. Ein Beispiel:

Listen 192.168.0.6:80

Durch diese Anweisung wird der Apache nur auf Port 80 der Netzwerkschnittstelle gebunden, der die IP-Adresse 192.168.0.6 zugeordnet ist. Bitte beachten Sie außerdem, dass der Server auch über den TCP-Port 443 (HTTPS) auf allen Netzwerkkarten ansprechbar ist, sofern SSL aktiviert ist. Die Ursache dafür liegt darin, dass die Datei conf/ssl.conf durch den Apache ebenfalls geladen wird (httpd.conf, Zeilen 1040-1042) und dort eine entsprechende Listen-Anweisung vorhanden ist. Die oben gemachten Aussagen bezüglich der Gefahr einer universellen Anweisung treffen selbstverständlich auch für SSL zu.

Tipp 2: User nobody

Nach der Installation des Apache ist es die Aufgabe des Administrators, die Konfigurationsdatei des Apache durchzuschauen und dort verschiedene Änderungen der Grundkonfiguration vorzunehmen. Eine wichtige Änderung ist die Korrektur der in den Zeilen 266-267 enthaltenen Definition der Benutzer- und Gruppenkennung, mit der der Apache betrieben werden soll.Standardmäßig sieht diese Konfiguration aus Gründen der Kompatibilität wie folgt aus:

User nobody
Group #-1

Der Benutzer nobody wird hier verwendet, da dieser bereits auf einer Vielzahl von Systemen existiert und dort gerne für das Ausführen von Systemdiensten mit nicht privilegierten Rechten benutzt wird. Aus Sicherheitsgründen sollten Sie einen separaten Benutzer für die Ausführung des Servers erstellen und dessen Benutzerkennung in die Konfigurationsdatei des Apache eintragen. Die aus Kompatibilitätsgründen standardmäßig verwendete Gruppenkennung #-1 ist sehr interessant, da diese streng genommen ungültig ist und dafür sorgt, dass der Apache mit einer falschen und in der Regel nicht existierenden Gruppenkennung ausgeführt wird (z.B. 4294967295).

Erzeugen Sie deshalb für die Ausführung des Apache eine separate Gruppe oder stellen Sie durch Eingabe des Befehls id nobody die korrekte Kennung der Gruppe fest, der der Benutzer nobody angehört und korrigieren Sie den Wert der Gruppenkennung in der Datei httpd.conf. Sie können unter anderem durch die folgenden Befehle eine separate Gruppe und einen Benutzer für die Ausführung des Apache erstellen:

# groupadd wwwuser
# useradd -g wwwuser -d /nonexistent -s /bin/false wwwuser

Ändern Sie nun in der Datei httpd.conf die User- und Group-Anweisung:

User wwwuser
Group wwwuser

Tipp 3: Konfigurationsoptionen für das Wurzelverzeichnis

In den Zeilen 316-319 der Datei httpd.conf werden Konfigurationsoptionen für das Wurzelverzeichnis »/« des Dateisystems festgelegt. Die besagte Stelle der Konfigurationsdatei sieht wie folgt aus:

<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

Ich persönlich sehe keinen Grund dafür, dass der Apache, hervorgerufen durch die Angabe der Option FollowSymLinks, standardmäßig symbolischen Links folgt. Dieses Verhalten ist insbesondere deshalb fragwürdig, da durch diese Standardkonfiguration ebenfalls solche Links beziehungsweise Verweise verfolgt werden, bei denen die Zieldatei bzw. das Zielverzeichnis nicht demselben Benutzer gehören, dem der eigentliche Link gehört. Dadurch ist es einem potenziellen Angreifer prinzipiell möglich, auf Dateien zuzugreifen, die außerhalb des als DocumentRoot definierten Verzeichnisses gespeichert sind. Aus diesem Grunde halte ich folgende Konfiguration für sinnvoller:

<Directory />
Options None
AllowOverride None
</Directory>

Falls Sie dennoch auf symbolische Verweise im Wurzelverzeichnis nicht verzichten können, sollten Sie das Verfolgen von symbolischen Links wenigstens auf solche beschränken, bei denen der Besitzer der Zieldatei beziehungsweise des Zielverzeichnisses mit dem Besitzer des Verweises identisch ist:

<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>

Die vorherige Variante ist dennoch wahrscheinlich die sicherere. Des Weiteren ist es aus sicherheitstechnischer Sicht sinnvoll, den Zugriff auf die Wurzel des Dateisystems (»/«) ebenfalls an dieser Stelle zu beschränken. Die beste Konfiguration an dieser Stelle der Datei httpd.conf ist deshalb wohl:

<Directory />
Options None
AllowOverride None
Order deny,allow
Deny from all
</Directory>

Mit Hilfe dieser Konfiguration lassen sich unter anderem so genannte Directory Traversals, das heißt mutwillige Durchstöberung des gesamten Verzeichnisbaums eines Servers, verhindern.

Tipp 4: Optionen für htdocs anpassen

Weiterhin werden in den Zeilen 331-360 der Konfigurationsdatei httpd.conf Optionen für das als DocumentRoot bezeichnete Dokumentenverzeichnis htdocs der lokalen Apache-Installation (z.B. /usr/local/apache2/htdocs) definiert. Gekürzt sieht die Passage wie folgt aus:

<Directory »/usr/local/apache2/htdocs«>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Auch hier halte ich es aus sicherheitstechnischen Gründen nicht für ratsam, automatisch Verzeichnislistings zu erzeugen und symbolischen Verweisen zu folgen. Durch Verzeichnislistings werden die Inhalte eines Verzeichnisses in einer Übersicht präsentiert, sofern in dem jeweiligen Verzeichnis keine Indexdatei vorhanden ist. Dadurch besteht die Gefahr, dass Verzeichnisinhalte ungewollt veröffentlicht beziehungsweise von außen eingesehen werden können. Des Weiteren existiert durch die vorhandene FollowSymLinks-Anweisung die Möglichkeit, dass ein Angreifer durch einen symbolischen Verweis auf Dateien und Verzeichnisse zugreift, die außerhalb des als DocumentRoot definierten Verzeichnisses gespeichert sind.

Ich empfehle daher folgende Konfigurationsänderung (gekürzt):

<Directory »/usr/local/apache2/htdocs«>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Sollten Sie die genannten Funktionen für ein bestimmtes Verzeichnis benötigen, sollten Sie diese explizit zum Beispiel mit Hilfe einer Directory-Anweisung für das entsprechende Verzeichnis, aktivieren.

Tipp 5: Die ServerTokens-Anweisung

Der Apache 2 bietet durch die ServerTokens-Anweisung die Möglichkeit, den Umfang der an den Client übermittelten Informationen (so genannte »Banner«) bezüglich zu der eingesetzten Version, der vorhandenen Erweiterungen und dem zugrunde liegenden Betriebssystem im Kopf (Header) einer Antwort des Servers zu definieren. Standardmäßig werden jedoch alle vorhandenen Informationen veröffentlicht, wodurch meiner Meinung nach zu viele sensible Daten über die allgemeine Serverkonfiguration an die Öffentlichkeit gelangen. Ein Beispiel einer großen deutschen Universität:

Apache/2.0.39 (Unix) mod_ssl/2.0.39 OpenSSL/0.9.6b DAV/2

Ein nicht sonderlich versierter Anwender mag dieser Zeile vielleicht wenig Bedeutung beimessen, aber für einen Angreifer liefert sie wichtige Informationen. Für die auf dem Server installierte Version des Apache 2 existiert eine Schwachstelle, die in der entfernten Ausführung von beliebigem Code resultieren kann. Außerdem existiert bereits seit dem 21. Dezember 2001 eine neuere Version (0.9.6c) der OpenSSL-Bibliothek, da verschiedene Schwachstellen in dem Programm entdeckt worden sind, wobei momentan die Version 0.9.7c aktuell ist. Ferner ist es ein Kinderspiel festzustellen, dass auf dem entsprechenden Server Sun Solaris 8 läuft.

Aus diesen und anderen Gründen empfehle ich durch folgende Konfiguration den Umfang der veröffentlichten Informationen auf ein Minimum zu reduzieren:

ServerTokens Prod

Dadurch identifiziert sich der Server nur noch mit der Kennung Apache und lässt somit keine direkten Rückschlüsse auf das verwendete Betriebssystem und die vorhandenen Erweiterungen (z.B. OpenSSL) zu. Die Identifikation als eine beliebige Software (z.B. Microsoft IIS 5) ist ebenfalls durch eine Manipulation des Quellcodes des Apache möglich, obgleich es sich dabei um eine Spielerei handelt.

Selbstverständlich ist mir bekannt, dass derartige Maßnahmen oft abwertend als »Security by obscurity« (etwa »Sicherheit durch Verschleierung«) bezeichnet werden und die aktive Sicherheit des eigenen Systems (wenn überhaupt) nur minimal erhöhen. Trotzdem denke ich, dass man aus Sicherheitsgründen einem potenziellen Angreifer nicht alle Informationen in mundgerechten Stücken präsentieren sollte, denn wie heißt es so schön: Gelegenheit macht Hacker :-)

Tipp 6: Fehlermeldungen

Der nächste Optimierungsvorschlag betrifft dasselbe Problem, da der Apache im Falle eines aufgetretenen Fehlers (z.B. Datei nicht gefunden) eine entsprechende Meldung präsentiert, in der unter anderem auch eine Signatur enthalten ist, die Informationen über die verwendete Software (inklusive Versionsangaben) und eventuell vorhandene Erweiterungen beinhaltet. Ein Beispiel:

Apache/2.0.44 (Unix) mod_ssl/2.0.44 OpenSSL/0.9.6b PHP/4.3.0

Auch diese Fehlermeldungen können einem Angreifer wichtige Informationen über ein potenzielles Ziel liefern. Diese lassen sich jedoch mit Hilfe der ServerSignature- Anweisung unterbinden:

ServerSignature Off

Alternativ können Sie im Falle eines aufgetretenen Fehlers durch folgende Einstellung nur die E-Mailadresse des Administrators anzeigen lassen:

ServerSignature Email

Tipp 7: /icons/ löschen

Direkt nach der Installation des Apache befindet sich in den Zeilen 549-556 der Datei httpd.conf eine Alias- und Directory-Anweisung, die die im Unterverzeichnis icons der lokalen Installation des Apache enthaltenen Icons als Verzeichnis /icons/ auf Ihrer Internetseite veröffentlicht. Dies bedeutet generell kein Sicherheitsrisiko, aber das Vorhandensein eines solchen Verzeichnisses gibt in der Regel Aufschluss auf den Konfigurationsstand des Servers.

Da für dieses Verzeichnis das Erzeugen eines Verzeichnisindizes standardmäßig eingeschaltet ist, empfehle ich, diese Funktion zu deaktivieren oder das Verzeichnis inklusive der genannten Konfigurationsanweisungen vollständig zu entfernen, sofern Sie dieses nicht benötigen.

Tipp 8: /manual/ löschen

Dasselbe Problem wird durch die Konfigurationsanweisungen in Zeile 596-615 der httpd.conf erzeugt, die durch eine AliasMatch- und eine Directory-Anweisung das Handbuch des Apache als Verzeichnis /manual/ auf Ihrem Server veröffentlichen.

Dabei handelt es sich nicht direkt um ein Sicherheitsrisiko, aber auch hier gibt das Vorhandensein eines solchen Verzeichnisses Aufschluss über den allgemeinen Konfigurationsstand des Servers. Außerdem ist für dieses Verzeichnis ebenfalls das automatische Erzeugen von Verzeichnisindizes eingeschaltet, weshalb ich dazu rate, diese Funktion zu deaktivieren oder das Verzeichnis inklusive der genannten Konfigurationsanweisungen vollständig zu entfernen.

Tipp 9: Test-Skripte löschen

Zu Testzwecken befinden sich im Verzeichnis cgi-bin Ihrer lokalen Apache-Installation zwei Skripte, die die Umgebungsvariablen des Servers ausgeben. Dadurch können Details der Serverkonfiguration (z.B. Datei- und Verzeichnispfade) veröffentlicht werden, die eigentlich nur den Administrator des Servers etwas angehen.

Das Vorhandensein dieser Skripte ist ein sehr deutlicher Hinweis auf den allgemeinen Konfigurationsgrad des Servers, insbesondere wenn solche Skripte später über eine Suche bei der Suchmaschine Google gefunden werden. Löschen Sie daher direkt nach der Installation des Apache die Skripte test-cgi und printenv aus dem Unterverzeichnis cgi-bin.

Tipp 10: Hilfsprogramme löschen

Viele Hersteller bieten fertige Installationspakete für den Apache an. Diese enthalten meist zusätzliche Konfigurationsanweisungen und Programme (z.B. htdig, sdbsearch, info2html), die beispielsweise das Durchsuchen des lokalen Hilfesystems der jeweiligen Distribution ermöglichen.

Aufgrund der Tatsache, dass diese Erweiterungen in der Vergangenheit mehrfach die Ursache von Sicherheitsproblemen waren (siehe http://lists.insecure.org/lists/bugtraq/2001/Aug/0028.html) und darüber hinaus Informationen über den allgemeinen Konfigurations- und Wartungsstand des Systems liefern, sollten Sie derartige Hilfsprogramme vollständig aus Ihrem System entfernen.

Fazit

Die genannten Vorschläge und Erfahrungswerte sind Hinweise, die die eigene Konfiguration des Apache sichern und darüber hinaus Einblicke in beliebte Konfigurationsmängel geben sollen. Sie sind keineswegs vollständig und führen nicht zur absoluten Sicherheit eines Systems, sondern sollen vielmehr als Hilfe zum sicheren Aufbau einer eigenen Konfiguration des Apache verstanden werden. (ala)

Apache Webserver 2

Dieser Beitrag basiert auf Kapitel 9 des Buchs „Apache Webserver 2 – Installation, Konfiguration, Programmierung“ von Sebastian Wolfgarten. Dieses Standardwerk über den Apache Webserver mit über 900 Seiten können Sie als eBook in unserem Partnerbuchshop Informit.de für 19,95 Euro downloaden.

Artikelserie

Apache Sicherheit Teil 1: Grundkonfiguration

Apache Sicherheit Teil 2: Noch nicht veröffentlicht

Apache Sicherheit Teil 3 Noch nicht veröffentlicht

Apache Sicherheit Teil 4: Noch nicht veröffentlicht