Misbruik / Commentaar Spam

[Len]

Ik host voor mijn oude TFC clan nog de website, die gebruiken we voor contact en babblebox

Maar ineens kreeg ik een mail dat ik op 80% van mijn 40gig datatransfer was ??

En het klopte ook nog, maar ik merkte op dat er wel veel bezoekers waren ineens... 2094 unieke bezoeken...

Ik heb van veel van die grootgebruikers (20-30 MB) het IP gebanned, maar ik blijf veel bezoeker trekken. Een van de sites waarvan mijn bezoekers kwamen is:

*op verzoek weg gehaald*

En allemaal gaan ze naar mijn www.clan21.nl/index.php
Helaas kan ik niet mijn webcoder te pakken krijgen. Die heeft wat meer kennis wat er mis is hoop ik.

wat bezoekers:


Zowiezo is het niet de bedoeling om dergelijke gegevens hier te plaatsenIemand een idee wat hier aan de hand is? Is het slim om mijn site voor een tijdje offline te gooien?

[ Voor 65% gewijzigd door whoami op 04-06-2007 08:56 . Reden: link verwijderd ]

[Snake]

Kun je zien welke bestanden het meeste traffiek trekken?

Heb je een .htaccess(ervanuitgaand dat je Linux hosting hebt) om ervoor te zrogen dat images niet gedeeplinked kunnen worden?

[Len]

Het meeste traffiek trekt index.php

En ik zal kijken of ik toch het deeplinken uit kan zetten.

[Verwijderd]

Len schreef op zaterdag 02 juni 2007 @ 16:45:
Iemand een idee wat hier aan de hand is?

Dat zijn gewoon spammers. Ze hopen dat ze ofwel in openbare statistieken verschijnen, of dat degene die de statistieken leest (jij dus) die site gaat bezoeken.

Als ik jou was zou ik die link naar die spamsite ook weghalen. Want met die link doe je ze een heel groot plezier.

[Verwijderd]

Ik heb er al een keer op geklikt

[Alex Picard]

Zit er misschien een exploit in je index.php? probeer anders even in de accesslog te kijken

[BasieP]

ik zou hem tijdeljik offline gooien, en je code debuggen
lijkt er erg op dat er idd een exploid in zit.

post je code anders eens hier (de relevante code, dus niet de lappen tekst of opmaak)

btw:
die lijst met bezoekers hebben we geen drol aan, en staat ook nog vol met prive gegevens.
zou je die kunnen weghalen?

[ Voor 24% gewijzigd door BasieP op 03-06-2007 22:04 ]

[Len]

Ik heb het vermoeden dat mijn site gebruikt word om via de comments op de frontpage links te spammen.

btw:
Ik zie alleen maar IP en hostnames staan hoor, echt prive is dat niet te noemen. Ik heb het hier neergezet alleen maar om aan te geven dat er van heel de wereld mensen data genereren op mijn site.
Het is pas echt prive als ik een paar PIN codes hier zou neerzetten: 3354 2236 9981 8633

_{PS. Sorry als iemands PIN code hier nu op het www staat ik kon het ff niet laten.}

[gorgi_19]

Je hebt toch logbestanden? Daarin staat toch exact welke pagina (inclusief querystring) en welke actie (GET, Post, etc) er gedaan wordt?

[ Voor 68% gewijzigd door gorgi_19 op 04-06-2007 01:39 ]

[Len]

gorgi_19 schreef op maandag 04 juni 2007 @ 01:39:
Je hebt toch logbestanden? Daarin staat toch exact welke pagina (inclusief querystring) en welke actie (GET, Post, etc) er gedaan wordt?

NU weet ik het bijna zeker, ik zie alleen dat die "bots" reacties met spamlinks willen plaatsten.

code:

82.114.212.24 - - [02/Jun/2007:10:13:15 +0200] "POST /index.php?news=comment&action=edit&id=93&post=372 HTTP/1.1" 200 150197 "http://www.clan21.nl/fixtures.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
66.232.124.248 - - [02/Jun/2007:10:20:20 +0200] "GET /index.php?action=edit&id=67&news=comment&post=429 HTTP/1.1" 403 - "-" "-"

Ik had het meeste al uit staan. Ik denk dat ik de site maar via .htaccess dicht gooi met een password

[dusty]

Yup, het is alleen maar voor de "comments spam", meer linkjes naar hun website, betere resultaten in zoek machines.

