The development of cloud services and IoT solutions without adequate attention to information security leads to infections by botnets such as Mirai. According to Cloudflare data, in early September 2025, several IoT service providers and cloud services, including Google Cloud, became the sources of a UDP Flood attack with a capacity of 11.5 Tbps lasting 35 seconds. This is comparable to continuously streaming 10,000 hours of high-quality video in just half a minute. Such attacks clearly demonstrate the capabilities of attackers: DDoS attacks of hundreds of Gbps can now be carried out with minimal effort, causing business downtime for hours or even days.
What makes these attacks so powerful and how can they be countered? We explain this in the article and suggest what measures should be taken to mitigate the consequences.
How UDP Flood Works
UDP Flood is a type of volumetric DDoS attack at the transport (L4) network layer, in which the attacker sends a large number of UDP packets to random or predefined ports of the target host.
Originally, the UDP (User Datagram Protocol) was designed as a minimalist transport over IP for applications that do not require reliable delivery mechanisms: acknowledgment of receipt, retransmissions, or packet ordering. This is precisely why an attacker can continuously “flood” the target in one direction without waiting for any response. These properties subsequently made UDP a convenient foundation for VoIP, video streaming, and online gaming — where the loss of individual packets is not critical.
Another feature of UDP is that the destination host responds with an ICMP “service unavailable” message if the port is closed and ICMP is not restricted by security policies. This process loads the attacked server with processing the request, checking for a service on the specified port, and formulating a response. The response message would also load the attack source itself, but attackers began using the IP Spoofing technique, replacing the sender’s IP address in the packet with a random one. This way, using minimal resources, the attacker achieves saturation of both the downstream and upstream communication channels.
We previously examined SYN Flood in detail — a classic TCP attack aimed at exhausting connection tables and TCP stack resources.
Let’s compare UDP Flood vs TCP SYN Flood.
| Criterion | UDP Flood | TCP SYN Flood |
| Attacker’s computational cost | Low | High |
| Scalability | High | Limited by maintaining half-open connections |
| Ease of IP address spoofing | High | Medium |
| Resource exhaustion | Channel bandwidth / hardware limits (TCAM tables, session tables, control-plane CPU) / destination host CPU | Number of service users / destination host CPU |
| Impact on ISP | High | Low |
| Detection method | Traffic profile anomalies (PPS/BPS, flow asymmetry, multiplied increase of sources) | Ratio of SYN packets to total traffic (SYN ratio) |
| Protection method at target host level | UDP flow rate limiting, service protection mechanisms (DNS RRL, SIP rate control, QUIC Retry Token) | SYN Cookies |
Types of UDP Flood
Knowing that an attack operates at the transport layer via UDP is only the first step. For effective protection, it is important to identify its specific type: the mechanism, traffic source, and application protocols involved. Without this, countermeasures may prove either excessive or ineffective. Let’s examine the main varieties of UDP Flood that ISPs most commonly encounter.
UDP Flood via Botnet (non-spoofed)
Today this is the most common scenario. The growing number of vulnerable IoT devices, outdated servers, and home routers creates a massive base for botnets. Traffic comes from real IPs of infected devices, so packets appear legitimate and are poorly filtered.
Risks extend beyond the attacked party: an operator whose network contains infected subscribers may face CG-NAT table overflow due to massive outgoing traffic. As a result, regular users suffer, and the operator effectively becomes an unwitting participant in the attack.
Classic UDP Flood (spoofed)
An old but still relevant method: a stream of UDP packets is generated with spoofed sender addresses, often using readily available utilities. The low entry threshold makes it popular among novice attackers.
Its prevalence is gradually declining thanks to the implementation of BCP38 filtering and the emergence of more effective amplification methods. Nevertheless, with weak filtering, this type of attack can still overload channels.
Both types can attack a single port or many random ones. In the second case, the target host is additionally loaded with processing ICMP responses.
Reflected UDP Flood (reflection/amplification)
A particularly dangerous subtype that uses open reflector services. The attacker sends a small request with a spoofed victim’s address, and the server returns a significantly larger response to the victim. The amplification factor can reach tens, hundreds, and even thousands of times, making it possible to generate enormous traffic with minimal attacker resources.
Carpet Bombing and Multi-Vector Attacks
Any of these types can be directed not at a single host but at an entire subnet — the so-called carpet bombing, where traffic is distributed across multiple addresses and is harder to detect. In practice, attackers often combine several methods simultaneously, forming multi-vector attacks that require comprehensive protection.
How to Detect UDP Flood
The first step in building protection is learning to identify in a timely manner what kind of attack has hit the infrastructure.
The first and most obvious sign is a sharp and anomalous increase in incoming traffic. Unlike the organic load growth characteristic of peak hours, an attack appears as a vertical spike on the graph: traffic increases several times or by orders of magnitude in seconds. At the same time, the CPU load on the border router or firewall rises rapidly, as the equipment is forced to process every incoming packet.
Simultaneously, there is degradation in service quality: latency increases, packet loss rate grows for legitimate users, services begin responding slowly or stop responding altogether. In the case of an attack on CG-NAT, the ISP receives complaints from subscribers about inability to establish new connections — a sure sign of translation table exhaustion.
A characteristic picture when analyzing traffic: a high proportion of UDP packets with minimal or fixed size, conditionally random or clearly repeating destination ports, an anomalously high number of unique sender IP addresses (in spoofed attacks), or, conversely, traffic from certain ASNs or geographic regions (in botnet attacks). In reflection attacks, traffic will come from addresses of known public DNS or NTP servers, which is itself an anomaly. The list of vulnerable servers is often distributed through Threat Intelligence platforms, providing a ready list for blocking or rate limiting.
For prompt detection of attacks, ISPs typically use several monitoring sources.
- NetFlow/sFlow/IPFIX — router telemetry remains the primary data source for traffic analysis at the operator level. Collectors allow building traffic profiles in real time and detecting anomalies by protocol, port, volume, and geography. Threshold alerts for sharp UDP traffic growth are configured based on baseline normal load metrics.
- SNMP monitoring of router interfaces via Zabbix, Prometheus with SNMP exporter, or Grafana allows recording channel saturation and anomalous growth of error counters and dropped packets.
- DPI (Deep Packet Inspection) enables analysis at the packet content level, identifying characteristic signatures of known attacks, including reflection traffic from specific reflector types. DPI-based solutions, such as Stingray by VAS Experts, make it possible to not only detect an attack, but also instantly apply granular filtering policies without blocking legitimate traffic.
- Anomaly detection systems (NBAD) — specialized AntiDDoS solutions that analyze traffic behavior relative to a baseline and automatically initiate mitigation procedures when an attack is detected. The response time of such systems is measured in seconds, which is critically important during high-intensity attacks. Stingray AntiDDoS is a prime example of a system in this class: by analyzing QoE data using neural networks and machine learning algorithms, the detector identifies deviations from the norm, classifies threats, and determines their sources.
Protection Methods
Protection against UDP Flood is not universal: a DNS server, SIP platform, and web services are attacked differently and require different countermeasures. Below are practical recommendations for each type of infrastructure with specific commands and settings.
DNS Server Protection
DNS is a dual target: the server is attacked directly and also used as a reflector for attacks on others. An authoritative resolver with open recursive resolution and without rate limiting is an ideal amplifier for an attacker.
Closing Recursion for External Clients
An authoritative DNS server should not respond to recursive queries from external IPs. In BIND:
options { recursion yes; allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; allow-query-cache { 192.168.0.0/16; 10.0.0.0/8; }; };
In Unbound — deny queries from all except trusted subnets via access-control.
access-control: 192.168.0.0/16 allow access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse
Response Rate Limiting (RRL)
Limits the number of responses to a single IP address per unit of time. Reduces the effectiveness of DNS Amplification and protects against direct query flooding. Example for BIND 9.18+:
rate-limit { responses-per-second 15; window 15; slip 2; };
Minimizing ANY Responses
ANY queries yield the maximum amplification factor. Modern versions of BIND and Unbound return minimal-any by default, but it’s worth specifying explicitly.
minimal-responses yes; // BIND minimal-any yes; // BIND 9.11+
VoIP / SIP Infrastructure Protection
SIP operates over UDP (port 5060) and is particularly vulnerable to flooding: each incoming packet requires parsing at the application level, which quickly exhausts the resources of SBC (Session Border Controller) and Asterisk/FreeSWITCH. In addition, SIP infrastructure often faces combined attacks — flooding combined with registration spam and Toll Fraud.
SIP-aware Rate Limiting on SBC
The Session Border Controller should limit the number of SIP messages (INVITE, REGISTER, OPTIONS) from a single IP. Example configuration in Kamailio:
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 16)
modparam("pike", "remove_latency", 4)
The pike module blocks a source when it exceeds 16 requests in 2 seconds. For enterprise traffic, the threshold should be calibrated to real load.
Restrictions at the Linux Kernel Subsystem Level
Filtering at the OS level before packets reach the SIP stack significantly reduces load. Using iptables:
iptables -A INPUT -p udp --dport 5060 -m hashlimit \ --hashlimit 50/sec --hashlimit-burst 100 \ --hashlimit-mode srcip --hashlimit-name SIP \ -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j DROP
Using nftables:
table inet filter {
chain input {
type filter hook input priority 0;
ip protocol udp udp dport 5060 \
limit rate over 50/second burst 100 \
per ip saddr accept
ip protocol udp udp dport 5060 drop
}
}
The value of 50/sec or 50/second is adjusted to real load — the current setting is suitable for a small corporate SBC. The limit must be applied per-IP, otherwise legitimate burst traffic may be dropped or RTP negotiation disrupted.
Hiding SIP Infrastructure Behind SBC
Media servers (Asterisk, FreeSWITCH) should not have public IPs. The SBC accepts all external SIP/RTP traffic, terminates it, and forwards it to the internal network. This eliminates direct attacks on application servers.
Separate Bandwidth for RTP Traffic
Media streams (RTP/UDP) should be allocated to a separate port range and bandwidth-limited at the QoS level. During an attack, a flood on port 5060 should not compete with active voice sessions.
Note: SIP OPTIONS flood is a popular attack that mimics legitimate keepalive requests. Make sure your SBC distinguishes OPTIONS from trusted peers and random sources, and strictly limits the latter.
Web Services and API Protection
HTTP operates over TCP, but UDP Flood affects web infrastructure indirectly: by saturating the channel and overloading border equipment, the attack makes all services unavailable, including web ones. A separate threat is QUIC (HTTP/3), which operates over UDP/443: attackers are increasingly using QUIC reflectors or attacking QUIC endpoints directly.
Restricting UDP/443 (QUIC) During an Attack
If the web server does not use HTTP/3, port UDP/443 should be closed completely. If QUIC is needed — implement rate limiting similar to SIP.
ip protocol udp udp dport 443 \ limit rate over 500/second burst 1000 \ per ip saddr accept ip protocol udp udp dport 443 drop
Using QUIC Connection Migration with Caution
Connection migration in QUIC allows IP changes without dropping the connection — useful for mobile clients, but can be used for amplification. Control the preferred_address and migration parameters in the server configuration.
Nginx Configuration for Protection Against QUIC Attacks
In addition to network filters, nginx parameters can be optimized to reduce load during indirect UDP attacks.
quic_retry on; quic_max_idle_timeout 30s; quic_max_packet_size 1350;
Ensure your version of nginx supports QUIC and the corresponding directives. These settings do not replace network-level protection but help reduce load on the web server.
Universal Protection Measures for Operators
uRPF (BCP38)
Filters packets with spoofed addresses directly on the router — before entering the operator’s network. Strict mode is most effective but requires symmetric routing; loose mode is suitable for multihoming. Example for Cisco IOS on a border interface:
ip verify unicast source reachable-via rx ! strict mode ip verify unicast source reachable-via any ! loose mode
BGP Flowspec
Allows distributing filtering rules across the entire network through BGP announcements — blocking attack traffic closer to the source without overloading central nodes. Example rule for blocking UDP flooding on a specific prefix:
match destination 203.0.113.0/24 protocol udp dst-port 53 then discard
For Flowspec to be applied, network equipment must support this functionality at the data plane level.
RTBH (Remotely Triggered Black Hole)
An emergency measure during terabit-range attacks: announcing the attacked prefix to the blackhole community of the upstream provider. Traffic is discarded at the peering point — before reaching your channel. The victim is temporarily unavailable, but the operator’s infrastructure is protected.
ip route 203.0.113.1/32 Null0 router bgp 65000 network 203.0.113.1/32 route-map BLACKHOLE
Scrubbing Center
With an own or rented traffic cleaning center, the attacked prefix is redirected through it via BGP. The scrubbing center filters anomalous traffic and returns clean flow via GRE or MPLS tunnel to the operator.
Protection by VAS Experts
The Stingray AntiDDoS system provides comprehensive protection against UDP Flood at the operator level, combining DPI, behavioral analysis, and automatic mitigation in a single solution.
| Capability | Description |
| Line-rate DPI | Traffic analysis up to 5 Tbps without performance degradation |
| Packet rate detection (Mpps-level) | Instant detection of anomalous PPS growth and protection against packet-rate attacks that load CPU and equipment control-plane |
| Granular filtering | By protocol, port, packet size, geography — without blocking legitimate traffic |
| CG-NAT protection | Control of outgoing flooding, prevention of translation table exhaustion |
| BGP integration | Automatic initiation of RTBH and Flowspec upon attack detection |
| Carpet bombing detection | Aggregated analysis at AS level — detects distributed attacks on subnets |
| Inline filtering in data-plane | Mitigation directly at the operator’s node without routing traffic to an external scrubbing center — complete protection cycle within a single platform |
Case Studies
Analyzing public incidents allows us to not only assess the scale of modern threats but also extract practical lessons for our own infrastructure.
Case 1 — GitHub, February 2018
| Attack power | 1.35 Tbps (record at the time) / 126.9 Mpps |
| Duration | ~10 minutes |
| Vector | Memcached UDP Amplification (port 11211), ~50,000 reflectors |
| Amplification factor | Up to 51,000x (1 byte of request → 51 KB of response) |
| Consequences | GitHub was unavailable for several minutes before switching to Akamai Prolexic |
| Key takeaway | Memcached should not be accessible from the internet. UDP/11211 should be closed globally |
| How it was mitigated | Traffic redirection through Akamai scrubbing center absorbed the attack in ~8 minutes |
Case 2 — NDA Microsoft Azure Client, November 2021
| Attack power | 3.47 Tbps / 340 million packets per second |
| Duration | ~15 minutes |
| Vector | UDP Reflection on port 80 with simultaneous use of four amplification protocols: SSDP, CLDAP, DNS, and NTP. |
| Distribution | The attack originated from approximately 10,000 sources across 10 countries — USA, China, South Korea, Russia, Thailand, India, Vietnam, Iran, Indonesia, and Taiwan |
| Target | Corporate Microsoft Azure client in Asia (not publicly disclosed) |
| Consequences | None; automatic mitigation performed without operator involvement |
| Key takeaway | Multi-vector amplification is the new norm; protection must be automated |
| How it was mitigated | Azure DDoS Protection; then inline protection via NVA with Gateway Load Balancer |
Case 3 — NDA Cloudflare Client, September 2024
| Attack power | 3.8 Tbps / 2.14 billion packets per second |
| Duration | ~65 seconds |
| Vector | UDP Flood via botnet (ASUS routers, DVRs, VPN servers) |
| Target | Cloudflare client from the financial sector |
| Consequences | None; automatic mitigation performed without operator involvement |
| Key takeaway | Terabit-range attacks have become commonplace; manual response is impossible |
| How it was mitigated | Automatic systems: Anycast + behavioral analysis + instant Flowspec |
Case 4 — DDoS Scrubbing in Western Europe, September 2025
| Attack power | 1.5 billion packets/s — one of the largest by packet rate in public history |
| Duration | ~65 seconds |
| Vector | UDP Flood via botnet of CPE/IoT devices; more than 11,000 unique networks worldwide |
| Target | Website of a European DDoS scrubbing vendor FastNetMon — an attempt to disable the protection system itself |
| Problem | Traffic to individual IP was below alert thresholds, but the backbone was saturated |
| Consequences | Zero for users; the incident was publicly disclosed by FastNetMon |
| Key takeaway | High frequency of small UDP packets loads CPU of network devices more than volumetric attacks |
| How it was mitigated | FastNetMon Advanced detected the spike within seconds and automatically rerouted and discarded malicious traffic before channel saturation |
Conclusion
UDP Flood is not the only, but one of the most destructive forms of DDoS attacks. The connectionless nature of the UDP protocol makes it an ideal attack vector: there is no need to establish a connection, no built-in protection against spoofing, and amplification mechanisms can turn an attacker’s modest resources into terabits of junk traffic.
Modern attacks have become automated, multi-vector, and short in duration — which excludes manual response and requires automatic detection and mitigation systems. Carpet bombing attacks additionally bypass classical threshold monitoring. In these conditions, those with layered defense architecture win out, not a set of disconnected tools.
Quick Checklist: What Needs to Be Done
- Implement uRPF (BCP38) on all border interfaces — this is the foundation;
- Configure NetFlow/sFlow telemetry with analysis at the AS level, not just individual hosts;
- Close open recursive DNS resolvers and apply RRL on authoritative servers;
- Place SIP infrastructure behind an SBC with application-level rate limiting;
- Restrict or close UDP/443 (QUIC) where HTTP/3 is not used;
- Have ready procedures for RTBH and BGP Flowspec — do not configure them under attack pressure;
- Consider implementing a DPI platform for traffic visibility at the packet level.
