BGP Blackhole vs BGP FlowSpec: het juiste DDoS-filter kiezen

Het probleem definiëren

RTBH kondigt een speciale route aan om verkeer naar een IP of prefix te verwerpen. Het is simpel en breed ondersteund, maar de dienst is offline.

FlowSpec vervoert filterregels via BGP. Die precisie is krachtig, maar een te brede regel kan echte gebruikers stil blokkeren.

Het operationele verschil zie je bij saturatie. Blackhole verandert bereikbaarheid van een bestemming; FlowSpec verandert pakketbehandeling in de routing-infrastructuur. Daarom heeft elke FlowSpec-regel vertrouwen nodig: stabiele velden, normaal gebruikersgedrag en een actie die snel teruggedraaid kan worden.

Om blackhole en FlowSpec 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

Een verkeerde keuze kan duurder zijn dan de aanval. Blackhole voorkomt saturatie maar veroorzaakt uitval. Een slechte FlowSpec-regel kan grafieken goed laten lijken terwijl gebruikers falen.

Bij protected transit betaalt de klant voor bereikbaarheid. Beslissingen moeten gebaseerd zijn op pps, Gbps, poorten, pakketprofiel en stabiliteit van de signature.

Een runbook moet bepalen wie upstream regels mag propageren. Een lokale drop is snel getest; upstream FlowSpec raakt een groter domein. Voor netwerken met klantverkeer horen goedkeuring, logging en vervaltijd bij het product.

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.

Mogelijke oplossingen

Handmatige RTBH is de noodrem als een bestemming andere klanten bedreigt.

Handmatige FlowSpec werkt voor stabiele aanvallen met duidelijke kenmerken, maar is traag.

Een volwassen model gebruikt gecontroleerde automatisering met drempels, korte regels, vervaltijd, monitoring en blackhole alleen als laatste redmiddel.

Soms is rate-limit veiliger dan discard. Als aanval en legitiem verkeer overlappen, verlaagt een tijdelijke policer de druk terwijl captures en metrics een strengere regel bevestigen.

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.

Blackhole of FlowSpec kiezen zonder legitiem verkeer te raken

Peeryx gebruikt FlowSpec om upstreamvolume te verlagen, niet om de hele DDoS-stack te vervangen.

Een goede regel combineert bestemming, protocol, poortreeksen, pakketlengte en trafficcontext. Ze is tijdelijk en omkeerbaar.

Schoon verkeer wordt geleverd via GRE, IPIP, VXLAN, router VM of cross-connect, zodat het netwerkmodel begrijpelijk blijft.

Peeryx scheidt ruw volumebeheer van dienstgerichte beslissingen. Upstream-tools verlagen de vloed; lokale mitigatie behoudt context en voorkomt zelf veroorzaakte uitval.

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 gameserver ontvangt 80 Gbps UDP. Blackhole stopt saturatie maar disconnect iedereen.

Een betere regel combineert pakketlengte, bronpoorten, pps/Gbps-ratio en fragmenten, zodat aanval verdwijnt en echte clients blijven.

Hetzelfde geldt voor TCP-floods. Een regel op flags helpt bij abnormale SYN- of ACK-patronen, maar moet naast normaal verbindingsgedrag worden gelegd.

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

Fouten ontstaan vaak door snel te handelen zonder bewijs.

Een andere fout is klantcommunicatie vergeten. Bij blackhole moet de klant weten dat bereikbaarheid bewust wordt opgeofferd; bij FlowSpec dat de regel tijdelijk en bewaakt is.

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.

• FlowSpec behandelen als applicatiefirewall.
• Regels actief laten na de aanval.
• Filteren op één veld.
• Een heel prefix blackholen voor één IP.
• Legitiem verkeer niet meten voor en na de regel.

FAQ