Veröffentlicht am

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.

Veröffentlicht am

Mit der .htaccess gegen Hotlinking von Bildern

Es gibt ein paar unbelehrbare, die der Meinung sind, dass man Dateien – insbesondere Bilder – von anderen Servern einfach so in die eigene Webseite „reinladen“ kann. Ist ja technisch kein Problem – sogar gewollt. Von der rechtlichen Fragestellung mal ganz abgesehen sieht es aber so aus, dass derjenige, der die Dateien auf seinem Webserver liegen hat, den Traffic bezahlen muss, den der verursacht, der die Bilder in seiner Webseite verwendet. Von der Rechenleistung und der Netzwerkbandbreite mal ganz zu schweigen.

Was kann man dagegen tun?

Erstens kann man natürlich denjenigen Kontaktieren, der die Daten verwendet. Der ist oft aber gar nicht aufzuspüren.

An dem Punkt helfen dann technische Maßnahmen. So weit auf dem Webserver mod_rewrite installiert ist reichen zwei einfache Zeilen in der .htaccess.

Da die Problemkinder oft Grafiken sind, gibt es eine wirksame, eigentlich ganz unterhaltsame Option: Statt der angeforderten Grafik verschickt man eine andere, riesig große Grafik in grausamen Farben. Wenn man die einfarbig hält, dann bleibt die Dateigröße auch bei einer hohen Pixelzahl schön klein – in der Regel wesentlich kleiner als die zu ersetzende Datei. Und wenn alles gut läuft, dann will die Ersatzgrafik sowieso niemand sehen, also wird sie auch nicht so oft abgerufen 🙂

Also: Datei hochladen und folgende Zeilen in die .htaccess:

RewriteCond %{HTTP_REFERER} bandbreiteklauer\.com [OR,NC]
RewriteCond %{HTTP_REFERER} beepworld\.de [OR,NC]
RewriteCond %{HTTP_REFERER} facebook\.com [NC]
RewriteRule jpg$ /dont_hotlink.png [L]

Dabei einfach „bandbreiteklauer\.com“, „beepworld\.de“ und „facebook\.com“ durch die Domains der Bösewichte ersetzen. Will man mehr oder weniger Server aussperren, dann einfach weitere Zeilen mit RewriteCond einfügen. Es ist nur wichtig, dass die letzte Zeile am Ende nur [NC], alle anderen aber [OR,NC] enthalten, damit das ganze als ein zusammengehörender Block gehandhabt wird.

Veröffentlicht am

Sinnlosen Bot-Traffic vermeiden

Im WWW wimmelt es inzwischen ja nur so von verschiedenen Bots. Manche füttern Suchmaschinen, manche machen anderes. Manche sind sinnvoll für Webseiten-Betreiber, manche nicht.

Ich habe inzwischen angefangen, besonders sinnlose, störende oder sogar schädliche Spider auszusperren, die unsere Webseiten herunterladen wollen. Immerhin verbrauchen die unsere Bandbreite und unsere Rechenleistung, die wir an anderer Stelle besser einsetzen können.

Einige Bots sind ja noch so nett und schauen erst mal in die robots.txt, ob sie Daten abrufen dürfen. Andere greifen einfach zu. Und die allerschlimmsten sind die, die sich noch nicht mal als Bot identifizieren. Gegen die ist nicht so leicht anzukommen – denn man erkennt sie einfach nicht.

Ein paar von dieser Sorte sperre ich grundsätzlich in der .htaccess anhand der IP aus:

SetEnvIfNoCase Remote_Addr "^82.99.30." banned
SetEnvIfNoCase Remote_Addr "^69.58.178." banned
SetEnvIfNoCase Remote_Addr "^69.84.207." banned
SetEnvIfNoCase Remote_Addr "^91.205.124." banned
SetEnvIfNoCase Remote_Addr "^86.162.11.102" banned
SetEnvIfNoCase Remote_Addr "^82.99.30." banned

order allow,deny
allow from all
deny from env=banned

Das ist allerdings nur ein Tropfen auf den heißen Stein… Diese IPs sind sehr spezifisch und sind einfach ein paar, die mir negativ aufgefallen sind.

Bei den folgenden Bots / User Agents ist das einfacher. Damit diese Regeln funktionieren muss vorher mod_rewrite mit „RewriteEngine On“ eingeschaltet werden.

