UDP flood: volume without a conversation

The reason is on attack layers: inspection happens after arrival, and this attack succeeds by consuming what carries traffic rather than what processes it.

UDP has no handshake. A sender does not wait for permission, does not maintain a session, and does not need a reply to consider the packet delivered. Each packet is independent, which is what makes the protocol useful for real-time traffic and what makes it convenient here.

Three properties follow.

Volume scales with bandwidth alone. The attacker's own machine keeps no per-connection state, so the only limit is what their network can emit.

Source addresses can be forged. Because nothing is returned to the sender, a packet can carry any source address and still do its job. Blocking what you see in the counters therefore blocks addresses that may have nothing to do with the sender.

Closed ports cost you twice. A packet arriving at a port with no listener normally produces an error response. Under flood conditions, generating those responses consumes processing and outbound capacity, which turns your own correctness into part of the load.

The evidence lives in counters rather than in application logs.

Three things in that shape matter more than any number.

Destination ports vary without pattern. Legitimate UDP traffic goes to services you run. Traffic spread across arbitrary ports has no service behind it and no reason to exist.

Sources are widely distributed and short-lived. Address ranges appear, contribute, and vanish, which is consistent with forgery rather than with a population of clients.

Your established sessions are unaffected in kind, only in capacity. Existing traffic is not being attacked; it is being crowded out.

Two distinctions save time.

Against an application-layer flood, the difference is where the load appears: here the application is idle and the interface is full. Logs that stay quiet during an outage are a signal in themselves.

Against a protocol attack such as a connection flood, the difference is state: there is none. Nothing is half-open, no table is filling, and the server is refusing nothing. It simply is not receiving.

Four measures, in the order they help.

Filter upstream. The only place a saturating flood can be removed is before your link carries it. Whoever provides connectivity can drop by protocol, port, and source properties at their edge, and this is the conversation to start first.

Rate limit UDP that has no business existing. Where you run no UDP services, that traffic can be discarded categorically upstream. Where you do, limits per port and per source are cheaper than inspection.

Do not answer what you do not serve. Suppressing error responses for unused ports removes the second cost described above. This is a configuration decision with a trade-off: those responses exist for diagnostics, and silencing them makes some legitimate troubleshooting harder.

Have capacity in front of you. Absorbing volume is infrastructure rather than configuration, which is why this family is answered by whoever sits between you and the internet.

What does not help: rules that read requests, challenges, and anything applied on the server itself. Filtering traffic after it has crossed the link consumes the resource it was meant to protect.

Sitting behind a provider helps only for traffic that goes through them, and this is where the defence most often fails in practice.

If your server's own address is reachable from the internet, packets sent straight to it never touch the edge that was supposed to absorb them. The protection is real and simply not in the path. Nothing about the flood changed; it went around.

Two measures close that gap, and both belong to the origin rather than to the provider.

Accept traffic only from the edge. Where the origin refuses connections from everywhere else, direct floods still consume its link, but they stop producing any effect on the service, and upstream filtering has a rule it can apply.

Do not publish the address. Records that resolve to the origin, error pages that reveal it, and mail sent directly from the same machine all place it in circulation. Whether it is discoverable is not something you can undo later, which is why the time to decide is before launch.

Floods can also arrive as replies rather than as direct traffic, when a service is made to answer a forged request toward you. The general shape of that technique is described on volumetric attacks, and the specific case built on the naming system belongs to the naming layer of this network, where record behaviour and resolver rules are already documented. Repeating it here would describe one mechanism in two places and keep neither current.

Bridge WAF inspects requests, which is the wrong layer for this attack and is stated plainly for that reason. What applies instead is termination: when visitors reach your site through the platform's edge, your origin's address is not the one being flooded, and the capacity in front of your content is the platform's rather than your link's. Asking a provider which component covers which layer is fair, including here. See what the platform offers at Bridge CDN.