Drie dagen in augustus: wat een DDoS-aanval onthulde over ons netwerk

Op de avond van 11 augustus 2026 werd een van onze klanten het doelwit van een van de grootste aanvallen die we ooit op onze infrastructuur hebben gezien. Omdat wij de internetverbinding van deze klant verzorgen, trof de impact ons direct. Een paar uur later richtte de aanvaller zich ook op onze eigen diensten. We hebben reeds een technisch postmortem van dit incident als PDF gepubliceerd. In dit artikel willen we dieper ingaan op wat er precies is gebeurd tijdens deze drie dagen, waarom het afhandelen van een aanval van deze omvang zoveel tijd in beslag nam en wat we sindsdien in onze infrastructuur hebben aangepast.

Een aanval die onze eigen capaciteit oversteeg

Om de schaal in perspectief te plaatsen: we schatten dat er een piekvolume van 500 tot 600 Gbit/s ons netwerk en de getroffen klant raakte, verspreid over al onze verbindingen samen. Twee van onze upstream-providers bevestigden dat 260 Gbit/s daarvan direct via hen liep. Dit is meerdere malen meer dan onze eigen uplinks in eerste instantie kunnen verwerken, ongeacht hoe goed de verdedigingen binnen ons eigen netwerk zijn ingericht.

Gedurende het incident werden verschillende diensten op verschillende momenten beïnvloed: elke applicatie op Deploio, onze eigen website, Cockpit en ons ticketsysteem. Het is belangrijk om te benadrukken dat dit geen enkele, continue uitval van 42 uur was, maar een reeks golven met periodes van normaal functioneren ertussen. Van dinsdagavond rond 19:15 uur tot donderdag rond 12:51 uur bleven deze golven terugkeren, telkens met verschuivende doelwitten en variërende intensiteit.

Eén ding stond gedurende het hele proces vast: de veiligheid van uw gegevens. Er was geen sprake van ongeautoriseerde toegang en er zijn geen systemen gecompromitteerd. Dit was een overload-aanval, geen inbraak.

Bevestigd door externe telemetrie

Onafhankelijke telemetrie van het threat research-team van Nokia Deepfield bevestigt onze eigen analyse van de gebeurtenissen. Hun sensoren zijn geregistreerd als bots op dezelfde command-and-control (C2) servers die de aanvallers gebruikten, waardoor ze de werkelijke aanvalscommando's kunnen loggen op het moment dat ze worden verzonden, en niet alleen het verkeer dat later bij een doelwit arriveert.

Deze data tonen aan dat er twee botnet-families bij betrokken waren, CECbot en Katana. Ook bevestigen ze de volgorde die we zelf hebben waargenomen: de aanval richtte zich eerst direct op onze klant en breidde zich pas ongeveer drie uur later uit naar de infrastructuur van Nine. Dit is precies wat je zou verwachten als we werden geraakt omdat we de internetverbinding van die klant verzorgen, en niet omdat we het eigenlijke doelwit waren.

Daarnaast kwam een detail naar boven dat vermeldenswaardig is: onze klant kondigt zijn adresblok aan via twee verschillende providers (ons en één andere). Iedereen die deze aanval zou proberen te filteren of te attribueren door alleen naar ons netwerk te kijken, zou dus slechts de helft van het beeld zien. De data van Nokia attribueert de aanval niet aan een specifieke actor, en wij doen dat ook niet.

Hoe een aanval als deze precies werkt

De aanvallers maakten gebruik van een techniek genaamd UDP-amplificatie. In eenvoudige termen: je stuurt kleine verzoeken naar open diensten op het internet, maar in plaats van je eigen adres als afzender te gebruiken, vervals je (spoof) het adres van het slachtoffer. De reactie, die vele malen groter is dan het oorspronkelijke verzoek, komt dan niet bij de aanvaller terecht, maar direct bij het doelwit. Een relatief kleine hoeveelheid van de eigen bandbreedte van de aanvaller verandert zo in een massief aanvalsvolume, verspreid over tienduizenden bronnen wereldwijd. (Voor gedetailleerde mechanieken verwijzen we naar CISA onder "UDP-Based Amplification Attacks").

