Tipps und Tricks » Good Bots, Bad Bots » Crawler sperren

Sperren für Spider, Crawler und Bots realisieren

Wie bereits im Artikel "Good Bots, Bad Bots" erläutert schiebe ich die verschiedenen Bots in 3 Schubladen. Der vorliegende Artikel zeigt Maßnahmen gegen "nicht ganz so böse" Bots, genauer gesagt gegen diejenigen, die sich selbst über den User-Agent zu erkennen geben. 

Dazu zunächst ein wenig Hintergrundwissen. Das HTTP-Protokoll ist in RFC 2616 beschrieben. User-Agent heißt eine Variable, die bei der Anfrage an einen Webserver übermittelt werden soll. Damit soll gewährleistet werden, dass der Server auf besondere Eigenheiten des anfragenden Geräts reagieren kann. Das wichtige Wörtchen heißt "soll", und noch wichtiger ist: Der Inhalt dieser Variablen kann sehr leicht gefälscht werden.

Gibt sich also ein Besucher als Bot zu erkennen, ist er (vermutlich) schon mal keiner der schlimmsten Sorte. Vermutlich deshalb, weil die wirklich Bösen sich auch schon mal mit dem User-Agent eines Guten tarnen. Wie man sieht, fischen wir in trüben Gewässern.

Der Fischer verwendet unterschiedliche Maschenweiten für seine Netze, und ich will analog vorgehen. Es gibt etliche Bots, die ich zwar nicht haben will, die sich aber an die Spielregeln halten. Für sie ist robots.txt das Mittel der Wahl. Andere müssen härter angepackt werden.

robots.txt

Es gibt etliche Bots, die ich zwar nicht haben will, die sich aber an die Spielregeln halten. Für sie ist robots.txt das Mittel der Wahl. Andere müssen härter angepackt werden.

In robots.txt kann ich unverbindliche Anweisungen an Bots geben. Der Robots Exclusion Standard und die daraus resultierende Datei  ist in Wikipedia recht gut beschrieben, deshalb hier nur ein paar Anmerkungen aus eigener Erfahrung:

Die Anweisungen werden generell nicht sofort befolgt, und die Bots verhalten sich unterschiedlich. Manche lesen sie vor jedem Scan, andere in Intervallen von bis zu 14 Tagen. Wer dort eine Anweisung einträgt, braucht Geduld.

Ein erheblicher Nachteil ist, dass ich den wirklich Bösen Hinweise auf Angriffsziele liefern kann. Andererseits kann ich auf diesem Wege auch Fallen stellen.

Der große Vorteil: Die Datei gibt es genau einmal pro Domain, die Syntax ist einfach, die Serverlast und damit die Kosten sind gering.

.htaccess

Damit gebe ich Anweisungen an meinen eigenen Apache Webserver. Sie sind verbindlich, werden sofort befolgt und ich kann dem unerwünschten Besucher einen Fehler 403 (Forbidden) statt des angeforderten Inhalts liefern.

Nachteil: Ich brauche diese Datei in jedem Verzeichnis der Domain, die Syntax ist etwas komplexer, und der Mechanismus funktioniert nur bei eingeschaltetem mod_rewrite. Hier ein Beispiel:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_USER_AGENT} ^Spiderlytics
  RewriteRule ^.* - [F,L]
</IfModule>

Über die Flags in eckigen Klammern gebe ich F für Forbidden und L für Last mit. Der Besucher bekommt also einen Fehler 403, danach passiert nichts mehr.

Testen

Nun will ich sehen, ob meine Bemühungen Erfolg haben. Dazu verwende ich üblicherweise wget, ein Programm, mit dem man (unter anderem) Webseiten herunterladen kann. Über den Parameter -U kann ich den User-Agent mitgeben. Beispiel:

wget -U Spiderlytics http://www.shopnix.de

Ausgabe:
--2014-01-22 09:34:47-- http://shopnix.de/
Auflösen des Hostnamen »shopnix.de (shopnix.de)«... 46.4.216.213
Verbindungsaufbau zu shopnix.de (shopnix.de)|46.4.216.213|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 403 Forbidden
2014-01-22 09:34:48 FEHLER 403: Forbidden.

Ciao Bello!

Fortsetzung folgt, es gibt noch engere Maschen!

 

Powered by Etomite CMS.