Akamai stopt hosting bekend beveiligingsblog na grootschalige ddos-aanval

Akamai heeft de website KrebsOnSecurity offline gehaald doordat de site werd getroffen door een herhaaldelijke ddos die bijna dubbel zo groot was als wat Akamai in zijn bestaan ooit heeft meegemaakt. De site behoort toe aan beveiligingsexpert Brian Krebs.

Dat schrijft Business Insider naar aanleiding van een tweet van Krebs van vrijdag met de tekst: "Akamai's kicking me off their network tonight", ofwel 'Akamai gooit me vanavond van zijn netwerk af'. Krebs voegt daar wel snel aan toe dat hij de webhosting gratis van Akamai/Prolexic kreeg en hij het besluit goed begrijpt, al was het maar omdat het 'hun een heleboel geld per dag moet kosten om de ddos af te slaan'.

Op het hoogtepunt van de aanval kreeg Krebs' site meer dan 620Gbit/s aan data te verwerken, bijna het dubbele van de daarvoor grootste aanval die Akamai ooit te verwerken kreeg. Dat ging toen om 363Gbit/s schrijft Krebs op zijn site, waar een kopie van te vinden is op Archive.org.

Er lijkt echter wel een verschil te zijn tussen de 363Gbit/s-aanval en die van gemiddeld 620Gbit/s op Krebs' site, namelijk het type botnet. Die eerste zou zijn gegenereerd door een vrij standaard botnet waarbij verkeerd geconfigureerde dns-servers worden gebruikt om de aanval te versterken. De aanval op Krebs' site lijkt echter direct van een zeer groot botnet van gehackte apparaten te komen. Het verschil met een amplified of versterkte ddos en de aanval op Krebs' site is dat de opgezette verbindingen naar de site toe methodes gebruiken die een echte verbinding tussen de aanvallende host en het doel vereisen, zoals syn, get en post.

Martin McKeay van Akamai heeft aan Krebs uitgelegd dat het om een zeer ongebruikelijke manier van aanvallen gaat en dat dit soort aanvallen pas recentelijk opduikt. Het volume dat de site van Krebs te verduren kreeg was volgens McKeay zeer nieuw.

Het gebruikte verkeer was zo gegenereerd dat het leek op generic routing encapsulation of gre. McKeay legt verder op Krebs site uit dat gre-verkeer niet op dezelfde manier gespoofd of gefingeerd kan worden zoals bij een aanval via dns reflection. Het leek volgens McKeay alsof de aanval van systemen uit de hele wereld kwam. Ook zijn er indicaties dat het botnet gebruikmaakte van gehackte internet-of-things-apparaten, zoals routers en ip-camera's. Beveiligingsbedrijf Symantec waarschuwde deze week voor een stijgend aantal ddos-aanvallen met behulp van dit soort apparaten.

Het vermoeden is dat dit soort monster-aanvallen de 'nieuwe norm' gaan worden, schrijft Krebs aan het eind van zijn blogpost. Verder vermoedt hij dat de aanvallen te maken hebben met een recente serie verhalen over een inhuur-ddos-dienst vDOS waarbij de Israëlische politie twee mannen arresteerde die in het initiële rapport van Krebs als oprichters van de dienst genoemd werden. De ceo van Cloudflare heeft inmiddels zijn hulp aan Krebs aangeboden.

Foto: Twitter

Reacties (116)

[totaalgeenhard]

Jammer dat Akamai geen vuist heeft gemaakt.

Het opofferen van een gebruiker is het laatste wat je zou willen doen.
Aangezien Akamai één van de grootste CDN is, zou het beter geweest als ze tegen aanval hadden gedaan. Terug tracen en host van het internet laten wegnemen.

Zodat elke volgende idioot weet dat hij zijn botnet gaat opofferen als ze bepaalde infrastructuur aanvallen.

Akamai zou als ze een derde partij benaderen niet zomaar gepareerd / genegeerd worden.
Als kleine partij een abuse gaat sturen, zien beheerders/security team aan email al dat het weinig zin heeft om achteraf te onderzoeken, bovendien kost het tijd en energie.

Begin van het jaar had ik zelf met een amplified DNS attack te maken. Was maar een paar Gb/s.

Nadat ik NETFLOW had ontvangen maakte ik een script die automatisch PER IP abuse verstuurde.

Tot mijn verbazing (al een tijdje niet hoeven te doen) bleken juist Rusland, Braziliaanse ISP's als eerste te reageren. Vroeger was het zo dat juist Oost-Europa/Azië en Zuid-Amerika gewoon zinloos om abuse te mailen.

Ook was het heel opvallend om te zien dat WHOIS gegevens van CIDR IP blocks niet volledig waren, email niet werkte of geen telefoon nummer etc..

Men zou een RFC moeten komen voor abuse meldingen op IP niveau die wel geheel standaard geautomatiseerd is.

Om lang verhaal kort te maken na een weekend te hebben geklaagd over ruim 100.000 IP's van nameservers met instructies hoe ze zonetransfers kunnen blokkeren, was 90% van verkeer weg.

Aangezien het veel tijd en energie kost om een botnet op te bouwen zal aanvaller niet gelukkig zijn met deze actie.

Maar als alle partijen gaan backtracen en er bovenop gaan zitten zullen daders veel selectiever te werk gaan.

Helemaal traceren naar dader is heel lastig, meerdere ISP's in meerdere landen moeten samenwerken terwijl aanval realtime gaande is. Gezien verschillende tijd zones, is het lastig om iemand 's nachts aan de andere kant van de wereld aan de lijn te krijgen en hem te verzoeken te backtracen.

Maar indien er ooit een oplossing komt die realtime backtracen mogelijk maakt zal probleem grotendeels verdwenen zijn en binnen redelijke tijd kunnen worden opgelost.

Anonimiteit van de daders bestaat alleen dankzij het feit dat ISP's niet samenwerken en niet bereikbaar zijn.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 22:46]

[GrooV]

Akamai verzorgde een gratis proxy voor Krebs. Als daar je betaalde klanten onder gaan leiden is het leuk maar dan moet je in overleg met Krebs er mee stoppen. Akamai is een CDN, geen DDOS mitigator. Daar heb je diensten zoals Cloudflare of Incapsula voor.

Het nullrouten van IP adressen die onder vuur liggen gebeurt bij bijna alle providers, of je nu betaald of niet. Sinds het gebruik van Amplification attacks zijn DDos aanvallen zeer sterk en krachtig geworden, deze worden nu ook minder uitgevoerd door huis tuin en keuken machine's maar door DNS of NTP servers die worden overladen door aanvragen met spoofed IP's. Deze aanvallen kunnen weken aanhouden (zie protonmail attack) waardoor er serieuze netwerk problemen kunnen ontstaan.

Het aanpakken en traceren van de daders is niet te doen, dat kost te veel uren en geld. De enige manier om dit echt te stoppen is dat alle providers gebruik gaan maken van Ingress filteren of BCP38 (zie https://en.wikipedia.org/wiki/Ingress_filtering)

Overigens zijn er de laastste dagen erg veel aanvallen, zo heeft OVH 1.1Tb/s verwerkt, https://twitter.com/olesovhcom/status/778019962036314112

[Reactie gewijzigd door GrooV op 23 juli 2024 22:46]

[totaalgeenhard]

Akamai bestaat al heel lang en een reden om Akamai diensten te gebruiken was naast (destijds) kosten besparing ook het technische geneuzel zoals DDoS en security uit te besteden.

Dit deden ze al toen Cloudflare nog niet bestond.

Verder is Cloudflare gewoon een concurrent van Akamai, hun corebusiness is gewoon CDN.

Wat ik me altijd al afgevraagd heb waarom Cloudflare qua DDoS (waar ze erg mee te koop lopen) nooit echt getest zijn. 600Gb/s is voor cloudflare ook niet zonder meer te behappen.

[GrooV]

Cloudflare maakt gebruik van AnyCast routing, hierdoor kom je altijd uit bij een server die bij jou in de buurt staat.

Als er dus een wereldwijde DDOS aanval wordt gelanceerd op Cloudflare dan wordt de load automatisch verspreid over lokale servers

Zie, https://blog.cloudflare.com/a-brief-anycast-primer/

Inmiddels hebben ze 86 PoP's waardoor ze de load goed aankunnen.

De snelste routers kunnen tegenwoordig maximaal 100Gbps aan, dus als je een aanval niet wereldwijd kan spreiden kom je altijd wel in de problemen

Verder is Akamai meer een traditioneel CDN, welke ook data heeft. Cloudflare heeft geen data maar is alleen een reverse caching proxy

[Reactie gewijzigd door GrooV op 23 juli 2024 22:46]

[totaalgeenhard]

Ze hebben gebruikt gemaakt van GRE dus anycast was in dit geval te omzeilen. (ik weet niet de details)

We hebben 6 werelddelen waar (veel) mensen wonen dus als er uit elk 100Gb/s komt en via anycast lokaal terecht komt verzocht dat nog steeds voor overlast, in beste geval hogere latency. Maar in een werelddeel als Afrika loopt het verkeer gewoon vast.

Met betrekking Pop's van Cloudflare:

Akamai has the most pervasive content delivery network (CDN) - more than 216,000 servers in over 120 countries and within more than 1,500 networks around the world.

bron: https://www.akamai.com/us/en/about/facts-figures.jsp

Even uitgaande dat elke land maar 1 pop heeft (in Nederland weet ik dat het er al meer zijn) heb je het al over 120 pop's.

Het aantal netwerken is interessanter omdat vanaf die 1500 netwerken het aanval vandaan kwam/zal komen. Nu weet ik niet of ze met elk van die 1500 een peering agreement heeft of dat er ook netwerken tussen zitten die via een open peer exchange point gaan. Maar in je peering agreement kan je wel bedingen dat ze bij abuse verkeer snel reageren.

[GrooV]

Met GRE kan je AnyCast niet omzeilen, AnyCast is onderdeel van BGP, wat op layer 3 draait. GRE draait daar net weer boven, een soort van layer 3+

[totaalgeenhard]

Ligt eraan waar het is ingepakt en waar het zal worden uitgepakt.

[rjmno1]

Akamai staat bekend van de snellere downloads een van de snelste ter wereld.
Je kon deze server ook toevoegen aan de download aplicatie.
Maar wat het nut van deze ddos aanval ook is de redenen waarom ze dat doen is allemaal niet nutig imo.

https://en.wikipedia.org/wiki/Akamai_Technologies

Wat is er voordeel uit te halen dat sommige servers offline zijn.
En het probleem is dat ze niet te traceren zijn.
Als ze aan zoiets beginnen is alles al afgeschermd en niet meer te achterhalen van wat voor een ip adres het vandaan kwam.
Je kunt de server platleggen ja maar de redenen waarom ze het doen is echt nutteloos.
Het zijn gewoon een stelletje cyber criminelen die tijd te veel hebben.
volgens deze wiki hebben ze natuurlijk ook clou servers.
volgens de wiki heeft akamai heel veel klanten om bijvoorbeeld 30 dagen versie te downloaden van een of ander product.
Vroeger kon je op het akamai server bestanden downloaden die veel gebruikt worden door mensen bijvoorbeeld winrar of 30 dagen test versie van nero.
Tegenwoordig zit het ingebouwd in de aplicatie dat ie nog effe moet downloaden zodat de gehele installatie als ie klaar is eens eindelijk met de gedownloade informatie de installatie van het programma te kunne opstarten.
Dat soort bestanden staat op de akamai cloud of server toepassing.

[Reactie gewijzigd door rjmno1 op 23 juli 2024 22:46]

[totaalgeenhard]

En het probleem is dat ze niet te traceren zijn.

Lees aub mijn oplossing en eerdere uitleg.

Het is niet zo dat je daders niet kunt opsporen, het moet alleen snel en realtime gebeuren.

Alleen daders opsporen is niet de oplossing. Zie eerdere uitleg.

[xrf]

Akamai is een CDN, geen DDOS mitigator. Daar heb je diensten zoals Cloudflare of Incapsula voor.

Krebs on Security werd gehost bij het 2014 door Akamai overgenomen bedrijf Prolexic, dat zich toelegt op het afweren van DDoS-aanvallen.

Brian heeft in een recent artikel nog een paar paragrafen besteed aan hoe de DDoS-bescherming van Prolexic in elkaar zit. Kort gezegd komt het er op neer dat Prolexic via het Border Gateway Protocol zich tot "eigenaar" verklaart van het IP-adres dat wordt ge-DDoS't; Prolexic vangt zodoende alle verkeer voor dat IP af. Het filtert vervolgens kwaadaardig verkeer eruit en stuurt het legitieme verkeer door naar de echte server.

Edit: Verduidelijkt dat het afweren van DDoS aanvallen niet slechts een specialisme maar de core business van Prolexic is.

[Reactie gewijzigd door xrf op 23 juli 2024 22:46]

[GrooV]

Dat wil natuurlijk niet zeggen dat Krebs ook op een anti DDoS server stond

[kimborntobewild]

Achter anti-DDoS netwerkapparatuur, bedoel je? Het lijkt me dat een file/webserver zèlf niet zoveel aan anti-DDoS doet?

[xiphoid]

Werken bedrijven nog steeds niet samen met het null-filteren?

[totaalgeenhard]

uRFP heeft geen zin als packets niet gespoofed zijn.
Bij een amplified attack is verkeer tussen slachtoffer en "proxy" aanvaller niet gespoofed.

Bovendien moet men zich zeker niet focussen op daders. In Nederland is doorlooptijd tussen aangifte en veroordeling jaren. In die periode loopt verdachte gewoon rond. Bovendien in 99% van de gevallen zal er niets met je aangifte gebeuren of komt het niet tot een veroordeling. Dus focussen op daders zal nooit het aantal DDoS incidenten doen afnemen.

Ik ken OVH niet, maar als aanval grotendeels binnen hun netwerk gaande was (en ik zie dagelijks hack attempts vanaf OVH IP's, dan is 1.1Tb/s wel mogelijk.

France-IX heeft maximum throughput van 532 Gb/s gehad.

[Aetje]

Tja, als dit soort aanvallen de norm wordt tast dat de integriteit van het internet aan. Always online services van games, kritieke systemen die betalingsverkeer reguleren, overheidsdiensten... als DigiID een tijdje down zou gaan zou dat voor veel overheidsdiensten een groot probleem zijn bijvoorbeeld. En da's alleen maar Nederland.

Filtering aan provider zijde, herkenning van nodes die deel uitmaken van een botnet en deze actief van de netwerken af kicken, en providers/peers die hier niet aan meewerken de peering van afsluiten, dat is nodig om dit probleem te verhelpen. En afsluiten van hosts die amplification attacks mogelijk maken. Maar dat gaat weer tegen het vrij internet in.

Maar goed. Iedereen die hosting bij Akamai afneemt weet nu dat die hoster geen grote DDOS aanval af kan slaan. En criminelen weten dat nu ook.

[Blokker_1999]

Hoe wil je hier een vuist tegen maken? DDOS is altijd een kwesite van voldoende bandbreedte hebben en bandbreedte kost ook weer geld.

De aanval traceren gaat niet omdat het waarschijnlijk om tienduizenden tot honderdduizenden gehackte apparaten wereldwijd gaat. Botnets zijn een echte plaag en vormen een reëel bedreiging voor het internet in zijn huidige vorm.

De meeste ISPs erkennen dat zoiets niet kan en zullen inderdaad zoveel mogelijk stappen ondernemen en wanneer het aantal punten vanwaar een aanvaal afkomstig is beperkt is kan je dat upstream laten aanpakken. Maar als de aanval van zowat overal ter wereld komt is er geen beginnen aan want niet elke ISP doet iets met klachtenmails, zeker als ze geautomatiseerd worden verstuurd.

In uw geval zal de aanvaller ook niet echt een te groot probleem hebben. Zijn lijst met kwestbare DNS servers is ingekort, maar zijn bots zijn nog altijd actief en hij kan die weer op een andere manier inzetten.

Het betreft hier ook net geen amplification attack omdat die attacks inderdaad net iets beter op te lossen zijn upstream. Maar ik moet de eerste ISP nog tegenkomen die even enkele duizenden klanten van het internet gaat disconnecten omdat ze een PC hebben die onderdeel is van een botnet.

De anonimiteit van daders bestaan omdat het internet nooit met security in gedachte werd ontworpen en iedereen maar kan doen wat hij/zij wenst. De beheerders van een botnet opsporen is verdomd lastig omdat zij hun sporen zeer goed weten te wissen en voldoende tussenliggende systemen gebruiken om hun botnet mee aan te sturen, systemen die kwetsbaar geneog zijn om hun sporen op te wissen.

[totaalgeenhard]

Ik geef de oplossing al.

Een RFC voor geautomatiseerde backtracing.

Zodra backtracen geautomatiseerd is kun je afspraken maken over eventueel geautomatiseerd (tijdelijk) offline halen.

Nu zullen kleine partijen geen kans maken.

Maar de grote partijen onderling zullen het belang er van wel inzien.

Voor alle duidelijkheid het gaat niet om REPRESSIEVE maatregelen naar de daders, want dat is inderdaad om verschillende redenen lastig. (met name lokale wetgeving.)

Maar technische preventieve en reactieve processen zijn gewoon mogelijk indien er een wil is. Een standaard geconfigureerde device in een infrastructuur hoeft dan geen bron van ellende voor een ander te zijn.

[Blokker_1999]

En dan, dan heb je je tracking tot aan de ISP. En wat moet die daar mee gaan doen? Honderden zoniet duizenden klanten gaan afsluiten? Zelfs al zou je alleen maar Akamai of Cloudflare voor deze mensen onbereikbaar maken dan ga je alsnog een zware storm over je heen krijgen.

Ga je proberen berichten te injecteren in hun websitebezoek? Gegarandeerd dat je een klacht aan je been krijgt omdat je traffiek injecteerd zonder dat de klant erom gevraagd heeft en heb je die miserie weer.

Een ISP kan zijn klanten aanschrijven en enkel als dat zonder gevolg blijft kunnen ze stappen ondernemen. Maar dan verlies je al snel dagen. Mijn vader heeft bijvoorbeeld jarenlang de mails van zijn ISP gemist omdat zijn contact gegevens foutief stonden. Nadat hij gaan klagen was over een probleem kreeg ik ineens enkele dagen later telefoon met de vraag of het opgelost was omdat mijn telefoonnummer er nog als contactpersoon stond ook al woon ik er al meer dan 5 jaar niet meer ... .

[totaalgeenhard]

Er zijn een aantal ISP's buiten Nederland die paar uur tot 48 uur null route op dienstenverlening zetten, zodra klant contact opneemt, worden ze geïnformeerd over de reden.

Bovendien is het in veel landen (waaronder Nederland) zo dat indien jij weet dat jouw infrastructuur betrokken is bij strafbare feiten en je geen actie onderneemt je aansprakelijk gehouden kan worden.

Dus naast technische zijn er ook andere mogelijkheden.

Het gaat erop neer dat gekozen oplossing in deze zaak gewoon fout is, ongeacht of het wel of niet om gratis host ging. Hij zat er immers niet voor niets.

Akamai had gewoon haar naamsbekendheid en invloed richting elke partij waarover die DDoS op hun infra binnen kwam om te voorkomen dat in de toekomst het wederom zo vrijblijvend is.

[Dreamvoid]

De beheerders zijn inderdaad lastig te traceren, maar de bots niet - die kunnen door hun respectievelijke ISP relatief makkelijk 1 voor 1 offline gehaald worden, zeker nu we langzaam naar een ipv6 wereld zonder NAT gaan. Da's vervelend voor mensen met een gehackte webcam ofzo (dan moeten ze een firmware reset doen) maar het alternatief is al helemaal niet wenselijk.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:46]

[Blokker_1999]

Dat kan, en dan krijg je ineens heel veel boze klanten die niet begrijpen waarom je hun van het internet hebt afgesloten. Vergeet niet dat vele machines die deel uitmaken van een botnet gewoon computers zijn die bij mensen thuis staan en die niet veel kennen van de technische achtergrond.

En dat aantal kan al zeer snel oplopen. Krijg je ineens ook weer een stormloop op bijvoorbeeld je klantenservice als je er zo enkele honderden of duizenden in 1 keer afsluit.

ISPs pakken het probleem vaak op een zachtere manier aan door klanten te gaan informeren wanneer er zulke activiteit wordt opgemerkt zodat ze het probleem kunnen verhelpen. Maar daarmee los je het probleem niet onmiddelijk op.

[Dreamvoid]

In de huidige situatie met NAT sluit je inderdaad alles af van een klant, maar ik denk meer over de toekomst - over een paar jaar heeft de klant diverse ipv6 netwerkdevices, zijn wasmachine, zijn koelkast etc. Als je specifieke devices afsluit kan de klant vanaf veilige devices nog altijd internetten, en kan je dus de 'schade' een stuk beperken.

Het is anders totaal onmogelijk om iets te doen aan een botnet van slimme koelkasten.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:46]

[rjmno1]

Ja daar heb je gelijk in maar ik denk eerder dat die apparaten op je wifi aangesloten worden. Zie google met internet of things.
Maar dan ook komen ze inderdaad wel op je modem binnen.

https://nl.wikipedia.org/wiki/Internet_der_dingen

steeds meer apparaten worden op het internet aangesloten.
Het kan zomaar zijn dat je wasmachine in de toekomst een nieuwere firmware nodig heeft omdat deze een virus heeft opgelopen lol.
Off topic

[r2504]

Misschien is het tijd dat klanten wel eens gaan weten... en hun verantwoordelijkheid dragen. Iedere ISP heeft trouwens reeds de nodige clausules in z'n contracten staan die afsluiten gewoon mogelijk maakt... tijd dat men dit ook eens gaat doen.

[WhatsappHack]

Allemaal captain hindsight praatjes (aldanniet met wat interessante statistieken erdoor), maar ik vind het altijd raar dat andere mensen gaan beslissen waar een bedrijf hun geld en resources aan moeten uitgeven/weggeven. Het is altijd makkelijk om het geld van een ander te besteden en zeggen wat ze "zouden moeten doen" of "hadden moeten doen", maar de realiteit is dat het zo niet werkt.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[totaalgeenhard]

Realiteit is dat bij grote organisaties het management bij technische (structurele) issues irrationele beslissingen neemt en de mensen die met hun laarzen in de modder staan het nakijken geeft.

Stel het Microsoft (schijnt nog steeds klant te zijn) te zijn geweest, hoe zouden ze dan gehandeld hebben.

[WhatsappHack]

Realiteit is dat bij grote organisaties het management bij technische (structurele) issues irrationele beslissingen neemt en de mensen die met hun laarzen in de modder staan het nakijken geeft.

Welnee, ze maken een compleet realistische keuze.
Dat iemand het niet kan betalen, is niet de schuld van AKAMAI. Ze hebben het lange tijd gratis aangeboden, maar omdat de aanvallen nu gewoon te ziek groot worden voor AKAMAI om dit *gratis* te blijven oplossen: dat is gewoon logisch. Ergens moet je een grens trekken, en daar is helemaal *niets* irrationeel aan.

Stel het Microsoft (schijnt nog steeds klant te zijn) te zijn geweest, hoe zouden ze dan gehandeld hebben.

Blijven hosten, want Microsoft betaald waarschijnlijk wél een fiks bedrag.
Apple is ook groot afnemer, alle updates van iOS en OS X bijvoorbeeld lopen zowat via AKAMAI. iCloud loopt ook over AKAMAI systemen heen.

Maar het verschil is dat Apple en Microsoft daar heel veel geld voor neertellen.
Als jij voor een klant gratis en voor niets tig gigabit aan extra capaciteit neer moet gaan leggen om je betalende klanten te beschermen: dan zit je met een rendement probleem. Op een gegeven moment houdt het sinterklaas spelen op, en zo simpel is het.

Maar hee, waarom ga jij hem niet gratis hosten? Je zegt immers al dat het een fluitje van een cent is om de aanvallers (grotendeels) te stoppen via wat abuse complaints, go for it! Maak je meteen een goede naam voor jezelf Biedt hem gratis hosting aan en doe wat volgens jou AKAMAI zou hebben moeten doen...
Als 't allemaal zo super simpel en goedkoop is moet dat geen probleem zijn, toch?

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[totaalgeenhard]

Het heeft niets met betalen te maken, het werd gesponsord. Wat nog ergers is voor Akamai.

Je maakt hiermee een statement, als Akamai iets host wat je niet aanstaat kun je gewoon trachten het weg te ddossen.

Als je eerst DDoS had afgeslagen structureel had doen verminderen en dan in goed overleg klant de deur had gewezen, had je en één aanvaller gehad die weet dat je Akamai beter niet kunt aanvallen en had je 1 PR ramp minder gehad.

Op sponsoring zit je rendement niet in je directe omzet.

Door nu zo te handelen gaan Apple, Microsoft en overige grote klanten toch eens (voorzover ze dat niet al reeds hebben gedaan) naar concurrent kijken.

Zeker indien op termijn ze zelf een DDoS krijgen of hogere latency ervaren.

Gezien je tweede deel van je reactie heb je kennelijk nog nooit in een organisatie gewerkt waarin ze procedures hebben voor o.a. dit soort gevallen.

Want het is geen kwestie van technische keuzes, maar een duidelijke keuze van management die niet overziet wat de consequenties is.

Ik ken nog wel wat organisaties waar ze SIEM operators zoeken met interne opleiding.

[WhatsappHack]

Het heeft niets met betalen te maken, het werd gesponsord. Wat nog ergers is voor Akamai.

Het heeft alles met betalen te maken, je kan niet oneindig gratis producten uitgeven; zo simpel is het.

Je maakt hiermee een statement, als Akamai iets host wat je niet aanstaat kun je gewoon trachten het weg te ddossen.

Als je GRATIS door Akamai gehost wordt, dan bestaat die kans ja.
Wat nogal logisch is. Het zegt alleen niets voor de klanten die wél betalen.

Door nu zo te handelen gaan Apple, Microsoft en overige grote klanten toch eens (voorzover ze dat niet al reeds hebben gedaan) naar concurrent kijken.

Je had het hiervoor over irrationele beslissingen.
Zowel het vorige citaat waar ik op reageerde als het citaat waar ik nu op reageer zijn voorbeelden van irrationeel denken van jou kant.

Zo werkt het namelijk helemaal niet in de zakelijke wereld. Apple is zeer goede klant van AKAMAI, is dat al jaren; en zijn altijd voorzien van een zeer goede dienst met uitermate hoge uptime en (D(RD)oS-)resistentie. En die gaat dit echt niet heroverwegen omdat een klant die gratis gehost werd de deur wordt gewezen nu er een drastische wijziging heeft plaatsgevonden in de situatie waar het om gaat.

Wat je over het hoofd blijkt te zien is het volgende, dus ik draai het eens om naar Apple toe:
Stel Apple sponsort een goed doel, en zegt "Al jullie medewerkers krijgen een telefoon van ons, om jullie te ondersteunen". Er werken 100 mensen bij de organisatie. Dit kost Apple, en dan ga ik foutief even uit van de verkoopprijs van een iPhone, 100 * 769 = €76.900.

De organisatie krijgt opeens een toelage en krijgt steun van meerdere overheden voor uitbreiding in meerdere landen. Er komen nu opeens 2500 mensen te werken. Als ze al die medewerkers ook moeten gaan voorzien kost het ze €1.922.500 als ze doorgaan.
Maar de situatie is veranderd, dus kan Apple heroverwegen: gaan we dit nog wel doen. Geen haan die er naar kraait als Apple besluit dat de initiele 100 gesponsorde toestellen wel genoeg waren, en echt niet iedereen van een gratis iPhone gaat voorzien. Dat is volstrekt logisch, een begrijpelijke zakelijke beslissing. Volgens jou zouden dan alle afnemers van Apple echter opeens moeten heroverwegen om nog wel toestellen bij Apple te kopen, want het blijkt dat ze een organisatie met 2500 medewerkers niet van telefoons kunnen voorzien. Maar dat is niet waar: ze kunnen het wel, maar ze besluiten om dat niet GRATIS te doen. Aan een betalende klant leveren ze uiteraard wel! Het is dus geen kwestie van KUNNEN wij dit gratis leveren, maar een kwestie van WILLEN wij dit gratis leveren. Dat kan je niet, zoals jij nu onterecht doet, 1 op 1 doortrekken naar betalende klanten.

Nu komen we dus terug bij AKAMAI. AKAMAI heeft gratis hosting aangeboden, en heeft dit ook, ondanks vele grootschalige DDoS aanvallen, prima gedaan en woord gehouden.
Nu verandert de situatie opeens: een gewijzigd type aanval genereert zo achterlijk veel verkeer dat het daadwerkelijk een risico gaat vormen tenzij ze flink gaan uitbreiden.

AKAMAI heroverweegt: gaan wij die klant nog steeds voorzien van gratis hosting, of moeten we het helaas afblazen omdat het nu teveel geld en resources gaat kosten om te blijven onderhouden; terwijl we er niets voor terug krijgen? Dat is wederom een afweging tussen "KUNNEN wij dat" en "WILLEN wij dat". Ze kunnen het vast wel, maar of ze het gratis willen doen? Dat is even de vraag. (Nee dus. Logisch.)

Dat is *volstrekt* logisch, en grote bedrijven snappen dat prima. De toezegging voor gratis hosting is gedaan in Situatie A, nu ontstaat Situatie B; en in Situatie B willen ze er niet langer mee doorgaan. Prima zakelijke beslissing, en een logische beslissing. Maar heeft totaal geen relatie met het feit of AKAMAI dat ook zou doen bij een betalende klant... Welnee, want ze hebben wel vaker opgeschaald voor hun grote *betalende* klanten. Die zijn dus prima voorzien... Je snapt toch wel dat er een verschil zit tussen betalende klanten en klanten die de spullen gratis krijgen?

Jij vind het blijkbaar erg vervelend dat ze de hosting niet doorzetten, en op basis daarvan maak je een irrationele niet-objectieve beoordeling van hetgeen AKAMAI nu heeft gedaan... Objectief en zakelijk bekeken is het echter een prima reactie van AKAMAI, ze hebben hun woord lange tijd gehouden en alle kosten en aanvallen geabsorbeerd: maar nu het te gek voor woorden wordt, dankzij een nieuwe generatie aanval, trekken ze de stekker uit die sponsoring. Logisch, niets meer niets minder.

Dus nee, Apple en Microsoft gaan niet vanwege deze volstrekt logische en voor de hand liggende zakelijke beslissing van een professioneel bedrijf opeens zeggen "Oh jee, nu zijn wij ook in gevaar! Dat wij wel miljoenen aan AKAMAI betalen, dat vergeten we maar even voor het gemak. Fuck het onbetrouwbare AKAMAI!!1!" ... No way.

Als je eerst DDoS had afgeslagen structureel had doen verminderen en dan in goed overleg klant de deur had gewezen, had je en één aanvaller gehad die weet dat je Akamai beter niet kunt aanvallen en had je 1 PR ramp minder gehad.

Er is hier echter geen sprake van een PR-ramp.

Gezien je tweede deel van je reactie heb je kennelijk nog nooit in een organisatie gewerkt waarin ze procedures hebben voor o.a. dit soort gevallen.

Want het is geen kwestie van technische keuzes, maar een duidelijke keuze van management die niet overziet wat de consequenties is.

*grinnik*
AKAMAI weet niet wat de consequenties zijn van een gevoelige site gratis hosting bieden. Ik denk dat AKAMAI dat dondersgoed weet, en destijds ook wist. Echter is het speelveld nu veranderd. Dat kan je echt niet zomaar incalculeren, en op een bepaald punt moet je gewoon een grens trekken. Dat hebben ze nu, terecht, gedaan.

Ik ken nog wel wat organisaties waar ze SIEM operators zoeken met interne opleiding.

Top

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[totaalgeenhard]

Het zou je sieren als je eens letterlijk leest wat ik wel geschreven heb en daarop in zou gaan ipv verhaal te verzinnen die niet in de buurt komt met wat ik WEL geschreven heb.

[WhatsappHack]

Ik heb letterlijk gelezen wat je hebt geschreven, sterker nog: ik citeer exact wat je hebt gezegd, en daar reageer ik op... Het staat er dus blijkbaar wel.

Als je echter vindt dat ik je niet goed begrepen heb of je verkeerd snap, wat natuurlijk kan gebeuren: dan zul je dat moeten uitleggen, en vertellen waar ik precies fout zit en hoe ik jouw woorden blijkbaar anders geïnterpreteerd heb dan je bedoeling was...

[bbob]

Goed verhaal maar zoals het artikel al stelt host akami voor 0 euro. akami is een cdn netwerk en niet specifiek gericht als hoster tegen ddos aanvallen. Cloudflare aan het einde van het artikel wel en als ik mag gokken willen die juist nu de hosting doen om aan te tonen kijk host je via ons dan kunnen wij de ddos afslaan. Voor cloudflare goede reclame en dat is ook hun verkoopverhaal.

[Rafe]

Krebs is niet fan van CloudFlare omdat ze volgens hem juist DDoS'ers het leven makkelijk maken: Spreading the Disease and Selling the Cure.

[kwakzalver]

1+1=3
nieuws: KPN kampte met internetstoring bij aantal wholesale-klanten - update

Zou me niet verbazen dat KPN het ook flink voor zijn kiezen heeft gekregen en bijna gelijktijdig overbelast werd.

Het blijft speculeren. Maar op de KPN infrstructuur zie ik toch meer port scans en attacks langskomen dan bij andere aanbieders.

[cornedor]

De storing bij KPN is veel later geweest dan de DDoS.
Dit bericht is al van 15 uur geleden: http://www.businessinside...-krebs-ddos-attack-2016-9

[totaalgeenhard]

Heb je zakelijk DSL ?

Whois je IP eens, dan zie je de reden.

Bij KPN kun je interessante doelgroep dankzij WHOIS er zo uit vissen.

[koelpasta]

Om lang verhaal kort te maken na een weekend te hebben geklaagd over ruim 100.000 IP's van nameservers met instructies hoe ze zonetransfers kunnen blokkeren, was 90% van verkeer weg.

Zoveel slechte configuraties? En dan ook nog eens zoiets essentieels/gevoeligs als zone transfers? Wow....

[donny007]

Om die 620Gbit/s even in perspectief te zetten: het grootste internetknooppunt van Japan (JPNAP) verwerkt op de piekmomenten zo'n 670Gbit/s.

[totaalgeenhard]

DE-CIX grootste ter wereld qua volume

Gemiddeld 3000 Gb/s
https://www.de-cix.net/about/statistics/

AMS-IX grootste ter wereld qua aantal connected parties

Gemiddeld 2500 GB/s
https://ams-ix.net/technical/statistics

Het een erg grote aanval.

[supersnathan94]

Euhm. AMS-IX verwerkt op piekmomenten tegen de 5Tbit/s zelfs op dit moment zitten ze al over de 3Tbit.

So of ik heb een andere definitie van internet knooppunt of er klopt iets niet aangezien er in Japan echt wel wat meer verkeer zou moeten zijn.

[WhatsappHack]

AMS-IX heeft wel het verkeer van zowat heel vast Europa te verwerken he... Japan is dan relatief gezien toch ff een heeeeeel stuk kleiner en ook een stuk minder inwoners. Klein verschilletje

[supersnathan94]

Houd er wel rekening mee dat Japan de snelste breedbandverbindingen ter wereld heeft? In Hong kong heb je 2Gbit/s voor nog geen 50 dollar.

Ja je hebt gelijk dat er een verschil in inwoners is en dat het gemiddelde maar net iets boven dat van Nederland ligt (0.4 mbit/s), maar met 127 miljoen mensen op zijn klein stukje had ik toch wel wat meer verwacht. Zeker op piek momenten. Kan me best voorstellen dat die 2Gbit verbindingen dan lekker gebruikt worden.

[Aikon]

Het knooppunt in Japan verwerkt alleen verkeer voor Japan gezien de geografische ligging en een AMS-IX voor een flink deel ook van (en naar) EU en USA.

[djiwie]

Hong Kong ligt in China en niet in Japan.

[supersnathan94]

Je hebt helemaal gelijk!

Toch kwam ik iets dergelijks tegen toen ik zocht op internet speed japan. Ik zal ff kijken hoe het precies zit.

edit:

Would you expect any less from tech-savvy Japan? High-speed fiber optics run throughout the country, enabling some of the world’s fastest internet speeds. Peak speeds in Japan are nearly triple the global average for internet users. But the country known for its human-like robots and other cutting-edge technology isn’t content with its current speeds — not by a long shot.
Japan is one of several countries working on 100Gbps internet using advanced “optical packet switching technology”. For now, one Japanese internet provider is offering 2Gbps speeds — twice the pace of Google Fiber — for about $50 a month. That makes it the world’s fastest commercially available internet service.

http://nomadcapitalist.co...st-internet-speeds-world/

[Reactie gewijzigd door supersnathan94 op 23 juli 2024 22:46]

[Jack Flushell]

Euhm. AMS-IX verwerkt op piekmomenten tegen de 5Tbit/s zelfs op dit moment zitten ze al over de 3Tbit.

Hij zegt toch ook gemiddeld? Kijk naar de graph, hobbeltjes en bobbeltjes heh...

Houd er wel rekening mee dat Japan de snelste breedbandverbindingen ter wereld heeft? In Hong kong heb je 2Gbit/s voor nog geen 50 dollar.

Hong Kong ligt op / naast China.

[...]maar met 127 miljoen mensen op zijn klein stukje had ik toch wel wat meer verwacht.

Heb jij enig idee hoe groot Japan is?
Niet zo groot als Europa, maar och... je fietst er niet even doorheen op een herfstige zondag hoor...

[Reactie gewijzigd door Jack Flushell op 23 juli 2024 22:46]

[supersnathan94]

Nee hij zegt letterlijk piekmomenten.

Dat hong kong niet bij Japan hoort heeft iemand anders ook al aangegeven. Mijn fout, had ik moet weten. Wel raar dat dit via google naar boven kwam. En ja ik weet hoe groot Japan is ongeveer de helft van frankrijk als we het op vierkante KM's bekijken. Kijken we naar inwoners dan heeft Japan echter 2 keer zoveel inwoners. De bevolkingsdichtheid is dan ook 4 keer zo groot als in frankrijk. En france-IX doet op piekmomenten ook ongeveer 600Gbit/s.

Vind je het dan raar dat ik van Japan verwacht dat ze hoger zouden zitten? Ze hebben een van de snellere verbindingen liggen (gemiddeld nog steeds sneller dan nederland) en toch halen ze per dag net zoveel binnen als frankrijk wat de helft minder inwoners heeft.

[Jack Flushell]

Misschien raar, maar wel een feit

[GlowMouse]

Dit is slechte reclame voor Akamai. Momenteel heeft Akamai het grootste content delivery network, maar schijnbaar zijn zij niet in staat een ddos te doorstaan. Door toe te geven aan deze ddos zetten ze bovendien de deur open voor nieuwe aanvallen op hun netwerk.

[fibergeek]

De enige oplossing voor een DDOS is meer transit bijbouwen, wat veel geld kost. Transit betaal je per mbit (boven je commit), dus dit soort geintjes zijn nog eens extra duur daarmee. Ik kan me wel inleven dat je om dergelijke redenen besluit om niet "gevoelige" sites te hosten.

[totaalgeenhard]

Meer capaciteit is niet de oplossing.

Bovendien peeren grote partijen GRATIS. Ze betalen een fixed fee voor een PORT op een exhange point (zoals AMS-IX)

De snelheid waarmee dader kan opschalen is veel groter dan dat een ISP poortjes bij een AMS-IX erbij kan zetten.

De enige oplossing is samenwerking en het liefst automatisch. Dan kan een proces bij begin detectie van aanval gestart worden.


ps: Ook qua kosten niet, naast kosten die Akamai moet maken, moet exchange point kabels, routers en switches ophangen. Hardwarematig opschalen doen ze niet in een paar uurtjes, terwijl aanvaller in die paar uurtje al meer aanvalskracht kan opdoen.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 22:46]