Welkom in de wereld van spam, en de reden waarom heel veel mensen voor een crappy CAPTCHA oplossing gaan.

[dusty]

Ik verplaats dit topic van WEB naar SA&E.. Alhoewel het niet geheel compleet in de lijst past, denk ik dat wij in SA&E hier een prima onderwerp mee kunnen hebben en hoe je dit tegen kunt gaan.

Sommige mensen gaan voor CAPTCHA ( niet perfect, en irritant voor de meeste mensen )
Andere mensen gaan voor Javascript ( niet perfect, sommige bots kunnen ondertussen ook de javascript runnen. )

Welke manieren gebruiken de mensen hier om commentaar spam tegen te gaan, en hoe bevalt het? Voordelen? Nadelen?

Op mijn eigen site gebruik ik een CAPTCHA voor gasten, leden kunnen zonder problemen reacties plaatsen. Het bevalt mij prima, gasten bevallen het een stuk minder goed maar er zijn wel wat gasten die vanwege de CAPTCHA maar lid worden.. Spam is nihil geworden, echter een zwaardere restrictie die gasten bij mij hebben is dat zij geen links mogen plaatsen.

[PeterSelie]

enige echt goede manieren zijn inderdaad de site gaan beveiligen met een wachtwoord (.htaccess), CAPTCHA, het blokkeren van publieke comments / posts dmv van een verplicht gebruikers systeem of het veranderen van comment URL's / registratie URL's van standaard CMS-en

[Mentalist]

In W3-blog (weblogsoftware, atm niet publiek beschikbaar omdat ik niet denk dat iemand het boeit ) heb ik 3 opties gemaakt: CAPTCHA (waarbij er 2 verschillende meegeleverd zijn, een "simpele" die alleen wat lijntjes trekt e.d. en die van Sprite_tm), een "domme vraag" (bijvoorbeeld "één plus één is ?" of "wat is de naam van de webmaster?" , kan de admin zelf aanpassen) die uiteraard direct nutteloos is zodra een spammer (Homo sapiens) een kijkje op je site neemt en zijn bot aanpast, al kan hij wel goed geautomatiseerde bots tegenhouden. En tenslotte een implementatie van Akismet. Een combinatie van deze 3 mogelijkheden is ook mogelijk.

Of het werkt in de praktijk? Ik zou het werkelijk niet weten, recente versies van W3-blog zijn nooit ergens serieus ingezet . W3-blog was ontworpen om naadloos in bestaande designs te integreren, oorspronkelijk ontworpen voor een bekende die al een design had..

Len, kan je de DM functie van dit forum even aanzetten? (nee, daar krijg je geen spam op )

[ Voor 15% gewijzigd door Mentalist op 04-06-2007 08:41 ]

[Verwijderd]

Even offtopic.. kan je zo'n spambot niet bij een foute beoordeling van Akismet doorlinken naar een Google-ad

Ik denk dat ik Akismet nog wel de mooiste oplossing vind, ik lees goede berichten over deze methode, en je kan bij false positives ook nog eens toedragen aan de waterdichtheid van dit systeem, door deze "handmatig" te verwijderen en aan te melden. Captcha's zijn namelijk tegenwoordig ook al te lezen door sommige spambots, het kan natuurlijk bijdragen aan de veiligheid, maar kan wel zo irritant zijn... zeker wanneer bijvoorbeeld het verschil tussen 0 en O te klein is.

[Mentalist]

Verwijderd schreef op maandag 04 juni 2007 @ 08:16:
Even offtopic.. kan je zo'n spambot niet bij een foute beoordeling van Akismet doorlinken naar een Google-ad

Ik denk dat ik Akismet nog wel de mooiste oplossing vind, ik lees goede berichten over deze methode, en je kan bij false positives ook nog eens toedragen aan de waterdichtheid van dit systeem, door deze "handmatig" te verwijderen en aan te melden. Captcha's zijn namelijk tegenwoordig ook al te lezen door sommige spambots, het kan natuurlijk bijdragen aan de veiligheid, maar kan wel zo irritant zijn... zeker wanneer bijvoorbeeld het verschil tussen 0 en O te klein is.

In mijn captcha (beide versies) is dat afgevangen, als het goed is komt er nooit een O, 0, I, l en nog wat andere tekens in de string voor. Maakt voor de effectiviteit ook weinig uit, spambots hebben juist geen problemen met die verschillen.

Doorsturen bij een foute beoordeling is trouwens wel te doen denk ik (of in ieder geval extra ads tonen bij foute beoordeling), maar zodra Google er achterkomt ben je je inkomsten kwijt denk ik. Ik weet het ook niet zeker meer trouwens, pin me er niet op vast. Maar je kan beter niks bijzonders laten zien bij een foute respons, dat trekt alleen maar de aandacht van de mensen achter de bots.

[ Voor 17% gewijzigd door Mentalist op 04-06-2007 08:44 ]

[Evilbee]

Ik heb het opgelost door met javascript een sha1 hash te berekenen over ingevoerde waardes en een random hash ( die ik bereken aan de hand van het ipadres en de datum). En deze mee te posten en daarna te controlleren met PHP. Sinds dien heb ik nooit meer last gehad van comment spam.

[RobIII]

In een oud(er) topic heb ik hierover al eens gepost: RobIII in "[Beveiliging] Faken van post variabelen"

RobIII schreef op maandag 09 april 2007 @ 18:35:
Wat ik zelf altijd doe voor gastenboekjes is het volgende:
Als de 'gast' een berichtje invult wordt er een email verstuurd naar de eigenaar met de inhoud van het bericht en 3 links: goedkeuren, afkeuren en afkeuren + ipban. Dat is een kwestie van een URL aanroepen met het (GU)ID van het bericht en de actie. Bij goedkeuren gaat er een bit op 1 (het gastenboek toont alleen goedgekeurde berichten), bij een afkeuring wordt het bericht verwijderd (of een ander bit op 1 ofzo) en bij de laatste actie wordt er ook meteen een IP ban gezet en krijgt dat IP vanaf dat moment een 403 forbidden ofzo.

Dat is een van de weinige manieren om je gastenboek lekker schoon te houden en rommel er dus uit te houden. Het plaatsen van een bericht is dus wel met wat vertraging, maar als je dat duidelijk uitlegt op de 'bedankt voor uw berichtje' pagina is er niemand die daar een probleem mee heeft, i.t.t. sommige 'moeilijke' captcha's e.d.

[ Voor 79% gewijzigd door RobIII op 04-06-2007 10:30 ]

[Mentalist]

Ik zie toch meerdere nadelen in jouw methode RobIII:

• De vertraging die je zelf al noemt.
• Komt er een spammer langs, heb je als webmaster opeens 500 e-mails in je inbox.
• Spammers gebruiken vaak, zoals je al in de topicstart zag, bots. Het is pas voorbij als je alle bots hebt ge-IP-banned, dat moment zal natuurlijk nooit komen.
• Stel iemand heeft een bot op zijn computer staan (uiteraard onbewust zoals meestal het geval is), en die persoon komt naar je gastenboek, dan zal hij mogelijk een 403 krijgen.
• Door dynamic IP's kunnen ook mensen die er niets mee te maken hebben opeens een ban aan hun broek hebben.

Ik geef toe dat ik in W3-blog ook een IP-ban optie heb, maar de enige manier om die als bezoeker te activeren is door te proberen X keer op het adminpanel in te loggen binnen X tijd met foute gegevens. Ik weet niet meer of je dan ook automatisch uitgesloten was van comments posten.. Zou ik nog eens naar moeten kijken. Logischerwijs ban ik dan inderdaad het IP en niet de user die poogt in te loggen, dat zou de deur wel erg ver openzetten voor misbruik. Maar zombie-PC's die proberen logins te bruteforcen zijn (denk ik) zeldzamer dan commentspambots.

[ Voor 5% gewijzigd door Mentalist op 04-06-2007 10:56 ]

[RobIII]

[quote]W3ird_N3rd schreef op maandag 04 juni 2007 @ 10:53:
Ik zie toch meerdere nadelen in jouw methode RobIII:

• De vertraging die je zelf al noemt.

True

[quote]W3ird_N3rd schreef op maandag 04 juni 2007 @ 10:53:
• Komt er een spammer langs, heb je als webmaster opeens 500 e-mails in je inbox.

Kwestie van 1 keer de IP-block link aanklikken; het komt zelden voor dat je "500" berichten in een keer binnen krijgt (ook op grote(re) commerciële sites overigens). En 500 mails is natuurlijk click-shift-click-delete rossen en klaar.

[quote]W3ird_N3rd schreef op maandag 04 juni 2007 @ 10:53:
• Spammers gebruiken vaak, zoals je al in de topicstart zag, bots. Het is pas voorbij als je alle bots hebt ge-IP-banned, dat moment zal natuurlijk nooit komen.

