Seltsame User-Agents aussperren, Search-Bots reinlassen

Vor lauter Bots kann man sich als Webseiten-Betreiber zur Zeit ja kaum noch schützen. Die nervigsten und gefährlichsten sperre ich bei unseren Webprojekten seit gewisser Zeit schon über die Webserver-Konfiguration oder .htaccess Datei aus. Beispielsweise die Kennung „Mozilla/4.0“ oder „Mozilla/5.0“ ohne jegliche weitere Information.

Normale Browser-Kennungen, wie beispielsweise die vom Internet Explorer oder von Firefox, beginnen in der Regel auch mit dieser Kennung, beinhalten dann aber weitere Informationen dahinter in Klammern.

Zugriffe, die in der Browser-Kennung keine weitere Information enthalten, sind in der Regel Angreifer-Tools, die als Ziel haben, Sicherheitslücken zu finden oder Spam-Kommentare zu hinterlassen.

Seit kurzem sind mir aber sehr häufig auch Zugriffe aufgefallen, die vom MSNBot, also dem Suchmaschinen-Spider von Bing, Microsoft’s Suchmaschine, kommen – und die sich auch nur mit „Mozilla/4.0“ identifizieren. Den will ich reinlassen.

Glücklicherweise kann man den MSNBot anhand der IP-Adresse identifizieren.

Also sieht meine mod_rewrite-Rule für die .htaccess so aus:

RewriteEngine On

RewriteCond %{REMOTE_ADDR} !^65.55.
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[1-9]\.[0-9]$ [NC]
RewriteRule ^.*$ - [F,L]

Mit der ersten Rewrite Condition wird festgelegt, dass die folgende Regel nur für Zugriffe von IPs gilt, die NICHT Mit 65.55. anfangen.

Die folgende Condition beschränkt das ganze weiter auf User_Agent-Strings, die die Form „Mozilla/“ gefolgt von einer Versionsnummer in der Form „x.y“ (x und y nur einstellie Ziffern) haben.

Und die Rewrite-Rule am Ende legt fest, dass alle derartigen Zugriffe mit einem Forbidden (HTTP Fehler 403) beantwortet werden sollen.

wget und administrative cronjobs

Wer – so wie ich – gerne seine CRON-Tabelle mit Hintergrund-Jobs füllt, die der Server beispielsweise ein mal pro Tag erledigen soll, der sollte gerade in der Kombination wget und PHP-Script etwas aufpassen. Es gibt da einen Fallstrick, der nicht auf den ersten Blick sichtbar ist:

Angenommen, das PHP-Script braucht etwas länger. Und genau das ist ja in der Regel der Fall. Dazu legt man solche Aufgaben in den Hintergrund.

WGET fängt also an, die PHP-Seite abzurufen – und wartet, und wartet, und wartet… Das macht es 900 Sekunden, also 15 Minuten lang. Wenn das Script dann noch nicht fertig ist, dann gibt wget auf zu warten. Und hier kommt der Haken: Es hört dann nicht auf, sondern es versucht es gleich noch mal. Standardmäßig 20 mal.

Wozu das führt ist relativ klar: Es läuft jetzt ein weiterer Prozess, der noch mal das gleiche tut wie der erste Prozess. Der bremst in der Regel den ersten Prozess noch weiter aus und läuft selbst auch langsamer, da er mit dem ersten Prozess konkurriert. Nach 15 Minuten kommt dann der nächste Prozess dazu, alles wird noch langsamer, …

Deshalb immer dafür Sorgen, dass es nur einen einzigen Versuch gibt:
wget --tries=1 --spider http://www.example.com/cronjob.php

Oder alternativ:
curl http://www.example.com/cronjob.php

cURL setzt standardmäßig auf „Nicht wieder Versuchen„.