Route hijacking en DDoS: hoe een BGP-incident uitval veroorzaakt

Het probleem definiëren

Een origin hijack is een verkeerde AS-origin voor een prefix.

Een more-specific of route leak kan verkeer aantrekken en het pad breken.

Het gevaar is dat de dienst intern gezond lijkt. Servers en firewalls tonen normale waarden, omdat verkeer al is omgeleid.

Om route hijacking en BGP-beveiliging te beoordelen moet je drie lagen scheiden: het BGP-signaal, het echte verkeer en de gebruikerservaring. Als je die mengt, lijkt de sessie stabiel terwijl bruikbaar verkeer een ander pad neemt of verdwijnt in een te brede filterregel.

Technische kopers zien snel of een aanbieder alleen marketingwoorden gebruikt of de grenzen van zijn architectuur kent. Bij DDoS is eerlijkheid over grenzen juist een vertrouwenssignaal.

Waarom dit belangrijk is

Veel DDoS-plannen veronderstellen dat verkeer bij mitigatie aankomt.

Als routing faalt, tonen scrubbinggraphs soms niets terwijl gebruikers offline zijn.

Een aanvaller heeft geen enorme packet rate nodig als hij bereikbaarheid kan manipuleren. Een kort routingincident veroorzaakt zichtbare downtime en verwart incident response.

Financiële schade ontstaat niet alleen bij totale uitval. Gedeeltelijke incidenten zijn vaak lastiger: sommige providers bereiken de dienst wel, andere niet; bepaalde landen zien hogere latency; gamesessies vallen weg; support krijgt klachten die moeilijk te reproduceren zijn.

Voor SEO en verkoop trekt deze uitleg betere leads aan. Een serieuze klant zoekt niet alleen een Tbps-cijfer, maar wil weten of routing, handoff-limieten, false positives en continuïteit echt begrepen worden.

Voor Nederlandstalige technische kopers tellen concrete grenzen meer dan capaciteitsclaims. Een artikel moet tonen hoe beslissingen worden genomen, welke aannames getest worden en hoe de dienst bij fouten terugkeert naar een veilige toestand.

Die extra voorbereiding loont omdat storingen korter worden en de klant ziet dat bescherming niet alleen uit marketingcijfers bestaat.

Zo wordt routing security een echt onderdeel van beschikbaarheid.

Mogelijke oplossingen

Routinghygiëne: IRR, AS-SET, prefix-limits en filters.

RPKI/ROA beperkt ongeldige origins wanneer validatie wordt toegepast.

Externe monitoring detecteert origin changes en more-specifics.

RPKI moet samen met monitoring. Een geldige ROA helpt weinig zonder alert op concurrerende origins, en monitoring zonder escalatiecontacten bevestigt alleen sneller de storing.

Een technische actie heeft een procedure nodig: welke metric triggert, welk bewijs is vereist, wie of welk systeem mag handelen, maximale duur en de voorwaarde voor terugdraaiing. Zonder grenzen wordt een nuttige tool een operationeel risico.

Maak ook onderscheid tussen noodmaatregel en permanent ontwerp. Een agressieve actie kan tien minuten acceptabel zijn om capaciteit te redden, maar mag zonder review geen vaste configuratie worden. Normaal verkeer verandert per tijdstip, land, game en clientversie.

Het ontwerp heeft acceptatiecriteria nodig: verwachte latency, maximaal pakketverlies tijdens mitigatie, handoff-capaciteit, escalatiecontacten en exacte voorwaarden voor disruptieve maatregelen.

Daarnaast heeft elk ontwerp een eenvoudig testplan nodig: routes extern controleren, handoff-bandbreedte meten, latency vergelijken, escalatie testen en documenteren welke wijziging bij nood als eerste wordt teruggedraaid.

Juist bij route hijacking is snelheid belangrijk: een nette contactlijst, voorbereid bewijs en bekende routing objects maken escalatie veel korter.

Route hijacks detecteren en beperken vóór uitval

Peeryx neemt routing security mee in protected transit.

Voor activatie moeten ASN, AS-SET, limieten en ROA duidelijk zijn.

Tijdens incidenten moet diagnose ook het control-plane BGP controleren.

Peeryx neemt route security mee in activatie. Prefix-eigendom, AS-SET, route objects en verwachte origins worden gecontroleerd vóór kritieke productie.

De waarde van een gespecialiseerde provider zit in het koppelen van beslissingen aan echt transport: BGP, tunnels, cross-connect, prefixes, sessielimieten en capaciteit. Mitigatie mag niet losstaan van het pad vóór en na filtering.

Bij Peeryx moet de klant zijn architectuur simpel kunnen uitleggen: waar verkeer binnenkomt, welke laag schoonmaakt, wat upstream wordt gefilterd, wat lokaal wordt beslist en hoe legitiem verkeer terugkomt. Als dat niet helder is, is het ontwerp niet klaar.

In de praktijk vertaalt Peeryx deze onderwerpen naar simpele beslissingen: welk prefix wordt beschermd, welk verkeer is normaal, welk patroon geldt als aanval en welke actie hoort bij welke drempel.

Zo ontstaat een verkoopargument dat technisch houdbaar is: niet alleen grote mitigatiecapaciteit, maar een begrijpelijk pad voor legitiem verkeer, begrensde ingrepen tijdens de aanval en een duidelijke terugkeer naar normaal bedrijf.

Concreet voorbeeld

Een hoster annonceert een /24 via mitigatie, maar een ander AS annonceert verkeerd hetzelfde prefix.

Met ROA, filters en alerts wordt het incident sneller gezien.

Hetzelfde helpt bij geplande wijzigingen. Bij migratie naar protected transit bevestigt externe zichtbaarheid dat Internet de verwachte origin ziet.

Voor productie horen gecontroleerde tests: een route terugtrekken, een tunnel wisselen, latency meten via meerdere providers en controleren of logs veranderen bij padwijziging. Die voorbereiding bespaart minuten tijdens een echte aanval.

Dit detail helpt ook bij providers vergelijken. Twee aanbiedingen lijken qua prijs gelijk, maar slechts één heeft heldere BGP-integratie, gedocumenteerde regels en voldoende handoff.

Veelgemaakte fouten

De fout is routing security los zien van DDoS.

Een veelgemaakte fout is een te brede ROA max-length. Dat maakt operatie makkelijker, maar verzwakt bescherming tegen ongeautoriseerde specifiekere aankondigingen.

Optimaliseren voor de installatiedag is niet genoeg. Het ontwerp moet maanden later nog begrijpelijk zijn wanneer klanten, prefixes, een tweede transit of een nieuwe PoP worden toegevoegd. Operationele documentatie is onderdeel van bescherming.

Een veelgemaakte fout is na de eerste installatie niet opnieuw testen. Elke nieuwe route, tunnel en klant kan aannames veranderen.

Wie dit niet vooraf beschrijft, moet het onder aanvalsstress bedenken. Juist daar ontstaan de duurste fouten.

• ROA max-length te breed.
• IRR/AS-SET niet onderhouden.
• Geen prefix-limits.
• Alleen servers monitoren.

FAQ