[Basz0r]

ISP's moeten veel harder optreden tegen abuse in hun eigen netwerk. En machines/netwerken die grote hoeveelheden 'vreemde' data uitsturen veel sneller traceren en dichtzetten. Als een machine onbewust niet is beveiligd, dan bewustzijn kweken bij de eigenaar. En als het wel bewust is, dichtzetten en zo'n klant niet meer toe laten.

Het wordt dan uiteindelijk net zoals bijschalen een kat en muis spelletje. Maar je werkt er wel naartoe, dat je eigen netwerk steeds minder misbruikt kan worden voor dergelijke aanvallen. Grote ISP's doen dit ook al voor SPAM abuse binnen hun eigen netwerk. Waarom ook niet in hetzelfde volume voor netwerk verkeer?

[Reactie gewijzigd door Basz0r op 23 juli 2024 22:46]

[Dreamvoid]

Het is voornamelijk een gebrek aan goede uitwisseling - je kan bij een DDOS prima loggen wie de bots zijn, die adressen doorgeven aan de betrokken ISP, en die adressen vervolgens offline halen - al is dit lastig met devices die achter een NAT laag zitten. Maar met de invoering van ipv6 wordt dat de komende jaren steeds minder een probleem.

Probleem is dat de ISP's van elkaar moeten vertrouwen dat deze gegevens authentiek zijn. Als een Chinese ISP beweert dat bv Akamai's logs vals zijn, dan houdt het natuurlijk op.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:46]

