Wie draagt de kosten van gebruikte bandbreedte bij een DDoS-aanval?

Ik denk dat het antwoord ook afhankelijk is van hoe de hosting in elkaar zit.
Gebruik je een website op een shared hosting platform en is de aanval gericht op dat specifieke adres of heb je een eigen IP adres en is het gericht op dat adres alleen of op dat adres en ook andere adressen bij de hoster? Er zijn verschillende combinaties mogelijk. De vraag is dus eigenlijk: waar is de aanval op? Op de hoster (range van IP adressen) of op een specifiek doel (1 IP adres).

Het zal altijd wel middelen blijven tussen de twee partijen, want het verkeer word door de hoster slechts doorgezet. Indien er een (D)DoS aanval plaats vind zal dit verkeer door de klant aangetrokken zijn.

Een grote rol in dit verhaal speelt de reactietijd van de hoster. Indien de hoster niet de netwerkbeheerder is zal deze meer tijd kwijt zijn om het verkeer te laten null-routen, en dit kan in sommige situaties erg lang duren terwijl de teller blijft lopen.

In dit geval is het een kwestie van upstream provider, hoster en klant die op in overleg een verdeling zullen moeten afspreken.

In het geval dat de hoster ook het netwerk beheert zal deze vanzelfsprekend actie moeten ondernemen.

Ja, de klant heeft rechten, maar is wel verantwoordelijk voor het aangetrokken verkeer. Ja, de host wil daar niet de kosten voor dragen, maar moet indien er niet snel gehandeld kan worden toch ook de verantwoordelijkheid dragen. En ook de upstream provider kan aangekeken worden, door het dan wel/niet ontbreken van firewall en IDS.

Deze partijen kunnen zonder al te veel moeite een API of controlpanel creeren waarbij een hoster (als klant zijnde) zelf snel een IP kan null-routen om verdere kosten te voorkomen. (tip :)

Het allerlaatse probleem wat ik in de praktijk terug heb gezien is de vraag wie de verantwoordelijke is om een daadwerkelijke beslissing te maken. Immers een langdurige DDoS aanval of null-route gaat extra kosten met zich mee brengen door bijvoorbeeld migratie naar andere IP adressen. Als dit tegen de wensen van de klant in gaat kan daar nog een behoorlijke (juridische) discussie over ontstaan, maar de klant zal niet altijd reageren (snachts bijvoorbeeld). Laat je als host de teller lopen met alle risicos van dien?

Daarnaast kan je ook de vraag stellen "wat wil je als klant ?". Een flink aantal internationale transit partijen bieden de mogelijkheid om een IP adres dat wordt aangevallen te nullrouten.

Met een nullroute voorkomt de NL hoster dat het verkeer z'n netwerk binnenkomt via die upstream en krijgt hij daarna ook geen rekening gepresenteerd. Tegelijkertijd heeft de aanvaller z'n doel daarmee bereikt, want het IP adres is onbereikbaar en daardoor is er sprake van een 'denial of service'.

Voor de spreekwoordelijke lokale kantklosgroep is het mogelijk acceptabel dat hun site er tijdelijk uitligt, echter voor een E-commerce omgeving waar substantiele handel doorheen loopt, of een grote site die voor z'n inkomsten afhankelijk is van advertising, is een nullroute over het algemeen geen oplossing.

Als klant zou je dan misschien wel liever zien dat de provider het attack verkeer wel z'n netwerk in laat komen, maar daarna intelligente detectie en mitigatie gebruikt om te zorgen dat (de bulk van) het valide verkeer, nog wel op de E-Commerce omgeving terechtkomt.

Klanten die dit soort wensen hebben, zouden bereid kunnen en moeten zijn om een premium tarief te betalen, voor "clean-traffic". Ik kan me voorstellen dat de extra kosten die de hoster daarvoor moet maken, worden uitgesmeerd in een permanent iets hoger tarief.

Goede argumenten, het is inderdaad zo null-routing alleen de aanval stopt maar niet het probleem.
Er zijn wel oplossingen hiervoor. Zo maakt Tweakers gebruik van RioRey, het netwerk blijft beschikbaar voor legitiem dataverkeer en de aanval wordt geblokkeerd. Maar... het dataverkeer blijft wel binnenstromen, dus wat dan?

@Sebastiaan, voor iedere hoster zal de rekensom er anders uitzien. Veel hosters (met content in hun netwerk dus) zien vooral verkeer hun netwerk verlaten, terwijl het reguliere verkeer *naar* hun netwerk marginaal is. Dat inkomende verkeer bestaat vooral uit valide HTTP-GET requests en TCP-acks. Dat inbound verkeer is soms maar 10% van het verkeer in de uitgaande richting.

De meest gebruikte afrekenmethode bij wholesale IP Transit is de 95e percentiel methode. Daarbij worden op basis van metingen van het gemiddeld bandbreedtegebruik per 5 minuten, de max(in,out) uitgedrukt in Mbps uitgesorteerd over een periode van een maand en worden de bovenste 5% van de metingen weggegooid. De hoogste waarde die je dan overhoudt is het aantal Mbps dat wordt vermenigvuldigd met je prijs per Mbps.

Bij gebruik van de 95% afrekenmethode met een/de IP Transit provider(s) van een een hoster met 2Gbps aan outbound verkeer en 10% daarvan, dus 200Mbps, aan inbound verkeer geldt, dat de hoster pas een rekening krijgt van z'n leverancier, als het aanvalsverkeer naar dat netwerk *meer* dan 1,8Gbps bedraagt. Voor Nederlandse begrippen is dat best een forse attack, alhoewel ik ze ook 5 tot 10 maal zo groot heb gezien.

Voor partijen waar de in/out traffic mix anders is, kan de rekensom anders zijn.

Partijen die per GB of TB betalen zullen wel altijd de "pineut" zijn als ze moeten betalen voor attack verkeer, want in deze methode wordt er geen rekening gehouden met het afvlakken van pieken in het dataverkeer. Als dit hosters zijn, dan zijn dat vaak kleinere partijen, die zelf geen BGP hebben geimplementeerd en die mee-liften binnen het AS nummer van een grotere Nederlandse hoster.

Daarbovenop dien je ook nog rekening te houden met de aanschafprijs/afschrijving van detection en mitigation appararatuur, de onderhoudscontracten daarop. De apparatuur komt ook nog eens in verschillende capaciteiten. Als je een te kleine mitigation appliance koopt, loop je het risico dat deze teveel verkeer voor z'n kiezen krijgt en er dus ook valide dataverkeer wordt weggegooid.

Verder is de maximale capaciteit van de verschillende upstream links van een provider ook nog een punt van zorg. Als de grootte van de aanval de afmetingen van de links overstijgt, dan kan je alleen nog maar kiezen om verder upstream gaan mitigaten / nullrouten, of om de capaciteit van je links op te waarderen.