Onderwerp: hosting die met spam om kan gaan

Ik heb de afgelopen paar dagen erg veel gemailed met verschillende personen over deze spamproblematiek (o.a. met Bob, de maker van Pivot en met een collega van Marco). Ook heb ik aardig wat tijd gestoken bekijken van mogelijke oplossingen en bezoeken van verschillende sites. Helaas ontbreekt het mij aan tijd om e.e.a. zelf op te zetten (Pivot + verschillende spam counter measures).
Een eenvoudig te maken conclusie is: Er is geen eenvoudige oplossing voor deze spam problemen. Je zou het anoniem plaatsen van comments uit kunnen schakelen, maar hier gaat bloggen juist om! Het ligt in zoverre dus niet aan de maker van het blogscript.
De ene oplossing werkt wat beter dan de ander, maar nog niet goed genoeg. Weer een andere oplossing is, vooral in een shared-hosting omgeving te CPU-tijd vretend, enz. Feit blijft dat je achter de feiten aan blijft lopen, helaas. Naar ik begrepen heb werkt Pivot-Blacklist i.c.m. Owen's Spam Action vrij goed. Maar ikzelf zou toch voorstander zijn van het firewallen van spammende hosts dan het plaatsen van dezen in een .htaccess bestand. Zoals een eerder vermeldde link al uitlegt: Vele .htaccess bestanden (in een shared-hosting omgeving) met tientallen, honderden of duizenden entries zorgen voor nogal wat CPU-tijd verbruik. Hetzelfde geldt voor het vergelijken van de refer met een (.php/.txt)lijst met "foute" refers.
Dus:
* foute refer (bijvoorbeeld een hostname waar "porno" in voorkomt) komt op de site. Door de refer met "porno" wordt deze geredirect (403) naar honeypot.php.
* REMOTE_ADDR wordt opgeslagen en meteen in een firewall configuratie geplaatst. De verbinding wordt vanaf dan geweigerd.

Maar1: Wil een shared hosting provider zijn klanten wel deze mogelijkheid geven?! Geven we een klant de mogelijkheid om zelf hosts toe te voegen aan een firewall, waar eindigd het dan? Kunnen ze op deze manier een host blokkeren, dan kunnen ze andere hosts op andere manieren (laten) blokkeren.
Maar2: Deze spam-refers "hoppen" nogal eens van host naar host. Het is erg eenvoudig om via een trojan een httpd te installeren op een "thuis PC", die dan een weekje ofzo dienst doet als webserver voor die betreffende website. En hetzelfde voor nameservers, mailservers, enz. We zien dit al erg veel bij de "gebruikelijke" e-mail spammers.
De firewall lijst zal dus regelmatig gecontroleerd moeten worden. Vrij eenvoudig op een (Linux/BSD) shell, maar het moet wel gebeuren.

Origineel geplaatst door Digiover
Ik heb de afgelopen paar dagen erg veel gemailed met verschillende personen over deze spamproblematiek (o.a. met Bob, de maker van Pivot en met een collega van Marco). Ook heb ik aardig wat tijd gestoken bekijken van mogelijke oplossingen en bezoeken van verschillende sites. Helaas ontbreekt het mij aan tijd om e.e.a. zelf op te zetten (Pivot + verschillende spam counter measures).
Een eenvoudig te maken conclusie is: Er is geen eenvoudige oplossing voor deze spam problemen. Je zou het anoniem plaatsen van comments uit kunnen schakelen, maar hier gaat bloggen juist om! Het ligt in zoverre dus niet aan de maker van het blogscript.
De ene oplossing werkt wat beter dan de ander, maar nog niet goed genoeg. Weer een andere oplossing is, vooral in een shared-hosting omgeving te CPU-tijd vretend, enz. Feit blijft dat je achter de feiten aan blijft lopen, helaas. Naar ik begrepen heb werkt Pivot-Blacklist i.c.m. Owen's Spam Action vrij goed. Maar ikzelf zou toch voorstander zijn van het firewallen van spammende hosts dan het plaatsen van dezen in een .htaccess bestand. Zoals een eerder vermeldde link al uitlegt: Vele .htaccess bestanden (in een shared-hosting omgeving) met tientallen, honderden of duizenden entries zorgen voor nogal wat CPU-tijd verbruik. Hetzelfde geldt voor het vergelijken van de refer met een (.php/.txt)lijst met "foute" refers.
Dus:
* foute refer (bijvoorbeeld een hostname waar "porno" in voorkomt) komt op de site. Door de refer met "porno" wordt deze geredirect (403) naar honeypot.php.
* REMOTE_ADDR wordt opgeslagen en meteen in een firewall configuratie geplaatst. De verbinding wordt vanaf dan geweigerd.

Maar1: Wil een shared hosting provider zijn klanten wel deze mogelijkheid geven?! Geven we een klant de mogelijkheid om zelf hosts toe te voegen aan een firewall, waar eindigd het dan? Kunnen ze op deze manier een host blokkeren, dan kunnen ze andere hosts op andere manieren (laten) blokkeren.
Maar2: Deze spam-refers "hoppen" nogal eens van host naar host. Het is erg eenvoudig om via een trojan een httpd te installeren op een "thuis PC", die dan een weekje ofzo dienst doet als webserver voor die betreffende website. En hetzelfde voor nameservers, mailservers, enz. We zien dit al erg veel bij de "gebruikelijke" e-mail spammers.
De firewall lijst zal dus regelmatig gecontroleerd moeten worden. Vrij eenvoudig op een (Linux/BSD) shell, maar het moet wel gebeuren.

Vraag is dan: maakt dat een probleem van de klant of van de hoster? Ik kan me voorstellen dat er meer hostingbedrijven zijn (net zoals jij zo te lezen), die geen tijd voor dit soort onzin hebben.

Afsluiten van de website en het probleem bij de klant leggen is voor de hand liggend. Het kost je namelijk enorm veel tijd, inspanningen en vooral geld om een oplossing te verzinnen voor iets wat wellicht niet eens je eigen probleem is?

Origineel geplaatst door eMiz0r
Vraag is dan: maakt dat een probleem van de klant of van de hoster? Ik kan me voorstellen dat er meer hostingbedrijven zijn (net zoals jij zo te lezen), die geen tijd voor dit soort onzin hebben.

Afsluiten van de website en het probleem bij de klant leggen is voor de hand liggend. Het kost je namelijk enorm veel tijd, inspanningen en vooral geld om een oplossing te verzinnen voor iets wat wellicht niet eens je eigen probleem is?

Geldt hetzelfde niet voor e-mail spam? Sluit je een klant af omdat deze enorm veel spam via zijn/haar e-mail ontvangt?
Ik ben van mening dat dit, net als alle andere vormen van spam, een algemeen probleem is dat enkel door de beheerders en applicatiebouwers opgelost (cq vermindert) kan worden.
Helaas heb je hierbij ook de hulp nodig van de beheerders aan de misbruikende kant. Dezen zijn over het algemeen niet zo welwillend mee te werken...

En besides, als je 1 klant afsluit omdat deze blogt en erg veel traffic hierdoor genereert, dan komt de volgende er zo weer aan.

Daar ben ik het niet helemaal mee eens, de beheerders zijn inderdaad de enige die het eigenlijk kunnen stoppen.
Maar de klant kan al veel voorkomen door verstandig met internet om te gaan.

Origineel geplaatst door TheMarco
crazycoder>

Ongenuanceerd maar toch mijn mening:

Het spamprobleem heeft NIETS te maken met weblogsoftware die al dan niet brak is. Ik voel mij ook verder niet eens geroepen om dit toe te lichten moet ik eerlijk zeggen.

Overigens als jij de perfect werkende EN simpele oplossing hebt: Online zetten en in de verkoop doen want er is dan ongetwijfeld een heleboel geld voor je te verdienen.

