Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Freitag, 29. Juli 2005
Referer-SPAM - Wenn die beworbene Site so gut ist, besucht sie doch selbst :)
Webworking
Aber dann gleich auch mal ein paar Zig-Tausend mal :)

Am letzten Wochenende kam es offenbar zu einer Referer-SPAM-Attacke auf einen gut besuchten Webauftritt den ich betreue.

(Da der Webserver dies einfach wegsteckte ohne zu murren, ist es mir erst jetzt beim Lesen der Statistik aufgefallen.)

Zwischen dem 22 und 24.7. hat ein Host 198032 Zugriffe auf eine Seite gemacht, wobei insgesamt 31.119.306 kB (29 GB) geladen wurden.

Hierbei wurden jeweils 10 Attacken gefahren um mit zwischen 18600 bis 20500 Zugriffen jeweils auf die Webseite (innerhalb des Webbaumes) per Referer Information hochzupuschen. Dies ist in der Statistik auch dementsprechend erfolgreich. Die Plätze 3 bis 14 in den Refererinfos waren durch Links auf irgendwelche Pornosites belegt.


Ziel solcher Referer-SPAM-Attacken ist es, dafür zu sorgen, daß die in der Referer Information übertragene Website in Onlinestatistiken auftaucht.
Diese Statistiken wiederum könnten ja von Suchmaschinen gelesen werden. Die Suchmaschinen würden dann wiederum solche Seiten im Ranking hoch werten, da dann ja viele Links verweisen darauf verweisen.

Somit handelt es sich hier eindeutig um einen vorsätzlichen Missbrauch von IT-Systeme zu kommerziellen Zwecken.
Wäre eine deutsche Site beworben worden, hätte dies sicherlich eine Anzeige nach sich gezogen.

Leider ist Provider ein DSL-Zugangsanbieter in New York, so daß eine rechtliche Verfolgung in diesem Fall weitgehend sinnlos ist.
Ich vermute durch den Traffikverbrauch ist der Provider selbst schon gebeutelt und hat vielleicht selbst schon reagiert.

Dieser Art der Attacken ist leider in letzter Zeit ziemlich stark im kommen. Es gibt inzwischen eine Branche, die mit genau solchen Mitteln arbeitet um Geld zu verdienen.
Noch schlimmer: Im Gegensatz zu Mail-Spam ist diese Form der Werbung noch nicht genug verpönt und gesellschaftlich noch nicht gebranntmarkt.
Man schlage eine IT-Zeitung auf und man findet einige Angebote von "Suchmaschinenoptimierer".
Selbst der Heise-Verlag macht da motivierende mit, indem dieser
einen Wettbewerb der besten Suchmaschinenoptimierer ausgerufen hat.
(Vgl: Siehe im Netz: "Hommingberger Gepardenforelle").



Selbst wenn wir in unseren Statistiken diese Information weglassen werden wir -wie bei SPAM auch- weiter attackiert.
Eine andere Möglichkeit gibt es zwar auch, sie ist aber properitär und nur für eine Suchmaschine wirksam: Google bietet die Möglichkeit eines NONFollow-Tags an, mit der Links deklariert werden sollen, die nicht verfolgt werden sollen.

Eine Setzung solcher Tags wirkt sich damit gegen Referer-SPAMer dann sogar negativ aus.


Um die Gefahr durch RefererSPAM in Zukunft etwas einzugrenzen werde ich jedoch auf eine etwas abgewandelte automatische Reaktion setzen.

Folgende Anweisung findet sich nunmehr in einer .htaccess-Datei, die sich in den Statistik-Verzeichnissen befindet:

Meine Domain hab ich mal durch "example.com" ersetzt.
	RewriteEngine On
	RewriteCond %{HTTP_HOST} !example.com$ [OR]
	RewriteCond %{REMOTE_HOST} !example.com$ [NC]
	RewriteCond %{HTTP_REFERER} !example.com [NC]
	RewriteCond %{HTTP_REFERER} ^(.+)$ [NC]	
	RewriteRule ^(.*)$ %1 [R=301,L]


Das bedeutet folgendes:
Wenn derjenige, der auf einen Statistikseite geht eine Host abruft, welcher nicht mit example.com aufhört oder von dem Host kommt und die Refererinfoein Inhalt hat und der Inhalt nicht example.com enthält, dann wird der Zugriff zurückgeleitet auf die Seite die in der Refererinfo steht.

Also kurz gesagt: Ein Refererspamer wird auf die von ihm beworbene Seite umgeleitet und verursacht dann dort die Traffikkosten.

Diese Regelung funktioniert natürlich nur für Seiten innerhalb des Webauftritts. Auf keinen Fall sollte man das für die Startseite verwenden.
(Und wer keine Rechner im selben Netz hat braucht natürlich die ersten beiden RewriteConditions auch nicht.)

Für die Startseite slebst müsste man andere Lösungen machen.



Anderer Nachteil: Legitime Links von fremden Seiten, die von fremden Rechnern aufgerufen werden, werden ebenfalls umgeleitet.
Aber dieses Problem sollte man umgehen dadurch, daß man nicht auf innere Bereiche der Statistik linkt, sondern auf die dazugehörigen Startseiten des Webauftritts.


Laut aktuelle Log ist diese Lösung erfolgreich.
Der Angreifer ist offenbar derzeit nämlich wieder dabei und nutzt dabei andere Provider. (Wahrscheinlich ist der andere
inzwischen Pleite wegen Traffikkosten).
Offenbar hat er es auch schon bemerkt und vermutet wohl, daß wir dieselben Möglichkeit nutzen wie viele andere auch, nämlich die Nutzung einer bekannten Liste von Hosts oder Refererinfos, die für Refererspam genutzt werden.
Beispielsweise so:
  RewriteEngine On
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*adult(-|.).*$ [OR]
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*anal(-|.).*$ [OR] 
  [...]

  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*tits(-|.).*$
  RewriteRule .* - [F,L]
Quelle: basquiat.de


Einen ähnlichen Ansatz macht Isotopp:
Kommentarspammer


Diese Varianten halte ich aber für den Dauerbetrieb für problematisch: Man müsste sich dann dauernd darum kümmern, seine Listen up-to-date zu halten. Dafür hat aber niemand Zeit.

Ich hoffe mal, das mein Ansatz etwas länger hält.
Aber auf Dauer wird er auch nicht helfen, da er einen Referer-SPAM-Atacke auf die Startseite nicht verhindert.

Dort jedoch könnte man einen anderen Ansatz machen:
Über ein Perlskirpt würde/werde ich die Zugriffe auf diese Startseite abrufen und für alle Zugriffe von mit Links von extern eine Zugriff ausführen auf die externe Seite.
Diese externe seite wird dann einfach nach einem Link auf unsere Site durchsucht.
Ist keiner vorhanden, wird diese Refererinfo und die genutzte IP einfach ne Weile lange geblockt oder mit einer Teergrube versehen.

... link


Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

hldxvk@cpcpehcnvkddccjqcycz.mil, jcoj@lxmimlljtdbnjvvddvq.ch, uikatoyow@txbneqtfvywdmehshfycnm.br, drhtlowm@bpninjjorgpqiqwbysxmokec.jp, fwjrn@bqmlmbfktzmluyngn.edu, tlulw@orpxohfsbidsqy.ru, wqor@hbpmpvdzssusgmdghimua.ar, qfwamml@sxgnjekwwkcwtevuf.jp, kapuofq@akmvtkzwoysolixvg.com, bjngfx@qfwfynytlcxttxuu.org, onstmi@ulljmpfsdoxylpchdwvmktni.ru, mrvga@lxvmibkprb.edu, mqdw@udbpqdwpt.dk, ifweqbk@yfofkupgicbnanxlpt.ca, xvjtupb@dbhpnvdzotcggwdebchyd.com, cdriqmy@wcvebcjurubcmsrjdisyl.org, imus@mvcjdexeso.st, fedwgfwkhv@ppbjvpfsohkcxemrlilz.eu, fbbexzx@xglxkynhojzmwbebfvqeegiw.edu, oldfztlgx@obxvqrrapltqudaid.tv, detlvsgv@wystrkvvrhlqwkgqnjiexs.pl, erffuhwi@qccomcbfeikdsgluqitplvp.at, adtnxejch@zvbxnkxqrfptg.mil, wmcghxj@vjopsscllrwvwhtlvlsgw.it, xzvd@uktwlkhhqv.eu, xgorgf@mzfruubmevkvdn.de, ggevu@hwjbjthghirhqraf.biz, bvjl@idyaqsgxibqvvoktf.us, bqjqsrlt@cjohxilh.es, optmywzug@elkycgpuncufkgbbnh.eu