Upstream filtering tegen DDoS: aanvalstraffic stoppen vóór uw infrastructuur verzadigt

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. Veel teams ontdekken dit pas tijdens een serieus incident, wanneer routes al onder druk worden aangepast.

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. Als één punt onduidelijk blijft, kan mitigatie theoretisch werken maar praktisch falen.

Ook commerciële taal is een probleem. “Veel capaciteit” legt niet uit wat gebeurt met legitieme UDP, bestaande TCP, latency, BGP communities of tijdelijke regels. Technische kopers willen mechaniek, niet alleen cijfers.

Waarom dit belangrijk is

Een verkeerde keuze wordt direct zichtbaar als storing. Eindgebruikers zien geen verschil tussen transitverzadiging, slechte BGP-policy of een te agressief filter; ze zien timeouts, packet loss of disconnects.

Ook kosten worden geraakt. Aanvalstraffic via het verkeerde pad kan 95th percentile, backbonegebruik en supporttickets verhogen. De architectuur moet de aanval vroeg reduceren zonder legitiem verkeer te offeren.

Voor latencygevoelige diensten zoals FiveM, Minecraft, VoIP of interactieve APIs moet stabiliteit behouden blijven. Bescherming die online blijft maar slecht aanvoelt is niet genoeg.

In de praktijk moet elk ontwerp vóór de klantmigratie worden getest: gecontroleerde verkeerssamples, duidelijke grenswaarden, vastgelegde rollback-stappen en een contactpunt per carrier. Die voorbereiding klinkt minder spectaculair dan grote capaciteitscijfers, maar bepaalt vaak of een platform tijdens een echte aanval stabiel blijft of dat het team onder druk moet improviseren.

Mogelijke oplossingen

Eerst moet het ingressmodel beschreven zijn: welke prefixes, welk ASN, welke upstreams en welke BGP-policy. Zonder basis kan automatisering het incident verergeren.

Daarna is proportionele filtering nodig. Blackhole, ACL, FlowSpec, scrubbing en rate-limit hebben verschillende impact. Elk middel heeft rol en eindtijd nodig.

Verder moet clean traffic delivery vóór de aanval vaststaan. GRE, IPIP, VXLAN, router-VM en cross-connect zijn geldig, maar verschillen in latency, controle en uitrol.

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.

Upstream filteren zonder klantverkeer te breken

Peeryx bekijkt dit eerst als netwerkontwerp: traffic naar een laag trekken die volume aankan, duidelijke aanvalsdelen verminderen en clean traffic teruggeven zonder de topologie te verbergen.

Het gaat niet om permanente generieke regels. FlowSpec of upstream filtering moet precies, tijdelijk en observeerbaar zijn. Tunnels of cross-connects moeten gedocumenteerd zijn.

Commercieel telt een bescherming die de klant begrijpt: pad, limieten, drempels, support en rollback in plaats van vage onbeperkte mitigatie.

Effectieve upstream filtering begint daarom vóór een incident met een duidelijke signatuurstrategie: welke protocollen zijn toegestaan, welke bron- en doelpoortreeksen zijn normaal, welke pakketgroottes of TCP-flags horen bij legitiem verkeer en welke uitzonderingen moeten behouden blijven. Zonder die voorbereiding wordt een noodregel vaak te breed en kan die echte sessies verstoren.

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 het incident kijkt het team naar volume, PPS, protocol, poorten, actieve routes en latency per ASN. Vermindert de actie de aanval zonder legitiem verkeer te raken, dan blijft ze actief; anders wordt ze smaller of verwijderd.

Na het incident gaan de gegevens in het runbook: welke community gebruiken, welk prefix verplaatsen, welke regel niet herhalen en welke capaciteit later nodig is. Zo verbetert de bescherming per aanval.

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.

Veelgemaakte fouten

• Capaciteit verwarren met echte mitigatie.
• BGP-wijzigingen improviseren tijdens aanval.
• Te brede filters op UDP of TCP toepassen.
• Latency en packet loss tijdens mitigatie niet meten.
• Het retourpad van clean traffic vergeten.
• Geen duidelijke rollback voor tijdelijke regels hebben.

FAQ