Het cruciale punt hierbij is: zodra je eigen internet-uplink vol is, helpt filteren binnen je eigen netwerk niet meer. De pakketten die je wilt wegfilteren hebben de lijn al verstopt op het moment dat ze je filter bereiken, samen met al het legitieme verkeer dat dezelfde lijn probeert te gebruiken. Vanaf dat moment moet mitigatie verder stroomopwaarts plaatsvinden, bij de providers die het verkeer naar jou transporteren.

Het instrument hiervoor is blackholing. We vragen onze upstream-providers om al het verkeer dat bestemd is voor een specifiek adres volledig te stoppen en te droppen in plaats van het aan ons te leveren. Dit beschermt betrouwbaar het hele netwerk en elke klant die niets met de aanval te maken heeft. De prijs hiervoor is dat het getroffen adres tijdens die tijd bewust onbereikbaar wordt voor iedereen, inclusief echte bezoekers. In veel gevallen tijdens dit incident was dat de feitelijke reden dat een applicatie offline was; niet omdat er iets kapot was, maar omdat we dat ene adres opofferden om de rest stabiel te houden.

De aanvaller gaf echter niet op. Wanneer we onze eigen website naar een nieuw IP-adres verplaatsten, werd dat nieuwe adres binnen enkele minuten opnieuw aangevallen. Bovendien ging het niet alleen om puur volume: het enorme aantal verzoeken was op zichzelf al genoeg om individuele diensten te overbelasten, ongeacht de bandbreedte. Dat vereiste een ander instrument dan blackholing; een tool die legitiem verkeer kan onderscheiden van kwaadaardig verkeer in plaats van beide onverschillig te blokkeren.

De weg terug naar beschikbaarheid

Dit is waar de maatregel die het incident uiteindelijk beëindigde, in beeld kwam. Toen duidelijk werd dat blackholing alleen niet stand zou houden tegen een aanvaller die ons ook raakte via het volume aan verzoeken, begonnen we onze blootgestelde applicaties achter bunny.net te plaatsen (een Europese CDN met ingebouwde DDoS-bescherming). Dit startte we één dag na het begin van het incident en was de volgende dag voltooid. Tegelijkertijd evalueerde en implementeerde onze klant aanvullende beschermingsmaatregelen aan hun zijde. Sindsdien stopt het aanvalsverkeer bij de beschermingsprovider, terwijl legitieme verzoeken ons nog steeds bereiken.

Eén ding dat ons concreet hielp tijdens deze drie dagen: omdat we ons eigen netwerk beheren, konden we direct wijzigingen in de routing doorvoeren terwijl de aanval nog gaande was. We konden aanvullende beschermingsmaatregelen coördineren zonder te hoeven wachten op wijzigingen in externe netwerkinfrastructuren van derden. Dit is mede de reden waarom een aanval van deze omvang niet is uitgelopen op een totale uitval van meerdere dagen.

Drie tekortkomingen die we hebben gevonden

We hebben tijdens dit incident drie concrete tekortkomingen gevonden, en we kiezen ervoor hier open over te zijn.

