Amsterdamse Cloudflare-servers kampen met grootschalige ddos-aanvallen

De Amsterdamse servers van het content delivery network Cloudflare hebben voor de vijfde keer in korte tijd te maken gehad met grootschalige ddos-aanvallen. Door de aanvallen waren sites die gebruik maken van Cloudflare-servers tijdelijk niet bereikbaar.

Logo CloudflareDe meest recente aanval vond dinsdagochtend rond een uur of half 10 's ochtends plaats. Naast klanten die gebruik maken van de Amsterdamse servers van Cloudflare, werden bij deze aanval ook een aantal Londense servers getroffen. Na iets minder dan twee uur zou de aanval volgens Cloudflare over zijn, alleen blijkt de Amsterdamse server van Cloudflare op het moment van schrijven alleen sporadisch bereikbaar. Hoewel er niet bekend is op welke manier de aanval tegen Cloudflare werd uitgevoerd, is het aannemelijk dat er ntp amplification is gebruikt. Daarbij kan een aanvaller zijn aanvalskracht ruim tweehonderd keer vergroten.

Matthew Prince, ceo van Cloudflare, laat in een verklaring tegenover Ispam weten dat dataverkeer van betalende Cloudflare-klanten tijdens een aanval afgelopen zondag via Cloudflares datacentrums in Londen Parijs en Frankfurt werd geleid. Dit zodat het effect van de aanvallen voor betalende klanten zo gering mogelijk zou blijven. Zodra de ernst van de aanval afnam, werden alle diensten van betalende klanten weer via de Amsterdamse servers geleid.

In februari dit jaar werden bij één van de grootste ddos-aanvallen ooit ook al Nederlandse Cloudflare-servers getroffen. Door een kwetsbaarheid in het ntp-protocol kunnen servers die dit protocol draaien door een aanvaller worden gebruikt om zijn eigen capaciteit te vergroten.

Door Taco Blauw

Stagiair

01-07-2014 • 13:25

34 Linkedin

Submitter: Nic

Reacties (34)

34
33
25
2
1
7
Wijzig sortering
Cloudflares infrastructuur kennende zegt die een aantal dingen.
Om te beginnen haalt cloudflare zo ver ik weet meestal niet zelf een server uit de roulatie.
Cloudflare doet namelijk aan wat zij noemen 'Load Balancing without load balancers' en dat houd simpel weg in dat door middel van anycast het pakketje wordt geleid naar het dichtstbijzijnde datacenter wat antwoord geeft. Gaat het datacenter down of is deze overbelast wordt alles vanzelf omgeleid naar een datacenter in de buurt. In tegenstelling van wat tweakers doet vermoeden maakt cloudflare dus geen onderscheid tussen hun klanten.

Doordat cloudflare de zelfde ip adressen gebruikt voor zijn verschillende datacentra is het dus aannemelijk dat de aanval heeft plaats gevonden via vooral nederlandse NTP servers of dat de aanvallers een truuk hebben bedacht om anycast te omzeilen.

Ik kan persoonlijk niet wachten op het volgende blog artiekel als het inderdaad weer om een bijzonder grote DDoS aanval gaat.

Voor de geïnteresseerde zijn hier een paar van hun vorige. Het geeft direct een goed beeld hoe er met een aanval wordt omgegaan.

400Gbit DDoS waarschijnlijk derptrolling destijds : http://blog.cloudflare.co...amplification-ddos-attack
Meer over de dergelijke NTP attacks : http://blog.cloudflare.co...ng-ntp-based-ddos-attacks

En natuurlijk het tijdperk voor de NTP attack , de DNS attack.
Spamhaus deel 1 : http://blog.cloudflare.co...d-spamhaus-offline-and-ho
Spamhaus deel 2 : http://blog.cloudflare.co...almost-broke-the-internet

Veel lees plezier!
Ik heb alleen maar slechte ervaringen met Cloudflare. Mijn site werd er niet sneller op, terwijl ze dat wel beloven. In tegenstelling zelfs, heel vaak was mijn site niet te bereiken.
Ik heb dezelfde ervaring. Vooral de Amsterdam locatie had ik vaak pings van 400 - 500 ms en werd mijn site botertraag. De DDoS aanvallen worden steeds groter en het lijkt zelfs dat Cloudflare steeds meer moeite heeft om ze te pareren of er zelfs helemaal niet meer in slaagt. Ze zijn natuurlijk ook wel het ultieme doelwit geworden omdat veel sites tegenwoordig over Cloudflare lopen.

