UDP flood attack vergeleken met versterkte DDoS

UDP flood attack: werking, herkenning en bescherming

Een UDP flood attack is een netwerkaanval waarbij grote hoeveelheden UDP-pakketten de verbinding, netwerkapparatuur of server van een doelwit overbelasten. Daardoor loopt legitiem verkeer vertraging op of komt het niet meer aan. De aanvaller kan rechtstreeks pakketten sturen of daarvoor andere apparaten misbruiken. Bij een versterkte aanval sturen tussenliggende servers extra veel antwoordverkeer naar het slachtoffer.

Het onderscheid telt omdat dezelfde storing verschillende oorzaken kan hebben. Videobellen, games en andere toepassingen gebruiken UDP voor legitiem verkeer, waardoor alles blokkeren ongewenste gevolgen heeft. Bovendien helpt een lokale firewall nauwelijks wanneer de internetverbinding vóór die firewall al volloopt.

Hier lees je hoe directe UDP-floods verschillen van versterkte DDoS-aanvallen en welke signalen dat verschil zichtbaar maken. Je leert verkeersmetingen beoordelen, pakketgegevens lezen en passende maatregelen kiezen. Ook krijg je afzonderlijke aanwijzingen voor slachtoffers en beheerders van servers die onbedoeld antwoorden versturen.

Hoe werkt een floodaanval via UDP technisch gezien?

Bij een UDP flood attack verstuurt een aanvaller zoveel UDP-verkeer dat een onderdeel van het netwerk de belasting niet meer verwerkt. Het knelpunt kan de internetverbinding, pakketverwerking, firewall of ontvangende toepassing zijn. UDP vraagt geen verbindingsopbouw voordat een afzender gegevens verstuurt, waardoor een aanvaller direct pakketten naar een doeladres kan sturen.

Waarom maakt het verbindingsloze UDP-protocol een floodaanval mogelijk?

UDP betekent User Datagram Protocol en verstuurt losse gegevenspakketten zonder ingebouwde bevestiging van ontvangst. De UDP-header bevat 8 bytes, waaronder een bronpoort en bestemmingspoort. Anders dan bij TCP vindt vooraf geen drievoudige verbindingsopbouw plaats. Daardoor hoeft een UDP-afzender geen werkende terugverbinding aan te tonen voordat de ontvanger verkeer krijgt.

UDP is daarmee niet onveilig ontworpen; het laat betrouwbaarheid en controle grotendeels aan de toepassing over. Een gesprekstoepassing kan bijvoorbeeld liever een verloren geluidspakket overslaan dan op herverzending wachten. Bij misbruik ontbreken echter ingebouwde verbindingscontroles die ongewenst verkeer vroeg kunnen afremmen. De ontvangende infrastructuur moet daarom zelf grenzen stellen.

Waar raakt een directe UDP-floodaanval het netwerk?

Een directe UDP flood attack volgt deze route: aanvallende apparaten → internetverbinding van het slachtoffer → netwerkapparatuur → ontvangende server. Grote pakketten belasten vooral de beschikbare bandbreedte. Kleine pakketten kunnen juist veel verwerkingswerk per seconde veroorzaken. Alleen de gemeten gigabits per seconde vertellen dus niet het hele verhaal.

Een netwerk van besmette apparaten kan verkeer vanaf veel aansluitingen tegelijk versturen. DDoS betekent distributed denial of service: meerdere systemen proberen gezamenlijk een dienst onbereikbaar te maken. Een UDP-flood vanaf één bron is wel een overbelastingsaanval, maar niet automatisch een verspreide aanval. Het aantal zichtbare bronadressen bewijst bovendien niet hoeveel apparaten werkelijk meedoen.

Wat gebeurt er bij verkeer naar gesloten poorten?

Wanneer een UDP-pakket een gesloten poort bereikt, kan een systeem een ICMP-melding terugsturen dat de poort onbereikbaar is. Besturingssystemen beperken zulke foutmeldingen vaak om overbelasting te verminderen. Toch moet het apparaat het binnenkomende pakket eerst beoordelen. Ook zonder actieve UDP-dienst kan ongewenst verkeer capaciteit kosten.