We hebben zo'n 6000 klanten waarvan enkelen Pivot websites draaien. De enige websites die te maken hebben met referrer-spammers zijn Pivot websites.

Nu mag je mij verklaren waarom dit het enige script/applicatie is dat hier last van heeft. Wellicht is het niet de brakke code, maar een andere (Pivot gerelateerde) oorzaak die dit soort praktijken oproept. In beide gevallen ligt het probleem echter toch wel degelijk bij Pivot zelf.

Het probleem ligt bij de grote inzet van de log.
Het formulier is altijd hetzelfde waardoor een bot enkel steeds dezelfde zaken hoef te posten, werkt erg effectief hoor.

Origineel geplaatst door eMiz0r
Nu mag je mij verklaren waarom dit het enige script/applicatie is dat hier last van heeft. Wellicht is het niet de brakke code, maar een andere (Pivot gerelateerde) oorzaak die dit soort praktijken oproept. In beide gevallen ligt het probleem echter toch wel degelijk bij Pivot zelf.

Hetzelfde gebeurd bij andere blogs, zoals Drupal, MT (Movable Type) e.d. Wij zien ook vrij veel (geautomatiseerde) spam bij gastenboeken, zoals die van Dream Catchers. Het komt gewoon omdat, zoals Triloxigen al zei, de methode steeds hetzelfde is (en men het vaak op dezelfde lokatie installeerd). E1n automated script is alles wat een spammer nodig heeft.

Beste Webhosters / Webhosting afnemers,

Ik zal mijn kant op het verhaal vertellen.

De site van deze meneer veroorzaakte bij ons veel problemen. Zoals: server downtime, load die omhoog ging van normaal 0,13 % naar 100 % en veel van onze klanten en wij ook veel spam berichten ontvingen.

Natuurlijk is dit niet doel van deze meneer en hebben wij geprobeerd een oplossing te vinden. Deze werd echter neit snel genoeg gevonden in ogen van de meneer.

Wij zijn niet de beroerste en hebben deze meneer een groot deel van zijn geld terug gestort en op een vriendelijke manier verzocht om een nieuwe hosting provider te zoeken. Aangezien wij hem niet in zijn behoeften konden voorzien.

Dit is wel een kant het verhaal maar denk dat min6 zijn kant ook heeft verteld.

Vriendelijke groet,

Jan-Willem Fhij

Origineel geplaatst door Topservers
load die omhoog ging van normaal 0,13 % naar 100 %

Ongetwijfeld dat door de betreffende website de server het drukker kreeg als normaal (mischien wel ontzettend druk). Maar een load van 100% is onmogenlijk.
Een CPU usage van 100% ok, maar load? Dat wordt ten eerste niet in procenten uitgedrukt, en ten tweede is er in principe geen max aan een load tehangen. (eventueel dat de kernel waarde nprocs het max aan zou geven).

Origineel geplaatst door royen99


Ongetwijfeld dat door de betreffende website de server het drukker kreeg als normaal (mischien wel ontzettend druk). Maar een load van 100% is onmogenlijk.
Een CPU usage van 100% ok, maar load? Dat wordt ten eerste niet in procenten uitgedrukt, en ten tweede is er in principe geen max aan een load tehangen. (eventueel dat de kernel waarde nprocs het max aan zou geven).

Correct foutje het was cpu usage.

De reden dat Pivot zoveel referrer spam op zich af krijgt is het feit dat in default installaties een lijst met recente referrers op de frontpage wordt afgedrukt. Een spammer's natte droom natuurlijk. Ik heb enige tijd geleden een onderdeel aan Pivot-Blacklist toegevoegd dat de referrers in deze lijst via javascript toevoegt waardoor tools als het gewraakte PRStorm geen effect meer hebben. Hoe het werkt heb ik hier beschreven:

http://www.i-marco.nl/weblog/archive...er_spammers_21

Hoewel dit perfect werkt duurt het helaas een eeuwigheid voordat alle Pivot gebruikers het in gebruik genomen hebben, als ze het uberhaupt al doen. Het lijstje referrers zal dan ook verdwijnen in toekomstige Pivot versies. Helaas hebben de spammers hier een stukje blogosphere om zeep geholpen.

Heb inmiddels een manier gevonden om de spammers te blocken via IIS (Win2k3). Mochten er nog mensen zijn die hier een oplossing voor zoeken, here he goes:

Download ISAPI_Rewrite (de lite versie is gratis en voldoende te te blocken): http://www.helicontech.com/download/#isapi_rewrite en installeer het programma.

Er wordt automatisch een ISAPI Filter toegevoegd in IIS (onder "Web site"), dit behoeft verder geen actie.

In C:\Program Files\Helicon\ISAPI_Rewrite staat een file genaamd httpd.ini (dit is de vergelijkbare file zoals .htaccess onder Apache). Het bestand is Read Only, schakel dit even uit als je het bestand wilt kunnen editen.

Plaats vervolgens de volgende tekst in het bestand en sla het op:

[ISAPI_Rewrite]

# Defend your computer from some worm attacks
RewriteRule .*(?:global.asa|default\.ida|root\.exe|\.\.).* . [F,I,O]

RewriteCond Referer: .*(?:keyword1|keyword2|keyword3|keywordN).*
RewriteHeader Referer: .* damn\.spammers
RewriteCond Referer: .*http://(?:www\.)?spam-site1.com.*
RewriteHeader Referer: .* damn\.spammers
RewriteCond Referer: .*http://(?:www\.)?spam-site2.com.*
RewriteHeader Referer: .* damn\.spammers
RewriteCond Referer: .*http://(?:www\.)?spam-site3.com.*
RewriteHeader Referer: .* damn\.spammers
RewriteCond Referer: .*http://(?:www\.)?spam-siteN.com.*
RewriteHeader Referer: .* damn\.spammers

RewriteCond Referer: .*damn\.spammers.*
RewriteRule (.*) $1 [F,I,L]

Als je in de IIS logs van de website kijkt worden de http referrers altijd bijgehouden. Om even een voorbeeld te nemen:

HEAD /categories/juridisch/index.php - 80 - 148.244.150.52 HTTP/1.1 User-Agent:+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1) - http://homeschool.mvoicesfl.org/z128j4r/

De referrer is "http://homeschool.mvoicesfl.org/z128j4r/". Alles wat je hoeft te doen is in het bestand httpd.ini in plaats van "keyword1" bijvoorbeeld "homeschool" in te vullen. Alle referrers die het woord homeschool bevatten worden geblockt en krijgen een 404 error als ze de website proberen te bezoeken.

Bronvermelding: http://blog.rex.la/archive/2005/07/06/1549.aspx (handig om even door te lezen, daar staat duidelijk uitgelegd wat er precies gebeurd).

Origineel geplaatst door eMiz0r
Heb inmiddels een manier gevonden om de spammers te blocken via IIS (Win2k3). Mochten er nog mensen zijn die hier een oplossing voor zoeken, here he goes:

Download ISAPI_Rewrite (de lite versie is gratis en voldoende te te blocken): http://www.helicontech.com/download/#isapi_rewrite en installeer het programma.

Naar ISAPI_Rewrite ben ik ook aan het kijken. Bevalt dit? Zie WHT posting.

Origineel geplaatst door royen99


Ongetwijfeld dat door de betreffende website de server het drukker kreeg als normaal (mischien wel ontzettend druk). Maar een load van 100% is onmogenlijk.
Een CPU usage van 100% ok, maar load? Dat wordt ten eerste niet in procenten uitgedrukt, en ten tweede is er in principe geen max aan een load tehangen. (eventueel dat de kernel waarde nprocs het max aan zou geven).

http://downloads.mijn-sleutel.net/images/crash2.JPG http://downloads.mijn-sleutel.net/images/crash.JPG

@ Mikey

WTH ..?
Niet echt gezond lijkt me :P