Op deze pagina
Kernpunten
- TCP is statefulElke nieuwe sessie kan state verbruiken op server, firewall of load balancer.
- PPS telt zoals GbpsEen SYN-flood kan TCP breken met matige bandbreedte maar heel veel pakketten.
- Filtering moet vroeg gebeurenEen serverregel helpt niet wanneer poort, router of firewall eerst verzadigt.
- Beschikbaarheid is het doelMitigatie moet echte handshakes behouden, niet alleen grafieken schoner maken.
Definitie van het probleem: wat een SYN-flood echt probeert uit te putten
Een SYN-flood richt zich op het TCP-verbindingsmechanisme. Normaal stuurt een client SYN, de server antwoordt SYN-ACK en de client bevestigt met ACK. Tijdens een aanval krijgt het doel abnormaal veel SYN-pakketten, vaak vanuit gespoofte, gedistribueerde of instabiele bronnen. Server of tussenapparaat houdt dan state vast voor verbindingen die nooit afronden.
Het resultaat is niet alleen meer verkeer. Het is druk op verbindingsbronnen: state tables, TCP-backlog, firewall-CPU, queues, geheugen, NAT-systemen, load balancers, reverse proxies of webservers. Zelfs met beperkte Gbps kunnen pakketten per seconde en onvolledige states de service onbeschikbaar maken.
Moderne SYN-floods worden vaak gecombineerd met andere vectoren. Een UDP-golf verzadigt de link terwijl SYN-verkeer stateful componenten uitput. Een verdediging op basis van gemiddelde bitrate of breed poortblokken is dan onvoldoende. Je moet weten waar saturatie ontstaat en welke laag eerst ontlast moet worden.
- Backlog-uitputting
- Te veel onvolledige handshakes verhinderen dat echte clients ruimte krijgen in de TCP-queue.
- Druk op stateful apparatuur
- Firewalls, NAT en load balancers kunnen falen vóór de origin-server.
- Gespoofte of verspreide bronnen
- Pakketten kunnen uit veel IPs komen, soms vervalst, waardoor bronblokkering onbetrouwbaar wordt.
Waarom dit belangrijk is voor infrastructuur die online verkoopt
Voor eindgebruikers lijkt een SYN-flood niet op een netwerkaanval. Het lijkt op een pagina die niet laadt, een paneel dat verbinding weigert, een API-timeout, een instabiele gameservice of een zakelijke dienst die offline is. Als de dienst leads, klanten of omzet oplevert, kunnen enkele minuten genoeg zijn voor verloren verkoop en vertrouwen.
TCP zit overal: websites, APIs, SSH, klantpanelen, proxies, load balancers, tunnels en bedrijfsdiensten. Te agressieve mitigatie veroorzaakt snel false positives. Een TCP-poort blokkeren stopt misschien de aanvalsgrafiek, maar schakelt ook de service uit. Het juiste ontwerp behoudt capaciteit en precisie zodat legitieme klanten sessies blijven opbouwen.
Voor groei via organisch zoeken, LinkedIn of X is dit extra belangrijk. Een moeilijk gewonnen prospect moet bereikbare infrastructuur aantreffen. DDoS-bescherming is dus commercieel én technisch: het beschermt conversie, geloofwaardigheid en continuïteit.
| Symptoom | Te eenvoudige uitleg | Echte prioriteit |
|---|---|---|
| TCP-timeouts | De webserver is traag | Backlog, firewall, load balancer en upstream-saturatie controleren |
| Hoge firewall-CPU | Meer CPU toevoegen | Vóór het stateful apparaat filteren wanneer de aanval zijn rol overschrijdt |
| Weinig Gbps maar service down | De DDoS is niet groot | PPS en onvolledige states bekijken |
| Legitieme verbindingen geweigerd | Harder blokkeren | Aanvalssignaturen scheiden van plausibele openingen |
Mogelijke oplossingen tegen SYN-floods
De eerste bekende reactie is TCP-bescherming op systeemniveau: SYN-cookies, backlog-tuning en kernelgrenzen. Ze zijn nuttig, maar lossen niet alles op. Ze helpen de server niet te vroeg resources te reserveren, maar beschermen link, router, firewall of load balancer niet wanneer de aanval al te diep in de architectuur komt.
Dit deel van “SYN-flood-bescherming” maakt duidelijk wat de keuze echt verandert: routing, filterpunt, false-positive tolerantie en leveringsmodel.
ACLs, stateless filtering, pakketgrootte, TCP-flags en netwerkkenmerken kunnen vroeg toegepast zeer effectief zijn. Maar ze moeten precies zijn. Een brede regel snijdt gebruikers af of breekt specifieke services. Daarom zijn upstream filtering, scrubbing en clean delivery nodig zodra de exposure serieus wordt.
- SYN-cookies en kernel-tuning
- Nuttig voor origin-hardening, onvoldoende tegen upstream-saturatie.
- Contextuele rate limiting
- Effectief wanneer drempels passen bij de echte service.
- Vroege stateless filtering
- Vermindert druk vóór apparatuur state bewaart op ruis.
- Beschermde transit of scrubbing
- Reinigt verkeer vóór productie en levert alleen bruikbare flows.
TCP-filtering voor de echte service, niet voor een generieke regel
Verkeer kan binnenkomen via Anti-DDoS beschermde IP-transit met BGP, beschermde IPs, GRE/IPIP/VXLAN-tunnels of cross-connect, afhankelijk van de architectuur. De waarde is dat mitigatie vóór de kwetsbaarste klantapparatuur staat. Schoon verkeer wordt daarna teruggeleverd met een leesbaar handoff-model.
Voor zeer volumetrische of high-PPS-golven kan filtering worden gecombineerd met upstream relief. Dat moet precies, tijdelijk en proportioneel blijven: het doel is niet de klant blackholen, maar de aanval genoeg afsnijden zodat fijne mitigatie controle houdt.
Afhankelijk van de klant kan dezelfde logica BGP-gebaseerde IP-transit, een blootgestelde dedicated server, een webpanel, een API of een gameservice met stabiele TCP-verbindingen zoals Minecraft beschermen. De kern is het juiste filterpunt en deliverymodel kiezen in plaats van één generieke regel op de hele infrastructuur toe te passen.
- bepalen waar druk ontstaat: link, firewall, load balancer, kernel of applicatie
- duidelijk illegitiem verkeer zo vroeg mogelijk filteren
- dure stateful logica op het hot path vermijden
- clean delivery behouden via cross-connect, GRE, IPIP, VXLAN of router-VM
- het profiel aanpassen aan de service in plaats van één model te kopiëren
Concreet voorbeeld: webservice en klantenpaneel onder SYN-flood
Stel een hostingprovider of SaaS-platform voor met commerciële website, klantenpaneel en meerdere blootgestelde TCP-diensten. De aanval start met matige Gbps maar heel veel SYN per seconde. De link is niet noodzakelijk vol, toch zien klanten timeouts. De stateful firewall verbruikt CPU en de load balancer houdt te veel onvolledige states vast.
Het resultaat hangt af van service, volume, pad en legitiem gedrag. Maar het ontwerp wordt veel schoner. De klant probeert niet alleen een verdrinkende server te redden, maar ontvangt gereduceerd, leesbaar verkeer dat de applicatie realistischer kan verwerken.
Baseline
Normaal TCP-verkeer begrijpen: poorten, openingsritme, verwachte pieken en gebruikersprofiel.
Detectie
SYN/ACK-onbalans, instabiele bronnen, abnormale PPS of backlog-druk herkennen.
Filtering
Inconsistent verkeer vroeg droppen en stateful lagen niet op ruis laten werken.
Delivery
Schoon verkeer via het beste integratiemodel aan de klant leveren.
Veelgemaakte fouten vermijden
Een SYN-flood lijkt eenvoudig, dus veel teams behandelen hem met één regel. Dat is vaak onvoldoende. De echte vraag is welke resource faalt en waar in het pad de beslissing moet worden genomen.
Een tweede fout is server-hardening verwarren met netwerkbescherming. Linux, Nginx of HAProxy versterken helpt, maar beschermt geen verzadigde poort en geen firewall die al overbelast is. De server kan geen pakketten filteren die hem niet meer bereiken of eerder een tussenlaag breken.
- alleen naar Gbps kijken en PPS negeren
- globale rate limit activeren zonder legitiem verkeer te kennen
- de eerste echte verdediging achter een kwetsbare stateful firewall plaatsen
- alle nieuwe verbindingen blokkeren en dat mitigatie noemen
- schone verkeerslevering niet testen vóór een echte aanval
FAQ
Is een SYN-flood altijd groot in Gbps?
Nee. De aanval kan weinig bandbreedte maar veel pakketten per seconde of TCP-state-druk veroorzaken.
Zijn SYN-cookies genoeg?
Ze helpen op de server, maar beschermen geen upstream-capaciteit, firewalls, load balancers of transitpoorten.
Moet je tijdens de aanval alle TCP blokkeren?
Nee. Kritieke diensten gebruiken TCP. Mitigatie moet plausibele verbindingen behouden en inconsistent verkeer blokkeren.
Zijn SYN-flood en TCP-flood hetzelfde?
Een SYN-flood is een type TCP-flood gericht op verbindingsopbouw. Andere TCP-floods richten zich op bestaande sessies, flags of applicaties achter TCP.