Veel UDP-poorten zien betekent niet automatisch dat de aanvaller open diensten zoekt. Een flood kan willekeurige bestemmingspoorten gebruiken om eenvoudige filters te ontwijken. Omgekeerd kan één vaste doelpoort voldoende zijn om een game- of VPN-dienst te treffen. Onderzoek steeds welk onderdeel verzadigt, niet alleen welke poort in de melding staat.

Directe UDP-flood en versterkte DDoS vergeleken

Verschillen tussen directe UDP-floods en twee vormen van versterkte DDoS

Aanvalstype	Verkeersroute naar het doelwit	Versterking	Herkenningssignalen	Passende mitigatie
Directe UDP-flood	Aanvaller of botnet → slachtoffer	Geen noodzakelijke versterking	Veel UDP-pakketten; vaste of wisselende doelpoorten	Gerichte filtering; pakketlimieten; bovenstroomse filtering
NTP-amplification	Aanvaller → NTP-reflectoren → slachtoffer	Grote antwoorden op kleine verzoeken	Ongevraagde antwoorden; vaak bronpoort 123	Antwoordverkeer filteren; reflectoren beveiligen; providerbescherming
DNS-amplification	Aanvaller → DNS-reflectoren → slachtoffer	Grotere DNS-antwoorden dan verzoeken	Ongevraagde DNS-antwoorden; vaak bronpoort 53	Protocolbewuste filtering; resolverbeperking; providerbescherming

Een directe UDP flood attack bereikt het slachtoffer zonder noodzakelijke tussenliggende antwoordservers. Bij reflectie sturen andere servers hun antwoorden naar het slachtoffer; bij versterking zijn die antwoorden groter dan de oorspronkelijke verzoeken. Beide technieken kunnen samen voorkomen, maar reflectie betekent niet automatisch versterking. Ook een direct verzonden flood kan bronadressen vervalsen.

De rol van IP spoofing bij UDP-floodaanvallen

IP spoofing is het vervalsen van het bron-IP-adres in een pakket, zodat het lijkt alsof het verkeer van een ander apparaat komt. Dat adres staat in de IP-header, niet in de UDP-header. UDP controleert niet zelfstandig of de afzender op dat adres bereikbaar is. Een zichtbaar bronadres is bijgevolg niet zonder meer bewijs van de werkelijke herkomst.

Bij een NTP-reflectieaanval kan een verzoek aan UDP-poort 123 bijvoorbeeld het IP-adres van het slachtoffer als bron dragen. De tijdserver stuurt zijn antwoord dan naar het slachtoffer in plaats van naar de aanvaller. Bij een directe UDP flood attack kunnen vervalste bronadressen juist de herkomst verhullen zonder tussenliggende antwoordserver. Bronadresvalidatie bij het netwerk waar het verkeer vertrekt kan zulke pakketten tegenhouden. Een filter bij het slachtoffer kan daarentegen niet alleen aan het bronadres zien wie ze werkelijk heeft verstuurd.

Hoe veranderen reflectie en versterking de verkeersroute?

Bij reflectie verloopt de route als volgt: aanvaller → openbare antwoordserver → slachtoffer. De aanvaller zet het IP-adres van het slachtoffer als bronadres in het verzoek. De antwoordserver ziet hierdoor het slachtoffer als aanvrager. Deze techniek heet het vervalsen van een bron-IP-adres.

Network Time Protocol, afgekort NTP, synchroniseert klokken en gebruikt normaal UDP-poort 123. Oudere beheermogelijkheden zoals monlist, gekoppeld aan het verzoektype MON_GETLIST, konden veel informatie over eerder waargenomen clients teruggeven. Zulke antwoorden konden meerdere pakketten beslaan, terwijl het verzoek klein bleef. De bredere werking en risico’s van versterking via NTP verklaren waarom openbare antwoorddiensten aandacht verdienen.

Hoe bereken je de versterkingsfactor zonder appels met peren te vergelijken?

De versterkingsfactor is het aantal antwoordbytes gedeeld door het aantal verzoekbytes, gemeten op hetzelfde protocolniveau. Vergelijk dus geen verzoek zonder netwerkheaders met een antwoord inclusief headers. Historische monlist-aanvallen maakten misbruik van grote antwoordreeksen. Een universele factor bestaat niet, omdat antwoordinhoud, configuratie en meetmethode verschillen.

