Spam Traffic

[nokie]

Hallo,

ich bekomme seit ein paar Tagen auf allen meiner Seiten jede Menge Spam Traffic von social-buttons.com , nach ein wenig googlen habe ich festgestellt dass ich nicht der einzige bin der diesen bekommt und es sich um Werbung für ein idiotische social bar handelt. Der Spam traffic verfälscht meine analytics reports und ich würde traffic dieser seite gerne blockieren. Hatte bereits eine Anleitung gefunden, der ich allerdings nicht ganz folgen konnte. Jemand ne Idioten Erklärung für mich ?

Danke und Lg

[legion_x]

Ähnliches Problem bei mir:

Ich habe unter Google Analytics bereits unter Alle Filter einen neuen Filter angelegt:

Filtertyp: Custom
Ausschliessen
Filterfeld: Verweis

Und dann diese Parameter:
.*((darodar|priceg|semalt|buttons\-for\-website|makemoneyonline|blackhatworth|hulfingtonpost|bestwebsitesawards|o\-o\-6\-o\-o|(social|simple\-share)\-buttons)\.com)|(econom\.co)|(ilovevitaly(\.co(m)?))|(ilovevitaly(\.ru))|(humanorightswatch(\.org)).*

Zusätzlich aktiviere ich über den angebotenen Google Spam Filter:

Bots herausfiltern
-> Alle Treffer von bekannten Bots und Spidern ausschließen


Dennoch bekomme ich regelmäßig Besuch von Bots:

Social-buttons.com
site32.social-buttons.com


Kann mir jemand helfen?

[hanneswobus]

https://blog.netprofit.de/google-analyt ... erren.html
da stehen alle loesungsansaetze, das suchen hat mich ein paar sekunden meiner lebenszeit gekostet.
viel erfolg

[legion_x]

Hallo, ich habe mich jetzt an die Anleitung gehalten und möchte die Bots bereits in der htaccess blockieren. So sieht meine htaccess aus:

php_value memory_limit 128M

# BEGIN WordPress
<IfModule mod_rewrite.c>

# Block Semalt related referrer spam
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*\.free-share-buttons\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^https://.*guardlink.org/ [NC,OR]
RewriteRule ^(.*)$ – [F,L]

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress


## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/javascript "access plus 216000 seconds"
</IfModule>
## EXPIRES CACHING ##

<filesMatch "\\.(js|js.gz)$">
Header set Cache-Control "max-age=604800, private"
</filesMatch>


Seltsamerweise bekomme ich dennoch Spam von "site3.free-share-buttons.com" und "guardlink.org"

Habe ich einen Fehler oben in der Spamerkennung? Weiß jemand Rat?

[Vegas]

Hallo, ich habe mich jetzt an die Anleitung gehalten und möchte die Bots bereits in der htaccess blockieren.

Der Artikel ist nur teilweise richtig. Der Fehler liegt nicht in Deinem .htaccess Code. Du kannst nichts per .htaccess blockieren, weil diese Bots Deine Seite gar nicht aufrufen, sondern direkt Analytics die Besucher vorgaukeln.

[legion_x]

Was kann ich denn stattdessen machen?

Ich meine, ich habe den - wie in anderen Blogs beschrieben - den Google Analytics Code mit Javascript aufgegliedert in:

ga('create', 'UA-' + '60255020' + '-1', 'auto');

Das scheint nichts zu helfen.

und habe auch in Google Analytics entsprechende Filter (zum Ausschließen bestimmte Adressen und Verweis-URLS) eingebaut. Auch das hilft nichts. Maximal mit benutzerdefinierten Segmenten kann ich die Bots erfolgreich aus der historical View entfernen. Aber das ist halt nur kosmetisch und nicht wirklich.

Ich kann mir wirklich nicht vorstellen, dass alle betroffenen Website dieser Welt unter den selben Problemen leiden müssen und es da keine Lösung gibt.

[Cash]

# Block Semalt related referrer spam
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*\.free-share-buttons\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^https://.*guardlink.org/ [NC,OR]
RewriteRule ^(.*)$ – [F,L]

Dieser htaccess-Eintrag kann nicht funktionieren, da die letzte Zeile kein OR enthalten darf. Außerdem werden einige Referer dahingehend manipuliet dass kein Slash mitgesendet wird. Ist der Slash wie bei dir in der htaccess eingetragen reagiert die htaccess auch nur auf den Referer mit Slash. Der Slash ist nicht notwendig und kann ohne weiteres entfernt werden.

Beispiel:

RewriteCond %{HTTP_REFERER} ^http://.*free-share-buttons\.com [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*guardlink\.org [NC]
RewriteRule ^(.*)$ – [F,L]

[nerd]

Die .htaccess loesungen sind nutzlos, wie schon geschrieben besucht der bot eben NICHT deine seite (dh. deine htaccess wird auch gar nicht bemueht).
Der spammer macht eine verbindung zum google analytics server selbst auf (genau wie jeder richtige besucher, dessen browser die GA.js ausfuehrt), mit gefaelschtem referer. Alles was er dazu braucht ist eine gueltige GA account nummer, und die laesst sich erraten oder durchprobieren.

[Cash]

Die .htaccess loesungen sind nutzlos, wie schon geschrieben besucht der bot eben NICHT deine seite (dh. deine htaccess wird auch gar nicht bemueht).

Eine interessante Aussage!