[Armin]

En machines/netwerken die grote hoeveelheden 'vreemde' data uitsturen veel sneller traceren en dichtzetten

Bij de meeste DDoS aanvallen is het verkeer van individuele machines nu net niet zo bijzonder. Enkele DNS transacties bijvoorbeeld. De truc is nu net dat deze gewone onschuldige transacties versterkt worden qua vollume en vooral qua omvang door bijvoorbeeld verkeerd afgestelde DNS servers. De DNS servers moeten dan aangepakt worden, de client zelf is vaak niet zozeer het probleem.

En slecht afgestelde DNS servers worden ook aangepakt, maar er zijn nog steeds talloze netwerkbeheerders van kleinere netwerken die menen dat ze perse zelf hun eigen DNS server moeten hebben, net als hun eigen SMTP (relay) server, etc.

[hackerhater]

Een DNS-server op het netwerk van een bedrijf is het probleem niet, maar dat ding mag niet van buitenaf bereikbaar zijn.
De server op mijn werk reageerd alleen op local lan.

[xiphoid]

Met klein abuse begint het al. Amazon bv doet eigenlijk niets tegen rapporten met data van aanvallen. Ze nemen het aan en zeggen bedankt, en dezelfde IP met dezelfde fingerprint blijven massa scannen, exploiten, abusen, en DoS attacks uitvoeren voor maanden. Als je maar betaald. Netjes of niet. Het boeit Amazon eigenlijk niets. Was het maar iets makkelijker om iemand met abuse oflfine aan te pakken. 90% als het niet 95% is, loopt er gewoon van weg.

