Identify UDP flood bottlenecks, coordinate upstream protection and verify legitimate DNS, VPN, voice or game traffic before changing firewall rules.
- Connection
Involve the upstream provider when the link is saturated.
- Host
Measure packet-processing load and resource exhaustion.
- Service
Filter for the actual protocol and legitimate traffic.
- Recovery
Verify real client access and keep a rollback path.
Prevent udp flood attack: Understand what a UDP flood can exhaust
A flood can overwhelm link capacity, packet-processing resources, connection tracking or the application itself. UDP source addresses can be spoofed, so an apparent source list may not identify the actual sender. High traffic alone is not enough to diagnose which resource is failing.
A packet sent to a closed UDP port may cause an ICMP error response, but the host does not necessarily reply to every packet. Linux has ICMP rate controls, documented in the kernel networking reference. Firewall policy and other limits also affect the response.
Measure impact with a bounded investigation
Compare current inbound bits per second, packets per second, CPU usage, drops and application errors with a normal baseline. Ask the hosting provider for edge metrics: a saturated upstream link may hide much of the traffic from host captures.
On a Linux host, read-only checks such as ss -s and UDP counters from nstat can support diagnosis. Availability and counter names vary. If capturing packets, use a limited sample and the correct interface; captures may contain sensitive traffic and can add load. Rising counters need context, not a single automatic “attack confirmed” threshold.
Filter around the service you actually operate
Inventory required UDP traffic, including DNS, QUIC, voice, games, VPNs and replies to outbound requests. Apply the least exposure needed and test from legitimate clients. A blanket UDP drop can break services that look unrelated to the attacked application.
Per-source limits alone can miss distributed or spoofed traffic and penalize many clients behind one shared address. Global limits have different tradeoffs. Choose thresholds from real traffic, protocol behavior and failure testing; a fixed 50-packets-per-second rule is not a universal safe default.
Keep a rollback path and remote access outside the rule being changed. Do not paste queue, buffer or connection-tracking settings into production without checking memory costs and the actual bottleneck.
Use protection that covers the protocol
A web CDN or ordinary HTTP reverse proxy does not automatically protect an arbitrary UDP service. Cloudflare documents proxy limitations and provides Spectrum for supported TCP and UDP applications, with protocol and plan conditions. Verify your service’s port, protocol and plan before assuming coverage.
For link saturation, involve the ISP, host or DDoS mitigation provider. Ask about upstream filtering, scrubbing and the effects of a temporary blackhole route. Blackholing can make the target unavailable; it is an operational tradeoff, not restored service.
Reduce amplification exposure
Review public recursive DNS, NTP, caching and other UDP listeners against their current vendor guidance. Restrict services intended for internal clients and remove unneeded public listeners. Test only systems you own or are authorized to assess.
The CISA, FBI and MS-ISAC DDoS guide covers preparation and response. Coordinate source-address filtering with the network operator; it is not a setting that makes one host immune to all spoofed traffic.
Prepare a usable incident checklist
- Record affected services, start time and customer impact.
- Contact the upstream provider early when capacity is threatened.
- Apply only tested mitigations with a clear rollback owner.
- Check legitimate client success as well as reduced attack traffic.
- After recovery, review exposure, alerts and the provider escalation path.
Keep the runbook and provider contacts available outside the affected service. For HTTP applications, also review the API protection guide.
Prepare an upstream-provider handoff
Keep the provider’s emergency contact and authorized account owner in the runbook before an incident. Supply the affected destination, protocol and ports, start time with time zone, observed bandwidth/packet rate and the services users cannot reach. Ask whether filtering or diversion is available for this exact service and whether activation changes routing or latency.
Distinguish access-link saturation from host or application exhaustion. A host firewall drop counter can rise while the incoming link is still full; it is not evidence that internet connectivity has recovered. Use provider-side observations alongside interface, host and service measurements. Keep packet samples short and approved, redact customer data and avoid collecting unlimited payloads during an already overloaded incident.
Define recovery before relaxing protection
Test a small set of legitimate clients across the actual services, including shared-address users where relevant. Check successful requests, loss, latency and application errors against the pre-incident baseline, rather than relying only on a falling packet counter.
Keep the previous configuration, a named rollback owner and a bounded review window. Relax temporary rules in controlled stages when evidence supports it; coordinate changes with the upstream provider. Document false positives, residual failures and which protection stays enabled. Do not assume that the end of one traffic spike proves the underlying exposure has been fixed.
Frequently asked questions
Can a local firewall stop a saturated internet link?
It can reduce host work, but packets have already crossed that link. Coordinate upstream filtering or capacity with the provider when the connection is the bottleneck.
Should I block all UDP traffic?
Only if your service does not require it and the change is authorized. DNS, QUIC, VPN, voice and games may depend on UDP; test legitimate use first.
Do per-IP limits solve distributed floods?
Not by themselves. Distributed or spoofed sources can evade them, and shared-address users can be affected; combine service-aware controls and upstream protection.
Does a larger UDP receive buffer fix every attack?
No. Kernel tuning cannot recover exhausted upstream bandwidth and may move the bottleneck. Diagnose and test before changing it.
Will a normal web proxy protect every UDP service?
No. Verify the product’s supported protocols, ports and deployment path; ordinary HTTP proxying is not general UDP protection.
What evidence should I send the provider?
Affected destinations, ports, timing, observed rates and service impact. Use approved bounded samples and redact sensitive payloads.
When should temporary filtering be rolled back?
Use a reviewed staged plan after legitimate service checks recover. A lower attack counter alone is insufficient.
What belongs in the incident runbook?
Provider contacts, authorized decision makers, baseline metrics, legitimate-client checks, configuration backups and the rollback owner.
Sources and further reading
Guidance reviewed October 14, 2026. Follow current official instructions and the policy for your actual service, device or workplace.
For a practical account of another network attack, see How to Protect APIs from DDoS Attacks.