1. Onvolledige automatische detectie: Onze geautomatiseerde aanvalsdetectie was alleen ingesteld op onze eigen adressen. Netwerken die we namens een klant aankondigen op het internet, maar die eigendom zijn van de klant, maakten geen deel uit van die automatisering. De allereerste golf raakte precies zo'n netwerk, waardoor het ongeveer 90 minuten aan handmatige mitigatie kostte om het in te dammen. We hebben dit gat dezelfde avond gedicht.
2. Verificatie van blackhole-signalen: We hadden nooit systematisch geverifieerd of ons blackhole-signaal daadwerkelijk effect heeft op elk traject dat ons verkeer aflegt. Dit signaal geldt alleen voor peers met wie blackholing vooraf was geconfigureerd, of voor verkeer dat ons bereikt via de route-servers van een internet exchange. Bij de internet exchanges waar we verbonden zijn, hebben we geen dergelijke overeenkomst met onze directe peers; blackholing dekt daar dus alleen verkeer via de route-servers, niet direct uitgewisseld verkeer. Bovendien hadden we nog geen manier om een specifiek netwerk bij slechts één specifieke provider in te houden, dus we moesten die functionaliteit bouwen terwijl de aanval gaande was en we onder volle belasting stonden. Dat werkte, maar het bouwen van een tool tijdens een noodsituatie is altijd trager en risicovoller dan wanneer deze al klaarstaat.
3. Gedeeld platformrisico: Dit was de meest vervelende consequentie voor veel klanten: onze eigen website draait op hetzelfde Deploio-platform als uw applicaties. Wanneer de aanval zich op onze website richtte, werden niet-gerelateerde applicaties op hetzelfde platform automatisch mee getroffen. En omdat Cockpit en ons ticketsysteem later ook direct werden aangevallen, verloren sommige klanten tijdelijk hun applicatie, de mogelijkheid om deze te beheren en een deel van hun manier om ons te bereiken, precies op het moment dat ze ons het hardst nodig hadden.

Wat is er nu anders?

Alle drie de tekortkomingen zijn inmiddels gedicht of wordt er actief aan gewerkt.

• Elk klantnetwerk dat we aankondigen, maakt nu automatisch deel uit van onze aanvalsdetectie; dit is nu een vast onderdeel van ons standaardproces.
• Onze blootgestelde applicaties blijven permanent achter de CDN van bunny.net met DDoS-bescherming staan. Het migreren van verdere diensten is nu een voorbereide procedure in plaats van iets dat we onder druk moeten improviseren.
• We monitoren nu de effectiviteit van onze mitigaties over elke verbinding en werken hierbij nauwer samen met onze upstream-providers.
• Omdat we er bewust voor kiezen om onze eigen diensten op het Deploio-platform te laten draaien (hetzelfde platform dat we aan onze klanten aanbieden), werken we aan het vergroten van de veerkracht hiervan. We evolueren de architectuur zodat individuele applicaties minder afhankelijk zijn van gedeelde adressen. Cockpit en het ticketsysteem zijn bovendien extra geharden, zodat u ons ook tijdens een aanval kunt bereiken. Het scenario van dit incident is nu een vast onderdeel van onze reguliere oefeningen.

Wat u zelf kunt doen

Dit incident leidt tot één concreet advies voor iedereen die eigen domeinen op Deploio draait:

Gebruik een CNAME- of ALIAS-record in plaats van een A-record. Een A-record koppelt uw domein aan één specifiek IP-adres op ons platform. Deze vaste binding was precies het probleem tijdens de aanval: waar we het adres op korte termijn konden wijzigen, kon de beschikbaarheid worden hersteld; waar dat niet kon, bleef alleen de botte maatregel (blackholing) over. Bovendien zijn andere applicaties vaak bereikbaar via hetzelfde gedeelde adres, wat precies het risico is dat hierboven wordt beschreven. Dit is primair een architecturaal probleem aan onze zijde waaraan we werken. Tot die tijd is een CNAME of ALIAS de meest effectieve stap die u zelf kunt nemen.

Daarnaast is het aanbevolen om, waar mogelijk, een CDN met eigen DDoS-bescherming voor uw applicatie te plaatsen. Dit is precies wat onze beschikbaarheid heeft hersteld. Voor de meeste setups is de inspanning beheersbaar en de lopende kosten laag.

Mocht u niet zeker weten welke optie bij uw applicatie past, neem dan contact op via support@nine.ch.

Slotwoord

We kunnen een aanval van deze omvang niet volledig voorkomen; dat ligt simpelweg buiten onze controle. Waar we wel invloed op hebben, is hoe snel we reageren en hoe weinig onbetrokken klanten in het kruisvuur terechtkomen. Dat is precies waar we sinds dit incident aan hebben gewerkt. Onze excuses voor het ongemak tijdens deze drie dagen en dank voor uw geduld.