Der Refererspam schläg, zumindestens bei mir, auf keiner meiner Domains im Analytics auf.
Und das kommt daher dass der Bot vorher per htaccess ausgefiltert wird.

Ich bezweifle auch, dass der Zweck des Bot ist, Refererspam in Analytics zu verbreiten.
Die ukrainische SEO-Klitsche greift damit zum einen den Quelltext einer aufgerufenen Seite ab
und verbreitet gleichzeitig Refererspam. Fast alle verwendeten Domain leiten doch zu Semalt weiter
oder stehen damit in Verbindung.

How to make $2000-5000/month with Semalt?

[Keyser Soze]

Was kann ich denn stattdessen machen?

Ich meine, ich habe den - wie in anderen Blogs beschrieben - den Google Analytics Code mit Javascript aufgegliedert in:

ga('create', 'UA-' + '60255020' + '-1', 'auto');

Das scheint nichts zu helfen.

Das hilft deshalb nichts, weil die Referrer-Spammer teilweise überhaupt nicht deine Webseite aufrufen und ihnen deshalb vollkommen egal ist, wie du deinen Code einbindest. Das ist der Denkfehler vieler Leute in dieser Hinsicht. Die Vorgehensweise ist vielmehr so, dass diese Spammer einfach alle Analytics-IDs durchgehen und die entsprechenden Tracking-Codes auf ihren eigenen Webseiten einbinden (Spammer die nach diesem Schema vorgehen kannst du in deinem Analytics-Account sehen unter "Technologie -> Anbieter -> Hostname").

[nerd]

Der Refererspam schläg, zumindestens bei mir, auf keiner meiner Domains im Analytics auf.
Und das kommt daher dass der Bot vorher per htaccess ausgefiltert wird.

Warum sollte der bot erst domains nach einem gueltigen GA account durchsuchen? Das dauert viel zu lange (gueltige domains finden, aufrufen, eventuell redirects und timeouts (.htaccess!) abfangen, quelltext nach ga-nummer parsen) und erzeugt fuer den spammer nur unnoetigen traffic. Alles was man braucht um einen eintrag in die analytics logs zu schreiben ist die GA-nummer, nach dem muster UA-XXXXXXXX-1.
Die kann man leicht erraten - im zweifelsfalle faengt man eben bei 10000000 an und zaehlt hoch. Die restlichen angaben wie referer und user-agent lassen sich beliebig im http-header setzen.
Soll heissen man kann mit einzigen request an die GA server die logs von irgendwelchen leuten vollspammen, ohne erst den umweg ueber deren server und webseiten zu gehen.

Der top comment auf https://moz.com/blog/how-to-stop-spam-b ... erral-data bestaetigt, dass er keinen spam auf accounts bekommt die auf XXXXXXXX-2 enden, soll heissen die spam bots probieren nur den default-account (-1) durch und ziehen dann weiter.

[Keyser Soze]

Der top comment auf https://moz.com/blog/how-to-stop-spam-b ... erral-data bestaetigt, dass er keinen spam auf accounts bekommt die auf XXXXXXXX-2 enden, soll heissen die spam bots probieren nur den default-account (-1) durch und ziehen dann weiter.

Das ist nicht korrekt, ich bekomme auch entsprechenden Spam für SubIDs >1.

[Melegrian]

Alles was man braucht um einen eintrag in die analytics logs zu schreiben ist die GA-nummer, nach dem muster UA-XXXXXXXX-1.

Das mag ja sein, nur ich verwende keinen Analytics-Code in den meisten Seiten, sondern meinen eigenen und hatte auch diesen Spam.

Das hilft deshalb nichts, weil die Referrer-Spammer teilweise überhaupt nicht deine Webseite aufrufen und ihnen deshalb vollkommen egal ist, wie du deinen Code einbindest.

Die können meinen Code nur kennen, wenn sie diesen abrufen.

[Cash]

...
Der top comment auf https://moz.com/blog/how-to-stop-spam-b ... erral-data bestaetigt, dass er keinen spam auf accounts bekommt die auf XXXXXXXX-2 enden, soll heissen die spam bots probieren nur den default-account (-1) durch und ziehen dann weiter.

In dem Artikel stehen noch eine ganze Menge weiterer Informationen u.a. werden dort ebefalls Sperren per htaccess empfohlen.
Außerdem wird genau dass angesprochen was ich oben bereits aufgeführt habe.

Die ukrainische SEO-Klitsche greift damit zum einen den Quelltext einer aufgerufenen Seite ab
und verbreitet gleichzeitig Refererspam. Fast alle verwendeten Domain leiten doch zu Semalt weiter
oder stehen damit in Verbindung.

Aber warscheinlich bin ich nicht Nerd genug um der Denkweise zu folgen.
Zumindestens widersprechen doch die direkten Zugriffe des Semaltbots auf Domains eurer These.
Mir reicht es schon aus dass der Bot auf mein Domains zugreifen will um entsprechende Sperren anzulegen. Das jemand nicht will das der Bot bereits auf dem Host/Server gesperrt wird lässt für mich eigentlich nur einen Schluß zu.

[Keyser Soze]

Ich habe nicht behauptet, dass alle Spammer den Analytics-Code einfach direkt aufrufen, anstatt erst umständlich vorher noch deine Domain aufzurufen. Ich stimme dir also zu, dass z.B. semalt einer der Spammer ist, die tatsächlich noch die Domains explizit aufrufen. Es gibt aber eben auch genug andere, die sich diese Mühe nicht mehr machen. Also ein klares "sowohl als auch".