Bekijk Volledige Versie : hosting die met spam om kan gaan
Hallo,
Ik ben op zoek naar een hostingprovider die met grote hoeveelheden Spam-scans om kan gaan. Mijn website trekt op een of andere manier duizenden spammers die mijn Pivot weblog scannen, hetgeen resulteert in een server die ontzettend traag wordt (CPU 84%, om maar iets te noemen).
Mijn vorige provider Flexwebhosting heeft dit uiteindelijk op kunnen lossen door duizenden IP's in .htacces te zetten, maar mijn nieuwe provider topservers.nl lukt dit op een of andere manier niet. (Dit concludeer ik omdat men mijn mails en telefoontjes niet meer beantwoord sinds het probleem speelt. Ondertussen staat de site al dagen offline.)
Ik zou erg blij zijn met een hosting provider die me op voorhand kan vertellen dat dit voor hun geen probleem is, zodat mijn site eindelijk weer eens langer dan twee dagen achter elkaar online kan zijn.
Alvast dank,
Wim
't Is me niet helemaal duidelijk wat je bedoelt met:
>Mijn website trekt op een of andere manier duizenden spammers die mijn Pivot weblog scannen.
Bedoel je wellicht spam entries/comments of verzend men via jou pivotlog spam?
Misschien een idee om je Pivot weblog te beveiligen tegen dit soort `aanvallen`?
TP edit: verkapte aanbieding
Triloxigen
23/09/05, 15:15
Iedere webhoster met een eigen server kan dit afvangen voor je.
Triloxigen
23/09/05, 15:18
Met gemak, gewoon IP's blokkeren :)
En anders kun je nog met een grafische authorisatie werken.
Zal best dat het heel eenvoudig is, maar dat geldt kennelijk niet voor iedere hosting provider. :)
Daarom wil ik er nu een die me op voorhand kan verzekeren dat het werkt, ik dacht misschien is die hier te vinden...
Wat ik bedoel met SPAM-scans weet ik ook niet precies, ik heb de info ook maar van mijn providers. Er wordt veel spam gepost op mijn site, maar nog meer IP's worden al door Pivot zelf geblokkeerd. Volgens mij is het zo dat (ookal worden ze geblokkeerd) ze wel gewoon alle entry's scannen o.i.d., en daarom zoveel CPU van de server trekken.
Mogelijk kun je eens hier naar kijken:
http://www.i-marco.nl/pivot-blacklist/
Thnz, die heb ik al geïnstalleerd. Maar is niet voldoende.
'spam scannen' is een term waar ik als spam expert nog nooit van gehoord heb. Er zijn twee mogelijkheden: ofwel men probeert comments of trackback te posten via de submit scripts van pivot ofwel men doet aan referrer spam door stomweg enorm veel pagina's van je blog op te vragen met fake referrers. Het eerste wordt 100% geblokkeerd door Pivot-Blacklist als je het goed geconfigureerd hebt. Ik ben de maker ervan en draai het zelf op 4 sites en krijg nooit spam. Je moet wel een van de extra features aanzetten: OSA, HashCash of SpamQuiz. Doe je dit niet dan wordt elk comment langs de volledige blacklist gescanned en dat is WEL CPU intensief. Die blacklist scan is bedoeld als 'last resort' voor als iets alle andere checks al gehaald heeft maar we toch voor de zekerheid het bericht nog even willen doorlichten om mogelijke handmatige spam ook nog af te vangen. Gebruik je dus een van de extra features dan worden alleen de legitieme comments gescanned. Tenzij je geenstijl.nl of een dergelijk druk becommentarieerd blog bent zou je dan dus geen last van CPU overhead moeten hebben.
Het tweede kost je veel bandbreedte maar zou niet veel CPU power moeten vragen. Ze vragen gewoon de pagina's op, lijkt me geen actie waar een server last van zou moeten krijgen. Het verlies van bandbreedte aan referrer spammers is alleen op te lossen door goede .htaccess rules. Niet alleen ip blocks maar ook rules die referrers met porno-, gok- of medicijntermen blokkeren en een 403 sturen die weinig bytes bevat. Zo doe ik het in ieder geval zelf. Ik bied overigens op mijn blog mijn continu up to date .htaccess aan voor wie hem wil.
http://www.i-marco.nl/weblog/
Hij staat bovenaan onder het lijstje 'current interesting reads'.
- Marco
Thna Marco. Helaas zijn de heren van Topservers.nl compleet onbereikbaar en kan ik ze dit dus niet mededelen.
Desondanks heb ik wel conact met een andere provider gehad die met hetzelfde probleem worstelde, ik zal hem dit ook even laten weten.
Overigens kun je nog verder gaan en de IP's in je firewall rules zetten. Aangezien ik momenteel nog op een wat brakke server zit die we binnenkort toch vervangen doe ik het nu even met .htaccess maar straks gewoon met iptables rules. Dan krijgen deze requests geen byte en geen cpu cycle meer van je server.
Misschien kom ik bot over maar een provider die hier niet mee om kan gaan vind ik persoonlijk knap waardeloos. De halve wereld is aan het bloggen en heeft last van dit type spam. Een beetje provider zou dus maatregelen moeten treffen. Ik kan het ook en ik ben geen eens een provider ;)
Ach ja prutsers vind je overal, zelfs in Deurne :)
Origineel geplaatst door min6
Thna Marco. Helaas zijn de heren van Topservers.nl compleet onbereikbaar en kan ik ze dit dus niet mededelen.
Stuur ze eens een PB:
http://www.webhostingtalk.nl/showthread.php?s=&threadid=76851 ;)
Overigens vind ik niet dat je de provider de schuld in de schoenen kan schuiven; je kan hooguit verwachten dat men probeert met je mee te denken. Tenslotte ben jij degene die met zo'n blog/script aan de slag gaat, niet de provider. Vanuit mijn eigen bedrijfsvisie geredeneerd help ik wel actief mee; aangezien ook ik net als TheMarco er vanuit ga dat er meerdere klanten met een vergelijkbaar probleem worstelen, vang ik meerdere vliegen in 1 klap.
Origineel geplaatst door headout
Stuur ze eens een PB:
http://www.webhostingtalk.nl/showthread.php?s=&threadid=76851 ;)
Overigens vind ik niet dat je de provider de schuld in de schoenen kan schuiven; je kan hooguit verwachten dat men probeert met je mee te denken. Tenslotte ben jij degene die met zo'n blog/script aan de slag gaat, niet de provider. Vanuit mijn eigen bedrijfsvisie geredeneerd help ik wel actief mee; aangezien ook ik net als TheMarco er vanuit ga dat er meerdere klanten met een vergelijkbaar probleem worstelen, vang ik meerdere vliegen in 1 klap.
Ja percies, ik zag net dat topservers een post had gemaakt (http://www.webhostingtalk.nl/showthread.php?s=&threadid=76851) dus aanwezig moet hij wel zijn :)
Ach laat de discussie over het al dan niet schuldig zijn van de provider maar achterwege, waar ik me met name aan stoor is het feit dat men sinds die problemen spelen geen tel. meer aanneemt en geen mail meer beantwoort. Dat ze wel gewoon aanwezig zijn verbaasd me niet.
SCHULDIG zijn de providers niet natuurlijk. Zij kunnen er ook niks aan doen dat er spam binnenkomt. Wat ik echter wel van een provider verwacht is dat deze de ontwikkelingen op het internet volgt en zorgt dat hij voorbereid is op zaken die voor de hand liggen.
Je hoeft geen enorme connaisseur te zijn om te weten dat 'webloggen' al geruime tijd populair is. Zelfs suffe politici doen er al aan mee, kun je nagaan. Kortom, als provider zijnde zou je je daar in verdiept moeten hebben lijkt mij. Als je dat vervolgens daadwerkelijk gedaan hebt weet je ook dat het blogspam probleem groteske vormen aan het aannemen is en actie dus vereist is. Er draaien zoveel spamruns dat als je een shared server hebt waar zeg 50-100 mensen een klein persoonlijk blogje op draaien je een goede kans hebt dat de machine af en toe ofwel praktisch onbereikbaar wordt ofwel zelfs helemaal het hoekje om gaat. En dat vinden die 100 bloggende klanten niet fijn natuurlijk. Dit alles is te voorkomen door gebruik te maken van gecentraliseerde lijsten met spam IP's, htaccess rules en aanverwante zaken.
Origineel geplaatst door TheMarco
http://www.i-marco.nl/weblog/
Hij staat bovenaan onder het lijstje 'current interesting reads'.
- Marco
Waar precies?
http://www.i-marco.nl/weblog/htaccess.txt
Maar staat inderdaad bovenaan bij 'current interesting reads'; duidelijk kan Marco niet zijn ;)
Pivot bied zelf ook webhosting aan. Ik neem aan dat die het zeker moet kunnen garanderen.
Ik heb zelf geen ervaring met Pivot.
Origineel geplaatst door TheMarco
SCHULDIG zijn de providers niet natuurlijk. Zij kunnen er ook niks aan doen dat er spam binnenkomt. Wat ik echter wel van een provider verwacht is dat deze de ontwikkelingen op het internet volgt en zorgt dat hij voorbereid is op zaken die voor de hand liggen.
Hetzelfde geldt voor alle e-mail injection runs die de afgelopen tijd enorm populair geworden zijn. Maar mijns inziens is deze specifieke issue op twee entiteiten terug te voeren:
* De maker(s) van Pivot; Zij hebben blijkbaar iets geproduceert dat erg eenvoudig te misbruiken valt (alle comment spam wordt naar mijn idee automated gepost)
* De thuis gebruiker die zijn/haar PC geinfecteerd laat raken door een (worm)virus / trojan.
Oke, dit is wel erg kort door de bocht, ik weet het.
Alle hosts die ik uit onze accesslogs heb gevist zijn breedband-hosts (from all over the world) en het zou mij niet verbazen als er een virusje op die betreffende host(s) rondwaard...
Stelling: Gaat Pivot de kant van phpBB en PHP-Nuke op?
Je hoeft geen enorme connaisseur te zijn om te weten dat 'webloggen' al geruime tijd populair is. Zelfs suffe politici doen er al aan mee, kun je nagaan. Kortom, als provider zijnde zou je je daar in verdiept moeten hebben lijkt mij. Als je dat vervolgens daadwerkelijk gedaan hebt weet je ook dat het blogspam probleem groteske vormen aan het aannemen is en actie dus vereist is. Er draaien zoveel spamruns dat als je een shared server hebt waar zeg 50-100 mensen een klein persoonlijk blogje op draaien je een goede kans hebt dat de machine af en toe ofwel praktisch onbereikbaar wordt ofwel zelfs helemaal het hoekje om gaat. En dat vinden die 100 bloggende klanten niet fijn natuurlijk. Dit alles is te voorkomen door gebruik te maken van gecentraliseerde lijsten met spam IP's, htaccess rules en aanverwante zaken.
Een DNSBL op HTTP niveau is iets waar ik (nog) geen vertrouwen in heb, noch professionele implementaties van heb gezien. Alhoewel ik mij hier niet in verdiept heb. Gezien de trend in vergelijking met SMTP kan je verwachten dat iets dergelijks er aan zit te komen (op een wat uitgebreidere manier dan nu het geval is). Verder vraag ik me af hoeveel CPU-tijd 100 htaccess bestanden met honderden, duizenden of meer entries vreten:
When (not) to use .htaccess files (http://httpd.apache.org/docs/2.0/howto/htaccess.html)
Dan zou je al voor een firewall oplossing moeten kiezen. Nadeel hieraan is dat je pas achter een spammende host komt als deze langs geweest is. Je voorkomt dus enkel een tweede (tweeduizendste) bezoek. Tevens is het werk zeer arbeidsintensief.
Origineel geplaatst door Digiover
Stelling: Gaat Pivot de kant van phpBB en PHP-Nuke op?
Is dat niet een logisch gevolg van de populariteit van het/een stukje software?
Een DNSBL op HTTP niveau is iets waar ik (nog) geen vertrouwen in heb, noch professionele implementaties van heb gezien. Alhoewel ik mij hier niet in verdiept heb.
Ik heb eens eerder een postje (http://www.webhostingtalk.nl/showthread.php?s=&postid=473678#post473678) over dit onderwerp geplaatst. Ik heb positieve ervaringen met het gebruik van proxy DNSBL's op websites.
Een groot forum dat ik beheer heeft regelmatig last van trolls. Ik gebruik nu ongeveer bovenstaande code bij het aanmelden om te voorkomen dat men vanaf proxy's aanmeldt. Dit werkt erg goed, en zou wat mij betreft een standaardoptie moeten zijn in dit soort scripts. Ik zie het echter zelden.
Origineel geplaatst door headout
Is dat niet een logisch gevolg van de populariteit van het/een stukje software?
Nee, het is het logische gevolg van brakke software. Zie bijvoorbeeld de Bugtraq of WebAppSec mailinglijsten, deze twee software pakketten zijn recordhouder wat betreft (ernstige) kwetsbaarheden.
Puzil.com (http://204.13.211.139/puzil/default.aspx) ziet er uit als een aardige (mogelijke) oplossing. Net als een Captcha (geen idee of dit in Pivot al beschikbaar is).
Marco, enig idee of Puzil publiekelijk beschikbaar wordt (het vraag - antwoord systeem / script), of dat het alleen op puzil.com blijft op een manier dat er gebruik van gemaakt kan worden?
Origineel geplaatst door skydancer
Ik heb eens eerder een postje (http://www.webhostingtalk.nl/showthread.php?s=&postid=473678#post473678) over dit onderwerp geplaatst. Ik heb positieve ervaringen met het gebruik van proxy DNSBL's op websites.
3 opmerkingen:
* checkdnsrr() (http://nl3.php.net/manual/en/function.checkdnsrr.php)
This function is not implemented on Windows platforms.
* Ik zou een die(); of exit(); bij in de functie gebruiken :)
* Zoals jouw postje nu is, moet het in ieder script apart gebruikt worden en zit het niet in de/een webserver ingebakken.
Maar afhankelijk van het betreffende script (pakket) zou het zeker een goede toevoeging kunnen zijn.
crazycoder
27/09/05, 19:00
Origineel geplaatst door TheMarco
Het tweede kost je veel bandbreedte maar zou niet veel CPU power moeten vragen. Ze vragen gewoon de pagina's op, lijkt me geen actie waar een server last van zou moeten krijgen. Het verlies van bandbreedte aan referrer spammers is alleen op te lossen door goede .htaccess rules. Niet alleen ip blocks maar ook rules die referrers met porno-, gok- of medicijntermen blokkeren en een 403 sturen die weinig bytes bevat. Zo doe ik het in ieder geval zelf. Ik bied overigens op mijn blog mijn continu up to date .htaccess aan voor wie hem wil.
Sorry hoor, maar voor een goed geschreven pakket zou je helemaal dat soort rare dingen niet uit moeten halen. Eenvoudige oplossingen zijn imo de beste, bij voorkeur zonder van derden afhankelijk te zijn voor om het even wat voor blacklist.
Ik vraag mezelf ook een beetje af tot in hoeverre de anti-spam maatregelen bij kunnen gaan dragen tot een extra hoge load.
* Ik zou een die(); of exit(); bij in de functie gebruiken
Ja, en ik voeg de bezoeker zelfs toe in de firewall!
De zelfde grapjassen gingen namelijk DDoSsen vanaf proxies toen ze niet meer konden registreren.. :(
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.
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.
Triloxigen
06/10/05, 10:37
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.
Triloxigen
06/10/05, 19:08
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.
Topservers
07/10/05, 14:14
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).
Topservers
07/10/05, 14:46
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/2005/08/17/bye_bye_referrer_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 (http://www.webhostingtalk.nl/showthread.php?s=&threadid=77654).
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
Origineel geplaatst door ThaBomb
@ Mikey
WTH ..?
Niet echt gezond lijkt me :P
Was het ook niet, persoonlijk record zullen we het maar noemen ... Kwam door rotte hardware en nog een veel rotter shell script :rolleyes:
ISAPI_Rewrite (nu nog de "Lite" versie) werkt erg goed, over de komende paar dagen zullen we zien of een test server bij ons het wat minder zwaar te verduren krijgt. Ik houd jullie hiervan op de hoogte, het is toch wel een issue waar meerdere providers mee te maken hebben (of krijgen).
@eMiz0r:
[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]
Kan natuurlijk veel korter (of de tests 100% goed zijn weet ik nog niet, maar het werkt):
[ISAPI_Rewrite]
# Defend your computer from some worm attacks
RewriteRule .*(?:global.asa|default\.ida|root\.exe|\.\.).* . [F,I,O]
# We herschrijven de refer
RewriteCond Referer: .*(?:keyword1|keyword2|keyword3|keywordN).*
RewriteHeader Referer: .* damn\.spammers [F,I]
# de herschreven refer krijgt een F flag (Forbidden, 403)
RewriteCond Referer: .*damn\.spammers.*
RewriteRule (.*) $1 [F,I,L]
Origineel geplaatst door Digiover
ISAPI_Rewrite (nu nog de "Lite" versie) werkt erg goed, over de komende paar dagen zullen we zien of een test server bij ons het wat minder zwaar te verduren krijgt. Ik houd jullie hiervan op de hoogte, het is toch wel een issue waar meerdere providers mee te maken hebben (of krijgen).
@eMiz0r:
Kan natuurlijk veel korter (of de tests 100% goed zijn weet ik nog niet, maar het werkt):
Klopt Jan, met Rewrite header kun je een specifieke url blokkeren. Echt praktisch is dat alleen niet, want zo blijf je bezig met die spammers :)
Het programma werkt echt ideaal. Sinds dat we deze methode gebruiken is de gemiddelde belasting van een server enorm gezakt. Ook het dataverkeer van de betreffende klanten is een stuk minder geworden, zodat ze niet meer zo snel in de problemen komen.
Hou me even op de hoogte als je eventueel nog wat dingen tegenkomt!
Webhosting4you
16/10/05, 21:26
Knip Janneman
Heel subtiel hoor webhosting4you om je eigen url hier te komen spammen ;)
Kan jij nou eens wegblijven van dit forum?
Alvast bedankt.
Origineel geplaatst door Wido
Kan jij nou eens wegblijven van dit forum?
Alvast bedankt. Valt me al mee dat hij deze keer zijn URL wél goed kan spellen :D