Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

Overlast door een hostingklant, wat nu?

  • Door
  • Arnout Veenman
  • geplaatst op
  • 5 april 2012 08:05 uur

Regelmatig komt het voor dat websites of servers van klanten van hosters overlast veroorzaken door bijvoorbeeld het versturen, gebruikt worden voor phishing of de server overbelasten. Naar  aanleiding van een vraag welke actie hierop te ondernemen als hoster, schreef Arnoud Engelfriet vorige week een blog. In dit artikel in aanvulling daarop een stapsgewijze uitleg over hoe op juridisch juiste wijze te handelen in het geval van overlast door een hostingklant.

Allereerst is het belangrijk om een aantal zaken vast te stellen, die allemaal in een bepaalde mate van belang zijn om te bepalen welke reactie gepast en juridisch juist is:

  • Waar wordt de overlast door veroorzaakt?
  • Waar bestaat de overlast uit?
  • In welke mate veroorzaakt de overlast schade?
  • Wat zijn de gevolgen als de overlast direct of juist niet direct wordt gestopt?
  • Is er overduidelijk sprake van (grove) schuld of opzet aan de zijde van de klant bij het ontstaan van de overlast?
  • Wat is de minst ingrijpende maatregel om de overlast te stoppen?
  • Wat zijn de gevolgen voor de klant als ik een bepaalde maatregel neem?
  • Wat heb ik in mijn algemene voorwaarden hierover geregeld?

Aard van de overlast en schade
Het is van belang om eerst goed vast te stellen waar de overlast door wordt veroorzaakt. Dit klinkt mogelijk als een open deur, maar het kan goed zijn dat er niet één overlastgever is, maar dat er meerdere zijn. In het geval dat de verkeerde klant uiteindelijk ten onrechte wordt geconfronteerd met (te zware) maatregelen, die voor hem schadelijk zijn terwijl dat niet terecht of proportioneel is geweest, dan kan dat tot aansprakelijkheid van de hoster leiden. Om die reden is het belangrijk om goed vast te stellen waar de overlast door wordt veroorzaakt.

Als de bron van de oorzaak is vastgesteld, moet duidelijk zijn tot welke overlast die leidt. Waar bestaat de overlast die wordt veroorzaakt uit? Hierbij valt te denken aan het versturen van spam, het hosten van een IRC-server, het hosten van een phishing-website, onevenredig beslag leggen op een deel van de capaciteit van de server of het bij tijden en wijlen onbereikbaar zijn van de hele server en alle (andere) websites die daar op draaien.

De volgende stap is om vast te stellen welke schade door de overlast wordt veroorzaakt. Immers veroorzaakt niet alle overlast ook daadwerkelijk schade. Indien een bepaalde klant bijvoorbeeld een onevenredig beslag legt op de capaciteit van de server waar de website van de klant op draait, hoeft niet persé tot schade te leiden. Ook het feit dat er een IRC-server wordt gehost ook niet direct tot schade te leiden, maar brengt wel bepaalde ongewenste risico’s met zich mee en de kans op andere illegale activiteiten. Het hosten van een phishing-website leidt daarentegen wel direct tot schade, gezien de slachtoffers die met een dergelijke website worden gemaakt, net als het versturen van spam, gezien daarmee het IP-adres van de server kan belanden op lijsten met spamversturende servers.

De overlast stoppen
Nu is het zaak om te bepalen op welke wijze er zo effectief en pijnloos mogelijk voor alle partijen een einde kan worden gemaakt aan de overlast en daar door veroorzaakte schade. In het geval van webhosting zal de hoster in beginsel altijd toegang hebben tot de bestanden en databases van de klant. Soms zal het daarbij mogelijk zijn om het overlastgevende element zelf te verwijderen of aan te passen, terwijl met zekerheid kan worden gesteld dat er verder geen schade wordt veroorzaakt aan de website of applicatie van de klant. Denk bijvoorbeeld aan een situatie waarbij er een los phishing-script op de server is geplaatst, dat op zichzelf staat.

Vaak zal dit echter niet het geval zijn en zal een cms of een eigen script dat problemen veroorzaken en onderdeel uitmaakt van een groter geheel. In dat geval is het riskant om zelf in de scripts of database van het betreffende systeem aanpassingen te doen of één bestand te verwijderen. Ook al gaat het om een bekend systeem, door een bepaalde modificatie van de klant, kan het net even anders reageren dan anders. Met tot gevolg het risico van aansprakelijkheid. De overlast stoppen is daarom in de meeste gevallen enkel zonder onnodige technische en juridische risico’s mogelijk door de hele website of server van de klant op zwart te zetten.

Af te wegen belangen
Zodra duidelijk is op welke wijze er het meest effectief kan worden ingegrepen, is het de vraag welke belangen er mee gemoeid zijn als er direct wordt ingegrepen, is de schade die door de overlast wordt veroorzaakt zodanig dat direct ingrijpen gerechtvaardigd is? Hierbij valt in de eerste plaatst te denken aan het belang van de hoster zelf. Daarnaast ook net zo belangrijk, de belangen van de overige klanten van de hoster die schade lijden door de veroorzaakt overlast. Ook mogelijke schade aan derden, zoals van potentiële phishing-slachtoffers mogen worden meegewogen.

Tegenover de belangen die direct ingrijpen rechtvaardigen staat het belang van de klant van wie de website of server is om een termijn te krijgen om zelf maatregelen te nemen om zo de overlast te stoppen of de overlast van tijdelijke aard is. Als de overlast bijvoorbeeld veroorzaakt wordt door dat de website in kwestie aandacht in de landelijke media heeft gekregen, dan is het belang om die aandacht ook echt te kunnen genieten er een die absoluut moet worden meegewogen.

Een laatste vraag bij de af te wegen belangen is de vraag of er sprake is van opzet of (grove) schuld bij de eigenaar van de overlastgevende website of server. Indien de eigenaar op zijn server doelbewust een IRC-server host, terwijl dat verboden is in de algemene voorwaarden, dan rechtvaardigt dat direct ingrijpen een stuk meer, dan als een klant die zijn Joomla cms verder keurig up-to-date heeft, door een 0-day exploit gehackt is en daardoor een phishingwebsite host.

Direct afsluiten of termijn stellen
De belangenafweging die nu moet worden gemaakt, resulteert in het antwoord op de vraag of direct kan worden ingegrepen of dat de eigenaar van de overlastgevende website of server een (en welke) termijn moet worden gegund om zelf in te grijpen? Als vuistregel kan worden gehanteerd dat indien directe afsluiting onevenredig meer schade voor de eigenaar van de overlastgevende website of server betekent dan die alle andere betrokkenen zal lijden, dat hem dan nog een termijn moet worden gegund. De termijn die moet worden gegund is afhankelijk van wanneer de onevenredigheid naar verwachting niet meer zal bestaan. Dit kan een heel korte termijn van één uur zijn, maar ook een van vijf dagen. Echter in de meeste gevallen ook nooit langer. Indien de klant het probleem niet zelf oplost binnen de gestelde termijn, kan de website of server alsnog offline worden gehaald.

Een voorbeeld van waarbij de onevenredigheid in schade door het afsluiten in plaats van termijn gunnen om zelf in te grijpen bestaat is een goed lopende webwinkel met enkele duizenden euro’s omzet per dag, terwijl de overlast bestaat dat een script dat een elk uur een backup maakt, dan één minuut lang er voor zorgt dat de server waar de website op draait iets minder snel reageert. In zo’n geval is te verwachten dat de schade die ontstaat door dat de website wordt afgesloten waarschijnlijk groter, dan de schade die ontstaat als het probleem nog een dag blijft voortbestaan.

Contact met de klant
Neem hoe de afweging van belangen ook uitvalt, zo snel mogelijk contact op met de klant. Daarbij is het aan te raden om je niet te beperken tot een enkel e-mailtje, maar een telefoontje, sms-bericht of faxbericht zijn aan te bevelen. Indien dat niet mogelijk is, zou zelfs een ouderwetse briefje tot de aanbeveling spreken. Daarbij zij opgemerkt dat als de website of server direct op zwart gaat, de e-mail van de klant mogelijk ook niet zal werken, indien dat vermoedelijk het geval is, kan absoluut niet worden volstaan met enkel het versturen van een e-mail.

Maak in de communicatie van de klant duidelijk waar de overlast uit bestaat en op welke wijze hij kan voorkomen dat zijn website of server offline gaat, of juist weer online komt. Indien de website of server offline is gezet, is het belangrijk om vooraf te bepalen op welke wijze de klant zelf toegang tot de website of server zal krijgen, indien die al offline gehaald is. De klant moet een reële kans krijgen om het probleem op te lossen, tenzij de dienstverlening per direct definitief wordt gestaakt, maar ook dan moet de klant in de meeste gevallen wel de kans krijgen om zijn gegevens op korte termijn veilig te stellen.

Algemene voorwaarden
Als laatste is het belangrijk om de mogelijkheden om in te grijpen in het geval van overlast goed in de algemene voorwaarden vast te leggen. In principe zou je zonder maar één woord in je algemene voorwaarden aan het onderwerp te wijden gewoon kunnen ingrijpen bij ernstige overlast, maar de drempel om in te grijpen is dan wel een stuk hoger en het blijft juridisch gezien risicovol. Het is daarom belangrijk om in je algemene voorwaarden een bepaling te hebben staan, waarin is bepaald dat in het geval van door de hoster geconstateerde overlast elke in de ogen van de hoster noodzakelijke maatregel mag worden genomen.

Nog geen reacties

Feedback!
Fill out my online form.
Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.