Op deze pagina
Het operationele probleem
In het klassieke model worden connectiviteit en mitigatie apart gekocht. Tijdens een aanval blijkt dan dat transit verzadigt vóór de scrubbinglaag of dat de provider alleen blackhole voorstelt.
Voor een hoster is IPs wijzigen of klanten verplaatsen tijdens een incident niet realistisch. Voor gaming kan verkeerd geplaatste bescherming latency en false positives verhogen. Beschermde transit voorkomt dat verdediging een late toevoeging wordt.
Waarom dit vóór een aanval telt
Het belangrijkste voordeel is voorspelbaarheid. Vóór het incident kan worden vastgesteld waar traffic binnenkomt, welke prefixes worden geaccepteerd, welke capaciteit de handoff beschermt en hoe commit en overage werken.
Het tweede voordeel is operationele snelheid. BGP, tunnels, post-filterregels en escalatie zijn al bepaald. Tijdens de aanval hoeft er geen nieuw pad geïmproviseerd te worden.
Mogelijke technische aanpakken
Reverse proxy past bij een concreet endpoint. On-demand scrubbing helpt wanneer diversion acceptabel is. Lokale firewalls blijven nuttig na volumereductie. Voor netwerkexposure is beschermde transit vaak de schoonste basis.
De architectuur kan beschermde transit, tunnels naar externe servers, router-VM voor BGP-controle en gamingfiltering combineren wanneer UDP extra gevoelig is.
Concreet gebruiksvoorbeeld
Een hostingplatform krijgt herhaaldelijk aanvallen op verschillende klant-IPs. Een lokale firewall helpt niet als de upstreampoort vol zit. Beschermde transit reinigt traffic voordat die de klantedge overbelast.
Voor gaming is de prioriteit niet alleen dat de link online blijft. Spelers moeten verbonden blijven. Daarom moet de transitchain ruimte laten voor specifiekere logica bij gevoelige protocollen.
Veelgemaakte fouten vermijden
- Providerlimieten negeren.