RewriteCond %{HTTP_USER_AGENT} ^BAGL/Nutch-0.9 [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Baiduspider [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^CCBot [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Java/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ URL\ Control [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Python-urllib [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^sonarv [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Touche [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Yanga [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^Yeti/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^BPImageWalker/ [OR,NC]
RewriteCond %[HTTP_USER_AGENT} ^QRVA [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*NaverBot/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*DBLBot/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*discobot/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*DotBot/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot/ [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*VoilaBot [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Pockey [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*NetMechanic [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*SuperBot [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebMiner [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebCopier [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Web\ Downloader [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebMirror [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Offline [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebZIP [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebReaper [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Anarchie [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Mass\ Down [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*BlackWidow [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebStripper [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*WebHook [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Scooter [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*swish-e [OR,NC]
RewriteCond %{HTTP_USER_AGENT} ^.*Teleport[NC]
RewriteRule ^.*$ - [F,L]

Was sperren diese Regeln aus?

  • Eine Hand voll Tools, die komplette Webseiten herunterladen
    Etwa Teleport oder WebReaper. Es gibt keinen wirklichen Sinn, das zu tun. Hier könnten und sollte eigentlich auch wget mit drin stehen, aber das verwenden wir stellenweise intern.
  • Diverse „Libraries“, die Programmierer verwenden können, um Webseiten abzurufen
    Etwa Java, Python-urllib und Microsoft URL Control. Diese Libraries werden oft verwendet, um SPAM-Bots zu schreiben oder um Webseiten zu „rippen“, um sie auf dem eigenen Webserver mit eigener Werbung zu spiegeln. Natürlich wird auf diesem Weg nicht die Library selbst ausgesperrt, sondern nur die User, die sich mit den Standard-UserAgents identifizieren. Ähnlich wie oben wget wäre hier auch auf Wunsch noch cURL einzufügen.
  • Einige asiatische Suchmaschinen
    Zum Beispiel Baidu oder Naver. Auf diesem Weg verhindern  wir vielleicht, dass manche Personen uns finden, aber Asien gehört nicht wirklich zu unserer Zielgruppe.
  • Einige sinnlose Suchmaschinen
    Das sind Suchmaschinen, die einfach (noch?) keine Relevanz haben oder die in unserer Zielgruppe keine Relevanz haben. Hier wären beispielsweise Yanga und Voila zu nennen. Stellenweise habe ich auch Cuil ausgesperrt (nicht in dieser Liste oben). In diesen Fällen steht die durch die Bots erzeugte Last auf unseren Servern in keiner Relation zu den auf diesem Weg erreichten Besuchern. Wenn beispielsweise ein Bot jeden Tag 1000 Dateien abruft, dann aber nur ein Besucher im Monat gebracht wird, dann macht das einfach keinen Sinn.
  • Einige komplett sinnlose Bots
    Da zu nennen wären beispielsweise der MJ12bot und der CCBot. Die sammeln einfach nur Daten und behaupten, irgendwann mal was sinnvolles damit zu tun. Von Majestic12 gibt es immerhin inzwischen eine Alpha-Version von der Suchfunktion. Die Relevanz ist allerdings gleich null.

Etwas anders – der Vollständigkeit halber aber auch erwähnt – ist das hier:

RewriteRule wp-login\.php - [F,L]
RewriteRule xmlrpc\.php - [F,L]
RewriteRule wp-atom\.php - [F,L]
RewriteRule login_page\.php$ - [F,L]
RewriteRule include\.php$ - [F,L]
RewriteRule php.*my.*admin - [NC,F,L]
RewriteRule mysql - [NC,F,L]
RewriteRule typo3 - [NC,F,L]
RewriteRule xampp - [NC,F,L]
RewriteRule w00tw00t - [F,L]

Damit sperre ich diverse URLs, die gerne von Hackern aufgerufen werden, die einfach mal schauen, was es für Angriffsflächen gibt,  und beantworte sie mit 403 FORBIDDEN.

Eigentlich ziemlich sinnlos, denn die entsprechenden Dateien gibt’s auf den Servern ohnehin nicht – und wenn doch, dann will man sie normalerweise auch aufrufen können. Aber es werden auf diese Weise doch ein paar Bytes gespart, da die 403 FORBIDDEN Fehlermeldung im Normalfall kleiner ist als die 404 NOT FOUND Datei.

Außerdem sind 404 NOT FOUND Seiten oft auch irgendwie mit der Datenbank verknüpft. Die 403 FORBIDDEN Seite kann man einfach ausgeben, während man das 404 NOT FOUND in der Regel mit einer Hilfestellung für die User verbinden möchte. Hackern ist es in der Regel egal, ob sie einem den Server durch viele schnell aufeinander folgende Aufrufe lahmlegen. Von daher: einfach eine statische 403 FORBIDDEN Seite rausjagen. Das erzeugt nahezu keine Server-Last.

And last, but not least: Man kann dann in der Log-Datei die entsprechenden Aufrufe leichter identifizieren.