Sebastian Software GmbH
← Übersicht
Dieser Beitrag ist über zwei Jahre alt und könnte veraltete Informationen enthalten.

Referrer Spam - Wie wir die Referrer-Müllhalde in Google Analytics vermeiden

(Geschrieben von Sebastian Werner am August 20, 2015)
Original-Report in Google Analytics ohne Filter
Das Original-Reporting sieht erst mal nicht direkt verdächtig aus. Normale Schwankungen könnte man denken.
Mit dem Aufsetzen einer Homepage gibt es recht überraschend immer wieder neue Tätigkeitsfelder. So kam es auch für uns. Wir wurden recht spontan auf ein Phänomen aufmerksam welches Wikipedia unter dem Begriff [Referrer-Spam](https://de.wikipedia.org/wiki/Referrer-Spam) beschreibt: In *[Google Analytics](http://www.google.com/analytics/)* gibt es jede Menge Traffic, aber vieles, wenn nicht sogar der größte Teil, davon scheint nicht von Menschen sondern von sogenannten Spam-Bots zu kommen.

Gefährlich ist Referrer-Spam in der Regel nicht. Lästig ist er aber trotzdem, denn er verfälscht die Ergebnisse der Webseiten-Analyse und erschwert dadurch unter anderem die SEO-Optimierung.

Unserer Überzeugung nach -- damit die Analyse der Besucher überhaupt irgendwie Sinn macht -- muss man im ersten Schritt diese Aufrufe aus den eigenen Statistiken loswerden. Es bringt ja nichts, sich über Erfolge zu freuen die nicht real sind und Besucherzahlen zu Feiern, die nicht der Realität entsprechen.

Uns bleibt bisher verborgen warum Google sich dem Thema nicht direkt selber annimmt. Aber vielleicht gibt es dafür ja Gründe. Auf dem ersten Blick erscheint Referrer-Spam aber nicht viel anders als Spam im Mailboxen: Es geht nur darum, dass jemand auf den Link klickt. Im Falle von Referrer-Spam sind diese Links oft Tools und Lösungen die speziell auf die Bedürfnisse des Webseiten-Anbieters zielen: Einfache Sharing-Funktionen via Buttons, SEO-Analyse und -Optimierung, Spezielle Rabatte für Produkte aber natürlich auch Erwachsenen-Inhalte, etc. In einigen Fällen handelt es sich dabei schlicht um Marketing für eigene Angebote. In den meisten Fällen wird auf echte Shops und Dienste verwiesen, die Prämien/Provisionen für Klicks bzw. die Gewinnung von Neukunden auszahlen.

Spam visits are low engagement, non-converting, high bounce-rate traffic. They skew all "success metrics" downwards.

Blocken unerwünschter Zugriffe

Eine erste sinnvolle Idee, wäre das Blocken der Zugriffe direkt im Webserver. Die Idee dabei ist, dass ein Webseiten-Aufruf, der nicht stattfindet auch keine Einträge in der Analyse-Software produziert. Yong Mook Kim hat darüber geschrieben wie man direkt in NGINX mit der Analyse des Headers $http-referer. Über den Status-Code 403, 405, etc. kann man dann direkt eine Fehler-Mitteilung an den Aufrufer rausgeben und sich ein weiteres Prozessieren ersparen.

Basis-Filter mit NGINX

server{
  # ...

  # Block Referrer SPAM
  if ($http_referer ~* (buttons|free|cheap|porn|semalt|offer|share)) {
    return 405;
  }

  # ...
}

In NGINX gibt es mittlerweile aber auch ein Modul ngx_http_referer_module, welches sich komplett dieser Funktionalität annimmt und in jeder NGINX-Installation direkt enthalten ist:

location / {
  valid_referers none blocked (buttons|free|cheap|porn|semalt|offer|share);

  if ($invalid_referer) {
    return 405;
  }
}

Übrigens ist das Feld Referer in der HTTP-Spezifikation (Version 1.0) tatsächlich falsch geschrieben. Also wundern Sie sich nicht wegen des einzelnen 'r's in der Wortmitte. In echt heißt es, auch im Englischen, "Referrer".

The spammer is draining your resources, consuming your bandwidth, decreasing your site's performance, and clogging your access and error logs with hundreds or thousands of bogus requests.

Basis-Filter mit Apache

Eine ähnliche Funktionalität für Apache sieht wie folgt aus:

# Block Referrer SPAM
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_REFERER} buttons|free|cheap|porn|semalt|offer|share [NC]
  RewriteRule .* - [F]
</IfModule>

Beide Code-Schnipsel müssen in die eigene sites-enabled/default bzw httpd.conf integriert werden.

Für eine optimale Sicherheit und Performance der eigenen Webseite ist das Sperren von unerwünschten Aufrufen auf jeden Fall eine gute Idee. Statt eigener Listen von bösen Wörtern zu pflegen kann man sich das Ganze aber noch ein wenig einfacher machen.

Filter mit Blacklisten für Apache

Für einen Großteil der Webseiten, wäre eine der folgenden Listen sicherlich einfacher, als selber alle problematischen Fälle zusammenzutragen:

Jeff Starr von Perishable Press hat sich wirklich über Jahre viel Mühe gemacht um diese Listen zu erstellen und zu warten. Es dürfte der pragmatische Ansatz sein, diese -- zumindest als Basis -- für eigene Filter zu benutzen.

Alle drei Listen sind frei unter der GPL verfügbar. Alle Blog-Posts zu diesen und vermutlich die Filter selber wurden zuletzt am 03. April 2015 geupdatet. Die ersten beiden sind vollständige Blacklists. Die "6G" verfolgt eine bessere Abdeckung von neuen Spam-Phänomenen - es besteht aber natürlich das Risiko, dass diese auch mehr "gute" Besucher blockt. Wobei man generell bei dem Einsatz von derartigen Blockaden natürlich immer Folgendes im Blick haben sollte:

A perfect firewall would block only bad traffic, but in reality it's inevitable that some good requests get blocked.

Daher macht es durchaus Sinn die "6G"-Variante zu nutzen und einfach zu beoachten, wie sich der Spam bzw. die Beschwerden entwickeln. Die dritte Liste ist eine kleine Ausnahme und beschränkt sich mehrheitlich auf das Filtern von zugriffen bestimmter User-Agenten. Interessanterweise nutzen die Spammer wohl nur eine begrenzte Zahl von Tools für ihre Aktionen. Der Ansatz User-Agenten zu filtern wäre daher eine Alternative bzw. Ergänzung zu dem konventionelleren Ansatz der "5G"- und "6G"-Listen.

It's one of many ways to improve the security of your site and protect against evil exploits, bad requests, and other nefarious garbage.

Jeder der Listen kann einfach für jeden Apache-Webserver genutzt werden. Hierzu kopiert man die Datei .htaccess lediglich in das Stammverzeichnis der eigenen Webseite bzw. fügt es mit der vorherigen Datei zusammen. Das klappt natürlich nur, wenn man nicht direkt in einem sehr günstigen Hosting-Vertrag ist, der keine eigenen .htaccess-Dateien erlaubt. Für alle, die vollen Zugriff auf den Webserver haben empfehlen wir eine Integration in die Standard-Konfiguration des Apache.

Für WordPress-Nutzer gibt es auch eine Alternative zu dem .htaccess-basierten Ansatz...

Einfache alternative Lösung für WordPress-Blogs

Jeff Starr hat mittlerweile, für die WordPress-Nutzer unter Ihnen, auch ein Plugin herausgegeben. BBQ schützt vor allen Formen von bösen Requests und Attacken auf WordPress. Die Lösung läuft komplett in PHP und kommt ohne Manipulation der .htaccess aus.

