Die Auswirkung der Apache-Konfiguration auf die Sicherheit der Webanwendung
Kommentare

Und das, was wir manuell können, kann auch HTExploit. Mit der Einschränkung, dass das Tool eine Liste möglicherweise vorhandener Dateien durchgeht und dadurch test.inc.php nicht findet, (siehe Listing

Und das, was wir manuell können, kann auch HTExploit. Mit der Einschränkung, dass das Tool eine Liste möglicherweise vorhandener Dateien durchgeht und dadurch test.inc.php nicht findet, (siehe Listing 11 und Abb. 2 und 3).

Listing 11: HTExploit im Einsatz
ceilers$ python htexploit -u http://localhost/~ceilers/Access-Test/ 

H H TTTTTT EEEE l t 
H H TT E l ii t 
HHHH TT EEE x x ppp l ooo ttt 
H H TT E x p p l o o ii t 
H H TT EEEE x x ppp l ooo ii tt 
p 
p v0.7b

[+] http://localhost/~ceilers/Access-Test/ seems exploitable. Enjoy :)

Would you like to run the 'full' scan module? [Y/n] Y

[+] Full Scan Completed.
[+] 1 files were downloaded, out of 750 (0% success rate). Report was saved in '/Users/ceilers/Documents/ceilers-it/Tools/HTExploit_v0.7b/htexploit-73659'

ceilers$
Abb. 2: Das Ergebnis von HTExploit
Abb. 3: Die einzige von HTExploit geladene Datei

Durch Analyse der heruntergeladenen Dateien können auch alle darin verlinkten PHP-Skripte aus dem geschützten Bereich aufgerufen werden. Allerdings scheint es in manchen Berichten über das Tool einen entscheidenden Irrtum zu geben: Die Skripte werden nicht als Sourcecode heruntergeladen, sondern ganz normal von PHP ausgeführt, erst das Ergebnis wird „heruntergeladen“ (bzw. genauer: Von PHP an den Client, in diesem Fall HTExploit, gesendet). Und auf andere Dateitypen ist gar kein Zugriff möglich. Die Gefahr, an vertrauliche Daten wie z. B. Datenbankzugangsdaten zu gelangen, ist also ziemlich gering, da die ja wohl hoffentlich korrekt geschützt sind, z.B. wie im Beispiel test.inc.php.

Trotzdem sollte man die Gefahr nicht unterschätzen. HTExploit ist in der Lage, GET-Requests an die PHP-Skripte in durch die .htaccess-Datei geschützte Verzeichnisse zu schicken. Nicht mehr, aber auch nicht weniger. Das bedeutet auch, dass die Skripte darin im Rahmen dieser Einschränkung (nur GET, kein POST) auf mögliche Schwachstellen untersucht und diese ggf. ausgenutzt werden können. Und das kann bei Testversionen oder auch alten Versionen der im offenen Bereich genutzten Skripte durchaus eine Gefahr darstellen. Kommen wir jetzt noch zu den weiteren schon 1997 veröffentlichten Konfigurationsproblemen [14].

Request-Methoden für CGI-Skripte

CGI-Skripte sollten ggf. prüfen, über welche Request-Methode sie aufgerufen wurden und beim Aufruf mit einer falschen Methode eine Fehlermeldung zurückgeben. Ansonsten können sie mit einer falschen Methode aufgerufen werden, wodurch Zugriffsbeschränkungen umgangen oder falsche Daten zurückgesendet werden könnten. Achten Sie dabei darauf, dass die Namen der Request-Methoden Case-Sensitive sind, die Methode get ist also nicht die Gleiche wie die Methode GET. Laut HTTP-Standard sind nur Methoden in Großbuchstaben definiert [15]. Wird ein CGI-Skript mit der Methode HEAD aufgerufen, muss es keinen Response-Body ausgeben. Es ist aber nicht schlimm, wenn es das doch tut, da der Apache ihn ignoriert und nur die Header als Antwort an den Client schickt.

Zugriffsbeschränkungen auf Basis des Hostnames

Für allow– und deny-Anweisungen kann der Hostname als Grundlage für die Zugriffsbeschränkungen verwendet werden. Dabei muss der angegebene Hostname dem Ende des vom Benutzer gelieferten Hostnames entsprechen. Betrachten wir dazu das folgende Beispiel:

order deny,allow
deny from all
allow from server.example

Diese Regeln erlauben, wie erwartet, Requests von server.example, zusätzlich aber auch solche von www.server.example, blog.server.example usw. Das mag noch nicht schlimm sein, aber: Erlaubt sind generell alle Zugriffe von Hosts mit einer auf server.example endenden Adresse, also auch von ganz anderen Domains wie z. B. boeserserver.example. Wenn Sie eine derartige Regel für ihre-domain.example verwenden, kann ein Angreifer z. B. nichtihre-domain.example registrieren und darüber die Zugriffsbeschränkung umgehen.

Es ist nicht möglich, den Zugriff explizit auf server.example zu beschränken, aber durch Verwendung von .server.example kann zumindest sichergestellt werden, dass Zugriffe auf die gewünschte Second-Level-Domain beschränkt werden.

Einfacher ist es aber, die IP-Adressen der Hosts für die Zugriffsbeschränkung zu verwenden. Das spart auch DNS-Abfragen, denn beim Verwenden eines Hostnames läuft die Prüfung folgendermaßen ab:

  • Der Request enthält nur die IP-Adresse des anfragenden Hosts; der Webserver muss den Hostnamen daher über eine Reverse-DNS-Abfrage abfragen
  • Das Ergebnis der Reverse -DNS-Abfrage wird mit den Angaben in der .htaccess-Datei verglichen

Bei einer Zugriffsbeschränkung auf Grundlage der IP-Adresse entfällt die Reverse-DNS-Abfrage und der Webserver kann sofort entscheiden, ob der Request zulässig ist oder nicht.

Weitere Konfigurationen

Kommen wir nun noch zu einigen weiteren sicherheitsrelevanten Konfigurationsoptionen:

  • Deaktivieren Sie alle nicht genutzten Module: Was nicht vorhanden ist, kann auch nicht angegriffen werden; achten Sie vor allem auf mod_info und mod_status, da die einen Angreifer mit nützlichen Informationen versorgen können
  • Schränken Sie AllowOverride auf das Benötigte ein
  • Schalten Sie die Indexierung aus, damit beim Fehlen der Default-Seite kein Verzeichnis-Listing ausgegeben wird (es sei denn, sie wollen wirklich das Verzeichnis ausgeben)
  • Schalten Sie das Verfolgen symbolischer Links aus, die könnten u. U. zu Orten im Dateisystem führen, die Sie nicht im Web sehen möchten.

Ob Sie die Serversignatur durch Angabe von „ServerSignature Off“ in der httpd.conf ausschalten, wie es oft empfohlen wird oder nicht, ist letztlich Geschmacksache. Nur weil ein Angreifer nicht sofort erkennt, um welche Apache-Version es sich handelt, verschwinden ja evtl. vorhandene Schwachstellen nicht. Die können immer noch ausgenutzt werden, ggf. probiert der Angreifer einfach alle möglichen Exploits durch. Und dass es sich beim Webserver um einen Apache handelt, verrät der SERVER-HTTP-Header immer. Wenn Sie die Serversignatur ausschalten, müssen Sie ggf. auch die Versionsinformationen aus den Default-Fehlermeldungen entfernen, sofern sie nicht sowieso eigene verwenden. Ansonsten können Sie sich das Ausschalten der Serversignatur sparen. Das Gleiche gilt für die Versionsnummer im SERVER-HTTP-Header, ggf. muss ServerTokens auf ProductOnly gesetzt werden. Wenn Sie keine Versionsinformationen ausgeben, müssen mod_info und mod_status ausgeschaltet sein. Auch die Onlinedokumentation verrät die Version, muss also entweder entfernt oder mit einem Zugriffsschutz versehen werden.

Übrigens ist es kein Problem, dass der Webserver sich als Apache zu erkennen gibt. Die Webserver lassen sich ggf. auch ohne ausgegebenen Namen und Versionsinformationen über Fingerprinting identifizieren [16]. Lediglich die Bestimmung der genauen Version ist über Fingerprinting kaum möglich.

Eine ausführliche Checkliste zur sicheren Konfiguration des Apache-Webservers gibt es vom Bundesamt für Sicherheit in der Informationstechnik (BSI) [17], die Übersichtsseite dazu finden Sie unter [18].

Fazit

Wer seine Webanwendung vor Angriffen schützen will, muss auch auf den Webserver achten. Und wie man am Beispiel von HTExploit sieht, können selbst altbekannte Probleme plötzlich zu einer akuten Gefahr werden. Wobei es in diesem Fall eine zusätzliche Gefahr gibt: Die vielen falschen Anleitungen zum Einrichten des Passwortschutzes im Internet. Es wird immer wieder neue falsch konfigurierte Server geben, denn die meisten falschen Anleitungen sind uralt und seit Jahren nicht mehr aktualisiert worden. Was kein Problem wäre, wenn sie korrekt wären, denn an der Konfiguration des Apache hat sich ja nichts geändert, und die vor Jahren korrekt formulierten Anleitungen sind immer noch aktuell.

Aber zurück zum eigentlichen Thema, der Konfiguration des Webservers. Eigentlich sollte ein einmal sicher konfigurierter Server für einen längeren Zeitraum sicher bleiben, neue Angriffe bzw. Schwachstellen mal außen vor gelassen. Aber auf die muss man ja immer vorbereitet sein und angemessen reagieren.

Schalten Sie also die TRACE-Methode aus, passen Sie ggf. die .htaccess-Dateien an und gehen Sie die Checkliste des BSI durch. Dann sollten Sie für einige Zeit einen sicherkonfigurierten Webserver für Ihre Webanwendung haben. Dass der dann regelmäßig auf den aktuellen Stand gebracht werden muss, was ggf. auch Anpassungen an der Konfiguration erfordert, dürfte sich von selbst verstehen. Im Allgemeinen werden sich die nötigen Konfigurationsänderungen aber in Grenzen halten.

Dipl.-Inform. Carsten Eilers ist freier Berater und Coach für IT-Sicherheit und technischen Datenschutz und Autor einer Vielzahl von Artikeln für verschiedene Magazine und Onlinemedien. Sie erreichen ihn unter www.ceilers-it.de, sein Blog finden Sie unter www.ceilers-news.de.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -