1Tbps DDoS-mitigatie: architectuur, echte limieten en schone traffic handoff

Probleemdefinitie: 1Tbps alleen maakt nog geen goede bescherming

Zeggen dat een provider 1Tbps DDoS-mitigatie heeft, beantwoordt de operationele kernvragen niet. Het getal kan theoretisch, globaal of gedeeld zijn en zegt niets over capaciteit per klant, waar absorptie gebeurt, welke aanvallen worden gedekt of hoe schone traffic terugkomt.

Het echte probleem is architectuur. Traffic moet naar een laag worden getrokken die volume kan absorberen, vroeg kan filteren en daarna compatibel met productie teruglevert. Voor BGP-klanten betekent dat gecontroleerde announcements; voor anderen kunnen beschermde IPs, tunnels of reverse proxies beter passen.

Het verschil tussen marketingbelofte en echte architectuur blijkt tijdens het incident: de klant moet weten of de provider traffic kan beoordelen per prefix, poort, protocol, tunnel of dienst. Zonder die zichtbaarheid helpt het getal 1Tbps niet bij het kiezen van regels of het aanpassen van een pad.

Ruwe capaciteit

Nuttig voor volumetrische absorptie, maar onvoldoende zonder handoffkwaliteit, PPS-limieten en false-positive controle.

PPS en states

Ook minder Gbps kunnen een dienst breken via packets per second, SYN-druk of uitputting van firewallstates.

Schone terugkeer

Legitieme traffic moet terug naar server, router of datacenter zonder vermijdbaar verlies of gevaarlijke asymmetrie.

Waarom dit belangrijk is voor netwerken die van internet afhangen

Wanneer een bedrijf afhankelijk is van publieke internetbereikbaarheid, kunnen enkele minuten downtime duurder zijn dan een maand bescherming. Hosters verliezen vertrouwen, gamingplatforms spelers en SaaS-diensten gebruikers. Bij 1Tbps kan het incident upstreams, poorten, edge-apparatuur en meerdere diensten tegelijk raken.

Plan aantrekking, reductie, filtering en schone aflevering vóór een incident. Leg toegestane prefixen, autorisatie, uitvalsignaal, wijzigingsbevoegdheid en herstelvoorwaarden vast. Test de werkelijke bestemming en terugweg: een opgebouwde tunnel in het dashboard bewijst niet dat een gebruiker de toepassing bereikt.

Dat is ook commercieel belangrijk. Een B2B-koper met budget zoekt niet alleen een maandprijs, maar volwassenheid. Een site die saturatie, handoff, MTU, BGP, FlowSpec, false positives en schone teruglevering uitlegt, wekt meer vertrouwen dan een pagina die alleen capaciteit herhaalt.

Mogelijke oplossingen om een 1Tbps-aanval te absorberen en filteren

Het eerste model is beschermde IP-transit met BGP: de klant annonceert prefixes, de provider trekt traffic aan, filtert de aanval en levert schone traffic terug. Dit past bij operators, hosters, ASN-netwerken en bedrijven die routingcontrole willen houden.

Het tweede model is delivery via GRE, IPIP of VXLAN wanneer server of netwerk bij een andere provider blijft. Cross-connect is vaak schoner bij hoog volume en latency-eisen. Gaming- of applicatieproxies helpen bij FiveM, Minecraft of HTTP, maar vervangen niet altijd upstream L3/L4-filtering.

In de praktijk combineren veel klanten meerdere modellen. Een hoster gebruikt beschermde transit voor prefixes, tunnels voor geleidelijke migraties en reverse proxies voor specifieke gamingdiensten. Belangrijk is die opties niet als concurrenten te tonen, maar als bouwstenen van dezelfde continuïteitsstrategie.

Rekenvoorbeeld: wat bereikt een oplevering van 10 Gbit/s?

Hypothetische capaciteitsberekening, geen gemeten Peeryx-aanval of filterbelofte: de aanval levert 1.000 Gbit/s en de legitieme belasting is 8 Gbit/s. Neem aan dat upstream al het legitieme verkeer behoudt. De percentages tonen het nog aankomende deel van de aanval, niet het geblokkeerde deel. Alle snelheden moeten op dezelfde protocollaag worden geteld.

Als de 10-Gbit/s-verbinding vóór verdere filtering ligt, overschrijden de eerste twee gevallen de nominale snelheid. Het laatste laat slechts 1 Gbit/s nominale marge, nog zonder encapsulatie, bursts, groei of uitvalreserve. Als lokale filtering vóór de oplevering ligt, meet dan de echte uitvoer: deze tabel voorspelt geen filterresultaat. Herhaal het budget bij elk beperkt segment, niet alleen bij de klantpoort.

Een lagere resterende bitrate kan nog steeds veel pakketten of toestandsbelasting veroorzaken. Een upstream-reductiefactor zegt niets over verloren legitieme pakketten, geslaagde spelersverbindingen of applicatieresponstijd. Meet die resultaten afzonderlijk en spreek grenzen af vóór acceptatie van het ontwerp.

• Capaciteit en uitvalreserve plannen ↗
• Een pakketbudget berekenen ↗

Veelgemaakte fouten vóór aankoop van 1Tbps DDoS-mitigatie

De eerste fout is alleen capaciteit vergelijken. Twee providers kunnen 1Tbps noemen, maar één heeft betere handoff, nabijheid, regels en support. De tweede fout is PPS negeren: veel incidenten breken queues, states of workers voordat bandbreedte de limiet raakt.

De derde fout is het retourpad niet testen: MTU, terugroute, tunnelgrootte of asymmetrie kunnen verlies geven terwijl mitigatie werkt. De vierde fout is te agressief filteren waardoor legitieme gebruikers collateral damage worden.

Een andere fout is het normale scenario niet documenteren. Vóór een aanval moet duidelijk zijn welke legitieme bandbreedte, poorten, landen, gevoelige applicaties en piekmomenten normaal zijn. Zonder baseline wordt filtering op het verkeerde moment te agressief of te traag.

• Alleen een Tbps-getal kopen zonder architectuur te vragen.
• PPS-, CPU-, poort- en firewallstate-limieten negeren.
• GRE, IPIP, VXLAN, BGP of cross-connect niet vóór noodsituaties valideren.
• Geen monitoring hebben tijdens de aanval.
• Een applicatie-reverse-proxy verwarren met upstream volumetrische mitigatie.

FAQ over 1Tbps DDoS-mitigatie