Rumble in the Jungle: Abwehr von Referer Spam

Referer Spam (oder auch „Referrer Spam“) ist schon sehr alt und eigentlich harmlos. Dennoch ärgert mich diese Spam-Art, zumal sie gerade in den letzten Monaten bei einigen Projekten, die ich betreue, vermehrt auftritt. Nachdem ich wiederum einige Wochen tatenlos zugeschaut habe, leitete ich nun Gegenmaßnahmen ein. Erfolgreich. Doch es ist ein Kampf gegen Windmühlen.

Was ist Referer Spam?

Wenn ein Benutzer einen Link auf einer Webseite klickt, wird bei der Weiterleitung die Zielseite als sogenannter Referer mit übertragen. Im Logfile des Zielservers taucht also die Quell-Seite mit auf. Somit kann der Administrator nachvollziehen, woher der Klick kam.

Was bezwecken Spammer mit Referer Spam?

Referer-Spam ist Werbung. Nichts weiteres. Der Administrator prüft die Logfiles und jeder Seiteninhaber, der ein wenig Suchmaschinenoptimierung (SEO) betreibt, interessiert sich auch für die Links (Backlinks), die auf seine Seite zeigen. Es taucht eine neue Backlinksquelle in den Logs auf? „Prima!“, denkt sich der Seiteninhaber und schaut sich die Quellseite an. Enttäuscht wird er feststellen, dass die Seite keinen Link zu seiner Seite beinhaltet, sie aus SEO-Sicht also wertlos ist. Oftmals wird er aber auch erleichtert feststellen, dass kein Link vorhanden ist – denn welcher SEO will gerne Links von russischen Erwachsenenangebote, dubiosen Pillenverkäufer- oder Casinoseiten? Dennoch hat der Spammer zumindest ein Ziel erreicht: Er hat es geschafft, dass ein Besucher seine Seite besucht hat. Durch den Referer hat er quasi seine Visitenkarte in den Logfiles hinterlassen und der Admin ist der Einladung gefolgt. Neudeutsch würde man dies „Direktmarketing“ nennen.

Früher war auch ein Skript auf vielen Webseiten anzutreffen, welches die letzten Referers auswertete und die Quellseite samt Backlink anzeigte. Sozusagen eine Rückwärtsverlinkung. Hier macht der Referer-Spam wirklich Sinn, denn durch das Skript erhält der Spammer automatisiert einen öffentlich sichtbaren Backlink.
Dies ist auch der Fall, wenn ein Analysewerkzeug wie AWStats oder Webalyzer öffentlich zugänglich ist (siehe „Ist Referer-Spam schädlich“).

Wie kann man Referer-Spam betreiben?

Prinzipiell ist dies sehr einfach. Man schreibe ein kleines Skript, welches den ganzen Tag eine bestimmte Liste an Webseiten aufruft. Es muss sichergestellt sein, dass das Skipt beim Aufruf der fremden Seite den Referer auf die eigene Seite überträgt – besser gesagt:  den Referer fälscht, denn der Aufruf kommt ja nicht wirklich über diese Seite.

Aufwand: Ein alter Rechner, eine DSL-Leitung mit täglich wechselnden IPs und ein Skript, welches man in einer ersten Version sicherlich innerhalb einer Stunde fertig programmiert hat. Also: Kein wirklicher Aufwand.

Ist Referer-Spam schädlich?

Eigentlich nicht, sofern man die Referers nicht auf der eigenen Seite ausgibt. Wenn ja, entsteht ein Backlink zu der Spammer-Seite, welches aus SEO-Sicht schädlich kein kann. Zu beachten ist, dass man – schon aus vielen anderen Gründen – den Zugriff auf Analysedaten von Webalizer und AWStats unterbinden sollte (Passwortschutz), da sonst auch hier ein Backlink entsteht.

Wenn man diese zwei Dinge beachtet, ist Referer-Spam nicht weiter schädlich. Zu Recht die Frage, warum ich trotzdem gegen den Spam vorgehe. Nun, zum einen verbraucht der Spam meine Bandbreite. Auch kein wirkliches Problem, wenn der Spammer meine Seite nur einmal am Tag aufruft. Dann ist dies zu vernachlässigen. Läuft sein Skript jedoch Amok und ruft meine Seite beispiesweise sekündlich auf, müssen Abwehrmechanismen getroffen werden.

