Google Hacking verhindern, Teil 2
Wie kann man sich vor Google Hacking schützen? Bisher haben Sie bereits erfahren, wie Sie Verzeichnisse schützen können, so dass die Suchmaschinen-Crawler sie ignorieren. In manchen Fällen ist zwar das Crawlen erwünscht, aber die Seiten sollen nicht im Cache der Suchmaschine landen. Auch das ist möglich.
Indexieren ja, archivieren nein!
In der robots.txt legen Sie fest, welche Verzeichnisse
und/oder Dateien von den Suchmaschinen-Crawlern ignoriert werden sollen.
Sollen Seiten zwar von den Suchmaschinen erfasst, aber nicht im Cache
aufgenommen werden, müssen Sie in jeder betroffene Seite ein
entsprechendes META-Tag im HEAD-Bereich angeben. Mit
<meta name='robots' content='noarchive'>verbieten Sie allen Suchmaschinen das cachen der Seite, und mit
<meta name='Googlebot' content='noarchive'>nur Google.
Weitere nützliche Optionen sind
-
<meta name='robots' content='noindex'>
um die Aufnahme einer Seite in den Index zu verhindern (auf der Seite enthaltenen Links wird aber gefolgt), -
<meta name='robots' content='nofollow'>
damit die Seite indexiert, den Links darauf aber nicht gefolgt wird, und -
<meta name='robots' content='noindex, nofollow'>
für Seiten, die nicht in den Index aufgenommen werden sollen und deren Links nicht gefolgt werden soll.
Speziell für den Google-Crawler gibt es noch nosnippet:
<meta name='Googlebot' content='nosnippet'>verhindert, dass Google Ausschnitte übernimmt. Gleichzeitig werden so markierte Seiten auch nicht in den Cache übernommen.
"Sonstiges"
Zum Abschluss möchte ich die verschiedenen Google-Hacking-Techniken durchgehen und jeweils mögliche Schutzmaßnahmen aufzeigen. Los geht es mit den im ersten Teil vorgestellten einfachen Google Dorks. Sofern die auf Versionsinformationen etc. basieren, ist Abhilfe ganz einfach: Lassen Sie die Versionsnummer weg. Welchen Benutzer eine Webanwendung interessiert deren Version? Meist ist noch nicht mal der Programmname von Interesse, aber den wird man wegen des damit verbundenen Copyright-Hinweises selten los.
Wenn ich beispielsweise in einem Webshop einkaufe, interessieren mich vieles: Die angebotenen Waren, deren Preis, Liefer- und Zahlungsbedingungen, die Identität des Anbieters, ... Was mich ganz bestimmt nicht interessiert, ist, ob der Shop nun mit osCommerce, xt:commerce, Zen Cart oder was auch immer läuft.
Das gleiche gilt sinngemäß für die Fehlermeldungen. Die gehören ins Logfile, nicht auf die Webseite. Jedenfalls nicht in aller Ausführlichkeit. Wie viele Besucher Ihrer Website können mit den ausführlichen Fehlermeldungen überhaupt etwas anfangen? Und selbst wenn sie die Fehlermeldung verstehen, was haben sie davon? Reparieren können sie sowieso nichts.
Für die Benutzer reicht der Hinweis, dass ein Fehler aufgetreten ist und die Betreiber der Anwendung darüber informiert wurden. Viel wichtiger als eine Fehlermeldung ist ein Hinweis, wie der Benutzer weiter vorgehen soll. Soll er die Aktion noch einmal durchführen? Was passiert mit gemachten Eingaben - sind die verloren oder gespeichert worden? Geben Sie dem Benutzer hilfreiche Tipps und speisen Sie ihn nicht mit einer für ihn unverständlichen oder zumindest unnützen Fehlermeldung ab!
Alles eben geschriebene gilt analog auch für die in der dritten und vierten Folge beschriebene Möglichkeit, Server zu erkennen. Welcher Server eine Verzeichnisliste ausgegeben hat, ist für den Benutzer doch ziemlich uninteressant. Genauso wie die Fehlermeldungen des Webservers.
Was das im dritten Teil beschrieben "Durchzählen" von Verzeichnissen betrifft, gibt es zwei mögliche Schutzmaßnahmen:
- Speichern Sie nichts auf den Webserver, was nicht auch veröffentlicht werden soll. Für eine zukünftige Veröffentlichung vorgesehene Dateien sind bis zum Veröffentlichungstermin auf einem lokalen Rechner viel besser aufgehoben als auf dem Webserver.
- Wenn Sie schon nicht für die Allgemeinheit bestimmte Dateien auf dem Webserver speichern, schützen Sie sie durch eine Passwortabfrage. Mittels HTTP Basic Authentication geschützten Seiten werden von den Suchmaschinen ignoriert, und auch Angreifer kommen zumindest nicht ohne weitere Mühen an die geschützten Dateien.
Und dass das Intranet nicht im Internet auftauchen sollte, nicht einmal in Teilen, ist wohl auch einsichtig. Ein Passwortschutz verhindert das Auftauchen der internen Seiten im Internet und den Suchmaschinen.
Womit wir zur fünften Folge kommen: Das Erkennen von Webanwendungen an Fehlermeldungen lässt sich durch das Ausschalten der Fehlermeldungen verhindern. Die für die Webanwendung typischen Pfade und/oder Skripte könnte man theoretisch durch eine große Umbenennungsorgie ändern, aber das sollte man besser sein lassen.
Auch bei der in der sechsten Folge beschriebene Suche nach Netzwerkhardware sind wieder unnötige Fehlermeldungen im Spiel. Da gilt, wie früher bei Peter Lustig am Ende von "Löwenzahn": "Ausschalten".
Bei Geräten, die entweder gar nicht ans Internet angeschlossen oder zumindest nicht ohne vorherige Authentifizierung zugänglich sein sollten, dürfte die Abhilfe klar sein: Stecker ziehen oder eine Authentifizierung erzwingen.
Kommen wir zu den interessanten Dateien aus dem siebten Teil. Wie man deren Aufnahme in die Suchmaschinen verhindert, wurde bereits beschrieben. Oft gibt es aber eine einfachere Lösung: Die Dateien gar nicht erst auf dem Webserver speichern oder sie mit einem Passwortschutz versehen.
Und damit ist das Thema "Google Hacking" auch abgeschlossen. Um was es in der nächsten Folge gehen wird, habe ich noch nicht entschieden.
Übersicht über alle Artikel zum Thema
- Google Hacking, ganz einfach
- Google Hacking - The Next Generation
- Google Hacking: Verzeichnislisten und Intranets
- Google Hacking: Webserver finden
- Google Hacking: Webanwendungen finden
- Google Hacking: Portale und Netzwerkhardware finden
- Google Hacking: Interessante Dateien finden
- Google Hacking verhindern: Verzeichnisse schützen
- Google Hacking verhindern, Teil 2
Trackbacks