Unfreundliche Web-Crawler aussperren

[vgwort line=“10″ server=“vg08″ openid=“50d0f7ff771346ceb5b70eb28aab7541″]

Beim Auswerten der Webalizer Statistiken sind mir Angriffe und verschiedene Suchmaschinen aufgefallen, von denen ich noch nichts gehört hatte. Die Angriffe gingen in der Regel gegen phpMyAdmin Installationen. Die laufen bei mir jedoch ins Leere. Über diese Angriffe schreibe ich später, d.h. in einem anderen Artikel. Heute soll es um eine spezielle Suchmaschine gehen.

Web-Crawler

Unter den Web-Crawlern stach der Pixray-Seeker™ heraus und ich habe mich gefragt: Was ist so toll an meinen Seiten, dass dieser Web-Crawler mehrfach täglich vorbei schaut?

Eine Suche bei Google und die Seite www.pixray.com brachte schnell die Antwort: Das Geschäftsmodell dieser jungen, dynamischen deutschen Startup-Firma ist die Suche nach urheberrechtlich geschützten Grafiken / Bildern gegen Geld.

Die Homepage der Firma Pixray ist – noch – recht dürftig und ich fand keinen Hinweis, dass sie die robots.txt¹ beachten. Nach meinen Beobachtungen hält der Web-Crawler sich an die robots-txt. Auf einem Server, der alle Crawler aussperrt, liest er nur die robots.txt. Dies jedoch mehrfach täglich. Die Kundeninformation ist ausbaufähig und ein positives Beispiel fand ich bei 80legs.

Eine weitere Suche nach dem Pixray-Seeker führte mich zu Barrierefreie Weblösungen. Hier gibt es eine lebhafte Diskussion über diesen Crawler, die mich auf die Idee brachte ihn – und einige Angriffe – zu sperren und mich endlich mit dem Module rewrite des Apache auseinander zu setzen. Es war eine lange Auseinandersetzung, bei der ich mir ins Knie geschossen, aber nicht aufgegeben habe².

Zwar habe ich nur eigene oder lizenzfreie Bilder auf meinen Server, aber gut finde ich es nicht, dass eine private Firma laufend Hausdurchsuchungen auf meinen Servern betreibt. Immerhin muss ich für die von denen benötigte Bandbreite zahlen. Da ich nicht einsehe, warum sich jemand bei der Suche nach Urheberrechtsverstößen an einen Ausschluss über die robots.txt hält, muss der Weg etwas handfester sein. Fraglich ist, wie lange sich eine Firma, die ihr Geld mit der Aufdeckung von Urheberrechtsverstößen verdient, aussperren lässt. Wenn sie von zu vielen gesperrt wird, ist ihr Geschäft in Gefahr.

Leider ist dies bei einem unkooperativen Besucher nicht so leicht. Grundsätzlich hilf die IP-Adresse, aber Suchmaschinen bestehen oft aus vielen Tausend Rechnern³. Wenn alle Adressen über eine Blacklist geblockt werden sollen, muss eine optimierte Suche stattfinden oder die Last durch die Adresssuche wäre erheblich. Die Pflege einer solchen Liste wäre nur in Kooperation mit dem Betreiber des Crawler-Grid möglich. Der Betreiber braucht sich nur weitere, neue Adressen zu suchen und schon ist die Sperre wirkungslos. Wenn man eigentlich jedem Unbekannten das Lesen erlaubt, ist das sichere Verbieten für bestimmte, ggf. unkooperative Nutzer unmöglich. Es muss daher eine gewisse Mindestkooperation vorausgesetzt werden. Hier führt der einfache Weg über die Angabe des User-Agent (UA) im Aufruf der Seiten.

In der robost.txt ist dies recht einfach – ich nehme an, dass der Pixray-Seeker auch auf „Pixray-Seeker“ hört:

User-Agent: Pixray-Seeker
Disallow: /

Leider ist die Interpretation der robots.txt nicht einheitlich. Siehe die Beschreibung RES bei wikipedia. Als Wildcard wird ein Stern für „alle User-Agents“ einheitlich interpretiert. Bei den Pfadangaben werten manche Crawler den * aus. Fragt sich nur wie: Ob ich „u*“ und „u.*“ schreiben muss, ist der gewaltige Unterschied zwischen: „Funktioniert“ – „Funktioniert nicht“.

In der Serverkonfigurationsdatei oder der .htaccess hilft eine rewrite Regel auf der Basis des UA. Um dem Crawler eine Fehlermeldung zurückzugeben oder auf dummy-Seiten oder harmlose Bilder zu lenken.

Das folgende Beispiel demonstriert, wie man dem Hund nicht einfach eine Fehlermeldung „Not found“ zurück gibt, sondern einen Knochen vorwirft. Immer wenn der Pixray-Seeker ein Bild anfragt, wird statt des Original-Bildes ein Zufallsbild, das durch ein php-Script erzeugt wird, ausgegeben.

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} .*[Pp]ixray.*
RewriteRule (.*\.jpg) /dummyjpeg.php?bild=$1

Mein php-Script erzeugt einfach ein Zufallsbild mit bis zu 100 weißen Linien auf schwarzem Grund. Und nun das Script:

Update: 2021-10-05

Das Script war etwas in die Jahre gekommen und funktioniert mit neueren PHP-Versionen nicht mehr. Erstens muss php-gd auf dem Server installiert werden und zweites darf in imagejpeg($image,null,10); kein Leerstring („“)mehr stehen, sondern für die direkte Ausgabe muss null übergeben werden.

<?php
header("Content-Type: image/jpeg");
// Erzeugen eines zufälligen Bildes für Schnüffler
// Thomas Arend
// (c) 2012-2021


if (!$_GET['bild']) { $quelle ='' ; }
else { $quelle = urldecode($_GET['bild']) ;} ;

if ( $quelle != '' AND is_file ( $quelle ) ) {
$bildinfo = getimagesize ($quelle );
$width = $bildinfo[0];
$height = $bildinfo[1];
}
else {
$quelle = 'dummy.jpg';
$width = 1024 ;
$height = 768 ;
};

$image = imagecreate($width,$height);
$black = imagecolorallocate($image,0,0,0);
$white = imagecolorallocate($image,255,255,255);
$red = imagecolorallocate($image,255,0,0);

imagefill($image, 0,0,$black);

srand ( (double)microtime () * 1000000 );

for ($i= 1 ; $i <= rand (1,100) ; $i++ ) {

imageline
( $image ,
rand( 0,$width) ,
rand( 0,$height) ,
rand( 0,$width) ,
rand( 0,$height) ,
$white ) ;

}

imagestring ( $image, 5, 10, 10 , $quelle . ' - (c) 2012-2021 -Thomas Arend', $red );
imagestring ( $image, 5, 12 , 12 , $quelle . ' - (c) 2012-2021 -Thomas Arend', $white );

// imagejpeg($image,"",10); alter Aufruf
imagejpeg($image,null,10);
imagedestroy($image);

?>

Angriffe auf phpMyAdmin

Für Angriffe auf phpMyAdmin verwende ich folgende Rewrite Regel, die zwar nicht alles, aber viele Versuche abdeckt:

RewriteEngine On
RewriteRule php[Mm]y[Aa]dmin /dummy.php

Aber zu diesen Angriffen später mehr.