Weitere Themen Sicherheitshinweise

Tipps und Hinweise zu Sicherheitsaspekten beim Einrichten eines Webservers. Einige Vorschläge sind allgemeiner Art, andere beziehen sich speziell auf den Apache-Server.

Bleiben Sie auf dem aktuellen Stand

Der Apache HTTP-Server hat bezüglich der Sicherheit einen guten Leumund und die Entwicklergemeinschaft sorgt sich sehr um Sicherheitsbelange. Einige Probleme - größere oder kleinere - werden aber unvermeidbar erst einige Zeit nach der Veröffentlichung einer Version deutlich. Deshalb müssen Updates unbedingt beachtet werden. Wenn Sie Ihre Version des HTTP-Servers direkt von Apache erhalten haben, sollten Sie sich für die Apache HTTP Server Announcements List anmelden, um über neue Versionen und Sicherheits-Updates informiert zu werden. Ähnliche Dienste werden auch von anderen Distributoren der Apache-Software angeboten.

Die Gefährdung eines Webservers hat in der Regel ihre Ursache nicht im HTTP-Servercode. Meist stammt sie von Problemen in ergänzendem Code, in CGI-Skripten oder im zugrundeliegenden Betriebssystem. Daher müssen die Probleme im Auge behalten und die gesamte Software des Systems auf aktuellem Stand gehalten werden.

Berechtigungen für ServerRoot-Verzeichnisse

Unter normalen Bedingungen wird der Apache unter dem Benutzer root gestartet und zu dem mit der Direktive User definierten Benutzer gewechselt, um Anfragen zu bedienen. Wie bei jedem vom Benutzer root ausgeführten Befehl ist darauf zu achten, dass er vor Veränderungen durch andere Benutzer geschützt ist. Nicht nur die Dateien selbst müssen für root mit Schreibrechten versehen sein, sondern auch die Verzeichnisse sowie alle übergeordneten Verzeichnisse. Befindet sich die ServerRoot beispielsweise im Verzeichnis /usr/local/apache, dann sollte dieses Verzeichnis mit folgenden Befehlen zur root gemacht werden:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

Es wird davon ausgegangen, dass /, /usr und /usr/local nur vom Benutzer root modifiziert werden dürfen. Bei der Installation des ausführbaren Programms httpd sollt ebenfalls darauf geachtet werden, dass es entsprechend geschützt ist:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

Sie können ein Verzeichnis htdocs anlegen, das von anderen Benutzern modifiziert werden kann (root führt keine Dateien aus diesem Verzeichnis aus und sollte dort auch keine Datei dort anlegen).

Wird zugelassen, dass andere Benutzer Dateien verändern, die entweder von root ausgeführt oder geschrieben werden, dann ist der root-Benutzer des Systems gefährdet. Beispielsweise könnte jemand die binäre httpd-Datei austauschen, so dass beim nächsten Start irgend ein Code ausgeführt wird. Kann von anderen als dem Benutzer root in das Protokollverzeichnis geschrieben werden, könnte eine Protokolldatei mit einem symbolischen Link zu einer anderen Systemdatei versehen werden, so dass root die Datei möglicherweise mit irgendwelchen Daten überschreibt. Darf von anderen Benutzern in die Protokolldateien selbst geschrieben werden, könnte jemand das Protokoll mit falschen Daten überschreiben.

Server Side Includes

Server Side Includes (SSI) stellen den Serveradministrator vor zahlreiche mögliche Sicherheitsrisiken.

Das erste Risiko ist die erhöhte Belastung des Servers. Alle SSI-fähigen Dateien müssen vom Apache analysiert werden, unabhängig davon, ob SSI-Direktiven in den Dateien enthalten sind. Die zusätzliche Belastung ist gering, in einer Umgebung mit einem gemeinsam genutzten Server ist sie jedoch signifikant.

Bei SSI-Dateien bestehen generell die gleichen Risiken wie bei CGI-Skripten. Bei Verwendung des exec cmd-Elements können SSI-fähige Dateien jedes CGI-Skript oder Programm mit den Berechtigungen des Benutzers und der Gruppe ausführen, unter der der Apache ausgeführt wird (wie in der Datei httpd.conf konfiguriert).

Die Sicherheit von of SSI-Dateien lässt sich verbessern, ohne dass dabei auf ihre Vorteile verzichtet werden muss.

Um den Schaden auszuschließen, den eine unberechenbare SSI-Datei anrichten kann, kann der Serveradministrator suexec (wie im Abschnitt CGI im Allgemeinen beschrieben) aktivieren.

Die Aktivierung von SSI für Dateien mit den Erweiterungen .html oder .htm kann gefährlich sein. Das gilt insbesondere in einer gemeinsam genutzten Umgebung oder bei hohem Datenaufkommen. SSI-fähige Dateien sollten eine eigene Erweiterung wie beispielsweise das konventionelle .shtml haben. Damit wird die Serverbelastung auf ein Minimum beschränkt und das Risikomanagement wird erleichtert.

Eine andere Lösung ist die Deaktivierung der Möglichkeit, Skripte und Programme über SSI-Seiten auszuführen. Hierfür wird in der Options-Direktive Includes durch IncludesNOEXEC ersetzt. Die Benutzer können dann aber immer noch <--#include virtual="..." --> benutzen, um CGI-Skripte auszuführen, wenn sich diese Skripte in den mit der ScriptAlias-Direktive dafür vorgesehenen Verzeichnissen befinden.

CGI im Allgemeinen

Prinzipiell gilt, dass Sie dem Verfasser von CGI-Skripten und Programmen und seiner Fähigkeit, potenzielle Sicherheitslücken zu stopfen, vertrauen müssen. CGI-Skripte können im System mit den Berechtigungen des Webserver-Benutzers beliebige Befehle ausführen und daher extrem gefährlich werden, wenn sie nicht sorgfältig geprüft werden.

Alle CGI-Skripte werden unter dem gleichen Benutzer ausgeführt und können daher (versehentlich oder absichtlich) mit anderen Skripten in Konflikt geraten. Kann Benutzer A beispielsweise Benutzer B nicht ausstehen, dann schreibt er ein Skript, um die CGI-Datenbank von Benutzer B zu zerstören. suEXEC ist ein Programm, welches es ermöglicht, das Skripte unter anderen Benutzern ausgeführt werden. Es ist seit der Version 1.2 Bestandteil der Apache-Distribution und wird von speziellen Hooks des Apache-Servercodes aufgerufen. Eine andere beliebte Möglichkeit ist CGIWrap.

CGI-Skripte ohne ScriptAlias-Anweisung

Die Ausführung von CGI-Skripten aus einem beliebigen Verzeichnis sollte nur in Betracht gezogen werden, wenn

CGI-Skripte mit ScriptAlias-Anweisung

Die Einschränkung der Ausführbarkeit von CGI-Skripten auf spezielle Verzeichnisse lässt dem Administrator die Kontrolle darüber, was sich in diesen Verzeichnissen befindet. Das ist zwangsläufig sicherer als die Ausführung von CGI-Skripten aus allen Verzeichnissen, allerdings nur, wenn die Benutzer mit Schreibrechten in diesen Verzeichnissen vertrauenswürdig sind oder der Administrator bereit ist, jedes neue CGI-Skript/Programm auf mögliche Sicherheitslöcher hin zu überprüfen.

Die meisten Sites ziehen diese Möglichkeit vor.

Andere Quellen dynamischer Inhalte

Eingebettet Skriptoptionen, die als Teil des Servers selbst ausgeführt werden wie mod_php, mod_perl, mod_tcl und mod_python werden unter der Identität des Servers selbst ausgeführt (siehe User-Direktive) und deshalb können Skripte solcher Scripting Engines auf alles zugreifen, worauf der Serverbenutzer zugreifen kann. Scripting Engines können Einschränkungen auferlegen, es aber sicher, davon Abstand zu nehmen.

Die Systemeinstellungen schützen

Um wirklich sicher zu sein, müssen die Benutzer daran gehindert werden, .htaccess-Dateien einzurichten, die konfigurierte Sicherheitseigenschaften au├čer Kraft setzen können. Eine Möglichkeit, wie dies verhindert werden kann, ist folgender Eintrag in der Server-Konfigurationsdatei:

<Directory />
AllowOverride None
</Directory>

Das verhindert die Verwendung von .htaccess-Dateien in allen Verzeichnissen, abgesehen von denen, für die diese Möglichkeit speziell aktiviert wird.

Serverdateien standardmäßig schützen

Eine häufig missverstandene Eigenschaft des Apache-Servers ist der Standardzugriff. Wenn der Server den Weg zu einer Datei über normale URL-Regeln findet, kann er sie dem Client zur Verfügung stellen:

# cd /; ln -s / public_html
Accessing http://localhost/~root/

Das erlaubt den Clients, sich durch das gesamte Dateisystem zu bewegen. Mit folgendem Block in der Server-Konfigurationsdatei lässt sich das verhindern:

<Directory />
Order Deny,Allow
Deny from all
</Directory>

Damit wird der Standardzugriff auf Positionen im Dateisystem unterbunden. Fügen Sie die entsprechenden Directory-Blöcke ein, um nur den Zugriff auf die gewünschten Bereiche zu erlauben. Zum Beispiel:

<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

Schenken Sie den Direktiven Location und Directory besondere Aufmerksamkeit. Selbst wenn <Directory /> den Zugriff verweigert, kann eine <Location />-Direktive das aufheben.

Seien Sie auch vorsichtig im Umgang mit der UserDir-Direktive. Wird sie auf etwas wie ./ gesetzt, hat das den gleichen Effekt für den root-Benutzer, wie im ersten oben aufgeführten Beispiel. Setzen Sie Apache 1.3 oder eine spätere Version ein, ist es unbedingt zu empfehlen, folgende Zeilen in die Server-Konfigurationsdateien einzufügen:

UserDir disabled root
Die Protokolle überwachen

Um immer aktuell darüber informiert zu sein, was auf Ihrem Server vor sich geht, müssen Sie die Protokolldateien überprüfen. Auch wenn sie nur berichten, was bereits passiert ist, zeigen sie Ihnen doch, welchen Angriffen der Server unterworfen war und Sie können überprüfen, ob die erforderlichen Sicherheitsmaßnahmen getroffen wurden.

Einige Beispiele:

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10

Im ersten Beispiel wird eine Liste mit der Anzahl der Angriffe zur Ausnutzung der Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability angezeigt, im zweiten Beispiel werden die letzten 10 abgelehnten Clients aufgeführt:

[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

Die Protokolldateien geben nur wieder, was tatsächlich passiert ist. Hätte der Client auf die .htpasswd-Datei zugreifen können, wäre folgendes im Zugriffsprotokoll zu sehen gewesen:

foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

In diesem Fall wurde wahrscheinlich der folgende Abschnitt in der Server-Konfigurationsdatei als Kommentar gekennzeichnet:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
<Files>