Quick answer
A UDP flood sends a large volume of UDP packets to a target so that it spends all its capacity receiving, inspecting and discarding them. Unlike TCP there is no handshake, so the attacker never has to prove anything or wait for a reply — packets can be fired continuously with forged source addresses. It is the most common attack against game servers, voice servers and anything else that has to keep a UDP port open, precisely because those services cannot simply refuse the protocol.
Why attackers prefer UDP
TCP requires a handshake, which means the attacker's machine has to hold state and respond. UDP requires nothing: a packet is sent, and that is the whole interaction. The attacker can therefore emit at line rate with no bookkeeping.
It also means source addresses can be forged freely, since no reply needs to come back. The traffic arriving at the victim appears to originate everywhere at once, and blocking sources is both futile and harmful.
- No handshake, so no state or cost on the attacker's side
- Source addresses can be spoofed with no downside for the attacker
- Ideal for reflection and amplification through third-party servers
- Targets that need UDP open cannot simply drop the protocol
What actually breaks first
The packets do not need to be valid or even reach an open port. If the port is closed, the operating system generates an ICMP "port unreachable" reply for each one, which costs CPU and outbound bandwidth — the target can end up attacking itself.
If the port is open, the application has to look at every packet to decide it is garbage. For a game server that means the same thread handling player movement is being interrupted thousands of times a second to discard junk, which is why the symptom is stuttering and rubber-banding long before anything goes fully offline.
Amplification makes it much larger
Because UDP has no handshake, an attacker can send a small request to a third-party server with the victim's address forged as the source. The server replies to the victim with something much larger. Public DNS resolvers, NTP servers, memcached instances and some game-server query protocols all have this property.
This turns a modest connection into a large attack, and it means the traffic arriving at the victim genuinely comes from legitimate servers — a further reason source-based blocking does more harm than good.
The shortcut that looks like protection
Many providers respond to a UDP flood by null-routing the target address, or by dropping all UDP traffic for the duration. Both stop the flood from reaching them. Neither is protection, because from the player's point of view the server is exactly as unreachable as it would have been if the attack had succeeded.
For anything that depends on UDP, the useful question when comparing providers is not whether they can stop the flood but whether your legitimate UDP traffic keeps flowing while they do.
What real filtering looks like
None of this can be done on the server itself: by the time packets arrive there, the bandwidth has already been consumed. UDP filtering only works upstream, which is why non-HTTP services are delivered protection through routing rather than through a proxy.
- Rate and shape per source and per destination port, upstream of your link
- Drop packets that cannot be valid for the protocol on that port
- Recognise the signatures of reflection sources and discard them early
- Keep the legitimate protocol flowing — filtering, not blanket blocking
- Hide the origin address so the attacker can only reach the filtered path
Frequently asked questions
Last updated