[totaalgeenhard]

Het begint met configuratie van infrastructuur.

Naar mate men de Engelse taal niet machtig is of als tweede taal hebben naar mate infrastructuur slechter geconfigureerd is.

Als netwerken spoofen niet toestaan, standaard configuraties geen zonetransfers etc.. toestaan dan van je leeuwendeel al af.

Aan de andere kant de meeste mensen draaien een android versie waar meerdere lekken inzitten. Om maar te zwijgen over embedded Linux in b.v. internet of things.
Veel devices krijgen nooit een update pas als ze vervangen worden. En dat is een opkomend probleem.

Stel op een dag hebben alle huizen verlichting die elk een IP adres hebben. Zou jij je verlichting gaan vervangen omdat ze vulnerable zijn? Heb jij een firewall thuis die outbound verkeer controleert?

Een ISP kan uitgaand verkeer maar beperkt monitoren en filteren.

Ik kan een voorbeeld geven van een NAS van een klant die telkens door firewall in onze infrastructuur triggerde, met als gevolg dat hij niet bij zijn diensten kon komen. Aan de telefoon heeft het een paar uur gekost om NAS in zijn thuis netwerk te pinpointen als boosdoener en aangezien hij (zoals meeste mensen) hun eigen verkeer niet kunnen/zullen monitoren (sniffer) was hij er zelf nooit achter gekomen.

Als je dit uitvergroot naar een ISP met miljoen klanten..... kan ISP alleen een klant afsluiten en daarmee 1 aanvallende element uitschakelen. Maar een ISP zal niet alle (of significant deel van zijn klanten) kunnen afsluiten... want dan gaan ze failliet.

SPAM is ander verhaal, je hebt kunt gewoon meeste MTA (mail servers) geconfigureren dat ze SPAM databases gebruiken en daarmee vang je leeuwendeel af. Als je meerdere mail servers hebt kun je nog monitoren of mail van bepaalde source aan meerdere partijen tegelijkertijd word afgeleverd (dat doet Gmail) en dan kan je ze als spam bestempelen.

Maar als ontvangende partij van een DDoS heb je met een echte uitdaging te maken. Zo merk je pas als infrastructuur trager is, resources hoog (als je daarop monitored that's) dat er iets gaande is. Vervolgens ga je uitzoeken waar meeste verkeer heen gaat en dan heb je target gevonden (nog niet het IP als het meerdere Ip's heeft). En dan ga je beginnen met uitzoeken wie slachtoffer is.

Als jij 500 sites achter een IP hebt hangen, dan ben je tussen detectie en vinden van slachtoffer een uurtje zoet. Vervolgens is het uitzoeken van welke aanvalstechniek. Ondertussen moet aanval wel doorlopen want zodra het stopt heb je minder om mee te werken. (Voordat iemand er over begint. Maar aanval dat stopt zonder dat je conclusies hebt getrokken is irritant omdat zodra aanval weer begint jij ook opnieuw kunt beginnen....).

Zodra je aanvalsmethode hebt uitgevonden ga je strategie bepalen. Kun je iemand bellen/mailen? Dan even scripten en dan hopen dat ze er wat aan gaan doen. Je bent er zo een paar uur mee zoet.

[TheKmork]

Akamai is echter niet transit free en betaalt dus zeker wel voor transit. Natuurlijk handelen ze ook wel het nodige verkeer via peering af, maar het is dus verre van gratis voor ze (zelfs als je peerings voor het gemak even als gratis rekent).

Daarnaast is het over het algemeen zo dat partijen internet exchanges met name gebruiken voor de kleinere partijen/peers. Partijen waarmee echt grote hoeveelheden data uitgewisseld worden zullen over het algemeen via PNI (Private Network Interconnectie) gekoppeld zijn, dus gewoon een directe fiber connectie tussen de routers van de 2 netwerken. Dit is vele malen goedkoper dan alles maar via een IX te doen.

Wat je zegt over opschalen is echter wel correct, dit kan zeker niet zomaar even ad hoc, aangezien er fibers bijgeprikt moeten worden, poorten geconfigureerd, en natuurlijk ook betaald worden voor de extra poort capaciteit.

Kortom: Het zal Akamai nog steeds een hoop geld kosten om een dergelijke DDoS op te vangen, onafhankelijk of ze wel of niet voldoende capaciteit hebben liggen momenteel.

Samenwerken is mooi, en wordt ook in vrij vergaande schaal al gedaan, maar uiteindelijk wil er niemand de controle over zijn netwerk laten afhangen van andere netwerken. Dit om de simpele reden dat er gewoon netwerken op het internet zijn die je niet altijd 100% kan vertrouwen. Daarnaast bestaat er gewoon een groot risico op misbruik, want de mate van controle die hiervoor nodig is kan heel gemakkelijk ook misbruikt worden door malafide partijen.
Het internet is een netwerk van vertrouwen, maar elke (goede) netwerkprovider heeft daarnaast ook beschermingsmaatregelen in plaats om te voorkomen dat een fout of probleem (per ongeluk danwel met opzet) in anderman's netwerk voor problemen gaat zorgen in het eigen netwerk.

[totaalgeenhard]

Voor het gemak Nederland. Welke ADSL/Kabel provider betaald Akamai of vice versa? Rond 1999/2001 waren er nog wel wat "koppige" partijen waaronder KPNQWEST.

Dat je voor poort betaald is logisch anders had AMS-IX niet kunnen bestaan, volume betaal je niet voor (max capaciteit per poort is limiet.)

Voor een PNI heb je PoP nodig die in de buurt is. Alleen als transit dermate veel kost om een fiber in de grond te stoppen en ergens in de buurt van "tegen partij" te laten komen doen ze dit.

PNI in een datacenter komen vaker voor.
Of het "voordeliger" is dan via een IX heeft met de aan de overige kosten te maken. Moet er wel bij zeggen dat de grootste partijen in b.v. Nederland niet omkijken naar een paar ton investeren. In het buitenland ken ik wel landen waar elke vorm van peering (of PNI) om verschillende redenen not done is.
Sterker nog ik ken een land waar telefoon en internet verkeer tussen verschillende ISP/Telco's in dat land via Europa gaat.

Het geld zal niet in het verkeer zitten eerder in afhandelen van zeurende klanten die hogere latency of niet beschikbaarheid klagen en incident response. En nu imago schade. Dat grote concurrent iemand overneemt wil je niet. Grote klanten zullen er een mening door gaan vormen.

Het gaat niet over controle uit handen geven. In eerste instantie moet abuse gewoon geautomatiseerd verwerkt kunnen worden, dus slechts signaleren vervolgens kun je tussen partijen additionele stappen afspreken.

Als wij afspreken om te gaan peeren, kunnen we ook afspreken hoe we met abuse tussen ons in omgaan. En ik kan jou (en jij mij) snel overtuigen hoeveel tijd en energie het gaat schelen indien signaleren geautomatiseerd gaat, zodat jij of ik slechts na controle met een druk op de knop bron kan uitschakelen.

Eventueel kan je zelf dat proces automatiseren door een tresshold in te stellen 10x verschillende klachten (van b.v. verschillende peering partners) over een IP 24 uur null route.

[TheKmork]

Waarom zou transit enkel ingekocht kunnen worden bij kabel/DSL providers? Een partij als Akamai kan dit net zo goed inkopen bij een grotere partij zoals bijvoorbeeld een Level3, NTT, Telia of nog een van de andere grote jongens.

http://as-rank.caida.org/...o&mode1=as-table&as=20940

Hierin is te zien dat Akamai van een heleboel verschillende partijen transit geleverd krijgt. Nu weet ik dat deze statistieken niet zonder fouten zijn, maar dat Akamai transit inkoopt weet ik wel met vrij grote zekerheid.
Akamai heeft CDNs over de hele wereld verspreid staan en heeft hier (vrijwel) geen eigen netwerk tussen, dus die maken gebruik van andere netwerken om te zorgen dat deze CDNs gevuld blijven.
De enige manier waarom je dit kunt doen is door transit relaties met partijen aan te gaan, want bij peering is de afspraak (nee, geen technische limitatie, maar zoals het algemeen is afgesproken) dat je verkeer van een peer niet doorzet naar een andere peer, dus dat zou betekenen dat Akamai ofwel een eigen backbone zou moeten bouwen, ofwel elke individuele CDN van een full mesh aan tier 1 peers zou moeten voorzien. Dit is niet haalbaar natuurlijk.

Overigens vwb PNI's: Over het algemeen zitten de meeste grote providers wel in de grotere datacenters bij elkaar, en vaak ook wel in meerdere datacenters in de grotere steden (Londen, Frankfurt, Amsterdam etc), dus over het algemeen is het lang niet zo lastig als je doet voorkomen om een PNI aan te leggen tussen 2 partijen die willen peeren. Het is in mijn ervaring nog maar heel erg zelden voorgekomen dat een partij wilde peeren maar niet in een datacenter zat waar wij ook zaten. Zeker bij een grotere partij als Akamai komt dat eigenlijk niet voor (die zorgen wel dat ze hun CDNs opbouwen in datacenters waar de gewenste upstreams/peers zitten).

Mbt abuse:
Verwerken van abuse is 1 ding, maar wat wil je precies dat hiermee gebeurt? Dat een klant afgesloten wordt? Wil je dan alle klanten die deelnemen aan een DDoS gaan afsluiten? Daar moet je dan enorm veel accessnetwerken voor gaan aanschrijven, waarvan je nu al gegarandeerd bij een heleboel netwerken gewoon niet thuis krijgt. En bij de hogere transportnetwerken kun je al helemaal niet aankloppen, want die zitten er gewoon tussenin en doen helemaal niets met individuele host-IP's, die werken enkel met gehele prefixes (en die kun je al helemaal niet blokkeren).
De transportnetwerken bieden vaak wel blackholing mogelijkheden (dus verkeer met als bestemming jouw server droppen ze dan op jouw verzoek). Hiermee is de DDoS in feite geslaagd, host is onbereikbaar, maar de rest van je klanten worden dan in elk geval niet benadeeld door het verkeer.
Algehele blackholing biedt vrijwel elke netwerkprovider. Fijnmazigere controle is wat minder algemeen aanwezig ("blokkeer alle verkeer van buiten NL"), met name omdat het vaak lastig signaleren is waar verkeer vandaan komt, enkel waar het je netwerk binnen komt. Dit werkt dus vaak wel, maar is niet perfect. Er zijn echter wel enkele netwerkleveranciers die deze mogelijkheid bieden.

