Wat mag een webhoster doen bij overlast door een klant?

| AE 2956 | Ondernemingsvrijheid | 21 reacties

account-suspended.pngEen lezer vroeg me:

Als webhoster merk ik regelmatig dat sites van mijn klanten overlast veroorzaken. Mensen versturen (bedoeld of onbedoeld) spam, hun websites worden gehackt met spamscripts of Trojans die drive-by-downloads met malware inzetten. Of er staat ineens een proxy of IRC-botje op dat allerlei ongewenst verkeer veroorzaakt.

Nu kan ik natuurlijk het account op zwart zetten, maar dat voelt nogal zwaar als het gaat om één concreet dingetje. Mag ik in zo’n geval ook het bestand in kwestie fixen of verwijderen? Moet ik met de klant overleggen wat te doen? Ben ik sneller aansprakelijk bij het wijzigen van bestanden dan bij het afsluiten van de klant?

Een hoster heeft een zorgplicht naar zijn klant én naar andere klanten. Hij mag alles doen dat redelijkerwijs binnen die zorgplicht past en proportioneel is. Bij één spamrun een hele website offline halen is niet proportioneel bijvoorbeeld. Het lijkt me dan logischer dat je even een zware limiet zet op het aantal mails dat vanuit zijn account naar buiten gaat.

Bestanden wijzigen of weggooien is proportioneler dan een geheel account op zwart zetten. Je hebt alleen wel een groter risico op problemen, want een ontbrekend bestand kan allerlei andere fouten veroorzaken of tot onvoorziene schade leiden. En de vraag is dan of je dat had moeten voorzien; zo ja, dan ben je er voor aansprakelijk. Wat dat betreft is op zwart zetten ‘veiliger’. Maar het voelt niet prettig vanuit klantvriendelijkheid natuurlijk.

Het beste is om dit in de AV van de hoster te regelen. Als daarin staat dat hij alles mag doen dat hem goeddunkt, dan kan er eigenlijk nooit discussie ontstaan. Nou ja, tenzij hij hele grote dingen sloopt om één probleempje op te lossen.

Overleg met de klant is netjes maar de hoster is niet verplicht dit te doen, zeker niet als in de AV staat dat het niet hoeft. En als de klant niet op tijd reageert, dan mag de hoster sowieso zelf door want hij moet toch iets.

Meelezende hosters: hoe gaan jullie om met geïnfecteerde klantwebsites, overlastgevende eggdrops of spamruns bij klanten die niet in het spammerprofiel passen?

Arnoud

