Op deze pagina
Definitie van het probleem
Het probleem is dat aanvalstraffic het klantnetwerk bereikt voordat lokale filters kunnen ingrijpen. Als de poort al verzadigd is, helpt serverlogica niet meer.
upstream filtering DDoS dwingt om het volledige pad te bekijken: BGP announcement, gekozen upstream, echte poortcapaciteit, beschikbare filtering, clean traffic handoff en gedrag van de dienst.
Mogelijke oplossingen
Het doel is nutteloos volume bij de upstream te verwijderen zonder de dienst uit te schakelen. De regel moet precies zijn: protocol, poorten, pakketlengte, TCP-flags of herkenbare reflectiebronnen.
Een extra punt is de afstemming met het bedrijfsmodel van de klant. Een gamehoster, een SaaS-platform en een operator met een eigen ASN hebben niet dezelfde risicotolerantie. Bij een gameservice kan te agressief filteren van UDP meteen spelers verbreken, terwijl bij een bedrijfsapplicatie bepaalde doelpoorten veel strenger beschermd kunnen worden. Upstream filtering moet daarom geen standaardknop zijn, maar een instrument dat wordt afgestemd op poortmodel, protocolprofiel, klanttype en aanvalspatroon.
- BGP Blackhole vs BGP FlowSpec: het juiste DDoS-filter kiezen
Vergelijk blackhole en FlowSpec-regels.
Concreet gebruiksvoorbeeld
Een hoster met gameservers krijgt een UDP-flood boven zijn poortcapaciteit. Het duidelijke patroon wordt upstream gefilterd, legitieme UDP blijft werken en clean traffic komt terug via GRE, IPIP, VXLAN of cross-connect.
Tijdens productie moet elke regel tijdelijk, meetbaar en terugdraaibaar zijn. Het gaat niet alleen om de vraag of de upstream verkeer dropt, maar vooral of de klant daarna bereikbaar blijft, of UDP-antwoorden, BGP-sessies, monitoring en beheer nog werken en of de regel na de aanval netjes wordt verwijderd.
