Wat is een SYN Flood DDoS-aanval?
Een syn flood ddos is een DDoS-aanval waarbij een aanvaller de TCP-handshake misbruikt. De server krijgt veel SYN-verzoeken, maar ontvangt daarna geen afrondende ACK. Daardoor blijven halfopen verbindingen staan. Legitieme gebruikers merken hierdoor traagheid, foutmeldingen of volledige uitval. Dit artikel legt uit hoe de aanval werkt, welke signalen je ziet en welke maatregelen helpen om schade te beperken.
De aanval richt zich niet op de inhoud van een website, maar op de manier waarop netwerkverbindingen starten. Daarom kan een goed beveiligde applicatie toch last krijgen van een syn flood ddos. Vooral diensten die veel TCP-verbindingen verwerken, zoals webservers, mailservers en API-gateways, lopen risico.
Definitie van een SYN Flood DDoS-aanval
Een SYN flood DDoS-aanval maakt misbruik van het TCP-handshake-proces. Dat proces vormt de basis voor veel internetverbindingen. Normaal wisselen client en server drie berichten uit. Eerst stuurt de client een SYN. Daarna antwoordt de server met SYN-ACK. Tot slot stuurt de client een ACK terug.
Bij een syn flood ddos stopt de aanvaller bewust na de eerste stap. De server reserveert wel alvast geheugen en wachtrijruimte. Toch komt de bevestiging niet terug. Hierdoor raakt de backlog met halfopen verbindingen vol. Nieuwe, echte bezoekers krijgen dan geen plek meer.
Deze techniek valt onder DDoS-aanvallen op netwerkniveau. In tegenstelling tot een HTTP flood valt de aanval dus niet primair de webpagina zelf aan. Het doel is de verbindingsopbouw uitputten voordat de applicatie goed kan reageren.
Waarom de TCP-handshake kwetsbaar is
TCP is betrouwbaar omdat beide kanten bevestigen dat zij klaar zijn voor dataverkeer. Die betrouwbaarheid heeft echter een prijs. De server moet tijdelijk status bijhouden voor elke nieuwe verbinding. Daardoor kan een grote stroom halve verbindingen echte capaciteit opslokken.
Een aanvaller gebruikt vaak vervalste bronadressen. Daardoor stuurt de server SYN-ACK-antwoorden naar systemen die niets hebben aangevraagd. Dit maakt onderzoek lastiger. Lees ook de uitleg over vervalste IP-adressen als je wilt begrijpen waarom bronfiltering belangrijk is.
Hoe werkt een aanval met SYN flood DDoS stap voor stap?
Een syn flood ddos volgt een vast patroon. De details verschillen per netwerk, maar de kern blijft gelijk. De aanvaller opent veel verbindingen tegelijk en rondt ze niet af. Daardoor moet de server wachten tot time-outs verlopen.
- De aanvaller stuurt veel TCP SYN-pakketten naar een poort van het doelwit.
- De server ziet elk pakket als een nieuwe verbindingspoging.
- Daarom reserveert de server tijdelijk ruimte in de SYN-backlog.
- De server stuurt een SYN-ACK terug naar het opgegeven bronadres.
- De laatste ACK blijft uit, terwijl de server blijft wachten.
- Bij genoeg halfopen verbindingen raakt de wachtrij vol.
- Legitieme gebruikers ervaren daardoor vertraging, time-outs of onbereikbaarheid.
Een enkele server kan dit soms kort opvangen. Maar bij een gedistribueerde aanval komen de verzoeken vanaf veel systemen tegelijk. Botnets vergroten de druk op routers, firewalls en servers. Meer achtergrond over besmette netwerken vind je in de uitleg over een netwerk van geïnfecteerde apparaten.
TCP-handshake in een eenvoudig schema
Onderstaand schema toont het verschil tussen normaal TCP-verkeer en een aanval. Het gebruikt geen aanvalstooling. Daardoor blijft de uitleg gericht op herkenning en verdediging.
Normale TCP-handshake: Client -> Server: SYN Server -> Client: SYN-ACK Client -> Server: ACK Verbinding is open. SYN flood-patroon: Aanvaller -> Server: SYN Server -> Bronadres: SYN-ACK Aanvaller -> Server: geen ACK Halfopen verbinding blijft wachten.
Dit packet-level voorbeeld laat zien waarom de aanval effectief is. De server doet werk voor elke poging. De aanvaller hoeft echter minder terug te sturen. Zo ontstaat een scheve belasting.
Signalen en monitoring voor vroege detectie
Vroege detectie draait om afwijkingen in netwerkgedrag. Let daarom niet alleen op totale bandbreedte. Een syn flood ddos kan al merkbaar zijn voordat de lijn volledig volloopt. Vooral de verhouding tussen SYN en ACK geeft vaak snel inzicht.
- Veel SYN-pakketten per seconde: een plotselinge stijging wijst op verbindingsdruk.
- Lage ACK-ratio: veel SYN-verzoeken krijgen geen normale afronding.
- Volle SYN-backlog: de server houdt te veel halfopen sessies vast.
- Meer TCP time-outs: echte gebruikers krijgen trage of mislukte verbindingen.
- Afwijkende bronspreiding: verkeer komt uit veel netwerken of juist uit verdachte reeksen.
Combineer deze signalen met serverlogs, firewallstatistieken en routertelemetrie. Hierdoor zie je sneller of het probleem in de applicatie, in de server of in de netwerkrand zit. Toch moet je drempels voorzichtig instellen, want piekmomenten door echte bezoekers kunnen op aanvalspatronen lijken.
Gevaren van een SYN Flood-aanval
De gevolgen van een SYN flood-aanval kunnen groot zijn. Ze raken niet alleen de server, maar ook klanten, medewerkers en gekoppelde diensten. Vooral organisaties met publieke webdiensten merken de impact snel.
- Overbelasting van servers: de server raakt vol door onbeantwoorde SYN-aanvragen. Daardoor vertraagt de dienst of valt deze weg.
- Downtime en verlies van toegang: gebruikers kunnen diensten niet bereiken. Dit veroorzaakt verstoring in verkoop, support of interne processen.
- Verlies van klantvertrouwen: herhaalde uitval tast betrouwbaarheid aan. Klanten zoeken dan mogelijk een alternatief.
- Schade aan reputatie: zichtbare storingen trekken aandacht. Daardoor kan een technisch incident ook een communicatieprobleem worden.
- Hoge herstelkosten: teams moeten analyseren, filteren en herstellen. Bovendien kan extra infrastructuur nodig zijn.
Een syn flood ddos kan ook als afleiding dienen. Terwijl teams de beschikbaarheid herstellen, proberen aanvallers soms elders binnen te komen. Daarom hoort incidentrespons altijd breder te kijken dan alleen de overbelaste poort.
Voorbeelden en verwante DDoS-vormen
SYN flood-aanvallen komen voor bij verschillende soorten aanvallers. Denk aan cybercriminelen, afpersers en hacktivisten. Bekende DDoS-incidenten laten zien dat volumetrische druk en protocolmisbruik snel tot uitval kunnen leiden.
- Aanval op GitHub (2018): GitHub kreeg te maken met zeer grote DDoS-druk. Het platform was tijdelijk minder goed bereikbaar.
- De aanval op Dyn (2016): deze DDoS-aanval verstoorde grote delen van het internet. Daardoor waren bekende diensten tijdelijk onbereikbaar.
- Protocolaanvallen: aanvallers combineren soms meerdere methoden. Daardoor wordt filtering moeilijker.
Niet elke DDoS-aanval gebruikt TCP. Vergelijk deze aanval daarom met andere vormen, zoals ICMP-verkeer dat systemen overspoelt. Zo voorkom je dat je één verdedigingsmaatregel als oplossing voor elk type aanval ziet.
Bescherming tegen een SYN flood DDoS
Bescherming werkt het best in lagen. Eén instelling helpt zelden tegen elke situatie. Combineer daarom serverhardening, netwerkfiltering, monitoring en een duidelijk noodplan. Zo kan je team sneller reageren als de druk stijgt.
- Schakel SYN cookies in: de server hoeft dan minder status vast te houden voordat de handshake klopt.
- Vergroot en bewaak de SYN-backlog: extra ruimte helpt bij pieken, maar lost geen grote aanval alleen op.
- Gebruik rate limiting: beperk het aantal nieuwe verbindingen per bron, subnet of poort.
- Filter aan de netwerkrand: routers en firewalls kunnen verdachte patronen eerder tegenhouden.
- Werk met upstream filtering: laat schadelijk verkeer zo dicht mogelijk bij de bron of provider stoppen.
- Test je noodplan: leg vast wie belt, wie wijzigt en wie communiceert.
Rate limiting vraagt extra aandacht. Een te strenge limiet stopt misschien verkeer, maar blokkeert ook echte gebruikers. Daardoor ontstaat een false positive. Stel limieten dus af op normaal verkeer, seizoenspieken en bekende campagnes.
Maak daarnaast vooraf een praktisch plan. Een goede start is een checklist voor DDoS-preventie. Daarmee voorkom je dat teams pas tijdens de aanval zoeken naar contactpersonen, logbronnen en wijzigingsrechten.
Mitigatiekeuzes per netwerkarchitectuur
Niet elk netwerk heeft dezelfde beste oplossing. Een kleine VPS vraagt andere keuzes dan een groot platform met meerdere datacenters. Kies dus maatregelen die passen bij de plek waar de bottleneck ontstaat.
- Enkele server: activeer SYN cookies, beperk nieuwe verbindingen en monitor time-outs.
- Load balancer voor meerdere servers: laat de load balancer halfopen sessies opvangen en verdeel gezonde verbindingen door.
- Eigen netwerk met firewall: gebruik randfiltering, logging en tijdelijke regels op basis van aanvalspatronen.
- Providerafhankelijke omgeving: spreek vooraf af wanneer upstream filtering start en welke gegevens de provider nodig heeft.
Let daarbij op het verschil tussen capaciteit en filtering. Meer capaciteit geeft extra tijd. Filtering verlaagt echter de aanvalslast. In veel omgevingen heb je beide nodig, terwijl goede monitoring bepaalt wanneer je opschaalt.
Wat te doen bij een aanval met SYN flood?
Als je een aanval vermoedt, handel dan gestructureerd. Paniek leidt vaak tot te brede blokkades. Daardoor maak je de storing soms groter dan nodig.
- Bevestig de signalen: controleer SYN-ratio, backlog, time-outs en firewalllogs.
- Beperk de schade: activeer vooraf geteste regels voor filtering en rate limiting.
- Schakel hulp in: neem contact op met je provider als verkeer je lijn of randapparatuur raakt.
- Bescherm legitieme gebruikers: voorkom te agressieve blokkades op drukke maar echte netwerken.
- Leg alles vast: bewaar tijden, regels, grafieken en genomen besluiten.
- Evalueer na afloop: pas drempels, monitoring en procedures aan.
Na de aanval is analyse net zo belangrijk als herstel. Kijk welke systemen vol liepen, welke regels hielpen en waar ruis ontstond. Zo verbeter je de volgende respons zonder onnodig normale gebruikers te blokkeren.
Veelgestelde vragen
Deze korte antwoorden helpen bij herkenning, preventie en eerste stappen.
Is een SYN flood DDoS hetzelfde als een gewone DDoS-aanval?
Een SYN flood DDoS is een specifieke DDoS-vorm. De aanval misbruikt de TCP-handshake en vult de wachtrij met halfopen verbindingen. Een gewone DDoS-aanval kan echter ook andere protocollen of applicatielagen gebruiken. Daarom vraagt deze aanval vooral om maatregelen rond TCP, netwerkfiltering en backlogbeheer.
Hoe herken je een SYN flood-aanval snel?
Let op veel SYN-pakketten, weinig afrondende ACK-pakketten en stijgende TCP time-outs. Ook een volle SYN-backlog is een sterk signaal. Zo zie je vaak eerder dat het om verbindingsuitputting gaat, en niet alleen om gewone drukte op de website.
Helpen SYN cookies tegen elke aanval met syn flood?
SYN cookies helpen doordat de server minder status hoeft vast te houden voor halfopen verbindingen. Toch lossen ze niet elke aanval op. Bij zeer veel verkeer kan ook bandbreedte, firewallcapaciteit of routercapaciteit vol raken. Daarom combineer je SYN cookies met monitoring en filtering.
Kan rate limiting echte gebruikers blokkeren?
Ja, te strenge rate limiting kan echte gebruikers raken. Vooral gedeelde netwerken, mobiele providers en bedrijfsnetwerken kunnen veel verzoeken vanaf vergelijkbare adressen sturen. Stel limieten daarom af op normaal verkeer. Gebruik daarnaast monitoring, zodat je false positives snel ziet.
Wat is de eerste stap tijdens een SYN flood-aanval?
Controleer eerst of de signalen passen bij een SYN flood-aanval. Kijk naar SYN-ratio, ACK-ratio, time-outs en backloggebruik. Daarna activeer je vooraf geteste filtering. Neem ook contact op met je provider als verkeer de netwerkverbinding of randapparatuur overbelast.
Conclusie
Een SYN flood DDoS-aanval verstoort netwerken door de TCP-handshake half af te breken. De server blijft wachten op bevestigingen die niet komen. Hierdoor raken wachtrijen vol en krijgen echte gebruikers geen normale verbinding meer.
Goede bescherming begint met zicht op verkeer. Gebruik daarom monitoring op SYN-ratio, ACK-ratio, time-outs en backloggebruik. Combineer dit met SYN cookies, passende rate limiting, randfiltering en duidelijke afspraken met je provider.
Een syn flood ddos vraagt vooral om voorbereiding. Wie normale patronen kent, ziet afwijkingen sneller. Daardoor kan je team gericht ingrijpen, zonder meteen legitieme gebruikers te blokkeren.