Als je echt scrubbingdiensten bedoelt, dat is weer een hele andere tak van sport en ook meteen vele malen duurder (en ondoenlijk in de hogere tier transport netwerken. Dit kun je dus eigenlijk alleen reëel aan de edge doen. Aangezien een DDoS vrijwel niet te detecteren is aan de sturende kant zal dit dus moeten gebeuren aan de ontvangende kant. Nadeel hiervan is dus echter wel dat je dit pas in je eigen netwerk kan doen, of hooguit bij je directe upstream, maar die moet dan wel redelijk lokaal een scrubbing doos met voldoende capaciteit hebben (en zeker bij een aanval als deze zal het enorm duur zijn om deze capaciteit aan te kunnen).

Wat eigenlijk Dreamvoid hierboven ook al aanhaalt: Het is toch echt grotendeels een kwestie van vertrouwen en hoeveel moeite je erin wilt steken. Akamai heeft hier last van. De upstream provider over het algemeen een stuk minder omdat de aanval gedistribueerd binnenkomt, en zeker als het om peering zou gaan dan kan ik me voorstellen dat een netwerkprovider niet snel geneigd zal zijn om allerlei processen te gaan optuigen om dit te gaan regelen. Er zijn de nodige blackhole (nullroute) faciliteiten beschikbaar, en daar zul je het over het algemeen mee moeten doen (en die zijn inderdaad vaak geautomatiseerd en kun je zelf mbv een BGP community activeren).

_{Achtergrond: Ik werk zelf al zo'n 10 jaar in de IP transit wereld bij een tier 1 netwerk, waarvan ik de laatste 5 jaar als technisch peering coordinator heb gewerkt. Ik weet natuurlijk niet de inhoudelijke details van Akamai, maar vanuit het perspectief van transportnetwerk-leverancier zie je genoeg}

[Reactie gewijzigd door TheKmork op 23 juli 2024 22:46]

[totaalgeenhard]

Waarom zou transit enkel ingekocht kunnen worden bij kabel/DSL providers?

Geen idee, waar staat dat?

Als je beiden en/of in zelfde DC staat of/en zelfde IX zit en veel verkeer naar elkaar toe hebt dan verdwijnt de noodzaak voor transit omdat je het voordeliger middles peering of direct fysieke link kunt oplossen.

Alleen kleine partijen hebben niets te "bieden" om interessant te zijn en telco's met eigen infra willen dat terug verdienen met transit.

Die link die je aangeeft is niet per definitie transit.

Mbt abuse:

Lees eerste posting eens terug.

En ik herhaal nogmaals de enige maatregel tegen DDoS is reactief technisch geautomatiseerd. Repressief middels wetgeving is onzinnig, zie een andere reactie met nadere verklaring waarom.

Als je over peer of transit een DDoS binnenkrijgt zul je toch moeten afvragen of je met tegenpartij verder wilt gaan indien ze er niets aan doen. Ongeacht wie het slachtoffer is, immers het is niet de vraag of maar wanneer volgende aanval is. En met deze houding adverteren ze nu wereldwijd dat je dingen bij Akamai offline kunt krijgen.

Ik weet niet bij hoeveel ISP's je hebt gewerkt. Maar bij de verschillende waar ik vorige en deze eeuw binnen heb gelopen is er een groot verschil over hoe men tegen dit onderwerp aankijkt. Corporates hebben een heel andere inslag als ISP's die door techies opgezet zijn, aangezien die laatste groep zich niet met politiek en strategische keuzes lieten beïnvloeden... tenminste na grote opkoop en faillissement slag zijn er wel erg weinig partijen overgebleven.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 22:46]

[TheKmork]

Vwb je eerste vraag, reageer ik met een quote uit je eigen bericht:
"Voor het gemak Nederland. Welke ADSL/Kabel provider betaald Akamai of vice versa? Rond 1999/2001 waren er nog wel wat "koppige" partijen waaronder KPNQWEST."

Die vraag is dus niet relevant, want Akamai kan overal transit inkopen, dat hoeft niet bij de lokale DSL/kabelboer te zijn. Dat bedoelde ik met mijn eerste zin. En zoals je in de Caida link kan zien krijgt Akamai dus transit van KPN (International) o.a.

De link die ik geef is een overzicht van welke partijen transit leveren en welke partijen peeren. Als je kijkt naar kolom 4 dan staan daar de partijen die access diensten (= default route naar global internet) of transit (= full routing table) leveren aan Akamai.
Zoals ik al zei is de lijst niet zonder fouten, maar het is met de setup van Akamai technisch onmogelijk om volledig zonder transits te opereren.
Ja ze doen ook verkeer via peering, en ja dat zal ongetwijfeld ook wel de meerderheid zijn, maar desalniettemin kopen ze dus wel degelijk ook transit in.

Je zegt zelf al: "Als je veel verkeer naar elkaar toe hebt". Dat is inderdaad correct, maar een partij als Akamai is per definitie enorm content heavy en is daardoor vrijwel geheel eenzijdig verkeer. Natuurlijk gaat er ook nog wel iets van verkeer terug, maar het leeuwendeel is vanaf Akamai gezien outbound. De meeste grotere carriers vereisen toch een wat meer gebalanceerd verkeerspatroon om te peeren met een partij. Zeker carriers die geen directe eigen accessklanten hebben zullen dus niet zo gauw peeren met Akamai en er eerder geld voor vragen. Aangezien Akamai ook onmogelijk met *iedereen* kan peeren zullen ze dus op zijn minst met 1 of meerdere tier 1 netwerken een transit overeenkomst hebben om in elk geval gegarandeerd de klanten te kunnen bereiken.

[totaalgeenhard]

Vwb je eerste vraag, reageer ik met een quote uit je eigen bericht:
"Voor het gemak Nederland. Welke ADSL/Kabel provider betaald Akamai of vice versa? Rond 1999/2001 waren er nog wel wat "koppige" partijen waaronder KPNQWEST."

Welke relevantie heeft je vraag:

Waarom zou transit enkel ingekocht kunnen worden bij kabel/DSL providers?

Er zal geen Nederlandse ADSL/Kabel provider zijn die geen peering agreement heeft met Akamai. Er staat daar nergens iets over transit verkeer....

De meeste grotere carriers vereisen toch een wat meer gebalanceerd verkeerspatroon om te peeren met een partij.

Ik weet niet wat je definitie van carrier is, maar imho zijn dat de partijen met eigen infrastructuur die voornamelijk van transit moeten leven.

In geval van ADSL/Kabel providers dienen ze hun gebruikers tegen zo min mogelijke kosten tevreden te houden.

Aangezien CDN services van Akamai grote partijen betreft, zal een significant deel juist afgenomen worden door ADSL/Kabel klanten en derhalve maakt het niets uit dat er veel of weinig verkeer terug gaat, aangezien het anders die ADSL/Kabel leverancier gewoon veel geld gaat kosten.

Ik weet niet waar jij peering manager bent geweest, maar kennelijk was dat niet bij een content partij en ook niet bij een ADSL/Kabel boer.

Ik vermoed bij een webhosting partij. En zoals ik elders al schreef
indien partij niet interessant genoeg is, zal de noodzaak om er mee te peeren ook niet urgent zijn, zeker niet als je gewoon geld aan ze kunt verdienen. (zoals KPNQWEST deed.)

Dat Akamai transit verkeer heeft voor inbound om hun servers van de content te voorzien van hun klanten, zal ze weinig boeien, dat zijn te verwaarlozen kosten t.o.v. outbound.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 22:46]

[TheKmork]

Je lijkt steeds te vergeten dat er meer netwerken zijn dan enkel content of access (kabel/dsl) netwerken. Zoals ik al aangaf ben ik peering coördinator geweest bij een tier 1 ISP netwerk (ofwel een netwerk dat transit vrij is). Er zijn ook nog transport netwerken (carriers) die zowel geen/weinig eigen content hebben als geen eigen eyeballs. Deze hebben dus zowel kabel/DSL providers als content partijen als klant en leveren daar dan de internationale internet toegang voor. Deze leven dus inderdaad deels van transit en deels van extra diensten zoals business to business vpn etc.
Voorbeelden hiervan uit de tier 1 lijst zijn partijen als bijvoorbeeld Cogent, Level3/Global Crossing, XO, KPN International (staat als netwerk volledig los van KPN NL, gebaseerd op voormalig KPNQwest die je inmiddels enkele keren aanhaalde), Tata, GTT.

Ik denk dat we qua discussie enigszins langs elkaar heen aan het praten zijn, dus laten we deze discussie beëindigen. Het doet er uiteindelijk weinig toe voor het daadwerkelijke onderwerp van de discussie, want we waren het er al over eens dat "eventjes" opschalen van capaciteit niet even zomaar kan en de nodige kosten meebrengt, los van of dit nu via transit of peering gaat.

[TheKmork]

En ik reageer even apart op het abuse stuk, omdat dit feitelijk een aparte discussie is (en het vervuilt om het door elkaar te doen):

Als transitleverancier lever je de data naar je klant. Je transporteert heel simpelweg verkeer van netwerk A naar netwerk B. Als netwerk A aangevallen wordt dan kan netwerk A gebruik maken van de automatische blackholing dienst die de meeste transitproviders bieden. Deze mate van samenwerking bestaat al jaren, maar dit bestaat er enkel uit dat verkeer met een specifieke destination geblokkeerd wordt. Aangezien een DDoS per definitie uit een grote waaier van sources komt wordt er niet op source geblokkeerd.

Daarnaast is er het andere punt: Vertrouwen.
Je mag prima verkeer naar je eigen hosts blokkeren, die zijn van jou dus dat is geen enkel probleem. Als je iets met de source zou doen dan heb je in feite de mogelijkheid om de klanten van een ander te frustreren door hosts te blokkeren die helemaal niet van jou zijn maar (volgens jou) je iets aandoen.
Je kunt uiteraard melding doen bij provider X dat source Y je heeft aangevallen, en de meeste providers met een kundige abusedesk zullen dit ook serieus behandelen, maar dit is over het algemeen mosterd na de maaltijd en helpt niets met het bestrijden van DDoS'en. Hosts blokkeren schiet je uiteindelijk niets mee op tenzij je de bron van de infectie of het controlenetwerk weet te pakken, want geïnfecteerde systemen springen volgens mij (speculatie) sneller op dan er tegenop te blokkeren valt (met als bijkomend risico boze klanten en irritatie).

Lang verhaal kort: er zijn al verschillende methodes om DDoS te mitigeren, maar dit is ofwel duur (scrubbing, vooral duur bij grote volumes) ofwel haalt het alsnog de target host offline (nullroute/blackhole). Dit probleem bestaat al jaren, en de netwerk operator communities zijn er ook al tijden mee bezig om dit te bestrijden, maar het is niet enkel even een kwestie van informatie uitwisselen. Er zijn nu eenmaal bad actors op het internet (ook netwerken, niet enkel hosts), dus je kunt niet blind vertrouwen op informatie die je van extern ontvangt. Geen enkele provider zal dus volautomatisch een melding van partij X aannemen die partij Y zal raken tenzij partij Y onderdeel (of een achterliggende klant) is van partij X zelf.

Wat dit specifieke bericht betrof: Dit was een website die gratis hosting kreeg van Akamai, ik kan me voorstellen dat ze minder zin hebben om daar heel veel effort in te steken om die operationeel te houden dan een grote betalende klant. Uiteindelijk telt in zekere zin ook gewoon de diepte van de portemonnee van de klant, en in dit geval heeft Akamai zoals je al zegt besloten om niet meer met de tegenpartij verder te willen.

[GrooV]

Meer capaciteit is zeker wel de oplossing, kijk naar Cloudflare. Als je maar genoeg regionale PoP's hebt wereldwijd dan is de impact van een DDoS veel kleiner. Daarnaast doet Cloudflare zo veel mogelijk met peering, wat goedkoper is dan transit

[totaalgeenhard]

Akamai is veel groter dan cloudflare en aantal PoP's die Akamai heeft is veel groter. In derde wereldlanden zie je eerder Akamai rack/kooi staan dan Cloudflare.

Sterker nog ik heb zelfs in Nederland nog nooit Cloudflare rack/kooi zien staan. Terwijl Akamai in meerdere DC's in Nederland een rack/kooi hebben.

Bovendien regionale pop's hebben geen zin als aanval IP gericht is.

Met roundrobin/loadbalancing op domein heb je invloed waar je aanval heen laat gaan.

Maar bij IP gericht aanval krijg je ergens dat verkeer binnen en 600Gb/s filter je er niet zomaar uit, je core routers zullen er moeite mee hebben. Vergeet niet dat je ook gewoon je andere regulier verkeer ook hebt.


Nogmaals peering is voor een content partij geen probleem.
Akamai deed (doet?) o.a. Microsoft dus er is geen enkele ISP die niet gratis met Akamai wil peeren via een exchange point. Omdat het ISP's gewoon GELD kost indien ze het niet doen.

Je weet wel het verschil tussen transit en peer verkeer?

Even voor degene die het niet weten.

Providers kun je grofweg in 2 partijen onderbrengen.
Degene met veel eindgebruikers (je ADSL/Kabel provider) en degene die content hebben (webhosting bedrijven, cloud en cdn leveranciers).

Zodra jij iets bezoekt zoals Tweakers.Net loopt er verkeer tussen jouw systeem over infra van je ISP via bepaalde knooppunten naar Tweakers ISP. Als jouw ISP geen afspraken heeft met Tweakers ISP (het zogenaamde peering agreement) dan betaald jouw ISP voor het verkeer van/naar Tweakers.

Nederland was het eerste land buiten de VS die een verbinding had met APRANET (voorloper van Internet) en in die hoedanigheid hadden wij als eerste een EXCHANGE POINT (AMS-IX). Voor Europese bedrijven en universiteiten was het goedkoper om via AMS-IX toegang te verkrijgen dan
zelf kabels naar Amerika te leggen of via hun eigen nationale telecomoperator verkeer naar Amerika te laten gaan (zogenaamde transit verkeer).

Uiteindelijk heeft iemand heel wijs besloten dat ze tegen kostprijs (prijs infrastructuur/hardware) verkeer gratis met elkaar te delen.

Telco's die aan transit verkeer verdienden deden daar heel moeilijk over. Totdat ze erachter kwamen dat ze veel geld kwijt waren aan transit verkeer.

Een voorbeeld uit het verleden is Vuurwerk. Die had veel mot met KPN (digitale telefoonboek.. lang verhaal, Hoi Sander) maar ze waren destijds de grootste webhosting partij van Nederland. Dus veel KPN klanten haalden daar content op en daar betaalde KPN zelf dus ook voor. Uiteindelijk zijn ze via een exchange point een peering agreement aangegaan zodat verkeer gratis heen en weer kon.

Zo zijn er andere voorbeelden, zoals fysieke PoP (point of presence) op de Kabelweg in Amsterdam (HQ UPC) waar meerdere partijen binnen kwamen maar daar niet onderling peerden... terwijl kabels letterlijk op meters van elkaar lagen.

Even totaal niet technisch. Stel je hebt een buurman en in plaats dat jij gewoon aan gaat bellen en gaat praten met hem, ga je eerst met de auto naar een andere wijk/stad rijden naar een vriend van je buurman en praat met hem en omgekeerd gebeurd het zelfde. Die kosten (en tijd = latency) is dus transit.

[Reactie gewijzigd door totaalgeenhard op 23 juli 2024 22:46]

[GrooV]

Als je Anycast routing gebruikt hebben alle servers de zelfde IP adressen, dan kan je wel van uit Rusland de US gaan DDOS'en maar dan kom je gewoon in Moskou uit en blijft de US gewoon doordraaien.

Daarnaast heeft Cloudflare itt Akamai geen data, het enige wat ze doen is een reverse proxy aanbieden. Daar heb je maar een paar servers per PoP voor nodig.

Misschien even lezen wat CF nou echt doet ipv lange posts te typen met zinloze datacenter informatie en internet geschiedenis?

[Reactie gewijzigd door GrooV op 23 juli 2024 22:46]

[totaalgeenhard]

Niet als je GRE gebruikt.

[i-chat]

neej want meer PoP's betekend gewoon dat er meer henks en ingrids en gert en hermiens worden gekaapt om in een botnet te dienen zodat de dDoS'en nog groter worden,

de enige echte oplossing is om deze mensen aansprakelijk te maken voor de kosten, niet alleen de bandbreedte maar ook overige kosten. nu zult je zeggen ja maar niet iedereen kan of wil de kennis hebben om zijn pc veilig te houden, en dan zeg ik, als ik thuis aan een gasleiding ga lassen en ik blaas het hele blok op, dan kome mijn buren ook klagen, als ik zonder rijbewijs in de auto stap en iemand uit zijn schoen rijd, dan ben ik ook ten volle verantwoordleijk: ja maar ik kan niet autorijden is dan echt geen excuus, dat zou het bij computergebruik ook niet mogen zijn, hoe ingeburgerd het ook moge lijken,

[GrooV]

Deze aanvallen gebruiken amplification methodes, geen henk en ingrids meer

[Armin]

Het lijtk er nu net op dat deze aanval juist weer wél Henk en Ingrid's gebruikt.

Filteren is dan daarom ook lastig, want bij DNS versterking, kun je je richten op DNS verkeer. Maar bij Henk en Ingrid is hun verkeer vrijwel identiek aan een legitieme gebruiker.

[the_stickie]

Hun core business is content delivery, niet ddos protection. Bovendien kost het, los van de hardware, een pak poen om een getargete aanval af te slaan. Security engineers 24/7 en bandbreedte alleen kost voor zo'n aanval duizenden dollars/euros.

Ik vind het niet vreemd dat Akamai dit niet gratis wil blijven doen (en anderzijds ook niet vreemd dat Krebs hier niet wil voor opdraaien)

[xelnaha]

Incorrect,

in 2014 heeft Akamai Prolexic opgekocht (wat deze service is) en daarna is het dus WEL onderdeel gaan uitmaken van hun core business:

https://en.wikipedia.org/wiki/Prolexic_Technologies

[the_stickie]

Maar het niet zo dat als je hosting afneemt bij Akamai dat je services automagisch ddos protection krijgen. Je hebt wel gelijk dat Akamai dit ook aanbiedt, maar zover ik weet zijn deze services niet geïntegreerd.

[Armin]

Alleen nam Krebs Prolexic af

Al schijnt het voor hem gratis te zijn. Doch het is wel degelijk slechte reclame voor Akamai, want Krebs is een begrip in dat wereldje.Nu blijft bij iedereen hangen dat het kennelijk toch te veel was voor Akamai. Misschien niet technisch, maar wel qua kosten. Kennelijk doet dit Akamai dus toch pijn. Ofwel DDoS aanvallen hebben effect bij Akamai is de boodschap!

Toen Lizzard Squad een jaar of twee geleden Amazon aanviel, merkte niemand wat, en was de boodschap van Amazon achteraf dat ze niet eens capaciteit hoefde bij te plaatsen. Dat is goede PR.

[NSG]

Ik ga ervan uit dat de grootste klanten toch wel betalen voor de diensten, in tegenstelling tot Krebs.

[totaalgeenhard]

Maar dan nog.

Als je een klant hebt die door zijn content een aanval uit lokt kun je maar heel weinig doen.

Je kunt veel tijd en energie stoppen in wegnemen van de aanvallende nodes (die als proxy dienen voor dader).

Maar als andere ISP's niet hun abuse lezen/reageren of actie ondernemen blijft aanval doorgaan.

Ondertussen heeft je de rest van je infrastructuur er last van dus ook je andere klanten.

Dus laatste remedie is klant verzoeken om naar je concurrent te gaan

Overigens is het vaak niet meteen duidelijk waarom iemand een aanval heeft uitgelokt.

Als iemand op whatsapp ruzie met een ander heeft, dan zie je het aan de content op diens site niet terug wat de reden is.

In geval van een wikileaks (cable leaks) was reden zeer duidelijk.

[Anoniem: 525224]

Ze zijn er toe wel in staat, maar vinden het financieel niet rendabel.

Een bekend blog beschermen is goed.. Veel goed uitgeven omdat een paar kinderen per sé hun dingetje moesten uittesten.. is niet goed. (al zijn het geen kinderen, is het gedrag wel kinderlijk)

[NLsandman]

Akiamai kan wel ddos doorstaan alleen is dit een uitzonderlijke aanval, zulke aanvallen zijn heel zeldzaam.
Ze zullen nu hun netwerk geschikt maken om dit type aanval te doorstaan maar kunnen ze nu niet het risico nemen dat er weer zulke aanvallen komen op krebs zodat hun betalende klanten in gevaar komen die veel geld betalen voor ddos maatregelen.
Krebs maakte gratis gebruik van akamai.

Trouwens diegenen die deze aanval uitvoerden weten donders goed wat akamai aan kan, toegeven of niet, als bepaalde mensen iets offline willen hebben gaan ze net zo lang door tot het lukt.

[PolarBear]

krebsonsecurity.com verwijst in iedergeval naar 127.0.0.1 inmiddels.

[born4trance]

M.a.w. DDoS komt uit bij jezelf

[walkstyle]

Ik denk dat hij offline is gegaan door een loop probleem...

[born4trance]

Ahh, het adres resolved inmiddels naar 54.72.9.51 (ec2-54-72-9-51.eu-west-1.compute.amazonaws.com).

[Reactie gewijzigd door born4trance op 23 juli 2024 22:46]

[Terr-E]

Bijna; DoS komt uit bij jezelf. Het is niet langer Distributed.

[born4trance]

Goed opgemerkt

[WhatsappHack]

Dat is mogelijk een bekende techniek. FreeNode IRC bijvoorbeeld doet dit ook vaak bij grootschalige aanvallen. Het idee is dat een "dom" script enkel het eerste resultaat uit de round-robin pakt, en inderdaad zichzelf gaat DoS'en. Normale clients merken echter dat verbinden niet lukt, en springen direct of bij een tweede poging door naar een daadwerkelijk IP-adres. Zo'n script's doel is het offline halen en gaat gewoon zonder pardon pakketjes sturen en interesseert het niet of ze wel of niet aankomen, dus DoS't enkel zichzelf. Slimmere scripts werken daar omheen uiteraard.

Bijzonder effectief is het niet, maar het helpt toch verbazingwekkend goed tegen kiddies.

Ik weet niet of dit uit dezelfde gedachte was hoor Als het enige record 127.0.0.1 was: dan duidelijk niet. Kan het niet zien nu op mobiel, maar dacht misschien is 't een leuke toevoeging.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[Thomqa]

Het gebruik van internet-of-things-apparaten voor dit soort toepassingen is inderdaad een gevaarlijke ontwikkeling.

[Reactie gewijzigd door Thomqa op 23 juli 2024 22:46]

[Anoniem: 427499]

Dat lijkt me toch aardig voorspelbaar als 'elk' apparaat via internet benaderbaar is. Iets met kwetsbaarheden en gebruikers die geen patches doorvoeren ;')

[hackerhater]

Dat een apparaat een IPv6-adres heeft betekend niet perse dat ie van buitenaf bereikbaar is.
Daar zijn netwerk-firewalls voor.

[Dreamvoid]

Op zich is dit in een ipv6 wereld niet zo heel erg, als je als ISP merkt dat een IoT apparaat (dat een uniek ipv6 adres heeft) een bot is (oftewel, deel is van een DDOS aanval), kan je hem gewoon afsluiten van internettoegang. Dat is een erg drastische maatregel voor een PC of laptop (je haalt 1 of andere bejaarde offline die van niks weet), maar met IoT apparaten die door bedrijven worden beheerd is het gewoon een kwestie van de geinfecteerde bot vervangen/resetten. Op die manier is elke DDOS aanval een 'zelfmoord aanval' voor een botnet, elke bot die meedoet gaat na de aanval direct verloren.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 22:46]

[Zer0]

Het klinkt allemaal lekker makkelijk, maar het wordt dan wel een administratieve rompslomp.
Providers moeten dan op IPv6 adres gaan blokkeren, en deze dus administreren, en eind-gebruikers moeten deze blokkering weer op gaan heffen na het verwijderen van de bot, of het device compleet vervangen.

Dat is een erg drastische maatregel voor een PC of laptop (je haalt 1 of andere bejaarde offline die van niks weet),

En hoe gaat de ISP weten dat het om een IPv6 adres van een IoT device gaat en niet de laptop van mijn oma

[Dreamvoid]

Dat weet je niet, maar op een gegeven moment zijn er zoveel IoT devices, dat hackers zich nauwelijks meer op die paar PC's van ouwe oma's gaan richten.

[doogster]

Verontrustend bericht. Dit betekent dat er een organisatie is die ontzettend veel zombies tot haar beschikking heeft. Als zelfs IoT devices gebruikt worden ga je je toch afvragen of de ontwikkelingen (de snelle adoptie) op dit gebied wel wenselijk zijn.

[WhatsappHack]

"Zelfs IoT"?
Ik vind dat juist een van de meest logische vectors... Veel van die devices hangen maar wat, krijgen zelden of nooit updates en pentests wijzen uit dat veel echt kak security hebben. Ze worden zelfs ingezet om je internetverkeer af te tappen, daarom zet je IoT devices die naar buiten babbellen ook het liefst op een gast netwerk...

We hadden al gezien dat ze bitcoinminers op koelkasten kunnen draaien, dan is dit geen rare ontwikkeling.

[Anoniem: 525224]

Dat zijn ze ook niet.. maar met name landen als Nederland bloeien op trends en hypes.

Het is een hype.. zal wel nog een tijdje door blijven groeien, totdat mensen erachter komen dat het best wel een slecht ding is 99/100 keren.

[Anoniem: 582717]

Het aantal zombies valt wel mee vermoedelijk, maar de zombies die deze aanval gebruik maken maken misbruik van amplification.

https://www.us-cert.gov/ncas/alerts/TA14-017A

[WhatsappHack]

Volgens het artikel wordt er juist helemaal geen gebruik gemaakt van amplification...

[Anoniem: 582717]

Op zich hoef je niet een heel groot botnet te hebben om de boel plat te leggen via amplification.
het gaat er meer om hoeveel foutief geconfigureerde dns server aan het internet hangen en hoeveel van deze foutieve geconfigureerde dns servers bekend zijn bij het botnet.

De dns amplification factor is slechts 28 to 54 keer de size van het inkomende pakket, echter met dns heb je wel de grootste kans dat ze aan het internet hangen.

Neem je echter ntp dan heb je een amplification factor van 556 keer je size van je inkomende pakket.

Je zou die beheerders op hun kop moeten geven dat ze nog steeds hun dns servers niet hebben bijgewerkt naar een goede versie. Deze "faciliteren" nu een soort van deze aanval.

https://www.us-cert.gov/ncas/alerts/TA14-017A

[Reactie gewijzigd door Anoniem: 582717 op 23 juli 2024 22:46]

[WhatsappHack]

Dat is allemaal leuk en aardig, maar het hele probleem bij deze aanval is dat het geen amplification gebruikt, maar dat de totale capaciteit rechtstreeks vanuit het botnet kwam. En dat is behoorlijk ongekend en een zeer zieke capaciteit voor een botnet...

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[the_stickie]

Cloudflare zal maar wat graag Krebs helpen. Anders dan Akamai is ddos protection hun core business. Dus niet alleen is het mooie reclame om deze zeer gekende specialist te helpen, ze krijgen er ineens een paar leuke testcases bij terwijl de impact op hun infrastructuur waarschijnlijk beperkt is. Ze moeten nu ook al zorgen dat ze veel meer verkeer kunnen slikken, al was het maar voor een aantal klanten!

[Blokker_1999]

Ik denk niet dat zij staan te springen. Het is een aanval van ongekende hoogte waar elk netwerk het moeilijk mee gaat krijgen.Je gaat ook niet zomaar een klant binnenhalen waarvan je weet dat die je ongelooflijk veel geld kan gaan kosten.

[Armin]

Ik denk niet dat zij staan te springen

De CEO bood het aan

Maar het is enorme PR. Krebs is een begrip in die wereld, dus hem beschermen is goede PR. (Bovendien is een publiek geheim, o.a. gerapporteerd op Krebs, dat CloudFlare ook soms de andere kant beschermt tegen aanvallen van DDoS groepen onderling Dus ze zijn wel bekend met dit wereldje )

Maar als dit bericht waar is, wordt he nog interessant, want deze aanval schijnt (deels) niet te bestaan uit klassiek DDoS zoals DNS versterking, maar botnets. Die laatste doen echte HTTP transacties die veel moeilijker van nep te onderscheiden zijn. Filteren is dan lastiger, en verspreiden van de load is het enige/hoofd wapen.

[WhatsappHack]

Dit kan CloudFlare absoluut niet aan. Die gaan het niet aanbieden denk ik... Ze hebben vroeger eens geprobeerd spamhaus te beveiligen. Daar hadden ze moeite mee, en hebben toen gelogen over hoe groot die aanval was om te doen alsof het een wereldrecord was en 't daarom moeilijk was...

AKAMAI's overflow CDN is ook vele malen groter dan die van CloudFlare, dus kunnen meer DDoS verkeer opvangen dan CloudFlare; al is het niet hun core business. Als zelfs AKAMAI ermee stopt, al is t omdat het te duur wordt om gratis te doen, dan denk ik niet dat CF veel kans maakt... Maar goed

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[the_stickie]

Punt is niet de grootte van het cdn, danwel de sizing van de endpoints. Anders gezegd: Akamai heeft dan wel meer content servers (die ook nog eens geeografisch beter gespreid zijn), maar bij cloudflare ligt de focus net op de toegangspunten en hun bandbreedte en filtering die daar gebeurt gecombineerd met technologie om valide clients te detecteren.

Het is inderdaad zo dat Cloudflare graag uitpakt met cijfers mbt de aanvallen, dat is voor hen gewoon marketing.

De overgebleven vraag (gesteld dat je gelijk hebt dat Cloudflare dit niet aankan, waar ik het niet direct mee eens ben) is dan: welke partij kan wel beschermen tegen zo'n aanvallen? En als die er niet is (Akamai en Cloudflare zijn nu niet bepaalld de kleintjes in deze markt), is dit dan het einde van het (open) internet.

Overigens maakt Cloudflare er punt van adaptief te zijn, en dus hun netwerk continu te versterken en aan te passen nav voorbije 'security events'. 't zou dus net wél een knap staaltje (marketing...) zijn mochten ze Krebs een veilige haven kunnen/willen bieden.

[Reactie gewijzigd door the_stickie op 23 juli 2024 22:46]

[WhatsappHack]

Ik snap alleen dit niet:

Martin McKeay van Akamai heeft aan Krebs uitgelegd dat het om een zeer ongebruikelijke manier van aanvallen gaat en dat dit soort aanvallen pas recentelijk opduikt.

Hoezo ongebruikelijk? Dit is toch precies het type aanval dat we hadden voordat amplification populair werd. Gewoon losse zombies die pakketjes over en weer knallen, zonder reflection/amplification; dus rechtstreeks de host aanvallen. Het is gewoon weer iets ouds dat terug in de mode komt omdat het kan, blijkbaar.

Dus of er mist een stukje uitleg in dit artikel, of we zien nu gewoon hoe een oude welbekende techniek nu weer populair is omdat ze een manier hebben gevonden om de capaciteit *extreem* op te schroeven itt hoe het eerst was. o0

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:46]

[TheBlackbird]

Van IoT wordt al lang gewaarschuwd dat er ernstige veiligheidsrisico's zijn. Niemand ligt er voorlopig wakker van. 't Zal duren tot er elke week verschillende terabit/s DDoS'en opduiken met grote financiële gevolgen. Immers: enkel het verlies van geld zet een mens aan tot verandering.

Suggestie: bedrijven die onveilige IoT-apparaten maken DDoS'en door middel van hun eigen IoT-apparaten. Dan wordt de kost gedragen door zij die ze maken. (Dit is geen ernstige oproep, niet doen dus.)

[Reactie gewijzigd door TheBlackbird op 23 juli 2024 22:46]

[Dreamvoid]

Haha, ik denk eerder dat ISP's en hosting bedrijven de kosten gaan verhalen op de fabrikanten van die devices.