Das Original-Reporting sieht erst mal nicht direkt verdächtig aus. Normale Schwan­kungen könnte man denken.

Mit dem Aufsetzen einer Homepage gibt es recht überra­schend immer wieder neue Tätig­keits­felder. So kam es auch für uns. Wir wurden recht spontan auf ein Phänomen aufmerksam welches Wikipedia unter dem Begriff Referrer-Spam beschreibt: In Google 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 Ergeb­nisse 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 Statis­tiken loswerden. Es bringt ja nichts, sich über Erfolge zu freuen die nicht real sind und Besucher­zahlen zu Feiern, die nicht der Realität entspre­chen.

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ürf­nisse 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 engage­ment, 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 statt­findet auch keine Einträge in der Analyse-Software produ­ziert. 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 Prozes­sieren ersparen.

Basis-Filter mit NGINX

server{
  # ...

  # Block Referrer SPAM
  if ($http_re­ferer ~* (buttons|free|cheap|porn|­se­mal­t|of­fer|s­hare)) {
    return 405;
  }

  # ...
}

In NGINX gibt es mittler­weile aber auch ein Modul ngx_htt­p_re­fe­rer_­module, welches sich komplett dieser Funktio­na­lität annimmt und in jeder NGINX-Installation direkt enthalten ist:

location / {
  valid_re­ferers none blocked (buttons|free|cheap|porn|­se­mal­t|of­fer|s­hare);

  if ($inva­li­d_re­ferer) {
    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 Engli­schen, „Refer­rer“.

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

Basis-Filter mit Apache

Eine ähnliche Funktio­na­lität für Apache sieht wie folgt aus:

# Block Referrer SPAM
<IfModule mod_re­write.c>
  Rewri­teEngine on
  Rewri­teCond %{HTT­P_RE­FERER} buttons|free|cheap|porn|­se­mal­t|of­fer|share [NC]
  Rewri­teRule .* - [F]
IfModule>

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

Für eine optimale Sicherheit und Perfor­mance 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 Black­listen für Apache

Für einen Großteil der Webseiten, wäre eine der folgenden Listen sicherlich einfa­cher, als selber alle proble­ma­ti­schen Fälle zusam­men­zu­tragen:

Jeff Starr von Peris­hable Press hat sich wirklich über Jahre viel Mühe gemacht um diese Listen zu erstellen und zu warten. Es dürfte der pragma­tische 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 Black­lists. 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 derar­tigen 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 entwi­ckeln. Die dritte Liste ist eine kleine Ausnahme und beschränkt sich mehrheitlich auf das Filtern von zugriffen bestimmter User-Agenten. Inter­essan­ter­weise nutzen die Spammer wohl nur eine begrenzte Zahl von Tools für ihre Aktionen. Der Ansatz User-Agenten zu filtern wäre daher eine Alter­native bzw. Ergänzung zu dem konven­tio­nel­leren 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 Stamm­ver­zeichnis der eigenen Webseite bzw. fügt es mit der vorhe­rigen 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 Alter­native zu dem .htaccess-basierten Ansatz…

Einfache alter­native Lösung für WordPress-Blogs

Jeff Starr hat mittler­weile, für die WordPress-Nutzer unter Ihnen, auch ein Plugin heraus­ge­geben. 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 Manipu­lation der .htaccess aus.

BBQ checks all incoming traffic and quietly blocks bad requests containing nasty stuff like `eval`, `base64`, and exces­sively long request-strings. This is a simple yet solid solution that works great for sites where `.htac­cess` is not avail­able.

Für ambitio­niertere 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ünf­tigen Updates auch mit enthalten sind.

PHP-Webseiten fahren mit ZB Block gut

Es gibt eine weitere PHP-basierte und kostenlose Alter­native 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 funktio­niert unter anderem mit dieses PHP-basierten Lösungen: Drupal,
phpBB, VBulletin, Joomla, WordPress, CodeIgniter, …

Black­listen für NGINX-Nutzer nur nach Konver­tierung

Leider haben wir bisher keine vergleichbare Lösung zu den Black­listen von Jeff Starr für NGINX gefunden. Glück­li­cher­weise sind diese aber recht einfach struk­tu­riert und lassen sich gut - zumindest mit ein wenig Nacharbeit - für NGINX aufbe­reiten. Eine dieser Lösungen zur Konver­tierung von Apache-Konfigurationen nach NGINX ist daher vermutlich für Sie inter­essant:

Referer filtern mit NGINX mit Map-Modul

Eine weitere schöne Alter­native für NGINX ist die Nutzung des Moduls ngx_htt­p_­map_­module (Teil der Standard-Distribution von NGINX) die von Justas Azna vorge­schlagen wurde.

# /etc/nginx/blacklist.conf

map $http_re­ferer $bad_re­ferer {
    hostnames;

    # Standard-Wert toleriert die Abfrage
    default                  0;

    # Wenn etwas aus dieser Liste matcht
    # wird $bad_re­ferer "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 black­list.conf;

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

server {
  # ...

  if ($bad_re­ferer) {
    return 444;
  }

  # ...
}

Aufräumen in Google Analytics

Perfor­mance und Sicherheit profi­tieren nach dem Anwenden der vorher genannten Schritte auf jeden Fall. Leider sind diese Schritte nicht 100%-ig ausrei­chend bei den typischen Attacken auf Google Analytics.

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

Auch Tom Capper hat schon festge­stellt, 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 Ergeb­nisse zu erhalten – direkt in Google Analytics einen Filter einbauen.

Die Start­seite von Google Analytics mit den angelegten Views im Überblick.

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

Überblick des Admin-Bereichs in Google Analy­tics. Markiert sehen Sie direkt unseren jetzigen Arbeits­be­reich: *View Settings*
Hier sieht man die Einstel­lungen von unserem Standard-View "Alle Websitedaten". Hier sollten alle Filter deakti­viert bleiben, damit die Original-Daten erhalten bleiben.

Basis-Konfiguration

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

Das Leben kann so einfach sein. Einfach die Checkbox anhaken und schon sind Sie zumindest einiges vom Spam los.
This feature will automat­i­cally filter all spiders and bots on the IAB/ABC Inter­na­tional Spiders & Bots List from your data.

Die Daten­an­sicht zu ändern, ändert natürlich nicht die eigent­liche Aufzeich­nung. Dies ist ein typische Kritik­punkt bei Googles Optionen für Analytics. Es bleibt außerdem schlei­er­haft, warum jemand als Standard überhaupt diese Art von Spam-Bots erfassen wollen würde. Wir jeden­falls nicht. Vielleicht kommt es weil die Option selber noch relativ neu ist.

Die Verwendung der „Referral Exclusion“-Liste in Google Analytics funktio­niert übrigens nicht zur Spam-Vermeidung. Der Name würde das zwar sugge­rieren, aber…

Referrals exclu­sions 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 einge­richtete 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 fehler­hafte Daten erst gar nicht zu sammeln. Dafür kann man Filter einrichten. Nach einiger Recherche und eigenen Experi­menten empfehlen wir folgende drei Filter:

  1. Hostname Validierung
  2. Bildschirm-Auflösung
  3. Referral Quelle
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 eigent­liche Homepage laufen, haben in der Regel keinen oder einen anderen Hostname als die eigent­liche 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 Infor­ma­tionen, die nur bei einem regulären Webseiten-Aufruf statt­finden 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 raffi­niert 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 proble­ma­ti­schen Anfragen loszu­werden.

3. Referral-Quelle unter­suchen

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 automa­tische „Instal­la­tion“ von Filter-Regeln in Google Analytics. Dies geschieht über eine Autori­sierung 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 beispiels­weise 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 öffent­liche 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 Alter­native 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 Poten­tiale der geschal­teten Werbung auch direkt in der Analyse-Software sehen kann.

Wirkt leider nur für neue Daten

Der neue gefil­terte 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 reinkom­menden Daten angewendet werden.
  • Sie wirken nur für neu hinzu­kom­mende Daten - die alten Zahlen sind daher immer noch falsch.
  • Wenn Filter auf dem Hauptview angewendet werden, sind die betrof­fenen Einträge für immer weg.

Im Idealfall schauen Sie jetzt noch wie Sie die bishe­rigen Daten aufräumen…

Aufräumen histo­ri­scher Daten

Man kann übrigens die Statistik in Google Analytics leider nicht resetten: Statt­dessen dupli­ziert 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 prakti­kabel die histo­ri­schen Daten mit einfa­cheren Mitteln leicht zu berei­nigen. Das geht am besten über Segmente. Ein Segment dient dazu nur einen Teil der gesam­melten 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:

Das Segment "Bereinigt" hilft dabei auch in den histo­ri­schen Daten einen reinen Überblick zu gewinnen.

Klicken Sie auf „New Segment“ und legen Sie das Segment „Berei­nigt“ mit folgenden Daten an:

Die Einstel­lungen unseres gefil­terten Segments beschränken sich auf die Überprüfung des Hostnames und der Bildschirm­auf­lö­sung. Wir wollten die Liste von proble­ma­ti­schen Referrern nicht doppelt und dreifach pflegen. Das Segment dient ja auch nur dazu histo­rische Daten vom schlimmsten Ballast zu befreien.

Zurück in dem Reporting des Original-Views können Sie nun einfach das Segment „Berei­nigt“ hinzu­fügen…

Hier fügen wir das neu angelegte Segment unserem beste­henden View hinzu um histo­rische Websei­ten­daten gefiltert zu betrachten.

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

Histo­rische Daten im Überblick mit aktivierten gefil­terten Segment im Vergleich zu den Origi­nal­daten. Was auffällt: Die Kurven fallen weit gleich­mä­ßiger und weniger spitz aus.

Wenn Sie es bis hierher geschafft haben, gibt es nun vermutlich eine Webseite mehr, die über brauch­barere Statis­tiken verfügt.

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