Referer-Spam on Netsensei

Referer Spam

matthias@netsensei.nl (Matthias Vandermaesen) — Tue, 28 Nov 2006 21:45:50 +0000

Het is een oud zeer. Ik heb daar ook enorm veel last van. In de eerste plaats gaat het inderdaad om bots die massaal je pagina’s bezoeken en via de referer informatie in een HTTP request een linkje proberen te krijgen op je website via top 10 referer scripts en zo.

Als webeigenaar ben jij de dupe: er wordt immers reclame gemaakt op jouw kosten (bandbreedte). Bovendien is het vervuiling van je apache logfiles, je – vaak op deze logfiles gebaseerde – statistieken en van je databank als je referers logt. Ik kan mij voorstellen dat dit voor professionele websitebouwers die op basis van dergelijke informatie een profiel van bezoekers willen opstellen, een extra horde is.

Wat kan je er tegen doen? Wel, niet zo heel veel heb ik willen merken.

De HTTP specs (RFC 2616) schrijven voor uit welke velden een door een client gegenereerde HTTP request moet bestaan. Waar de inhoud van zo’n veld vandaan komt, dat wordt uiteraard niet gespecifieerd. Die vrijheid heeft tot misbruiken geleid.

Een client dient het referer veld in een HTTP request in te vullen. Dit is een ‘teruglink’ naar de bron waarvan de client naar een pagina werd geleid. Spammers schrijven bots die websites bezoeken en hun spamlinks expliciet via het referer veld proberen achter te laten.

Echter, een client moet via de user-agent string van een HTTP request zichzelf identificeren. De IE7 webbrowser heeft bijvoorbeeld deze identificatiestring:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
terwijl de Googlebot volgende string moet meegeven in het User Agent veld:
Googlebot/2.X (+http://www.googlebot.com/bot.html)
Je zou dus kunnen spammers kunnen blokkere n op basis van deze informatie via de .htaccess file en de robots.txt file. En strikt genomen kan je zo inderdaad wel wat spam tegenhouden. Helaas zijn ontwikkelaars ook hier vrij in de keuze van wat ze hier invullen. Gevolg: spammers kopiëren gewoon de user-agent strings van de grote browsers om zich te vermommen.

Wat je wel kan doen:

Referer spam is vrij doorzichtig. Door je apache logs te onderzoeken kan je al snel de spam terugvoeren tot een aantal IP adressen. Die kan je in je .htaccess file blokkeren. Jammer genoeg kan je dat niet lang volhouden omdat een lange .htaccess file parsen een serieuze aanslag is op de performance van je webserver. Een must is de aanwezigheid van een robots.txt file waarin je expliciet een aantal bots verbiedt of toelaat. Tenslotte kan je ook het nofollow attribuut opnemen in al je hyperlinks om spambots op een dood spoor te zetten.

O ja, je zou natuurlijk de referer wederkerig kunnen bevragen en zien of er daar inderdaad een effectieve, geldige link staat naar je pagina. Maar op die manier sla je het web effectief dood.

Desondanks is er – bij mijn weten – geen effectieve oplossing voor dit probleem en zal er altijd wel wat spam doorsijpelen.

Referer spam

matthias@netsensei.nl (Matthias Vandermaesen) — Tue, 18 Jul 2006 18:26:18 +0000

Ik heb daarjuist de .htaccess file dichtgetimmerd tegen spammers. Ik heb willen merken dat er in de afgelopen 18 dagen 1Gb aan data is versluisd. Webalizer toonde dat het gros naar allerlei bots gaat. Bovendien zitten de logfiles vol spam.

Via de .htaccess file kan je mensen op basis van een aantal variabelen toegang ontzeggen tot je website. Ik heb een beetje rondgespeurd op het Net en het beste van verschillende praktijken gecombineerd:

Er zit een vrij indrukwekkende blacklist op bepaalde woorden in de referer
Er is een lijst met ip’s van gekende spammers. Niet dat die zo hulpzaam is want spammers muizen er sowieso vanonder door regelmatig met een andere ip te opereren.
Tenslotte wordt er ook gediscrimineerd op basis van de user agent string van een referer hit. Hoewel die gemakkelijk te maskeren valt, is het toch nuttig om een aantal commerciële bots zoals larbin, turnitin, aipbot die géén direct nut hebben buiten te sluiten, Ook hits zonder een user agent string worden geweerd: het is nogal lomp om de robots.txt standaard niet te volgen.

Voor zover ik via de logfiles kan volgen heb ik willen merken dat leukers met een referer waarin “texas-holdem” en zo, lekker worden afgeblokt. Ik kan het zo ver drijven door spammers zo ver te drijven dat alle traffiek die deze kant opkomt, gewoon terug richting afzender wordt gestuurd. Alleen weet ik dat dat spammers niet tegenhoudt en ik het dubbel zo hard terug zou krijgen. Ik ben nu al blij dat het zo ook al vrij goed lijkt te werken.

Moesten er nu mensen opeens niet meer op mijn blog geraken: geef me een seintje! Het kan zijn dat je afgeblokt wordt door de strikte filter!

Ter referentie: dit is de .htaccess file die ik als basis heb gebruikt.

Geknoei met PHP

matthias@netsensei.nl (Matthias Vandermaesen) — Mon, 20 Feb 2006 23:21:49 +0000

Bon. Ik ben zo’n beetje begonnen met knoeien aan een versie 0.2 voor WP Referer. Een flink deel van de code kan ik blijkbaar meteen herbruiken. Haroe brova! De installatie van twee SQL tabelletjes had ik in WordPress 2.0 lopen in no time flat. Minus optimalisatie en zo.

Vooraleer ik verder ga, kijken of ik een haak kan zetten met Akismet om referer spam te counteren. De API is de eenvoud zelve. Alles gebeurt via POST requests over HTTP. Zo op het eerste zicht denk ik dat je wel Akismet en een Akismet API key (te verkrijgen via WordPress.com nodig zal hebben om WP Referer 0.2 te laten werken. Ik kan Akismet support natuurlijk optioneel maken, maar dat zou een beetje het punt bederven. Mijn ervaring is dat Akismet degelijk werk levert.

Moeilijker wordt het om referers door te sturen. De api-key.rest.akismet.com/1.1/comment-check call krijgt een pak argumenten mee. Dingen zoals ‘comment_author’ en ‘permalink’ die niet van toepassing zijn wanneer je referers wil checken. Hmz. Alles is weliswaar optioneel – ik hoéf ze niet mee te sturen – maar Mullenweg en co raden het toch niet aan om zomaar zaken weg te laten.

This is basically the core of everything. This call takes a number of arguments and characteristics about the submitted content and then returns a thumbs up or thumbs down. Almost everything is optional, but performance can drop dramatically if you exclude certain elements. I would recommend erring on the side of too much data, as everything is used as part of the Akismet signature.

Hmzr. Ik denk dat ik daar wel enige tijd in zal steken.

Verder denk ik er aan geen volledige URI’s meer mee te geven maar enkel nog het domein/host waar mensen vandaan komen. En de keywords functionaliteit moet ik ook eens herprogrammeren want die leek niet al te denderend te werken. Pom pom. Veel ideëen, weinig tijd.

Remember, code is poetry!