True; zeker omdat een IP waarop een bot draait een week later clean kan zijn en een ander IP dat clean "was" niet meer is.

[quote]W3ird_N3rd schreef op maandag 04 juni 2007 @ 10:53:
• Stel iemand heeft een bot op zijn computer staan (uiteraard onbewust zoals meestal het geval is), en die persoon komt naar je gastenboek, dan zal hij mogelijk een 403 krijgen.

Lullig joh. Had je je pc maar schoon moeten houden. Daarnaast is de "403" die ik serveer gewoon een nette pagina met tekst en uitleg waarom de post niet geaccepteerd wordt Zowieso is de kans natuurlijk nihil dat net die pc infected is én dat die ook nog eens net op jouw site is langsgeweest en die IP ban heeft gekregen.

[quote]W3ird_N3rd schreef op maandag 04 juni 2007 @ 10:53:
• Door dynamic IP's kunnen ook mensen die er niets mee te maken krijgen opeens een ban aan hun broek hebben.

Die kans van 1 op (ruwweg) 4 miljard neem ik dan maar voor lief

Overigens deel ik ook auto-bans uit. Kwestie van 1 read-only textbox in je form zetten met een fixed value (of een random keuze uit x values). Bots veranderen doorgaans doodleuk die value en als die dus niet matched met (1 van de) fixed value(s) kun je al automatisch een ban uitdelen zonder uberhaupt die mail te sturen.

[ Voor 12% gewijzigd door RobIII op 04-06-2007 11:05 ]

[Mentalist]

RobIII schreef op maandag 04 juni 2007 @ 11:00:
[...]

Kwestie van 1 keer de IP-block link aanklikken; het komt zelden voor dat je "500" berichten in een keer binnen krijgt (ook op grote(re) commerciële sites overigens). En 500 mails is natuurlijk click-shift-click-delete rossen en klaar.

Tis toch niet echt een voordeel imho .

[...]

Lullig joh. Had je je pc maar schoon moeten houden.

Dat is voor ons geeks een perfect acceptabel antwoord - maar leg het Ome Willem eens uit die niet als eerste een reactie kon plaatsen op de verse foto's van zijn pasgeboren kleinkind .

Ontzettend veel mensen hebben er geen flauw benul van wat spammers allemaal op hun PC uitvreten, en het kan ze ook niets schelen zolang de PC maar werkt. Ik ben het volledig met je eens, maar een aantal van die mensen zullen minder blij zijn met je oplossing .

Daarnaast is de "403" die ik serveer gewoon een nette pagina met tekst en uitleg waarom de post niet geaccepteerd wordt Zowieso is de kans natuurlijk nihil dat net die pc infected is én dat die ook nog eens net op jouw site is langsgeweest en die IP ban heeft gekregen.

True.

[...]

Die kans van 1 op (ruwweg) 4 miljard neem ik dan maar voor lief

Ook true, maar ik ga zelf liefst nooit uit van kansen als het even kan .

Overigens deel ik ook auto-bans uit. Kwestie van 1 read-only textbox in je form zetten met een fixed value (of een random keuze uit x values). Bots veranderen doorgaans doodleuk die value en als die dus niet matched met (1 van de) fixed value(s) kun je al automatisch een ban uitdelen zonder uberhaupt die mail te sturen.

Ook een handige truck, maar net als javascript denk ik dat bots die op den duur wel zullen "leren" .

[RobIII]

W3ird_N3rd schreef op maandag 04 juni 2007 @ 11:22:
Ontzettend veel mensen hebben er geen flauw benul van wat spammers allemaal op hun PC uitvreten, en het kan ze ook niets schelen zolang de PC maar werkt. Ik ben het volledig met je eens, maar een aantal van die mensen zullen minder blij zijn met je oplossing .

Het gros van de gehackte bakken komt niet in mijn kringen voor maar in China / de US
Daarnaast is het misschien wel een eerste "sein" voor ome-willem dat zijn bak gehackt is en dus bewijs ik hem (en de rest van de internet community) in dat geval een (gratis) dienst

[ Voor 3% gewijzigd door RobIII op 04-06-2007 11:32 ]

[Mentalist]

RobIII schreef op maandag 04 juni 2007 @ 11:31:
[...]

Het gros van de gehackte bakken komt niet in mijn kringen voor maar in China / de US
Daarnaast is het misschien wel een eerste "sein" voor ome-willem dat zijn bak gehackt is en dus bewijs ik hem (en de rest van de internet community) in dat geval een (gratis) dienst

Ook een goede mogelijkheid is dat Ome Willen niets aan zijn PC doet, je de huid vol zal schelden en zeggen dat je de site héél snel moet fixen .

[Verwijderd]

Misschien is een implementatie van KittenAuth iets voor je?

http://www.kittenauth.com/

Ik gebruik het op in m'n PHPBB2 board ingebouwd, en sindsdien heb ik geen last meer van postbots - ze komen er niet meer doorheen. Uiteraard is het niet perfect, maar het is meer moeite dan de meeste spammers er voor overhebben.

[UltimateB]

De oplossing die ik tot nu toe heb gebruikt is om de form een action->submit te geven naar aanleiding van een javascript click op een image. Tot op heden nog geen bots die js doen toch?

[dusty]

Er zijn (helaas) ondertussen wel een aantal bots die gewoon javascript doen.

[TheDane]

Ik bedacht me gisteren ineens een "goede" manier om dit soort spam tegen te gaan. Geen flauw idee of mensen al eerder op dit idee gekomen zijn (vast wel, so bear with me).


Als je nou serverside een timestamp genereert. Dat als hidden text field in je form parset. Bij het submitten van het formulier deze timestamp checkt tegen de tijd
1) die in het formulier staat
2) tussen moment van submitten van form en 't tonen er van.

Bij afwijken in geval 1 heeft een bot dus de inhoud van dat veld gewijzigd -> bot -> drop comment.
Bij afwijken in geval 2 kun je een regel checken "als comment binnen 1 seconde na 't tonen gepost wordt" -> bot -> drop comment

Dan wordt dus in ieder geval je site niet geflood, lijkt me.
Bovendien posten bots direct, dus die timestamp in je formulier is waarschijnlijk niet gevuld. In dat geval kun je de comment ook droppen.

Is di wa?

[Mentalist]

TheDane schreef op maandag 11 juni 2007 @ 17:59:
Is di wa?

Het is wel wat, maar het is een kwestie van tijd voor bots leren om van hidden/locked fields af te blijven en een ingebouwde realistische delay krijgen. Het is dus geen permanente oplossing.

[EdwinG]

Afwijking bij punt 1 moet toch juist?
(Submitten gebeurt later dan het genereren, dus is de tijd verschillend).

Ik denk dat de bots 1x je formulier bezoeken, en vervolgens direct de doel URL (inclusief POST waarden) aanroept. Dan is er dus altijd meer dan 1 seconde verschil. Je moet dus ook controleren of er niet te lang over gedaan is.

Maar zodra bekend is dat er gebruik gemaakt wordt van een timestamp, zal die voortaan goed geformuleerd worden. Daarom is het misschien handiger om een hash van die timestamp (inclusief salt) te gebruiken, en de salt + timestamp in een database te zetten, verbonden aan de session-key.

[Mentalist]

Een hash van de timestamp, zodat je nooit meer kan controleren of de waarde klopt, of ben ik nou gek .

[EdwinG]

Daarom ook de salt + timestamp in de database, verbonden aan de session key. Dan kun je die weer ophalen

edit:

Je kunt ook hash+timestamp in het formulier zetten, als je de salt maar apart houdt.

[ Voor 32% gewijzigd door EdwinG op 11-06-2007 23:18 ]

[Not Pingu]

Het probleem is dat bij (goede) bots juist geprobeerd wordt om zoveel mogelijk een menselijke user na te bootsen. Een wachttijd van 1 seconde of meer helpt wel enigszins om de flood te beperken en kost de bot meer tijd om een post te doen, dus kan hij minder flooden.

[Mentalist]

EdwinG schreef op maandag 11 juni 2007 @ 23:17:
Daarom ook de salt + timestamp in de database, verbonden aan de session key. Dan kun je die weer ophalen

Ik snap het nog steeds niet. Volgens mij kan je zo alleen controleren of de waarde van de client gelijk is aan de waarde die je hebt, maar dat koppel je dus aan de sessie en zo controleer je of de tijd nog intact is?

Kan je volgens mij net zo goed de tijd+sessie+random junk in je DB stoppen, random junk naar de gebruiker sturen, en bij een comment controleren of de teruggestuurde random junk recent in de database is gezet met dezelfde sessie.

Lijkt me allemaal nog steeds prima te faken voor een bot?

edit:

Je kunt ook hash+timestamp in het formulier zetten, als je de salt maar apart houdt.

Ik snap het nog niet. Kan je mij uitleggen waarom een bot dit niet kan faken?

Not Pingu schreef op maandag 11 juni 2007 @ 23:26:
Het probleem is dat bij (goede) bots juist geprobeerd wordt om zoveel mogelijk een menselijke user na te bootsen. Een wachttijd van 1 seconde of meer helpt wel enigszins om de flood te beperken en kost de bot meer tijd om een post te doen, dus kan hij minder flooden.

Nee, er is alleen een eenmalige vertraging, die zo lang duurt als de ingestelde vertraging (bijvoorbeeld 1 seconde). Als je een hoge ping hebt, kan je dan minder megabytes/seconde versturen?

[Not Pingu]

W3ird_N3rd schreef op maandag 11 juni 2007 @ 23:44:
Nee, er is alleen een eenmalige vertraging, die zo lang duurt als de ingestelde vertraging (bijvoorbeeld 1 seconde). Als je een hoge ping hebt, kan je dan minder megabytes/seconde versturen?

Maar omdat de bot ofwel zal moeten wachten op de vertraging, ofwel een volgende request moet plannen na het punt waarop de vertraging verloopt, heeft ie er meer werk aan. En als je per IP adres/cookie bijhoudt wanneer voor het laatst gepost is, zou bij elk volgende spam-request de teller weer opnieuw beginnen te lopen (dus niet flooden met 1 seconde offset, maar met 1 seconde interval).

[Mentalist]

Not Pingu schreef op maandag 11 juni 2007 @ 23:53:
[...]

Maar omdat de bot ofwel zal moeten wachten op de vertraging, ofwel een volgende request moet plannen na het punt waarop de vertraging verloopt, heeft ie er meer werk aan. En als je per IP adres/cookie bijhoudt wanneer voor het laatst gepost is, zou bij elk volgende spam-request de teller weer opnieuw beginnen te lopen (dus niet flooden met 1 seconde offset, maar met 1 seconde interval).

Per IP: niet praktisch. Stel je post een interessant artikel en je hele school duikt er met hetzelfde IP op: daar ga je.

Per cookie: bots kunnen prima cookies spawnen.

[TheDane]

EdwinG schreef op maandag 11 juni 2007 @ 22:27:
Afwijking bij punt 1 moet toch juist?
(Submitten gebeurt later dan het genereren, dus is de tijd verschillend).

Ik denk dat de bots 1x je formulier bezoeken, en vervolgens direct de doel URL (inclusief POST waarden) aanroept. Dan is er dus altijd meer dan 1 seconde verschil. Je moet dus ook controleren of er niet te lang over gedaan is.

[..]

Eh, nee toch?
Server genereert timestamp. die komt in formulier. Als 't formulier gepost is, wordt diezelfde timestamp dus teruggestuurd. Als die anders is, is er dus met 't formulier gesjoemeld. Eigenlijk (bedenk ik me nu ) is dat dus idd zo'n beetje hetzelfde idee als hashing. Maar met timestamp kun je dan ook nog (makkelijk) checken of er niet te kort of te lang over 't posten gedaan wordt, aangezien je na 't POST'en van 't formulier kunt kijken hoe veel tijd er tussen tonen van formulier en posten zit.

Overigens kreeg ik vandaag deze Animated CAPTCHA php class binnen.

Ongetwijfeld zullen bots daar tzt ook wel mee overweg kunnen, maar 't is een continuous battle ...

[Niemand_Anders]

Meestal gebruik in een vrij simpele oplossing. Normale comments zullen namelijk geen link naar andere websites bevatten. Wordt er dus een post gedaan met een url daarin, dan kun je die het beste laten moderaten. Het nadeel daarvan is dat er een menselijke tussenkomst nodig is.

Bij een andere website (welke volledig Nederlands is) welke ik heb moet de bezoeker een eenvoudige rekensom uitvoeren. Zoals 'hoeveel is drie plus twee'. Als ze dan '5' of 'vijf' invoeren wordt het commentaar geaccepteert. Er zijn vrij weinig spam bots welke kennis hebben van de Nederlandse taal.

Maar geen van de genoemde oplossingen voorkomt het hoge bandbreedte gebruik. Immers de 'validatie' komt na de post. De enigste manier om de data traffic omlaag te krijgen is verplichte registratie zodat anoniem posten niet meer mogelijk is.