Beschermde IP-transit tegen DDoS: mitigatie die legitiem verkeer intact houdt

De grenzen van het klassieke model onder DDoS

Voordat we naar beschermde transit kijken, is het belangrijk te begrijpen waarom het klassieke model niet meer werkt zodra een dienst serieuze of herhaalde aanvallen aantrekt.

In een standaardomgeving komt kwaadaardig verkeer te dicht bij productie voordat er echt beslissende filtering plaatsvindt. Daar beginnen verzadiging, factuurpieken en te destructieve noodmaatregelen.

Netwerksaturatie

Een volumetrische aanval kan 100 Gbps of zelfs meerdere Tbps overschrijden. Een 10G-, 25G- of 100G-poort kan vollopen voordat de dienst tijd heeft om te reageren.

Kostenpiek

Nee. Dit hangt af van factuurperiode, meetpunt, meetinterval en het aandeel hoge waarden. Vergelijk de afgesproken commit met het gemeten P95, niet met de hoogste verkeerspiek.

Blackholing van IP

In veel omgevingen wordt de noodreactie een blackhole op het aangevallen IP. De rest van het netwerk overleeft misschien, maar de getroffen klant blijft offline.

Wat is beschermde IP-transit anti-DDoS?

Beschermde IP-transit combineert internetconnectiviteit met DDoS-filtering vóór het afgesproken afleverpunt. Het doel is aanvalsverkeer te verminderen en diensten bereikbaar te houden. Het resultaat hangt af van verkeer, beleid, beschikbare capaciteit en afleverpad.

Hoe beschermde transit in de praktijk werkt

Verkeer voor beschermde prefixes wordt aangetrokken via het afgesproken routingbeleid. BGP bepaalt bereikbaarheid; de mitigatie-infrastructuur filtert. Permanente en op aanvraag geactiveerde paden hebben verschillende eisen voor convergentie en beheer.

Gefilterd verkeer wordt via de afgesproken aansluiting afgeleverd. Valideer ontvangende capaciteit, MTU, retourpad en echte applicatietransacties vóór productie. De totale mitigatiecapaciteit is geen bandbreedte die voor één poort of tunnel is gereserveerd.

1. Routing

   Aangekondigde prefixes, rechten en bedoelde ingang controleren.

2. Observatie

   Bandbreedte, pakketsnelheid en applicatiesymptomen vergelijken met normaal verkeer.

3. Filtering

   Het gekozen beleid toepassen en de werkelijke status controleren.

4. Aflevering

   Ontvangend pad en geslaagde legitieme transacties controleren.

Detectie, regeltoepassing en controle

Mitigatie vergelijkt waargenomen verkeer met ingestelde drempels en regels. Detectie, beslissing, toepassing en dienstherstel zijn afzonderlijke stappen. Hun duur hangt af van sampling, aanval, configuratie en netwerkpad.

Deze gids onderbouwt geen gemeten reactietijd over het volledige pad. Noteer tijdens kwalificatie het begin van afwijkend verkeer, de toepassing van de regel en het herstel van legitieme transacties. Een snelle lokale beslissing bewijst op zichzelf geen herstel van het hele netwerk.

Levering van schone traffic

De bestaande infrastructuur kan blijven staan als adressering, routing en eindpuntcapaciteit dit toelaten. Encapsulatie vervoert pakketten; zij herkent zelf geen aanval.

GRE / IPIP

L3-aflevering naar een bestaand eindpunt; controleer onderliggend netwerk, MTU en retourroute.

VXLAN

Overlay voor Ethernet-aflevering en segmentatie; houd rekening met extra overhead.

Cross-connect

Fysieke verbinding: bevestig poort, VLAN, redundantie en beschikbare capaciteit.

Router-VM

Routerings- of tunneleindpunt. Bruikbare doorvoer hangt af van het virtuele pad en toegewezen middelen.

Concrete use-cases

Een bestaande server beschermen

Een beschermingslaag toevoegen aan een OVH-, Hetzner- of vergelijkbare dedicated server zonder de hele infrastructuur te verplaatsen.

Eigen filterlogica hosten

Een dedicated server met XDP of andere logica gebruiken om filtering af te maken na upstream relief.

Gaming-workloads

FiveM, Minecraft en andere latencygevoelige diensten hebben snelle, schone en minimaal intrusieve mitigatie nodig.

SaaS, API’s en kritieke diensten

Niet-standaard applicaties en atypische flows profiteren sterk van mitigatie die rond werkelijk verkeersgedrag is ontworpen.

Filtering beoordelen met legitiem verkeer

Meet geaccepteerd en verwijderd verkeer, geslaagde nieuwe verbindingen, verlies en applicatieresponstijden. Minder aanvalsverkeer helpt als de dienst bruikbaar blijft. Neem niet aan dat een beleid geen foutieve blokkades of prestatieverlies veroorzaakt.

Poorten, pakketsnelheid, encapsulatie en ontvangende apparatuur begrenzen de aflevering. Toets optionele UDP- en TCP-limieten per bron aan gedeelde NAT, VPNs en legitieme pieken. Eén adres kan meerdere gebruikers vertegenwoordigen.

Upstream-FlowSpec kan een vastgesteld aanvalspatroon verminderen vóór een beperkt netwerkpad. Controleer bereik, ondersteunde actie, intrekkingsvoorwaarde en effect op legitiem verkeer. Een brede regel kan een dienst onderbreken terwijl de aanvalsgrafiek verbetert.

Veelgemaakte fouten om te vermijden

Een goed anti-DDoS-ontwerp moet de link, de factuur, de gebruikerservaring en de bedrijfslogica van de dienst beschermen. Als het slechts één van die lagen beschermt, blijft het onvolledig.

• Alleen naar Gbps kijken terwijl PPS vaak de echte beperkende factor is.
• Een generiek beschermingsmodel kiezen voor verkeer dat niet in standaardpatronen past.
• Routingontwerp negeren terwijl symmetrische en asymmetrische modellen zeer verschillende latency- en kostenimplicaties kunnen hebben.
• Aannemen dat beschermde transit elke aanvullende laag vervangt, terwijl een meerlagig ontwerp operationeel vaak het schoonst blijft.

Vragen en antwoorden