Op deze pagina
Het operationele probleem
FlowSpec ziet headercomponenten: bestemming, protocol, poorten, pakketlengte, TCP-flags en vergelijkbare velden afhankelijk van de provider. Het weet niet of een sessie bij een echte speler, kritieke API of botnet hoort.
Elke upstream heeft limieten voor regelaantal, acties, bestemmingsgranulariteit en ondersteunde velden. Ontwerpen alsof FlowSpec onbeperkt precies is, faalt juist tijdens incidenten.
Waarom dit vóór een aanval telt
Een te brede regel werkt voordat de klant legitieme traffic met eigen logica kan herstellen. De lijn lijkt schoon, maar echte gebruikers kunnen buitengesloten zijn.
Deze beperkingen voorkomen verkeerde verwachtingen. FlowSpec is het sterkst wanneer het zwaar, duidelijk verkeer verwijdert zodat downstreammitigatie met minder druk werkt.
Mogelijke technische aanpakken
Veilig gebruik is FlowSpec als ontlasting: korte regels, concrete bestemming, duidelijk protocol en expiratie. Is het patroon instabiel, probeer dan niet de hele aanval in één regel te beschrijven.
Beslissingen met state, baseline of applicatiekennis horen in DPDK/VPP, XDP, proxy, post-filterregels of gamegerichte logica.
Concreet gebruiksvoorbeeld
Een UDP-flood van 180 Gbps herhaalt poort en grootte richting één IP. Een smalle FlowSpec-regel verlaagt druk vóór de handoff. Een globale UDP-regel op het hele prefix kan DNS, games of monitoring breken.
Correct gebruik is stapsgewijs: duidelijke signature filteren, toegelaten traffic observeren en gemengde resttraffic aan een downstreamlaag met meer context overlaten.
Veelgemaakte fouten vermijden
- Providerlimieten negeren.
