Der Port 80 ist ein Tor zur Welt. Hier nimmt üblicherweise ein Webserver wie der Apache Anfragen entgegen und verarbeitet diese. Über diesen Port können aber auch Eindringlinge ins System gelangen. Die docken mit ihren kriminellen Ziele häufig nicht am Webserver an, sondern bei Add-ons, CGI-Skripten oder dem eigentlichen Betriebssystem. Damit das nicht passiert oder zumindest sehr unwahrscheinlich ist, achten Sie darauf, den Apache entsprechend resistent zu machen. Dazu gibt es verschiedene Möglichkeiten.
Wenn Sie anderen Benutzern außer root erlauben, die Rechte von Dateien zu ändern, die sonst nur root ausführen darf, können Sie in Kalamitäten kommen. Das gilt für Unix generell. Auf den Webserver Apache bezogen heißt das: Ein Angreifer könnte die Programmdatei so ändern, dass beim nächsten Start ein anderes Programm abläuft, Log-Daten überschreibt oder löscht. In unserem Workshop zeigen wir, wie Sie Webserver und Mail-Systeme richtig gegen Angriffe absichern.
Lese- und Schreibrechte für den Apache
Um das Ändern von Programmdateien zu verhindern, setzen schon die Standarddistributionen die Lese- und Schreibrechte sinnvoll. Wer Apache aber aus den Quellen installiert, muss aber auf die korrekten Verzeichnis- und Dateirechte achten. Welche Verzeichnisse das bei welcher Distribution beziehungsweise bei welchem Betriebssystem betrifft, steht detailliert im Apache-Wiki.
Der Apache-Server muss alle seine Konfigurationsdateien lesen können. Ebenso alle Dateien, die er darstellen soll - das betrifft sowohl HTML- und CSS-Dateien als auch verlinkte Dokumente und Bilder. Der Webserver beziehungsweise der dafür vorgesehene Benutzer (unter Debian und Ubuntu ist das www-data) sollte die Konfigurationsdaten allerdings nicht schreiben können. Daher sollte der Webserver auch nicht der Eigentümer der Konfigurationsdaten sein. Das bedeutet, wenn Sie den Webserver mithilfe der Quellen installieren: Legen Sie als Besitzer der Konfigurationsdateien root fest. Die Gruppe und alle anderen erhalten nur Leserechte. Das geschieht mithilfe des Befehls
chmod 644 APACHE-KONFIGURATIONSDATEI(EN)
Normalerweise läuft der Webserver als root und schaltet erst dann auf den mit der User-Direktive bezeichneten Nutzer um. In dem Fall braucht er nicht einmal spezielle Schreibrechte für seine Log-Dateien. Für CGI- oder PHP-Skripte, die der Webserver ausführt, gilt: Diese benötigen keine Ausführungsrechte, denn sie werden vom Webserver interpretiert und ausgeführt.
Content-Management-Systeme (CMS) und andere Webanwendungen, die mithilfe eines Webbrowsers verwaltet und mit Inhalten versehen werden, verlangen indes Schreibrechte für den Webserver-User auf bestimmte Verzeichnisse. In so einem Fall haben Sie zwei Möglichkeiten: Entweder Sie ändern den Besitzer des Verzeichnisses mit:
chown -R Webserver-User VERZEICHNIS
Damit wechselt das Verzeichnis sowie rekursiv (Option -R) alle Unterordner zum Besitzer "Webserver-User". Der heißt in vielen Linux-Distributionen "www" oder auch "www-data".
Die zweite Möglichkeit: Sie ändern die Gruppe für das Verzeichnis auf die Gruppe, in der der Apache-Webserver ist, und erteilen Schreibrechte für die Gruppe auf das Verzeichnis und seine Unterordner:
chgrp -R Webserver-Gruppe VERZEICHNISchmod -R g+w VERZEICHNIS
Allerdings ist hier Vorsicht geboten. Denn Verzeichnisse, in die der Webserver schreiben darf, sind typische Angriffsziele: Wenn es jemand schafft, ein PHP-Skript ins sogenannte Document-Root-Verzeichnis zu laden, kann es von extern einfach über den Browser gestartet werden, und Ihr Webserver führt den Code des Angreifers aus.
Das Document-Root-Verzeichnis ist der Haupt-Dokumentenbaum, der im Web sichtbar ist und aus dem heraus Dateien ausliefert werden. In der Apache-Konfiguration wird er mit "DocumentRoot VERZEICHNIS" angegeben. Voreingestellt in Apache ist das Verzeichnis /usr/local/apache/htdocs, in Debian ist es das Verzeichnis /var/www. "DocumentRoot" wird als Konfigurationsdirektive in der gesamten Serverkonfiguration ebenso benutzt wie für virtuelle Hosts. Greift nicht eine Alias-Direktive, hängt der Server die Pfade aus der angeforderten URL direkt an das Wurzelverzeichnis an und bildet so den Pfad zum Dokument. Ein Host-Zugriff auf www.mein_host.de/bilder/index.hmtl würde auf dem Server in einer Standard-Apache-Installation die Datei /usr/local/apache/htdocs/bilder/index.hmtl im Browser anzeigen.
Für viele Webanwendungen ist es nicht nötig, dass der Webserver Schreibrechte auf das Verzeichnis hat. Anstatt beispielsweise Plugins über den Browser zu installieren, kann man diese auch per SSH hochladen und dann selbst auf dem Server entpacken. Die Apache-Dokumentation führt als Beispiel das Joomla-CMS an. Das will seine Konfigurationsdatei ins Document-Root-Verzeichnis schreiben; wird ihm das aufgrund fehlender Rechte verweigert, zeigt es die Konfiguration im Browser an, und der Nutzer kann sie speichern und händisch hochladen.
Risiken von Server Side Includes (SSI)
CGI-Skripte und SSI (Server Side Includes) bergen einerseits Sicherheitsrisiken. Andererseits sind SSI bei Homepage-Betreibern vor allem deswegen beliebt, weil man mit ihnen schnell dynamische Seiten erzeugen kann. Per SSI kann beispielsweise das Datum abgefragt, ein CGI-Programm gestartet oder sogar ein Shell-Befehl ausgeführt werden. SSI-Direktiven werden direkt von einer HTML-Seite ausgeführt, sobald diese im Browser angefordert wird. SSI muss lediglich mit
Options +Includes
in der Apache-Konfiguration eingeschaltet sein. Dann sind zum Beispiel solche Kommandos innerhalb des HTML-Codes möglich:
<pre>
<!--#exec cmd="Irgendein-CGI-Skript" -->
</pre>
Ein Nachteil von SSI ist, dass alle Dateien zunächst von Apache auf SSI-Inhalte geparst werden - unabhängig davon, ob SSI-Direktiven drinstehen oder nicht. Das erhöht die Serverlast und kann sich vor allem auf Rechnern negativ auswirken, auf denen mehrere Webserver arbeiten, etwa virtuelle Maschinen bei einem Hoster. Dem kann man vorbeugen, indem man den SSI-fähigen Seiten andere Endungen gibt, etwa "shtml", und das in der Konfiguration entsprechend berücksichtigt:
AddType text/html .shtmlAddOutputFilter INCLUDES .shtml
Außerdem empfiehlt es sich, die Option explizit auf ein gewünschtes Verzeichnis anzuwenden. Der Grund: Optionsdirektiven können einander überschreiben. So kann es passieren, dass eine zuvor abgeschaltete Direktive weiter hinten in der Konfiguration wieder eingeschaltet wird.
Eine weitere Möglichkeit: Schalten Sie die Ausführung von Skripten und Programmen aus SSI-fähigen Seiten einfach ab. Ersetzen Sie dazu in der Optionsdirektive "Includes" durch "IncludesNOEXEC".
Risiken von Common Gateway Interface (CGI)
Die Optionsdirektive "IncludesNOEXEC" verhindert SSI, aber nicht das Ausführen von CGI-Skripten. Denn die können mit
<-- #inlcude virtual="Irgendein-CGI-Skript" -->
noch gestartet werden, wenn die Skripte in einem Verzeichnis liegen, das mit der ScriptAlias-Direktive festgelegt wurde. Wenn Sie CGI-Skripte auf dem Webserver einsetzen, sollten Sie dem Programmierer unbedingtes Vertrauen entgegenbringen. Denn CGI-Skripte können beliebige Befehle mit den Benutzerrechten des Webservernutzers ausführen und somit prinzipiell sehr gefährlich sein.
Darüber hinaus laufen alle CGI-Skripte mit denselben Benutzerrechten und können sich daher gegenseitig ins Gehege kommen. Hier gibt es seit Apache 1.2 zwei Lösungen: suEXEC und CGIWrap.
Mit dem suEXEC-Wrapper laufen jedes CGI-Programm und jede SSI-Direktive nur mit der Benutzer-ID des Webservers. Anfragen an den Wrapper kann der Administrator weiterleiten, indem er innerhalb eines virtuellen Hosts eine SuexecUserGroup definiert, etwa so:
SuexecUserGroup USER GRUPPE
oder mit der UserDir-Direktive Benutzerverzeichnisse festlegt. Die Direktive
UserDir /home/*/webUserDir disabled root
in der Konfiguration definiert zum Beispiel im Home-Verzeichnis jedes Benutzers (*) das web-Verzeichnis für den eigenen Webauftritt. Dieses wird dann im Browser angezeigt, wenn man
http://meinhost.de/~BENUTZER/
eingibt. Ganz wichtig ist die zweite Zeile der Direktive. Dieser Befehl schließt ab der Apache-Version 1.3 das Home-Verzeichnis des Benutzers root explizit aus. Sonst besteht die Gefahr, dass man nach der Eingabe
http://meinhost.de/~root
im Wurzelverzeichnis des Systems landet.
Sicherheitsrisiko .htaccess
Viele Anwender meinen, man müsse und solle mithilfe der sogenannten .htaccess-Dateien die Benutzerauthentisierung regeln. "This is simply not the case", schreiben die Entwickler in der Apache-Dokumentation. Die .htaccess-Dateien sollte man nur dann nutzen, wenn die Webserverkonfiguration nicht häufig geändert werden soll und die Nutzer die Änderungen selbst durchführen - etwa bei Hostern.
Prinzipiell empfehlen die Apache-Entwickler, auf .htaccess-Dateien zu verzichten. Die Direktive
<Directory />
AllowOverride None
</Directory>
in der Serverkonfiguration lässt keine .htaccess-Dateien zu, außer in Verzeichnissen, die gesondert angegeben sind. Ohne diese Direktive leidet die Geschwindigkeit. Denn mit "AllowOverride" durchsucht der Apache jedes seiner Verzeichnisse nach diesen Dateien, auch wenn dort keine stehen. Zusätzlich wird jedes Mal, wenn im Browser ein Dokument angefordert wird, auch die .htaccess-Datei geladen. Und um alles komplett zu machen: Der Webserver sieht auch noch in jedem darüberliegenden Verzeichnis nach .htaccess-Dateien, um ja keine darin stehende Direktive zu übersehen.
Außer dem Geschwindigkeitsnachteil sehen die Entwickler noch ein Sicherheitsproblem: "AllowOverride" erlaubt es den Nutzern, die Serverkonfiguration zu ändern. Dann hat der Administrator eventuell keine Kontrolle mehr über den Rechner.
Wollen Sie .htaccess-Dateien vermeiden, können Sie die Einträge stattdessen in einem <Directory>-Bereich definieren. Das sieht kaum anders aus. Ein .htaccess-Eintrag wie "AddType text/plain .txt" würde in einem <Directory>-Bereich zum Beispiel so aussehen:
<Directory /www/htdocs/texte>AddType text/plain .txt</Directory>
Schotten dicht
Wenn Sie den Webserver nur auf dem eigenen Rechner einsetzen wollen, schalten Sie den externen Zugriff einfach aus. Das geschieht mithilfe der Listendirektive in der Serverkonfiguration. Mit dieser Anweisung werden IP-Adressen und Port-Nummern festgelegt, auf denen der Webserver auf Anfragen wartet. In Debian und Ubuntu steht die Listendirektive in der Datei /etc/apache2/ports.conf (wo die Konfigurationsdaten in anderen Distributionen und Betriebssystemen zu finden sind, steht im bereits eingangs erwähnten Wiki):
NameVirtualHost *:80Listen 80
Um das Tor zur Außenwelt zu schließen, ändern Sie diesen Eintrag in:
Listen 127.0.0.1:80
Nach dem Sichern der Konfiguration und einem Neustart beantwortet der Webserver nur noch die Anfragen des Localhosts. Wollen Sie stattdessen den Apache in einem lokalen Netzwerk oder Subnetz einsetzen, hilft die Direktive "Allow from" aus dem Apache-Modul mod_authz_host, das es seit der Version 2.1 gibt. "Allow from" können Sie in den Konfigurationsbereichen <Directory>, <Files> und <Location> verwenden, etwa so:
<Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from 147.10 192.168.0 RedirectMatch ^/$ /apache2-default/ </Directory>
Nach einem Neustart des Webservers haben nur Rechner aus dem IP-Adressbereich 147.10.* und 192.168.0.* Zugriff auf das Webserververzeichnis. Falls Sie lieber mit Realnamen arbeiten, können Sie statt des IP-Adressbereichs auch den Domain-Namen angeben:
Allow from intern.net
Tipp zum Schluss: Listen lesen
Schließlich sollten Sie, wie bei jeder anderen Webanwendung auch, die "Apache HTTP Server Announcements List" mit Informationen über neue Versionen und Sicherheitslücken zum Apache-Webserver lesen.
Die Mailing-Liste können Sie auf der Apache.org-Website abonnieren. Die Informationen dort erhalten Sie zumeist auch auf den Security-Listen Ihrer Linux-Distribution, allerdings immer mit Verzögerung, denn die Software wird erst auf der entsprechenden Distribution kompiliert. (hal)
Dieser Artikel basiert auf einem Beitrag der CW-Schwesterpublikation TecChannel.