Ik heb een tijd geleden al mijn systemen gemoved naar OVH en heb Cloudflare opgezegd. Ik had ook veel last van DDoS aanvallen en vooralsnog weet OVH ze allemaal redelijk eenvoudig af te slaan zonder downtime van mijn services.
Gelukkig nullroute OVH meteen je servers zodra je te lang het slachtoffer van een DDOS bent, wat natuurlijk een stuk beter is /sarcasm

CloudFlare's netwerk is zo opgebouwd dat bij een DDOS op 1 datacenter deze meteen uit de roulatie wordt gehaald en wordt overgenomen door andere DC"s in de buurt. Hiedoor merken normale gebruikers niks van de downtime.

Juist omdat het CloudFlare netwerk zo goed is zijn de aanvallers zich gaan richten op de infrastructuur die CloudFlare gebruikt. Metname LIX was erg slecht geconfigureerd wat er voor zorgde dat aanvallers deze gemakkelijk plat konden krijgen.

Verder host cloudflare geen NTP servers en gaat het hier ook helemaal niet over het NTP protocol. (Wie wil er nou weer DDOS prototected tijd servers :S) maar het gaat over NTP amplification

@Tweakers, Cloudflare maakt geen onderscheid tussen gratis en betaalde klanten qua dc routing.

@hieronder, ik bedoelde als het voor betaalde klanten werkt dan werkt het ook voor de gratis klanten

[Reactie gewijzigd door GrooV op 1 juli 2014 14:47]

Dat was vroeger nu niet meer, OVH nullroute nooit meer. Hun nieuwe Anti-DDoS systeem is nog niet zo heel lang geleden live gegaan. Je loopt dus achter :)

Hier meer info:

http://forum.ovh.co.uk/sh...TANT-Anti-DDoS-Protection

Zie ook dit topic op hackforum, waar men klaagt dat OVH niet meer plat is te krijgen (login nodig):

http://www.hackforums.net/showthread.php?tid=3641627

En Cloudflare is leuk, maar het werkt alleen voor http(s) verkeer, zodra je game servers host ofzo heb je er niks meer aan en laten die nou juist vaak doelwit zijn van ddos aanvallen.

[Reactie gewijzigd door mkools24 op 1 juli 2014 13:47]

Ja leuk, die OVH VAC kan max 480Gbps tegenhouden. Smijt er 481Gbps tegenaan en OVH knikkert je vrolijk uit het netwerk want alles ligt plat. Ik heb nog van verschillende mensen gehoord dat ze dit jaar nog een server kwijt zijn geraakt bij OVH. Daarnaast ben je appels met peren aan het vergelijken, je vergelijkt een http caching proxy met game servers 8)7

Enige fatsoenlijke DDOS beveiliging is afspraken maken met je upstream providers welke het verkeer voor je blokkeren, zorg voor genoeg grote tier1-2 providers en je hebt genoeg bandbreedte ter beschikking om alles aan te kunnen.
Oh ja 480 is niet genoeg lol. De zwaarste aanval ooit gemeten is geloof ik 400 gbps.
Jou server is natuurlijk het enige verkeer dat OVH krijgt ... 8)7
Nope maar de gemiddelde grootte van een ddos aanval is geloof ik 3 gbps. Blijkbaar is die 480 genoeg anders lagen ze er constant uit, is het niet genoeg dan schalen ze gewoon bij, simpel.
Cloudflare garandeerd betalende klanten met het business plan ($200 de maand) 100% uptime. Middels rerouting als hun eigen servers problemen hebben, en middels een mirror als je eigen server issues heeft. Betalende klanten zijn ook beschermd tegen level3/4 attacks.
De dienstverlening verschilt wel degelijk. Zie de pricing plans
Anoniem: 524877
@frickY1 juli 2014 14:41
Klopt en ze hebben een keer al klanten geld terug gegeven omdat ze zich niet aan de 100% hebben kunnen houden door een storing

nieuws: CloudFlare raakt offline door storing op edge-servers

[Reactie gewijzigd door Anoniem: 524877 op 1 juli 2014 14:41]

CloudFlare's netwerk is zo opgebouwd dat bij een DDOS op 1 datacenter deze meteen uit de roulatie wordt gehaald en wordt overgenomen door andere DC"s in de buurt. Hiedoor merken normale gebruikers niks van de downtime.
Dit is overgens ook onjuist. Cloudflare maakt gebruik van Anycast, dus meerdere machines kunnen hetzelfde IP delen, hierdoor wordt de aanval verdeeld over alle datacenters wereldwijd, maar dit is alleen indien de Cloudflare IP adressen worden aangevallen.

Wat de aanvallers tegenwoordig doen net als bij de Spamhaus attack is de voorlaatste hop pakken, dus nog voor het Cloudlfare IP adres, waarmee ze dus hun aanval richten op het datacenter waar anycast ze op dat moment heen stuurt.

http://blog.cloudflare.co...almost-broke-the-internet
@Groov
het gaat hier over DDoS mitigation Attacks:
http://en.wikipedia.org/wiki/DDoS_mitigation
Ik heb een paar weken terug ook al mijn sites van cloudflare afgehaald. Als je elke maand down bent omdat hun weer problemen hebben schiet het ook niet echt op. Ik was er in ieder geval klaar mee. Je kan beter gewoon ervoor zorgen dat je een hoster hebt die goede peering contracten heeft en het liefst wereldwijd zijn eigen datacenters. Ben je een stuk beter af dan met dit Cloudflare gedoe.
Hoewel ik het wel met je eens bent, is het massaal verlaten van Cloudflare natuurlijk een verkeerd bericht richting de schoffies die die ddos'en uitvoeren. Cloudflare kan er niks aan doen dat ze continu onder vuur liggen en zijn slachtoffer.
Dat hebben ze wel degelijk aan zichzelf te wijten.
Zeker voor het vele geld wat de service kost, is klagen terecht

Cloudflare heeft geen bestaansrecht als die 'schoffies' zoals jij ze noemt niet zouden ddossen. Soort kip -ei verhaal.
Dat klopt, maar als je cloudflare hebt genomen om hoge snelheid en uptime te krijgen voor je services dan is het logisch dat je gaat denken aan overstappen als ze dat niet waar kunnen maken.

Of het nou hun eigen schuld is of die van anderen (zoals in dit geval), je huurt ze in met 1 doel. Als de dat niet kunnen waarmaken, dan moet je verder gaan kijken
Cloudflare kan er niks aan doen dat ze continu onder vuur liggen en zijn slachtoffer.
Het bedrijfsmodel van Cloudflare is juist bescherming bieden tegen dit soort aanvallen. Zonder aanvallen hadden ze ook geen klanten. Dat ze worden aangevallen is uiteraard niet hun schuld, maar dat ze er niet mee om kunnen gaan wel, dat beloven ze immers.

Net zoals je een brandkast niet kan verwijten dat het huis in brand vliegt, maar als dat gebeurt moeten de spullen in de brandkast wel veilig zijn, daar koop je zo'n ding voor.

Of, zoals wij laatst te horen kregen: "Maar meneer, de stroom is uitgevallen, daar kunnen de batterijen niet tegen."
True Cloudflare is ook slachtoffer. Echter heb ik te maken met commerciële websites die gewoon online moeten zijn. Ik kan helaas geen slachtoffer hulp spelen en maar bij Cloudflare blijven omdat het zo zielig voor hun is. Ik moet geld verdienen en dat maakte Cloudflare mij niet makkelijker. De keuze is voor mij dan ook snel gemaakt, ondanks dat het lullig voor hun is.

Overigens zijn ze ook niet helemaal zielig want ze pretenderen zelf op hun website bestand te zijn tegen DDos aanvallen. Dan lok je het natuurlijk ook wel een beetje uit en is het niet zo gek als klanten weglopen wanneer dit niet zo blijkt te zijn. Ook kwa transparantie zijn ze niet helemaal eerlijk. Ze zijn veel vaker down dan op hun website wordt aangegeven. Vooral de korte down times willen ze nog gauw doen alsof er niets aan het handje is.

[Reactie gewijzigd door ro8in op 1 juli 2014 14:40]

Is het dan niet handiger om verschillende cloud dns providers te gebruiken?

Zo iets als: dns1:ovh
dns2:cloudflare
dns3:...
meerdere DNS servers opgeven is voor redundancy voor het DNS gedeelte van een verbindings opbouw.

redundancy middels DNS om DDOS'en te omzeilen werkt niet echt. Vaak zijn DNS omzettingen gecached op welke router dan ook (browser DNS cache,je thuis routers DNS, je ISPs DNS, etc) en krijg je vrolijk een ip terug die misschien onder DDOS ligt.

[Reactie gewijzigd door DLGandalf op 1 juli 2014 15:31]

Toch moet je het mij even uitleggen.
Jij bent bij cloudflare weggegaan omdat regelmatig een datacenter er uit licht.
Een ander datacenter bijvoorbeeld london neemt de verbinding dan automatisch over en de ddos aanval wordt op die manier toch echt afgeweerd.

Het verschil met jou server los en via cloudflare is dan ook dat als ze jouw site proberen aan te vallen ze nu te maken hebben met datacenters vanuit de hele wereld en dat voor jou klanten als cloudflare dus wordt aangevallen de website aanvoelt alsof deze in Engeland is gehost of in het ergste geval misschien amerika (Een verschil dat voor mij persoonlijk weinig uit maakt amerikaanse sites zijn snel genoeg) in plaats van een rechtstreekse aanval op jouw server die de bezoekers van je site zal weerhouden. Natuurlijk heb je wel altijd het nadeel dat als een andere grote website wordt aangevallen ook jou site hier last van heeft.

Ik ben dus erg benieuwd waarom je deze keuze hebt gemaakt en waar jij de downtime op hebt gebaseerd want in de enkele gevallen dat mijn website onbereikbaar was door een cloudflare storing was dit vaak al opgelost voor ik op F5 kon drukken.

[Reactie gewijzigd door henk717 op 1 juli 2014 17:05]

Helaas is het niet waar dat een ander datacenter het over neemt. Mijn sites waren vaak gewoon onbereikbaar doordat Cloudflare er weer uit lag. Als de situatie zo was zoals jij het schetst was het geen enkel probleem. Echter in de praktijk loopt het vaak niet zo. Wellicht dat hun bij een aanval na een aantal uur de routing weten om te gooien waardoor je weer bereikbaar wordt, maar dat is voor mij al te lang. Ik wil simpelweg geen downtime en met cloudflare gebeurde dat vaker dan mij lief is. Dat bij downtime hun weer up zijn voor je F5 kon drukken die ervaring deel ik totaal niet. Tenzij jij 2 uur erover doet om F5 in te drukken xD Vandaar mijn keuze..

[Reactie gewijzigd door ro8in op 1 juli 2014 18:13]

Hier een betalende klant (business plan) en was deze ochtend wederom zeer slecht bereikbaar tot offline. Net als op 19 juni, en 16 juni ook al. Die 100% uptime garantie bij het businessplan kun je dus vergeten.

Ik snap niet waarom ze verkeer niet sneller kunnen rerouten. Deze ochtend heeft het bijna een uur geduurd. Op mijn vraag waarom dit zo lang duurt kreeg ik de volgende vrij inhoudloze reactie;
I understand your frustration here, we've been working on mitigating an attack in Amsterdam this morning which also spilled over into our London location also. Right now performance in Amsterdam has recovered. If you're still seeing issues can you provide any information.

Once we have fully mitigated we'll share an incident report with you and follow up further on this - right now we're still working on the issue at hand.
De eerste paar maanden was ik echt ruimschoots tevreden, ook met de gewonnen performance. Maar de afgelopen 2 maanden is het steeds vaker drama.
Van een probleem afgelopen zondag heb ik daar in tegen weer niets gemerkt.

[Reactie gewijzigd door frickY op 1 juli 2014 13:43]

Hebben ze geen uptime garantie dan?
[quote]CloudFlare Business
• All Pro features, plus full customization
• Advanced denial of service attack mitigation
• Railgun™ web optimization
100% uptime guarantee

Jawel. En toch waren we offline,
Zo een reclameleus helpt blijkbaar niet tegen een grote aanval.

[Reactie gewijzigd door frickY op 1 juli 2014 13:53]

Alles gaat een keer stuk, dat is nu eenmaal de realiteit. Maar als ze garantie bieden dan heb je nu recht op een vergoeding.
Als je je als schild opstelt kun je dit natuurlijk verwachten.
Ik vind het met name zeer kwalijk dat zoveel partijen hun NTP servers nog steeds open hebben staan voor misbruik in de vorm van amplification attacks. Voor hosters, check je eigen netwerk(en) op http://openntpproject.org/ en fix die shit.
Ahh daarom was geenstijl zo aan het kloten met een werkende site...
Dat cloudflare is leuk maar handig? Nope. Hun netwerk is dus niet voorbereid op dit soort aanvallen..
Ook door (steeds meer) fragmentatie in een IPv4 subnet, zitten meerder klanten in een subnet en bij een attack wordt een geheel subnet ge-null routed of door een ddos device gestuurd.

Als je in een subnet zit met een andere klant die DDOS gevoelig(er) is zoals een politiek blog of site dan kun je hier ook slachtoffer van worden.

Onderscheid (routering) op basis van BGP en klant IP is erg moeilijk (wil bijna niet mogelijk zeggen) en zal steeds moeilijker worden.

Zou IPv6 hier een oplossing voor bieden (niet suggestief!) omdat je hiermee al je klanten een /48 zou moeten geven en op basis hiervan de betreffende site/klant kun her-routeren.
Het is niet een subnet ansich die overbelast raakt, maar de apparatuur waar dat verkeer door heen moet. Met IPv6 heb je dat evengoed.
Matthew Prince heeft jaartje geleden een presentatie gegeven over DDoS en hoe cloudflare er mee omgaat op defcon 21. http://www.youtube.com/watch?v=q2FxTgd3uTE

Dit zullen weer een paar drukke dagen worden/geweest zijn voor hem.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee