Title: Sicherheitshinweise
Tipps und Hinweise zu Sicherheitsaspekten beim Einrichten eines Webservers. Einige Vorschläge sind allgemeiner Art, andere beziehen sich speziell auf den Apache-Server.
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.
Unter normalen Bedingungen wird der Apache unter dem
Benutzer root gestartet und zu dem mit der Direktive
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:
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:
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 (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
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
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.
Die Ausführung von CGI-Skripten aus einem beliebigen Verzeichnis sollte nur in Betracht gezogen werden, wenn
- Sie darauf vertrauen, dass die Benutzer keine Skripte schreiben, die absichtlich oder versehentlich das System angreifen.
- Sie die Sicherheit der Site als so angreifbar in anderen Bereichen einschätzen, dass eine weitere Sicherheitslücke auch nichts mehr ausmacht.
- Sie keine Benutzer haben und niemand Ihren Server besucht.
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.
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
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:
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.
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:
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:
Order Deny,Allow
Deny from all
</Directory>
Damit wird der Standardzugriff auf Positionen im Dateisystem
unterbunden. Fügen Sie die entsprechenden
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Schenken Sie den Direktiven
<Directory /> den Zugriff verweigert,
kann eine <Location />-Direktive das aufheben.
Seien Sie auch vorsichtig im Umgang mit der
./ 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:
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 "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:
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:
In diesem Fall wurde wahrscheinlich der folgende Abschnitt in der Server-Konfigurationsdatei als Kommentar gekennzeichnet:
Order allow,deny
Deny from all
<Files>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