Neem een vereenvoudigd rekenvoorbeeld met 60 verzoekbytes en 3 antwoordpakketten van elk 400 bytes. De antwoordreeks bevat dan 400 + 400 + 400 = 1.200 bytes, oftewel een factor 20. Bij duizend verzoeken per seconde gaat het om zestigduizend verzoekbytes tegenover 1,2 miljoen antwoordbytes per seconde. Deze illustratie gebruikt afgesproken meetgroottes en voorspelt geen specifieke NTP-server.

Let op: Een server hoeft niet gehackt te zijn om als reflector te werken. Een openbaar bereikbare functie die op verzoeken met een vervalst bronadres grote antwoorden kan sturen, kan al voldoende zijn.

Welke signalen verraden een UDP-floodaanval?

Een UDP flood attack herken je aan een afwijkende combinatie van verkeersvolume, pakkettempo, bestemmingen en dienstuitval. Een plotselinge piek alleen bewijst geen aanval: een evenement of software-update kan eveneens verkeer veroorzaken. Vergelijk meerdere metingen met normaal verkeer op hetzelfde tijdstip en controleer of de getroffen toepassing die pakketten verwacht.

Welke metingen tonen het knelpunt bij een UDP-flood?

Meet minimaal bits per seconde, pakketten per seconde en pakketverlies. Bekijk daarnaast processorbelasting, interfacefouten en wachtrijen op routers en firewalls. Een server met lage processorbelasting kan toch onbereikbaar zijn doordat de aansluiting volloopt. Een firewall kan omgekeerd vastlopen op pakketverwerking terwijl de bandbreedte nog ruimte biedt.

Een rekenvoorbeeld laat het verschil zien: honderdduizend pakketten per seconde van duizend bytes leveren 800 megabit per seconde aan pakketgegevens op. Bij pakketten van honderd bytes levert hetzelfde pakkettempo 80 megabit per seconde op. Het pakkettempo blijft gelijk, maar het gemeten bytevolume verschilt met een factor 10. Linklaagoverhead komt daar nog bij, afhankelijk van het meetpunt.

NetFlow en IPFIX beschrijven verkeersstromen met gegevens zoals adressen, poorten, protocollen en tellers. sFlow gebruikt onder meer steekproeven van pakketten en interfacegegevens. Deze technieken helpen patronen over meerdere verbindingen te herkennen. Bij steekproeven moet je wel rekening houden met ontbrekende korte stromen en beperkte detailinformatie.

Hoe herken je UDP-floodverkeer in pakketten en stromen?

Begin met een korte, afgebakende vergelijking van normaal en afwijkend verkeer. Kijk bijvoorbeeld naar een meetvenster van 60 seconden vóór en tijdens de storing. Onderstaande controlepunten ondersteunen de beoordeling, maar geen enkel punt bewijst zelfstandig een aanval. Combineer netwerkgegevens met informatie uit de getroffen toepassing.

• Een sterke stijging van UDP-pakketten naar één adres of één dienst.
• Veel ongevraagde antwoorden vanaf bronpoort 123 of 53.
• Vergelijkbare pakketgroottes vanaf veel verschillende bronadressen.
• Een scheve verhouding tussen uitgaande verzoeken en inkomende antwoorden.
• Meer pakketverlies, volle wachtrijen of uitval tijdens dezelfde verkeerspiek.
• Bronadressen of poortcombinaties die niet passen bij het normale gebruik.

Een NTP-client kan normaal antwoorden vanaf bronpoort 123 ontvangen. Die poort vormt geen zelfstandig bewijs van misbruik. Controleer of de client vooraf passende verzoeken verstuurde en of de aantallen kloppen. Een server die plots veel grote NTP-antwoorden naar vreemde bestemmingen verstuurt, kan juist zelf reflector zijn.

De belangrijkste vraag is niet hoeveel verkeer je firewall tegenhoudt, maar waar ongewenste pakketten de ruimte voor legitiem verkeer al hebben opgebruikt.

Hoe onderzoek je pakketgegevens zonder zelf een aanval uit te voeren?

Wireshark is een programma waarmee je vastgelegd netwerkverkeer kunt bekijken. Gebruik voor een bestaande opname bijvoorbeeld het weergavefilter udp.srcport == 123 om UDP-pakketten met bronpoort 123 te selecteren. tcpdump legt verkeer vast via een opdrachtregel; het filter udp and port 123 selecteert beide richtingen. Beide filters tonen verkeer en veroorzaken zelf geen flood.

Bekijk voor een veilige oefening één normale tijdsynchronisatie tussen apparaten die je zelf beheert. Een regulier NTP-bericht heeft 48 bytes basisinhoud, zonder eventuele uitbreidingen. Met een IPv4-header van 20 bytes en een UDP-header van 8 bytes is dat 76 bytes op IP-niveau. Ethernetheaders en andere linklaaggegevens vallen buiten deze optelsom.

Vergelijk de bron en bestemming van het verzoek met die van het antwoord. Bij een normale uitwisseling wisselen de adressen van rol en volgt het antwoord op een eigen verzoek. Bij ongevraagde reflectie ontbreekt zo’n passend verzoek vanaf het slachtoffer. Gebruik geen monlist-verzoeken, vervalste adressen of openbare servers voor deze oefening.

Wat doe je bij een vermoedelijke UDP-floodaanval?

Beperk een UDP flood attack zo vroeg mogelijk op de verkeersroute en laat de maatregel aansluiten op het knelpunt. Lokale filters helpen tegen ongewenste pakketverwerking, terwijl een verzadigde aansluiting filtering bij de provider vraagt. Bepaal eerst of je slachtoffer bent of zelf antwoordverkeer verstuurt. Die keuze voorkomt dat je het verkeerde probleem oplost.

1. Noteer het getroffen IP-adres, de begintijd en de uitgevallen dienst.
2. Meet inkomende en uitgaande bits en pakketten per seconde op de netwerkrand.
3. Bewaar een korte verkeersopname en bijbehorende stroomgegevens binnen je privacybeleid.
4. Controleer of het systeem ongevraagde pakketten ontvangt of juist veel antwoorden verstuurt.
5. Vraag de provider om filtering vóór de verzadigde verbinding als de aansluiting volloopt.
6. Pas gerichte filters toe en controleer onmiddellijk of legitieme diensten blijven werken.

Welke rol hebben firewalls en snelheidsbeperking bij UDP-floods?

Een firewall beoordeelt verkeer aan de hand van regels, verbindingstoestand of protocolkenmerken. Rate limiting begrenst het toegestane tempo, bijvoorbeeld in pakketten per seconde. Beide maatregelen kunnen lokale apparatuur ontlasten. Ze maken echter geen ruimte vrij op een internetverbinding die het aanvalsverkeer al volledig heeft gevuld.

Een uitsluitend op een bronadres gerichte limiet past slecht bij veel wisselende of vervalste adressen. Een globale UDP-limiet kan bovendien geldige gesprekken en VPN-verbindingen raken. Kies waar mogelijk een combinatie van doeladres, protocol, poorten en passend gebruikspatroon. Controleer zowel geblokkeerde pakketten als de bereikbaarheid van de echte dienst.

Iptables is een Linux-hulpmiddel voor pakketfiltering. Een regel die UDP-bestemmingspoort 123 blokkeert, kan onnodig de eigen tijdsynchronisatie of tijdserver uitschakelen. Zonder kennis van de rol van het apparaat is zo’n regel geen veilig standaardadvies. Laat wijzigingen beoordelen en houd een terugweg beschikbaar wanneer beheer op afstand wegvalt.

Wanneer moet de provider het verkeer afvangen?

De provider moet ingrijpen wanneer ongewenst verkeer de aansluiting vult of lokale apparatuur niet meer bereikbaar blijft. Bovenstroomse filters verwijderen pakketten voordat ze de beperkte verbinding bereiken. Een reinigingsdienst kan verkeer onderzoeken en alleen het toegestane deel doorsturen. Controleer vooraf of de dienst ook jouw legitieme UDP-toepassingen ondersteunt.

Bij een aansluiting van 1 gigabit per seconde past 2 gigabit per seconde aan inkomend verkeer niet door dezelfde toegang. Een lokale firewall verandert die verhouding niet, zelfs wanneer de server elk aanvalspakket direct weggooit. Tijdelijk verkeer naar het doeladres volledig verwerpen beschermt soms de rest van het netwerk. Het getroffen adres blijft dan wel onbereikbaar.

Vuistregel: Filter vóór het eerste onderdeel dat verzadigt; een filter achter dat knelpunt herstelt de verloren capaciteit niet.

Wat verandert er als jouw server de reflector is?

Als jouw server veel antwoorden op verzoeken met vervalste bronadressen verstuurt, ligt de eerste taak bij het stoppen van die antwoordfunctie. De beslisroute is kort: overwegend inkomende ongevraagde antwoorden betekent slachtofferonderzoek; overwegend uitgaande antwoorden op vreemde verzoeken betekent reflectoronderzoek. Beide rollen kunnen tegelijk voorkomen. Bekijk altijd twee verkeersrichtingen.

Beperk bij een reflector de blootgestelde dienst en controleer daarna of het uitgaande antwoordverkeer afneemt. De gerichte beveiliging van een eigen NTP-server vraagt een afzonderlijke configuratiecontrole. Bronadresvalidatie bij netwerkaanbieders helpt daarnaast vervalste verzoeken tegenhouden. BCP38, beschreven in RFC 2827, behandelt filtering van bronadressen die niet bij de herkomst van het verkeer passen.

Een thuisgebruiker bespreekt een verzadigde aansluiting met de internetaanbieder en bewaart tijdstippen van uitval. Een serverbeheerder levert daarnaast bestemmingsadressen, poorten en verkeersmetingen aan de hostingpartij. Een beveiligingsteam koppelt die gegevens aan routermetingen en wijzigingen in diensten. Zo krijgt iedere partij gegevens waarmee zij op haar eigen deel van de route kan handelen.

Waar liggen de grenzen van bescherming tegen UDP-aanvallen?

Bescherming tegen een UDP flood attack blijft afhankelijk van zichtbaarheid, beschikbare capaciteit en toegestane diensten. Geen losse poortregel onderscheidt alle geldige en ongewenste pakketten. Ook kunnen aanvallers verkeerspatronen veranderen nadat een filter actief wordt. Beoordeel het effect op dienstniveau en blijf meten tijdens de aanpassing.

Waarom volstaat een lijst met geblokkeerde bronadressen niet?

Bij reflectie horen de zichtbare bronadressen vaak bij misbruikte servers, niet bij de oorspronkelijke aanvaller. Bij directe floods kunnen vervalste bronnen of veel verschillende apparaten voorkomen. Handmatig adressen toevoegen schaalt hierdoor slecht wanneer bronnen blijven wisselen. Een structurele maatregel kijkt ook naar verkeersrichting, antwoordgedrag en de aangevallen dienst.

Bronadresvalidatie heeft eveneens grenzen: een slachtoffer kan niet eigenhandig afdwingen dat alle andere netwerken BCP38 toepassen. Strenge controles op het eigen netwerk voorkomen wel dat jouw aansluiting eenvoudig verkeer met onjuiste bronadressen verstuurt. Bij meerdere netwerkpaden moet de beheerder rekening houden met geldige asymmetrische routering. Anders kan een controle ook legitieme pakketten verwijderen.

Hoe voorkom je verkeerde conclusies uit monitoring?

Een stijging van firewallblokkades betekent niet automatisch dat gebruikers weer verbinding krijgen. Controleer daarom minstens twee uitkomsten: neemt de ongewenste belasting af en werkt de dienst weer? Een externe bereikbaarheidstest vult lokale grafieken aan. Meet ook vanaf een andere aansluiting, omdat één netwerkroute een vertekend beeld kan geven.

Let verder op versleutelde UDP-toepassingen: zichtbare pakketgegevens vertellen niet altijd wat de inhoud betekent. Beperkte stroomgegevens kunnen bovendien antwoorden tonen zonder de bijbehorende verzoeken vast te leggen. Dan is meer onderzoek nodig voordat je reflectie vaststelt. Bewaar voldoende context, maar verzamel geen complete inhoud wanneer tellers en headers de vraag al beantwoorden.

Kies bescherming op de plek van het knelpunt

Een UDP flood attack vraagt eerst een diagnose van de route, niet meteen een grotere blokkeerlijst. Direct verkeer en versterkte antwoorden kunnen hetzelfde slachtoffer raken, maar laten andere aanwijzingen achter. Vooral de verhouding tussen verzoeken en antwoorden, pakkettempo en verzadiging helpt om passende maatregelen te kiezen.

Voor het slachtoffer telt waar het verkeer capaciteit wegneemt. Voor de eigenaar van een reflector telt welke dienst ongevraagd antwoorden produceert. Lokale filtering, snelheidsbeperking en providerbescherming vullen elkaar aan, maar vervangen elkaar niet. Een bruikbaar noodplan legt vast wie welke metingen verzamelt en wie bovenstrooms kan ingrijpen.

Wij zouden bij een onduidelijke UDP-piek eerst willen weten welke meting de gebruikersuitval verklaart. Een druk dashboard alleen zou ons niet overtuigen om een brede blokkade te adviseren. Liever een gerichte ingreep met een duidelijke controle achteraf: dat is de redactionele afweging van Virus.NL.

Veelgestelde vragen

Hieronder vind je korte antwoorden over UDP-floods, versterking en de rol van filtering. Zo kun je de belangrijkste verschillen snel terugvinden.

Wat gebeurt er bij een floodaanval via UDP?

Een aanvaller stuurt zoveel UDP-pakketten dat een verbinding, netwerkapparaat of toepassing onvoldoende capaciteit overhoudt. Daardoor stijgt de vertraging of valt de dienst uit. De overbelasting kan ontstaan door veel bytes, veel pakketten of dure verwerking per pakket. Een aanval hoeft niet de volledige internetbandbreedte te vullen om hinder te veroorzaken.

Waarom is UDP gevoelig voor misbruik bij DDoS?

UDP vereist geen verbindingsopbouw voordat een ontvanger pakketten krijgt. Ook controleert UDP niet zelfstandig of een bronadres werkelijk bij de afzender hoort. Hierdoor kunnen aanvallers direct verkeer sturen of antwoorddiensten met vervalste bronadressen misbruiken. De toepassing en het netwerk moeten aanvullende controles bieden; verbindingsloos verkeer is op zichzelf geen bewijs van een kwetsbaarheid.

Hoe verschilt een directe flood van een amplification-aanval?

Bij een directe flood sturen aanvallende systemen hun pakketten rechtstreeks naar het doelwit. Bij amplification lokken kleine verzoeken grotere antwoorden uit bij tussenliggende diensten. Met het vervalste bronadres van het slachtoffer komen die antwoorden bij het slachtoffer terecht. Reflectie beschrijft de omweg; versterking beschrijft de groei van het verkeersvolume.

Welke rol hebben firewalls, rate limiting en providers?

Firewalls selecteren toegestaan verkeer en rate limiting begrenst het tempo. Deze maatregelen beschermen lokale verwerking zolang de inkomende verbinding bruikbaar blijft. Providers kunnen eerder op de route filteren en daarmee een verzadigde aansluiting ontlasten. De juiste combinatie hangt af van het knelpunt en de UDP-diensten die bereikbaar moeten blijven.

Betekent veel verkeer vanaf poort 123 dat NTP is gehackt?

Nee, bronpoort 123 past ook bij normale antwoorden van een tijdserver. Onderzoek of de ontvanger bijbehorende verzoeken verstuurde en of het volume daarbij past. Misbruik als reflector vereist bovendien niet altijd toegang tot het systeem. Een verkeerd blootgestelde antwoordfunctie kan voldoende zijn om ongewenst verkeer naar een slachtoffer te sturen.

Leg ter voorbereiding op een UDP flood attack vast welke UDP-diensten bereikbaar moeten blijven en wie je provider kan inschakelen bij uitval. Gebruik daarvoor een praktische checklist voor een DDoS-noodplan, zodat metingen en verantwoordelijkheden vooraf duidelijk zijn. Noteer ook hoe je na een ingreep controleert of gebruikers weer verbinding krijgen. Daarmee toets je niet alleen de blokkade, maar ook het herstel van de dienst.

Verder lezen

• NTP amplification: werking en risico’s