Böser Bot, guter Bot.

Wenn man gelegentlich in seine Log-Files schaut und betrachtet, was der eine oder andere Bot da treibt, dann fragt man sich wirklich: Geht es noch?

Auf diese Frage erhält man selten eine erhellende Antwort und es bleibt dem Webmaster überlassen, wild gewordene Spider, BetaBots und anderes Ungetüm auszusperren.

Ich befasse mich heute mit der Frage: Nehmen wir die große Keule oder reicht auch ein normaler Hammer? Egal welche Methode, wir sparen Traffic und entlasten den Webserver unseres Hosters.

Methoden

Mit Hilfe der "robots.txt"-Datei Spider auszusperren, erinnert an den Kampf eines gewissen Don Quichotte mit den Windmühlen. Das funktioniert eher selten. Recht unpraktisch ist die Einbettung der Aussperrlösung in das Webdokument (client-abhängiger Inhalt). Im Regelfall heißt das Zauberwort ".htaccess" und ausnahmsweise nicht Bitte!

Apaches Möglichkeiten

Es bietet sich zum einen die Rewrite-Engine [1] an. Das funktioniert nicht bei jedem Provider und ist aus meiner Sicht die Methode mit der Keule. Eleganter ist die Lösung mit Hilfe des Moduls "setenvif", wobei zwei Herangehensweisen möglich sind.

Haargenau

Mit der SetEnvIf-Anweisung und dem Attribut "User-Agent" lässt sich ein bestimmter Client erkennen und entsprechend behandeln. Für die Kennung der Besucher-Software (Bot, Spider, Browser) gibt es eine maßgeschneiderte Lösung: "BrowserMatch". Und das ist unser kleiner und effektiver Hammer. [2]

Browser oder nicht?

Es gibt zwei Direktiven: "BrowserMatch" arbeitet "case-sensitive". Das heißt, dass auf die Groß- und Kleinschreibung des Suchbegriffes geachtet wird. "BrowserMatchNoCase" berücksichtigt dies nicht. In beiden Fällen folgt eine "Regular-Expression"-Anweisung. Das ist der Suchbegriff. Dann setzt man eine Umgebungsvariable. Der Syntax:

BrowserMatch RegEx envvar
BrowserMatchNoCase RegEx envvar

Das Beispiel

Es folgt ein Beispiel-Eintrag für die .htaccess-Datei, den ich im Anschluss erläutere:

BrowserMatch ^CoolBot evil
BrowserMatch internetseer evil
BrowserMatch "^Mozilla\/4\.06 \(Win95; I\)$" evil
BrowserMatchNoCase WebDataCentreBot evil

Order Allow,Deny
Allow from all
Deny from env=evil

In Zeile 1 lege ich fest, dass einem Client, dessen Name mit 'CoolBot' beginnt, die Umgebungsvariable "evil" zugeordnet wird. Der Suchausdruck muss am Anfang der Client-Kennung stehen und exakt so geschrieben sein. Was hinter dem Suchstring steht, ist irrelevant.

In der zweiten Zeile haben wir eine etwas defizilere Konstruktion. Wenn in der Client-Kennung irgendwo das Wort "internetseer" zu finden ist, dann ist der Besucher böse.

Zeile 3 enthält einen "echten" regulären Ausdruck. Wenn der Name des Clients "Mozilla/4.06 (Win95; I)" ist - also genau diese Bezeichnung - dann kommt er in den Club des Bösen. Zu beachten ist, dass der reguläre Ausdruck zu 'escapende' Zeichen enthält. Das ist eine Besonderheit regulärer Ausdrücke.

Die Zeile 4 demonstriert das Ignorieren von Groß- und Kleinschreibung. Egal wie der Bot sich selbst schreibt und an welcher Stelle er seine Kennung platziert, er wird als Badboy eingestuft.

Nachdem ich meine Apathie gegen bestimmte Gäste definiert habe, bin ich Türsteher und sperre aus. Ich lege fest, dass jeder unsere Website besuchen darf, abgesehen von den bösen Jungs bzw. Clients. Diese werden anhand der Umgebungsvariable "evil" abgewiesen (Deny) und bekommen eine 403-Fehler-Meldung serviert. Das war's. Sehr effektiv oder?

403-Fehler anpassen

Wer viele Bots auf seiner Abschussliste hat, der sollte die Meldung für den 403-Fehler modifizieren. Jedes zu viel gesendete Byte ist überflüssig. Vor dem oben notierten Eintrag fügt man diese Zeile ein:

ErrorDocument 403 "403 Forbidden"

Alles, alles, alles

Das Gesamtkunstwerk sieht dann wie folgt aus:

# 403 error message
ErrorDocument 403 "403 Forbidden"

# 403 good bye
BrowserMatch ^CoolBot evil
BrowserMatch internetseer evil
BrowserMatch "^Mozilla\/4\.06 \(Win95; I\)$" evil
BrowserMatchNoCase WebDataCentreBot evil

Order Allow,Deny
Allow from all
Deny from env=evil

Tipps

Wer aussperrt, sollte sich davon überzeugen, dass er den Richtigen erwischt. Es gibt viele sinnvolle Clients. Man sollte sich vorher über den Bot informieren, den man auf seine Liste setzen will.

Man muss damit rechnen, dass ausgesperrte Bots drei Monate später unter neuen Namen wieder auftauchen. Das trifft insbesondere auf Beta-Bots zu, die durchs Netz rammeln.

Besonders wichtig ist es, den Namen des Ungetüms möglichst genau zu notieren. Das verhindert das unfreiwillige Aussperren ahnungsloser Besucher. Ein Selbststudium zur Thematik "Reguläre Ausdrücke" ist hier empfehlenswert.

Und schließlich möchte ich das lokale Testen empfehlen. Seine Konstruktionen sollte man in einer Arbeitsumgebung testen, bevor man sie auf das Web los lässt.

Schlusswort

Es gibt für jedes Problem mehrere Lösungen. Für das anfänglich beschriebene ist die vorgestellte Herangehensweise sehr effizient.

Quellen

[1] Module mod_rewrite (apache.org)
[2] Module mod_setenvif (apache.org)


Deprecated: Directive 'allow_url_include' is deprecated in Unknown on line 0