Das – für mich hauptsächlich – größte Ärgernis ist, dass meine Statistiken verfälscht werden.  Ich prüfe regelmäßig die Referers und die Spammer nehmen hier gerne Top-Platzierungen ein, denn sie besuchen meine Seiten täglich – zum Teil mehrmals. Auch die Anzahl der Besucher wird so verfälscht.

Eine rechtliche Betrachtung erspare ich mir. Geneigte Leser können im Law-Blog weitere Informationen finden. Die Zeit wäre mir zu kostbar.

Tür zu: Abwehr von Referer-Spam

Was also bleibt ist die Möglichkeit, dem Spammer keinen Zutritt zum eigenen Webserver zu gewähren. Die nachfolgenden Beispiele sind Regeln, die in der .htaccess-Datei (oder vhosts) Platz finden.

Den Gedanken, die IP eines Spammers zu blockieren, kann man schnell fallenlassen, denn die Zugriffe erfolgen meist über wechselnde IPs.  Dennoch der Vollständigkeit halber nachfolgend die Möglichkeit, eine bestimmte IP zu sperren:

order allow,deny
deny from xxx.xxx.xxx.xxx
allow from all

Im obigen Beispiel ist „xxx.xxx.xxx.xxx“ durch die aufrufende IP zu ersetzen. Wenn er Spammer wechselnde IPs nutzt, wird man mit dieser Methode nicht glücklich, da man jedes Mal die IP anpassen muss. Schnelle Abhilfe kann dieser Eintrag in der .htaccess-Datei jedoch schaffen, wenn kurzzeitig von einer IP (oder einer Handvoll IPs) vermehrt (oder gar eine kritische Masse) Zugriffe kommen und man diese Aussperren möchte.

Eine Möglichkeit ist, mittels der RewriteCond Signaturen der unerwünschten Referer aufzugreifen und zu blockieren. Zu beachten ist jedoch, dass man hier sehr schnell mehr Referers aussperrt, als man ursprünglich beabsichtigt. Denkbar ist folgende RewriteCond, die Aufrufe mit „casino“ oder „.ru“ blockiert:

RewriteEngine on
RewriteCond %{http_REFERER} casino [OR]
RewriteCond %{http_REFERER} .ru
RewriteRule .* - [forbitten, last]

Hinterlässt der Spammer eine eindeutige Signatur, kann mittels „SetEnvIfNoCase“ der User-Agent gesperrt werden. Diese Methode eignet sich auch hervorragend um „news aggregator sites“, die den eigenen Text-Content oder Bilder hotlinken, vor die Schranken zu verweisen. Vor einiger Zeit war „IzyNews“ ein solcher Kandidat, der in den Logfiles folgende Signatur hinterlassen hat:

„IzyNews/1.0 (http://izynews.com, multiple subscribers)“

Das folgende Beispiel erzeugt eine Umgebungsvariable (hier: “leecher“), wenn der Agent mit seiner Signatur zugreift. Die deny-Regel verwehrt dem Agent dann den Zugriff; er erhält einen „Error 403“.

SetEnvIfNoCase User-Agent „IzyNews/1.0“ leecher=yes
order deny,allow
deny from env=leecher

Im Falle von IzyNews.de erfolgte der Content-Klau per RSS, die Bilder wurden vom Originalserver nachgeladen. Somit entging einem der Leser. Geblieben ist dem Seitenbetreiber nur der Traffic für das Ausliefern der Bilder. In einem solchen Fall greift natürlich Signatur-Regel nicht, denn der Benutzer einer solchen News Aggregator Site sendet bei seinem Request den User-Agent seines eigenen Browsers. Referenziert wird der Zugriff jedoch über den Originalserver, so dass die Regel einfach über die nachfolgende Zeile erweitert werden kann:

SetEnvIfNoCase Referer izynews.de leecher=yes

So kann also wie im nachfolgenden Beispiel eine Bad-Word-Liste in der htaccess-Datei gepflegt werden, die den Referer-Spam ein wenig einschränkt. Die Pflege ist jedoch auswändig.

SetEnvIfNoCase Referer seite1.ru leecher=yes
SetEnvIfNoCase Referer seite2.ru leecher=yes
order deny,allow
deny from env=leecher