BBQ checks all incoming traffic and quietly blocks bad requests containing nasty stuff like eval, base64, and excessively long request-strings. This is a simple yet solid solution that works great for sites where .htaccess is not available.

Für ambitioniertere WordPress-Nutzer erscheint uns die Pro-Version von BBQ eine echtes Schnäppchen (nur einmalig $10) zur Absicherung der eigenen Webseite zu sein. Gerade wenn man bedenkt, dass es wirklich schön in WordPress integriert ist und alle zukünftigen Updates auch mit enthalten sind.

PHP-Webseiten fahren mit ZB Block gut

Es gibt eine weitere PHP-basierte und kostenlose Alternative zu den Listen bzw. WordPress-Plugins von Jeff Starr. ZB Block kümmert sich nicht nur um Spam-Zugriffe sondern auch um XSS-Attacken.

Es funktioniert unter anderem mit dieses PHP-basierten Lösungen: Drupal, phpBB, VBulletin, Joomla, WordPress, CodeIgniter, ...

Blacklisten für NGINX-Nutzer nur nach Konvertierung

Leider haben wir bisher keine vergleichbare Lösung zu den Blacklisten von Jeff Starr für NGINX gefunden. Glücklicherweise sind diese aber recht einfach strukturiert und lassen sich gut - zumindest mit ein wenig Nacharbeit - für NGINX aufbereiten. Eine dieser Lösungen zur Konvertierung von Apache-Konfigurationen nach NGINX ist daher vermutlich für Sie interessant:

Referer filtern mit NGINX mit Map-Modul

Eine weitere schöne Alternative für NGINX ist die Nutzung des Moduls ngx_http_map_module (Teil der Standard-Distribution von NGINX) die von Justas Azna vorgeschlagen wurde.

# /etc/nginx/blacklist.conf

map $http_referer $bad_referer {
    hostnames;

    # Standard-Wert toleriert die Abfrage
    default                  0;

    # Wenn etwas aus dieser Liste matcht
    # wird $bad_referer "wahr"
    "~social-buttons.com"    1;
    "~semalt.com"            1;
    "~hulfingtonpost.com"    1;

    # Die Liste kann z.B. aus den Daten von Piwik erstellt werden:
    # https://github.com/piwik/referrer-spam-blacklist

    # ...
}
# /etc/nginx/nginx.conf

http {
  # ...

  include blacklist.conf;

  # ...
}
# /etc/nginx/sites-enabled/mysite.conf

server {
  # ...

  if ($bad_referer) {
    return 444;
  }

  # ...
}

Aufräumen in Google Analytics

Performance und Sicherheit profitieren nach dem Anwenden der vorher genannten Schritte auf jeden Fall. Leider sind diese Schritte nicht 100%-ig ausreichend bei den typischen Attacken auf Google Analytics.

Angegriffen wird dabei nicht Ihre Website, sondern Ihr Google Analytics-Konto.

Auch Tom Capper hat schon festgestellt, das selbst Profile Log-Inhalte erhalten, die auf gar keiner Homepage verwendet werden:

I can only assume the spammers are randomly cycling through possible tracking IDs.

Man muss daher -- um klare Ergebnisse zu erhalten -- direkt in Google Analytics einen Filter einbauen.

Startseite Google Analytics
Die Startseite von Google Analytics mit den angelegten Views im Überblick.

Und das macht man am besten über einen neuen View. So bewahrt man immer die Originaldaten und kann im Zweifelsfall immer nochmal ein Blick dort hinein werfen.

Überblick Admin-Bereich
Überblick des Admin-Bereichs in Google Analytics. Markiert sehen Sie direkt unseren jetzigen Arbeitsbereich: *View Settings*
Einstellungen des Standard-Views
Hier sieht man die Einstellungen von unserem Standard-View 'Alle Websitedaten'. Hier sollten alle Filter deaktiviert bleiben, damit die Original-Daten erhalten bleiben.

Basis-Konfiguration

Ein erster logischer und einfacher Schritt sollte sein, die Option in den Einstellungen der Datenansicht zu ändern. Das Ganze ist etwas versteckt, aber mittels den Screenshots hier dürfte es auffindbar werden:

View Einstellung mit Option zum Filtern von Bots
Das Leben kann so einfach sein. Einfach die Checkbox anhaken und schon sind Sie zumindest einiges vom Spam los.

This feature will automatically filter all spiders and bots on the IAB/ABC International Spiders & Bots List from your data.

Die Datenansicht zu ändern, ändert natürlich nicht die eigentliche Aufzeichnung. Dies ist ein typische Kritikpunkt bei Googles Optionen für Analytics. Es bleibt außerdem schleierhaft, warum jemand als Standard überhaupt diese Art von Spam-Bots erfassen wollen würde. Wir jedenfalls nicht. Vielleicht kommt es weil die Option selber noch relativ neu ist.

Die Verwendung der "Referral Exclusion"-Liste in Google Analytics funktioniert übrigens nicht zur Spam-Vermeidung. Der Name würde das zwar suggerieren, aber...

Referrals exclusions list are for modifying how Google Analytics will attribute the visits from those domains, not excluding them.

Deshalb widmen wir uns jetzt der richtigen Lösung.

Filter einrichten

Leider reicht der oben eingerichtete Filter von Google Analytics für Bots nicht für viel - er basiert nur auf der Erkennung der Software, die den Zugriff macht. Außerdem macht es Sinn fehlerhafte Daten erst gar nicht zu sammeln. Dafür kann man Filter einrichten. Nach einiger Recherche und eigenen Experimenten empfehlen wir folgende drei Filter:

  1. Hostname Validierung
  2. Bildschirm-Auflösung
  3. Referral Quelle
Filterliste des bereinigten Views
Unsere 3 Filter für den bereinigten/gefilterten View im Überblick.

1. Hostname validieren

Die Validierung des Hostnamens ist trivial und äußerst wirksam. Attacken, die direkt Google Analytics betreffen und nicht über die eigentliche Homepage laufen, haben in der Regel keinen oder einen anderen Hostname als die eigentliche Seite. Die Idee ist also alle Log-Anfragen abzuweisen, die nicht den korrekten Hostnamen aufweisen.

2. Bildschirm-Auflösung

Die Anfragen, die direkt Google Analytics füttern haben in der Regel keine Informationen, die nur bei einem regulären Webseiten-Aufruf stattfinden können. So ist z.B. in der Regel das Feld "Bildschirm-Auflösung" ungesetzt. Diese Lösung haben wir als erstes bei Tom Capper entdeckt. Das ganze ist überaus raffiniert da sehr einfach. Weiterhin bedarf es keiner Wartung. Es bietet sich also an, Anfragen zu ignorieren in denen dieses Feld leer ist und damit direkt einen weiteren großen Teil der problematischen Anfragen loszuwerden.

3. Referral-Quelle untersuchen

Im Referral findet man in Spam-Anfragen oft immer die gleichen Wörter: free, cheap, webmaster, ... sind recht typisch. Seiten, die von einer Domain kommen, die diese Wörter enthalten will man in der Regel blockieren.

Mit dem Spam Filter Installer gibt es übrigens ein Tool für die automatische "Installation" von Filter-Regeln in Google Analytics. Dies geschieht über eine Autorisierung des Tools bei Google. Wem das nicht geheuer ist, der sollte es wohl lieber manuell machen. Für alle anderen stellt dies eine bequeme Methode dar, die Listen der Referral-Quellen nicht händisch anzulegen und zu pflegen.

Eine gute Basis für einen Filter (Feld: "Campaign Source") wäre beispielsweise die Liste von Jon Henshaw:

darodar\.|semalt\.|buttons-for-website|blackhatworth|ilovevitaly|prodvigator|cenokos\.|ranksonic\.|adcash\.|simple-share-buttons\.|social-buttons\.

Es gibt aber auch hier wieder öffentliche und gepflegte Listen wie z.B. diese hier vom Piwik Analyse Tool. Wer Interesse hat: Piwik wäre an sich für viele auch eine gute Alternative zu Google Analytics - zumindest wenn man nicht auch Werbung über Google macht. In dem Fall ist wohl Google Analytics unerlässlich damit man alle Erfolge und zukünftige Potentiale der geschalteten Werbung auch direkt in der Analyse-Software sehen kann.

Wirkt leider nur für neue Daten

Die Ansicht des Reports vom neuem gefiltertem View
Der neue gefilterte View im Einsatz. Da dieser erst in Zukunft Daten erhält ist er bisher noch völlig leer.

Bitte bedenken Sie noch:

  • Filter brauchen bis zu 24 Stunden, bis diese auf die neu reinkommenden Daten angewendet werden.
  • Sie wirken nur für neu hinzukommende Daten - die alten Zahlen sind daher immer noch falsch.
  • Wenn Filter auf dem Hauptview angewendet werden, sind die betroffenen Einträge für immer weg.

Im Idealfall schauen Sie jetzt noch wie Sie die bisherigen Daten aufräumen...

Aufräumen historischer Daten

Man kann übrigens die Statistik in Google Analytics leider nicht resetten: Stattdessen dupliziert man am besten das Profil und nutzt dieses in Zukunft für neue Einträge. Dazu muss man natürlich die Tracking-ID auch im Client-seitigen Code der Homepage auf den neuen Wert anpassen. Wir halten es aber für genauso praktikabel die historischen Daten mit einfacheren Mitteln leicht zu bereinigen. Das geht am besten über Segmente. Ein Segment dient dazu nur einen Teil der gesammelten Daten in den Views anzuzeigen. Das kann man auch dazu nutzen ein Spam-Filter umzusetzen. Und zwar so:

Gehen Sie zurück in den Admin-Bereich. Dort klicken Sie innerhalb des linken Bereichs auf "Segments". Sie bekommen eine noch leere Liste von Segmenten... wir wollen aber das hier sehen:

Segment-Überblick mit neu angelegtem Segment
Das Segment 'Bereinigt' hilft dabei auch in den historischen Daten einen reinen Überblick zu gewinnen.

Klicken Sie auf "New Segment" und legen Sie das Segment "Bereinigt" mit folgenden Daten an:

Einstellungen des bereinigten Segments
Die Einstellungen unseres gefilterten Segments beschränken sich auf die Überprüfung des Hostnames und der Bildschirmauflösung. Wir wollten die Liste von problematischen Referrern nicht doppelt und dreifach pflegen. Das Segment dient ja auch nur dazu historische Daten vom schlimmsten Ballast zu befreien.

Zurück in dem Reporting des Original-Views können Sie nun einfach das Segment "Bereinigt" hinzufügen...

Segment-Auswähler für Original-View
Hier fügen wir das neu angelegte Segment unserem bestehenden View hinzu um historische Webseitendaten gefiltert zu betrachten.

Und hier sehen Sie das Ergebnis der Mühe - eine schöne bereinigte Statistik. Sehr eindrucksvoll im Vergleich zum Original in blau:

Original-Report mit filternden Segment im Vergleich
Historische Daten im Überblick mit aktivierten gefilterten Segment im Vergleich zu den Originaldaten. Was auffällt: Die Kurven fallen weit gleichmäßiger und weniger spitz aus.

Wenn Sie es bis hierher geschafft haben, gibt es nun vermutlich eine Webseite mehr, die über brauchbarere Statistiken verfügt.

Wir sind immer dran an weiteren Themen. Verpassen Sie nichts: Melden Sie sich jetzt zu unserem Newsletter an.