Deel dit artikel

  1. hun websites worden gehackt met spamscripts of Trojans

    Hun websites of JULLIE servers (door een exploit van Apache, PHP, MySQL, Joomla, WordPress etc.)?

    De site van een bekende heeft hier al enkele malen last van gehad en hij gebruikt alleen statische HTML files.

    En wat als dan blijkt dat na het afsluiten van een site, het aan de server lag en de provider niet de laatste patches heeft geinstalleerd?

  2. Marcel: er zijn ook klanten die menen dat alles HTML is. Maar hadden er even niet aan gedacht dat het CMS nog een FCKEditor bevat en daar een example01.php bevat (o.i.d.). De meeste webbouwers kijken bijvoorbeeld niet meer naar een gebouwde website, en updaten eventueel gebruikte componenten ook niet. Jammer.

    Maar, en daar moet ik je gelijk geven, er zijn ook genoeg “providers” die lachend oude software blijven draaien. Soms ook op verzoek van klanten trouwens. Er zijn klanten van ons die per se op PHP 5.2.17 willen draaien, omdat zij geen tijd hebben om alle websites door te lopen op compatibiliteit met 5.3.x.

    Wij hebben het e.e.a. hiervoor in onze AV staan. We handhaven op het criterium: als wij, of andere klanten, er last van krijgen dan grijpen we in. Onze AV geeft recht tot opschorten van de diensten, maar in de praktijk nemen we maatregelen die afhankelijk zijn van de impact en het de overlast.

  3. Mij lijkt dat direct informeren van de klant in ieder geval noodzakelijk is, anders stelt de zorgplicht weinig voor.

    De reactie zou af moeten hangen van de urgentie lijkt me. Voor een website die virussen verspreidt lijkt me dat ook voor de klant volledig blokkeren beter is dan door laten lopen, want de reputatieschade en het risico dat de klant aansprakelijk gehouden wordt lijken me aanzienlijk. Ik kan me niet voorstellen dat het belang de website in de lucht te houden groter kan zijn dan het belang schade te voorkomen. Bij bijvoorbeeld spam zou blokkeren van de SMTP poort genoeg moeten zijn. Gezien het risico dat IP adressen van de provider zonder actie op blacklists terecht komen lijkt me dit sowieso redelijk wanneer er gespamd wordt. Als het gaat om kleinere problemen zoals advertenties, defacement of uploaden van warez zou ik eerste de reactie van de klant afwachten.

  4. Ik ken ook het verhaal van een provider die zijn klanten voorzag van een standaard “beheeromgeving”, maar er niet bij vertelde dat de klanten zelf de updates moesten bijhouden… Met als gevolg dat in een hack-actie een groot deel van de gehoste sites gepwnd was.

  5. Het lijkt mij gevaarlijk om als hoster maatregelen te nemen. Het feit dat je die maatregelen neemt betekent immers dat je toezicht uitoefent op de informatie op je servers en, bijgevolg, dat je kennis hebt van deze informatie. Dan verlies je de “safe harbour” die artikel 14 van de E-commerce richtlijn biedt – minstens riskeer je die te verliezen.

  6. Dit is één van de lastigste juridische kwesties waar hosters mee te maken hebben. Natuurlijk kun je in je algemene voorwaarden opnemen dat je alles mag doen wat je blieft in geval van problemen, maar de vraag is of dat stand houdt in het geval dat er iets aan de hand houdt. Het zal daarom altijd aankomen op een concrete belangenafweging. De problemen worden vrijwel altijd veroorzaakt door een een gescript systeem, het probleem zal vrijwel nooit ontstaan bij platte HTML. Zelf ingrijpen in de bestanden of database van een gescript systeem is riskant, je weet immers niet hoe het is opgezet en zelfs bij standaard software weet je niet of er bepaalde aanpassingen zijn gedaan. Daarnaast is het vaak niet mogelijk om één bestand te verwijderen zonder dat het systeem niet goed meer functioneert. De hele website op zwart zetten is daarom in veel gevallen de enige reële optie voor een hoster.

    Mijn advies is daarom om indien er geen sprake is van een probleem dat onmiddellijk hoeft te worden opgelost, de klant een redelijke termijn te geven om zelf in te grijpen (bijvoorbeeld binnen 24 tot 48 uur). Indien daarna nog niet is ingegrepen de website alsnog op zwart te zetten. In het geval van een acuut probleem, bijvoorbeeld door een spamrun of er sprake is van grote belasting van de server, kun je de website direct op zwart zetten. Wat je ook doet, meldt het probleem zo snel mogelijk bij de klant, zodat die zelf maatregelen kan nemen en daarmee de schade voor alle partijen zoveel mogelijk beperkt blijft.

  7. Goed punt Arnout. De manier waarop je er als hoster mee omgaat, maakt een wereld van verschil. Ik ken partijen die de website (en bijbehorend hostingpakket) op zwart gooien en dan een e-mail sturen (uitkomend op de zojuist offline gegooide account) en dan roepen dat ze voldoende hebben gedaan.

    Er zijn ook situaties te bedenken waarin een belletje ook prima kan, ook afhankelijk van de genomen maatregel natuurlijk. Voor de dossieropbouw zou ik ook altijd even een e-mail o.i.d. doen. Al is het voor je eigen logging.

  8. Mja, sorry hoor, maar wat is er mis om als hoster je klant even aan te spreken? Zoals al eerder geopperd hier is het vaak de software van de hoster die niet juist op orde is. Dus ik vind het nogal een delicate kwestie om zomaar aan de bestanden van je klanten te rommelen. Ik denk dat contact opnemen naar elkaar toe hier de juiste oplossing is. Een klant ziet vaak niet aan de resources dat er een spamrun gedaan wordt. Sterker nog, veelal wordt spam verstuurd vanuit een andere locatie, maar wel met het e-mailadres van bijvoorbeeld de klant. Waardoor de bounced mails voor overlast zorgen.

  9. @10 Soms is daar geen tijd voor als men een fout gebruikt om een spam run te doen dien je gelijk in te grijpen als hoster als je te lang wacht dan wordt het domein en IP adres geblokkeerd. Dit levert overlast op voor iedereen die het IP adres gebruikt of na hun wil gebruiken. In sommige gevallen kan het zelfs zijn dat een uplink provider de hoster benaderd als iemand last veroorzaakt hier dien je zo snel mogelijk te handelen.

    Als de software de schuldige is dan kan dat meestal niet gelijk aangepakt worden aangezien hier meerdere partijen last van kunnen krijgen. In meeste gevallen van misbruik is het de eigenaar van de website die een fout heeft gemaakt vele denken dat ze PHP kunnen of welke andere script taal maar feit is dat ze meestal niet op de hoogte zijn hoe te beveiligen.

  10. Mij lijkt het zaak om met minimale middelen in te grijpen, en dan alleen als het echt nodig is, en indien mogelijk in overleg met de klant. En ik zou als klant ook wel graag in de algemene voorwaarden o.i.d. willen zien welke maatregelen de hoster zou kunnen nemen, en in welke situaties. De situaties moeten zodanig helder geformuleerd zijn dat ze op een betrouwbare manier ontweken kunnen worden door een goedwillende klant.

    Voorbeeld 1: een site wordt gehackt, doordat de klant van wie de site is een beveiligingslek heeft veroorzaakt. Dat is volgens mij niet voldoende reden om in te grijpen. Als je dit detecteert, dan zou je de klant op de hoogte kunnen stellen, en assisteren in het verhelpen van het probleem. De leiding blijft bij de klant.

    Voorbeeld 2: een site wordt gehackt en begint massaal spam te versturen. Hierbij is het noodzakelijk dat de host direct ingrijpt, anders komt de host op zwarte lijsten te staan waardoor andere klanten geen e-mails meer kunnen versturen. Je moet dus een helder criterium hebben om spam te definiëren (bijv. een aantal e-mails per seconde, of iets meer geavanceerds), en als dat criterium bereikt is, met minimale middelen ingrijpen. Minimale middelen lijkt mij in dit geval het afsluiten van e-mail verkeer van deze klant, totdat het probleem is verholpen.

    Het wijzigen/verwijderen van bestanden van de klant lijkt mij een zeer ernstig middel, en ik zie geen enkele situatie waarin dat gerechtvaardigd is. Ik zou dat alleen doen als er voor de host een juridische noodzaak voor bestaat, bijv. als het om kinderporno gaat.

  11. Mij lijkt het zaak om met minimale middelen in te grijpen, en dan alleen als het echt nodig is, en indien mogelijk in overleg met de klant. En ik zou als klant ook wel graag in de algemene voorwaarden o.i.d. willen zien welke maatregelen de hoster zou kunnen nemen, en in welke situaties. De situaties moeten zodanig helder geformuleerd zijn dat ze op een betrouwbare manier ontweken kunnen worden door een goedwillende klant.

    Voorbeeld 1: een site wordt gehackt, doordat de klant van wie de site is een beveiligingslek heeft veroorzaakt. Dat is volgens mij niet voldoende reden om in te grijpen. Als je dit detecteert, dan zou je de klant op de hoogte kunnen stellen, en assisteren in het verhelpen van het probleem. De leiding blijft bij de klant.

    Voorbeeld 2: een site wordt gehackt en begint massaal spam te versturen. Hierbij is het noodzakelijk dat de host direct ingrijpt, anders komt de host op zwarte lijsten te staan waardoor andere klanten geen e-mails meer kunnen versturen. Je moet dus een helder criterium hebben om spam te definiëren (bijv. een aantal e-mails per seconde, of iets meer geavanceerds), en als dat criterium bereikt is, met minimale middelen ingrijpen. Minimale middelen lijkt mij in dit geval het afsluiten van e-mail verkeer van deze klant, totdat het probleem is verholpen.

    Het wijzigen/verwijderen van bestanden van de klant lijkt mij een zeer ernstig middel, en ik zie geen enkele situatie waarin dat gerechtvaardigd is. Ik zou dat alleen doen als er voor de host een juridische noodzaak voor bestaat, bijv. als het om kinderporno gaat.

  12. Overlast door andere klanten op een shared host is ook een zeer groot probleem. Voor studiedoeleinden maakte ik in het verleden gebruik van een shared host, waar ik onder mijn eigen domeinnaam wat test-projectjes onder .NET kon installeren voor de extra ervaring. Veel bandbreedte of schijfruimte had ik daarbij niet nodig dus voor nog geen 10 Euro per maand een leuke host gevonden. Eerste wat natuurlijk mis ging was een upgrade van .NET 1.1 naar 2.0 terwijl ik alleen maar ontwikkeltools voor 1.1 had. Was onaangenaam om erachter te komen dat de server-upgrade opeens mijn sites liet crashen. Maar goed, upgraden en klaar.

    Het werd vervelender nadat ik merkte dat mijn site opeens geinfecteerd werd door malware. Okay, geen probleem want ik zette de backup gewoon terug. Maar de volgende dag weer malware. En weer. Hoster gewaarschuwd en zij zouden ernaar kijken. En ja, ze verwijderden het iedere keer en het bleek steeds weer terug te keren. En waarom? Waarschijnlijk omdat een van de andere 100 klanten op die server op hun site een blog, forum of iets anders hebben geinstalleerd dat kwetsbaar was en waardoor de server steeds opnieuw geinfecteerd werd.

    Tegenwoordig host ik mijn site gewoon op mijn eigen webserver. Een MSDN licentie leverde mij Windows 2008 op en daarbij een goedkope mini-desktop van 400 Euro en ik heb een mooi systeem zonder dat ik daar nog een hoster voor lastig hoef te vallen. 🙂

    Maar goed, een hoster mag dus acties ondernemen tegen een lastige klant, maar met 100+ klanten op een enkele shared host, hoe identificeer je daarbinnen dan de klant die voor overlast zorgt? Hoe ver mag je als hoster gaan in een dergelijk onderzoek? (En moeten hosters hierover iets opnemen in hun AV?)

  13. @ Wim #13 Het probleem dat je beschrijft kan goed voorkomen worden door de verschillende gebruikersaccounts goed gescheiden te houden, en het overkoepelende systeem zo in te richten dat gebruikers niet aan elkaars spullen kunnen komen. Dan kan, zolang het overkoepelende systeem geen veiligheidslekken heeft, malware bij de ene gebruiker niet een andere gebruiker infecteren. Als een host dat niet goed op orde heeft, dan zou ik er gillend wegrennen.

    Dan heb je nog het probleem van excessief gebruik van resources (processor, geheugen, bandbreedte), al dan niet vanwege malware. Ook hierbij bestaan er technieken die de host kan inzetten om te voorkomen dat klanten elkaar te veel lastig vallen. Ik zou als klant graag willen dat de host goed beschrijft welk beleid op dit punt gevoerd wordt.

  14. @14 die technieken kosten geld en vergen investeringen vanuit de hoster, als men hier door de prijzen duurder moet maken dan lopen mensen naar een ander die goedkoper is. De meeste mensen en bedrijven die hun website laten hosten willen dat ze beschikbaar zijn en maken zich niet druk om veiligheid. In andere zaken zie je dat ook terug dat ze een goedkoop script willen hebben en daarbij ook niet op veiligheid let. Een shared account is ten alle tijden meer fout gevoelig dan laat we zeggen virtuele server een dedicated server is he beste dan kan je als zelf doen als je de kennis heb. Een vituele server en shared hosting accounts beschermen is ook niet 100% mogelijk er is altijd wel iets te verzinnen om de server onderuit te laten gaan.

  15. @ 15:

    Duur? Voor dit soort server-dingen bestaat toch allemaal open source software? Gebruikersaccounts binnen Linux zijn wat betreft bestandspermissies en werkgeheugen helemaal van elkaar te scheiden. Voor wat grondigere scheiding moet je je gebruikers misschien virtuele machines geven, maar ook daar bestaat goede open source software voor. Ik denk dat virtualisatiesoftware automatisch de mogelijkheid geeft om schijf, RAM en CPU gebruik te beperken, en voor het beperken van de bandbreedte bestaat vast ook wel wat.

    En ik ben weliswaar geen expert op het gebied van hosting, maar wat ik ervan begrijp is dat hardware-kosten juist lager kunnen zijn bij gebruik van virtualisatie. Maar misschien is dat alleen in vergelijking met dedicated hosting, en niet met “met z’n allen onder 1 OS”.

  16. @ 15:

    Duur? Voor dit soort server-dingen bestaat toch allemaal open source software? Gebruikersaccounts binnen Linux zijn wat betreft bestandspermissies en werkgeheugen helemaal van elkaar te scheiden. Voor wat grondigere scheiding moet je je gebruikers misschien virtuele machines geven, maar ook daar bestaat goede open source software voor. Ik denk dat virtualisatiesoftware automatisch de mogelijkheid geeft om schijf, RAM en CPU gebruik te beperken, en voor het beperken van de bandbreedte bestaat vast ook wel wat.

    En ik ben weliswaar geen expert op het gebied van hosting, maar wat ik ervan begrijp is dat hardware-kosten juist lager kunnen zijn bij gebruik van virtualisatie. Maar misschien is dat alleen in vergelijking met dedicated hosting, en niet met “met z’n allen onder 1 OS”.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS