Wat moet een provider doen bij een DDoS-aanval op de server van een klant?

| AE 2639 | Ondernemingsvrijheid, Security | 19 reacties

Een lezer vroeg me:

Recent kwam mijn website (een colocated eigen server) onder vuur door een DoS-aanval van buitenaf. Ik heb toen mijn provider gevraagd maatregelen te nemen en met name de IP-adressen te filteren of blokkeren waar de aanval vandaan kwam. Zij weigeren dit echter omdat ze vinden dat ik het beheer moet doen op mijn machine. Ook zeggen ze dat het voor hen ondoenlijk is om maatregelen te nemen. Maar ik neem bij hen toch een dienst af, kan ik ze dan niet verplichten in te grijpen als de dienst niet goed werkt?

De plichten die de provider heeft, volgen primair uit het contract. De vraag is dus wat daar instaat over abuse en filteren. En als er niets staat, moet je uit de aard van het contract afleiden wiens verantwoordelijkheid dit moet zijn. Bij een eigen colocated server ben je als klant zelf verantwoordelijk voor het beheer; de plichten van de provider houden op bij de netwerkstekker. De vraag wordt dan dus, is een DDoS-aanval iets dat de stekker raakt of pas het apparaat waar die stekker in zit?

De klant kan zelf blokkeren op een eigen firewall maar dan zit zijn inkomende netwerkverkeer nog steeds vol. Droppen aan de buitenkant (netwerk van de ISP) is efficiënter, zeker, maar hoe weet de ISP dan welke adressen ze moeten droppen?

Een DDOS aanval zou ik eerder als iets van buitenaf zien, net zoals een hagelstorm. Je kunt het niet voorkomen, je kunt alleen de impact beperken. En dan wordt de vraag dus, wat moet een ISP doen om die impact te beperken. Zij hebben een zorgplicht, net zoals een huisbaas moet zorgen voor een goed dak in een huurhuis. Maar dat houdt ergens op: een hagelstorm met tennisbalformaat hagelstenen die onder een hoek van 45 graden binnenkomt en je kelderruitje eruit gooit, is overmacht. Je kunt dan geen vergoeding van je huisbaas eisen.

Verder speelt altijd de vraag tussen kosten en baten een belangrijke rol. Een dure maatregel tegen een uitzonderlijk probleem is niet billijk en hoeft niet te worden ingevoerd. Een goedkope maatregel tegen een routineprobleem moet er altijd zijn. En daartussen is het grijze gebied waar advocaten zich in thuisvoelen.

Ook speelt mee welke opvattingen er in de markt heersen: als iedereen vindt dat de klant dit moet doen, dan kun jij niet zomaar van de ISP eisen dat hij het oplost. Als de heersende mening is dat de ISP dit moet doen, dan kun je eisen dat jouw provider dat ook gaat doen.

Het is ontzettend moeilijk om iets te doen aan DDoS-aanvallen. Een tijd geleden las ik een uitgebreide review bij Tweakers over de technieken en mogelijkheden om het tegen te gaan. Maar fundamenteel is het nauwelijks op te lossen: er komt een berg verkeer binnen en dat moet je filteren.

Arnoud

Deel dit artikel

  1. Er valt veel voor te zeggen om DDoS-protectie in de netwerkinfrastructuur van de provider in te bouwen, in plaats van op elke individuele server. Maar het lijkt me niet vanzelfsprekend dat dit inbegrepen moet zijn in een colocatiedienst, als zulke functionaliteit niet expliciet door de provider werd geboden.

    Colocatie is de goedkoopste en minst omvattende hostingvorm van servers. Als je daarvoor kiest, moet je niet gek opkijken dat je met technische problemen wordt geconfronteerd die je zelf moet oplossen. Bij managed hosting (waarbij de hostingprovider verantwoordelijk is voor het beheer van de server en bepaalde software en services erop) komt DDoS-protectie al wat meer op het bordje van de provider te liggen, maar zelfs dan is dat volgens mij niet vanzelfsprekend.

  2. Leuk stuk. Toevallig vroeg ik mij vanmorgen af wie schade in de vorm van de door de ddos-aanval verbruikte bandbreedte dient te dragen. Is het redelijk dat de klant deze (volledig) conform de prijzen voor bandbreedte van de hoster dient te vergoeden, komt dit voor rekening van de hoster of iets hier tussenin. Het zal natuurlijk in belangrijke mate afhankelijk van de maatschappelijke (branche) opvattingen zijn. Of zal het in zo’n casus aankomen op “alle omstandigheden van het geval”?

  3. Ja, daar ben ik ook wel benieuwd naar eigenlijk. Veel zal ook afhangen van of de mogelijkheid besproken is en wat de hoster toen zij (“wij hebben een bulletproof systeem dat daartegen bestand is”). En misschien speelt de aard van de site ook mee? Een politie-extremistische site zal ze eerder aantrekken dan de spreekwoordelijke kantklosverenigingswebsite.

    Volgens mij is er nog geen brancheopvatting, maar dat weet jij misschien beter dan ik? 🙂

  4. Ha Arnout, leuk dat je er nog op terugkomt (of is dit een ander geval?). De situatie die ik beschreef was toch iets anders. N.l. een eigen server op locatie waar de DDOS aanvallen op de router werden afgevangen maar wel het verdere internetverkeer af en toe lam legde. Maakt voor de vraag over verplichtingen van de ISP weinig uit lijkt me. Een van mijn suggesties was dat ze een actieve rol zouden kunnen of moeten spelen in het zeer snel doorgeven van DDOSSende- IP adressen aan een centraal punt dat snel kan reageren.

    @3: Er is geen sitehosting en verder ook helemaal niets interessants op deze server. Puur “kijken of het kan”.

  5. Interessant, maar het blijft onduidelijk of een ISP wel of niet hiervoor verantwoordelijk is. Hangt van de afspraak tussen klant en ISP af, dus.

    Zit wel met een ander, vergelijkbaar vraagje. Stel, je hebt een kleine website op een shared host bij een bepaalde provider. Je deelt dus een server (en IP adres) met tientallen, mogelijk honderden andere sites. Je eigen website zit oerdegelijk in elkaar en werkt perfect. Maar op een dag blijkt deze geinfecteerd te zijn met een vervelend virus. Provider gewaarschuwd, site opgeschoond en het lijkt in orde. Maar binnen een paar uur weer opnieuw geinfecteerd. En opnieuw. En opnieuw. Site vervangen door een enkele dummy pagina en poef! Dummy pagina geinfecteerd! Wat bleek? Een andere site (meerdere zelfs) op dezelfde server bleek geinfecteerd en was ook eenvoudig te infecteren. Welke site dat betreft is lastig uit te zoeken maar via een andere site kan het virus de gehele server besmetten en doet dit dan ook. Wie is er dan uiteindelijk verantwoordelijk?

    (Overigens, ik heb toen gewoon mijn contract met die host be-eindigd en domein naar elders verhuist. Probleem opgelost, maar blijft altijd een probleem met shared hosts.)

  6. @Wim, Ik denk dat in het geval van shared hosting de aanbieder van de dienst een zorgplicht heeft om dit soort kruisbesmettingen te voorkomen en te bestrijden. Met een goede configuratie van de server kunnen een heleboel problemen voorkomen worden.

    Natuurlijk is het beter om de echte verantwoordelijke, de verspreider van het virus, aan te pakken; maar zie die eerst maar eens te vinden!

  7. Hoe zou een provider ueberhaupt het verschil moeten zien tussen een DDOS en een website waarop het gewoon erg druk is in geval van colocating of een unmanaged dedicated server?

    Inderaad: niet, het verschil is alleen duidelijk voor de klant. En dat geeft mijns inziens tevens een indicatie wie er verantwoordelijk is.

    Als de provider kosten maakt lijkt het me niet onredelijk om ook de klant te belasten. Wellicht kan er wat coulance worden toegepast door niet de volledige marge ook door te belasten.

    Een goede provider zou als service wel zaken op de firewall/router willen blokkeren op uurtje/factuurtje basis natuurlijk.

  8. @Richard. Je redenering gaat in ieder geval in mijn casus (zie 4) niet op daar er geen website op dat adres staat. Verder is het een koud kunstje om een afwijkend patroon te signaleren en instellingen te maken die door de klant beheerd kunnen worden. Ook in de simpeler routers kun je al thresholds instellen. Het punt is juist dat de klant door het niet tijdig afvangen van de DDOS zijn verbinding geblokkeerd ziet. Het instellen van de router van de klant helpt hier niets tegen. Het opvangen van de aanval moet bij de ISP.

  9. Je kunt het niet voorkomen, je kunt alleen de impact beperken.

    Daar ben ik het niet helemaal mee eens. Natuurlijk zijn er gevallen wanneer volstrekt onduidelijk is waarom een server doelwit van een DDoS attack is, maar in mijn ervaring is er vaak wel degelijk een reden aan te wijzen. Wat betekent dat zo’n aanval misschien best voorkomen had kunnen worden.

    Ik heb vaak meegemaakt dat een DDoS-aanval een reactie was op een server die (al dan niet bewust) aan het spammen of aan het relayen was of malware verspreidde, of op iemand die aan het trollen / etteren was op een of ander forum of chatkanaal.

    Volgens mij ligt een deel van de verantwoordelijkheid dus bij de klant. In ieder geval kun je om die reden de verantwoordelijkheid niet bij voorbaat volledig bij de provider leggen.

    De provider heeft overigens natuurlijk zelf een belang om DDoS-aanvallen af te weren; een enorme golf verkeer kan immers ook nadelige gevolgen hebben voor andere klanten of voor de provider zelf. Een slimme provider zal daarom wel het een en ander regelen. Maar dat betekent niet automatisch dat klanten aanspraak kunnen maken op een recht op bescherming tegen DDoS-aanvallen.

  10. @10 Victor, naast het feit dat ik niet zozeer op jouw casus reageerde is deze mijns inziens wel degelijk van toepassing op jouw casus. In geval van colocating of een dedicated server zorgt jouw hoster ervoor dat jouw server warm, droog, van stroom en van netwerk voorzien staat te draaien.

    Jij stelt dat mijn redenering niet van toepassing is “daar er geen website op dat adres staat”.

    Welke diensten jij op die server aanbiedt en of dat wel of geen actieve website is valt absoluut buiten de scope van jouw hoster in geval van colocation of dedicated server.

  11. @Richard. Precies, het enige waar hij voor hoeft te zorgen is een ongestoorde internetverbinding. En wat is daarin precies het verschil tussen een hardwarestoring en een DDOS aanval? Voor de klant niet goed waarneembaar zou ik zeggen. Ook bij hardware storingen zal een ISP niet altijd de kosten voor herstel op de derden/leveranciers die het onheil veroorzaken kunnen verhalen.

  12. Een klant kan niet het verschil tussen een hardwarestoring en een DDoS waarnemen? Wat zeg je nou? We hebben het over klanten die een eigen server beheren, die volledige rechten, fysieke en/of virtual console toegang, en (als het goed is) kennis van beheer hebben.

    Los van het al dan niet waarneembaar zijn (mijns inziens geen issue doch tevens volslagen irrelevant) zijn de verschillen evident.

    Bij colocating is de hardware niet eens van de iSP dus daar gaat die ook de verantwoordelijkheid niet voor nemen.

    Bij een hardwarestoring op een dedicated server is het enorme verschil met een DDoS dat de hardware ook feitelijk van de ISP is en een ISP part noch deel heeft in de DDoS, eerder medegedupeerd wordt door het feit dat de klant een DDoS ondervindt – immers zijn die vaak niet heel precies en/of zijn ook shared routers en switches de klos.

    Wanneer de DDOS voorbij is draait alles gewoon verder, bij een hardwarestoring niet. Een klant kan een hardwarestoring niet helpen maar een DDoS is toch meestal wel doelbewust. Moet ik echt verder gaan?

    Ik begrijp werkelijk niet hoe je kan vragen wat het verschil is, ik moet nog met een lampje naar de overeenkomsten zoeken.

  13. Een provider heeft niet de plicht om dit te filteren maar een goede provider heeft wel maatregelen in zijn netwerk om dit te detecteren en zo nodig te blokkeren. Het is niet alleen in belang van die ene klant die te maken heeft met de DDOS aanval dat hij zijn website weer online krijgt maar ook in belang van andere klanten die in het zelfde segment zitten. Hoe eerder in een keten de DDOS aanval wordt tegen gehouden des te minder last je er van onder vindt.

  14. Er zijn verschillende manieren om een DDoS te ‘killen’, vraag is alleen of je de klant ‘bereikbaar wilt laten zijn’ (vaak de corp klanten die voor een RadWare/RioRey/Arbor betalen), ofdat je een colo/dedi klant niet verder op kosten wilt jagen en deze dan maar ‘offline haalt’.

    In het eerste geval hangt er een prijskaartje aan het technische verhaal, in het tweede geval kun je dmv een ‘remote triggered blackhole’ het IPje van de klant buiten je core al blocken. Qua traffic is het dan geen probleem meer, IPje is alleen niet meer bereikbaar. De ervaring is toch wel dat de keuze tussen een forse rekening en offline zijn door de door Niels genoemde ‘ettertjes’ vaak sterk neigt naar ‘2’. En ja en meestal weet men ook wel waarom er een DDoS heeft plaats gevonden …

  15. DDoS aanvallen worden vooral gedaan op UDP poorten.

    Mijn server is voor de zoveelste keer het doelwit geworden van een zware DDoS, en mijn provider is gewoon traag met reageren (dedicated machine). Het probleem bij veel providers is dat zij geen UDP kunnen filteren compleet, want normaal gesproken gebruiken de services (behalve DNS hosting) alleen TCP connectiviteit. Maar schijnbaar is het onmogelijk bij veel providers om UDP compleet te blokkeren, deze vertikken het om een simpele maatregel toe te passen, en ik vraag me af, als mijn contract opgezegd gaat worden door een DDoS, is dit dan een schending van het contract die ik getekend heb en dat ik maar een gedeelte van de server hoef te betalen, omdat mijn provider niet meer de service kan bieden waarvoor ik betaal ?

    Graag even wat meer info wil ik hierover weten, want het DDoS’en begint me de keel uit te hangen, en ik zit te denken om een 100mbit unmetered machine te nemen zonder datalimieten.

    Kan iemand mij misschien wat tips geven ?

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