Het is niet te geloven: alleen al in maart hebben de dames en heren referrer-spammers debsel.nl een beetje onder vuur genomen. Ik zie bij mezelf (en andere sites) ook wel eens een referrer die er niet tussenhoort, maar de hoeveelheden die Deb aantrekt zijn ronduit belachelijk te noemen. Duizenden!

Het minst vervelende resultaat is dat de -- door de server zelf gegenereerde -- statistieken voor haar site nogal vertekend zijn. "Boeie," roept Deb dan, "ik kijk daar niet naar." Echter, die gasten zijn zo hard bezig, dat ze er de server er behoorlijk mee vertragen -- het kost bandbreedte, en in de meeste gevallen ook wat processortijd. WordPress verzet het nodige werk voor zo'n weblog voor je neus staat, en bij tientallen of honderden requests tegelijk gaat zo'n server het dan ineens warm krijgen... Het werd dus tijd voor tegenmaatregelen.

Om te beginnen zijn haar statistieken nu achter een wachtwoordje gezet. Niemand die daar echt veel mee te maken heeft, en in ieder geval verdwijnen ze uit de zoekmachines. Dat zou ervoor moeten zorgen dat de spammers ten eerste geen eer meer van hun werk hebben, en ten tweede dat ze (hopelijk) de interesse in debsel.nl verliezen. Ik denk dat ik dat trouwens voor alle hosting-klanten ga doen: de voordelen (vooral gemak) van "openbare" statistieken wegen niet op tegen de mogelijke nadelen.

Als tweede maatregel zijn we eens met mod_rewrite aan de gang gegaan. In het kort zorgt mod_rewrite ervoor, dat je een request kunt "ombouwen". Het wordt nu al op debsel.nl en hier (en op heel veel andere sites) gebruikt om van die mooie URLs te maken -- dus bv. /archief/huppel/de/puppel/ in plaats van index.php?dit=dat&zus=zo. Je kunt echter ook URLs alleen laten veranderen als het gehele request aan bepaalde voorwaardes voldoet, en daar heb ik gebruik van gemaakt. Wat blijkt namelijk: de meeste request van de spammers kwamen óf voor /stats/ (en die zit nu achter een wachtwoord), óf als HEAD-request. Dat is mooi, want zo wordt het filteren veel makkelijker: in plaats van op enorme lijsten van domeinen te filteren -- een blacklist dus, en zoals u weet heb ik een hekel aan blacklists -- hoef ik nu alleen nog maar alle HEAD requests te blocken, en een paar "good guys" door te laten. Dat gaat heel eenvoudig met de volgende regels:

RewriteCond %{REQUEST_METHOD} (HEAD)
RewriteCond %{HTTP_USER_AGENT} !(netcraft) [NC]
RewriteRule .* - [F,L]

Oftewel: als de request-methode HEAD is, en-ie niet van Netcraft afkomstig is: blocken die handel.

Nadeel: het is een beetje bot mes, natuurlijk... Er zijn nog wel meer redenen te bedenken om een HEAD-request te versturen. Een korte blik op de logfiles leerde me echter dat dat, in ieder geval bij Deb, verwaarloosbare getallen zijn. Groot voordeel, uiteraard: het request wordt tegengehouden vóór dat het bij WordPress komt, dus dat scheelt een heleboel tijd en moeite voor de server. Mod_rewrite levert wel zijn eigen overhead op, maar die is verwaarloosbaar in vergelijking met die van WordPress.

Uiteraard is het over met de pret zodra de spamhoeren stoppen met HEAD-requests, maar dat zullen ze niet zo heel snel doen, denk ik. Ten eerste weten ze niet dat ik daar specifiek op block, en bovendien zou ze dat ontiegelijk veel meer dataverkeer kosten: een HEAD geeft alleen de headers terug (minder dan een halve kilobyte), terwijl een GET (wat je browser doet) de hele pagina ophaalt -- en dat kan aardig oplopen. Voor nu is het dus 1-0 voor mij... =]

"De documentatie-pagina van mod_rewrite"

"Post: 'Ik ben een spammer'"