What Is a Reflected ICMP/UDP Attack? | General Reflection Principle Explained

A reflected ICMP/UDP attack is a denial-of-service technique in which an attacker sends ICMP or UDP packets with a spoofed source IP address — the victim’s address — to third-party hosts or services, which then send their responses to the victim instead of back to the attacker. Unlike amplification-specific reflection attacks that rely on protocols producing responses many times larger than the request (DNS, NTP, SSDP), reflected ICMP/UDP attacks can work with response sizes similar to or only modestly larger than the request, deriving their impact primarily from IP spoofing and the volume of reflectors used rather than a large amplification factor.

TL;DR: Reflection abuses the fact that ICMP and UDP require no handshake to validate a sender’s identity, so an attacker can forge the victim’s IP as the source of a request and let a third-party host’s reply land on the victim instead of the attacker. ICMP Echo Reply reflection (the mechanism behind the classic Smurf attack) and general UDP reflection off exposed services both work this way, even when the reflector’s response isn’t dramatically larger than the original packet — the attack still concentrates traffic from many reflectors onto one victim and hides the attacker’s real IP. Mitigation centers on BCP38 source-address filtering at the network edge, since eliminating IP spoofing eliminates the reflection mechanism entirely, complemented by rate limiting, ICMP/UDP filtering policy, and upstream scrubbing capacity.

Last updated: 2026-08-27

The general reflection principle

Reflection and amplification are frequently discussed together, but they are distinct mechanisms. Reflection is the act of using a spoofed source IP address to redirect a third party’s response toward a victim who never sent the original request. Amplification is a separate, optional property: whether the reflected response is significantly larger than the request that triggered it.

Protocols like DNS, NTP, and SSDP are popular for DDoS specifically because they combine both properties — they are reflectable (connectionless, no source validation) and they can produce responses many times larger than the query, sometimes by factors of 50x or more. See What Is a DNS Amplification Attack? for a protocol that maximizes both properties.

Reflected ICMP and general UDP reflection sit at the reflection-only end of this spectrum: the response from the reflector may be roughly the same size as the request, or only modestly larger. An attacker using these vectors is not trying to multiply bandwidth the way a DNS or NTP amplification attack does — the value is in concealment (the victim sees traffic from many innocent third-party IPs, not the attacker) and in aggregation (many reflectors each sending a small amount of traffic can still sum to a significant volume against one target).

General reflection principle (protocol-agnostic):

Attacker → Reflector: Request packet, source IP spoofed to Victim's IP
Reflector: processes the request normally, has no way to detect the spoofing
Reflector → Victim: Response packet, addressed to the (spoofed) source IP
Victim: receives a response to a request it never sent

Repeated across many reflectors and many spoofed requests:
Victim receives converging traffic from many distinct, legitimate IPs
Attacker's own IP never appears anywhere in the traffic reaching the victim

ICMP Echo Reply reflection

ICMP (Internet Control Message Protocol) is commonly used for network diagnostics — the ping command sends an ICMP Echo Request and expects an ICMP Echo Reply from the target. Because ICMP, like UDP, has no connection-establishment handshake, a host receiving an Echo Request has no way to verify that the source IP in the packet is genuine.

Reflected ICMP attack flow:

Attacker → Third-party host: ICMP Echo Request, source IP spoofed to Victim's IP
Third-party host: replies automatically, as ICMP Echo Request/Reply is designed to do
Third-party host → Victim: ICMP Echo Reply
Victim: receives an unsolicited Echo Reply it never requested

The Smurf attack is the historically significant variant of ICMP reflection: instead of targeting one third-party host per request, the attacker sends a single spoofed ICMP Echo Request to the broadcast address of a network, which many networks historically forwarded to every host on that subnet. Every host that received the broadcast would reply to the spoofed victim IP simultaneously, turning one packet into potentially hundreds of reflected replies. Modern routers disable IP-directed broadcast forwarding by default (a practice formalized in RFC 2644), which has made classic broadcast-based Smurf attacks rare today, though direct one-to-one ICMP reflection off individual hosts remains possible wherever ICMP Echo is permitted from arbitrary sources. See What Is a Smurf Attack? for the broadcast-amplification variant in detail.

UDP reflection without a large amplification factor

Many UDP-based services beyond the well-known amplification protocols will respond to a request from any source IP, including services with query and response sizes that are roughly comparable — a modest amplification factor of perhaps 1x to 5x, or even less. The attack still functions as a denial-of-service technique for two reasons that are independent of amplification factor:

1. Attribution concealment. The victim’s network sees inbound traffic from many distinct, often legitimate, third-party service IPs — not from the attacker. This complicates simple source-IP blocking and can implicate innocent operators.
2. Aggregate volume from many reflectors. An attacker capable of sending spoofed requests to thousands of exposed UDP services can aggregate a large total response volume at the victim even if any single reflector’s response is only slightly larger than the request that triggered it.

UDP reflection example (generic, low-amplification case):

Attacker → Exposed UDP service A: request, spoofed source = Victim IP
Attacker → Exposed UDP service B: request, spoofed source = Victim IP
Attacker → Exposed UDP service C: request, spoofed source = Victim IP
...
[repeated across thousands of exposed UDP services]

Service A → Victim: response
Service B → Victim: response
Service C → Victim: response
...

Victim receives converging UDP traffic from thousands of distinct IPs,
none of which is the attacker

This is the reason reflection remains a relevant defense concern even for UDP services that are not classic amplification vectors: any UDP service that will respond to an unauthenticated request from an arbitrary source can, in principle, be recruited as a reflector.

Reflection vs. amplification: a clarifying comparison

The key takeaway: eliminating amplification factors (for example, deprecating the DNS ANY query type under RFC 8482) reduces the severity of amplification-specific reflection, but it does nothing against reflection attacks that never relied on a large response-to-request ratio in the first place. BCP38-style source filtering is the control that addresses the reflection mechanism itself, regardless of amplification factor.

Detection signals and telemetry

Reflected ICMP/UDP traffic has recognizable characteristics distinct from a direct flood originating from the attacker’s own infrastructure.

# Look for unsolicited ICMP Echo Replies arriving without a matching
# outbound Echo Request from this host
tcpdump -i eth0 icmp and 'icmp[icmptype] == icmp-echoreply' -nn

# Check volume and source diversity of inbound ICMP
tcpdump -i eth0 icmp -nn -c 1000 | awk '{print $3}' | sort | uniq -c | sort -rn | head

# Inbound UDP responses from unexpected source ports without
# corresponding outbound requests to those hosts
tcpdump -i eth0 udp -nn | grep -v "<known outbound query pattern>"

The single most reliable signal across reflection attacks generally is the absence of a matching outbound request for an inbound response — a network with full bidirectional flow visibility can distinguish solicited replies from reflected ones this way, though this correlation depends on visibility into both directions of traffic, which asymmetric routing or NAT can complicate.

Mitigation techniques

1. BCP38 / ingress-egress filtering (RFC 2827)

BCP38 is the structural fix: it requires networks to drop outbound packets whose source IP does not belong to the address block assigned to that network, and can also be applied on ingress to drop obviously spoofed inbound traffic. Because reflection depends entirely on the ability to forge a source IP, BCP38 adoption at the reflector’s network — or the attacker’s own network — prevents the spoofed packet from ever reaching a reflector with a forged address in the first place. Adoption remains incomplete across the internet, which is why reflection attacks persist despite BCP38 having existed as guidance since 2000.

2. Restrict or rate-limit ICMP where not operationally required

# Example: rate-limit inbound ICMP Echo Request/Reply at a network edge device
# (syntax varies by platform/vendor)
policy icmp rate-limit 100pps

Many networks can safely rate-limit ICMP traffic without breaking normal diagnostics, since legitimate ping usage is typically low-volume and low-frequency compared to a reflection attack’s sustained rate.

3. Disable IP-directed broadcast forwarding

Following RFC 2644 guidance, routers should not forward packets addressed to a subnet’s broadcast address from outside that subnet. This closes the amplification path that made classic Smurf attacks effective, independent of any ICMP rate limiting applied elsewhere.

4. Audit and close unnecessarily exposed UDP services

Services that respond to unauthenticated UDP requests from arbitrary internet sources are potential reflectors regardless of amplification factor. Restricting such services to known, authorized source ranges — or disabling them entirely where they’re not needed on internet-facing interfaces — removes them from the pool of usable reflectors.

5. Upstream scrubbing and distributed absorption capacity

Because reflection attacks can aggregate traffic from a very large number of reflectors, on-premise capacity is frequently insufficient regardless of any single reflector’s modest response size. Upstream, cloud-based, or distributed edge scrubbing capacity absorbs the aggregate volume before it reaches the origin network’s own uplink.

6. Stateful correlation of responses to requests

Where full bidirectional visibility exists, network devices or scrubbing infrastructure can correlate inbound ICMP/UDP responses against previously observed outbound requests and drop responses that have no corresponding request, filtering reflected traffic without needing to block ICMP or UDP outright.

Common mistakes

How to Implement on Azion

Azion’s distributed network sits ahead of the origin and can absorb and filter reflected ICMP/UDP traffic before it reaches origin infrastructure.

• DDoS Protection provides always-on detection aimed at volumetric reflection patterns, including ICMP and UDP-based reflected traffic
• Network Shield can help apply network-layer filtering rules — including by ASN, IP/CIDR range, or protocol — depending on configured Network Lists and policies
• Firewall enables custom rules for filtering traffic by protocol and source characteristics at the network layer
• WAAP combines these controls for teams that want DDoS protection layered with application-layer defenses

Because Azion’s distributed network absorbs traffic across many geographically dispersed locations, reflected ICMP/UDP traffic converging from many third-party sources is spread across aggregate edge capacity rather than concentrated against a single origin uplink.

Related Resources

• What Is a DNS Amplification Attack?
• What Is a Smurf Attack?
• What Is a DDoS Attack?
• Blackhole Routing vs. Edge Scrubbing
• Azion DDoS Protection
• Azion Network Shield

Frequently Asked Questions

What is a reflected ICMP/UDP attack? A reflected ICMP/UDP attack sends ICMP or UDP packets with a spoofed source IP address — the victim’s — to third-party hosts, which then send their replies to the victim instead of the attacker. It relies on IP spoofing and the connectionless nature of ICMP and UDP, not necessarily on a large response-to-request size ratio.

How is reflection different from amplification? Reflection is the use of a spoofed source IP to redirect a response toward a victim who never sent the request. Amplification is a separate, optional property describing whether that response is significantly larger than the request. Protocols like DNS and NTP combine both properties for maximum impact, while general ICMP and UDP reflection can occur even when the response is only comparable in size to the request.

What is ICMP Echo Reply reflection? It’s a reflection technique where an attacker sends an ICMP Echo Request with the victim’s IP forged as the source to a third-party host. That host, following normal ICMP behavior, sends an Echo Reply to the spoofed address — the victim — which receives a response to a ping it never issued.

How does the Smurf attack relate to ICMP reflection? The Smurf attack is a specific, amplified variant of ICMP reflection: instead of targeting individual hosts, the attacker sends a spoofed Echo Request to a network’s broadcast address, and historically every host on that subnet would reply simultaneously to the victim, multiplying one request into many replies. Modern routers disable this broadcast forwarding by default under RFC 2644 guidance, which has significantly reduced classic Smurf attacks.

Can UDP reflection work without a large amplification factor? Yes. Any UDP service that responds to an unauthenticated request from an arbitrary source IP can be used as a reflector, even if its response is only similar in size to the request. The attack still functions by concealing the attacker’s real IP and aggregating traffic from many reflectors onto one victim.

What stops IP spoofing from enabling reflection attacks? BCP38 (RFC 2827) is the primary structural control: it instructs networks to drop outbound packets whose source address doesn’t belong to their assigned IP range. If universally adopted, it would prevent spoofed-source packets from leaving the attacker’s network at all, eliminating the reflection mechanism regardless of protocol or amplification factor. Adoption remains incomplete across the internet.

Why do organizations still see ICMP reflection if Smurf attacks are largely mitigated? Broadcast-based amplification (classic Smurf) is largely closed off by default router behavior, but one-to-one ICMP reflection — an attacker spoofing a victim’s IP toward individual third-party hosts rather than a broadcast address — remains possible wherever hosts respond to ICMP Echo Requests from arbitrary sources without rate limiting.

Is blocking all ICMP traffic a good defense? Not generally recommended as a blanket measure. ICMP serves legitimate diagnostic and network-health functions (like Path MTU Discovery), and blocking it entirely can cause other network problems. Rate limiting ICMP traffic and disabling directed-broadcast forwarding are more targeted controls that address the reflection risk without breaking normal ICMP functionality.

How can a network tell reflected traffic apart from legitimate responses? The most reliable signal is correlation: a legitimate response corresponds to a request the local network actually sent. Reflected traffic arrives without any matching outbound request. This detection depends on full bidirectional flow visibility, which asymmetric routing, NAT, or limited telemetry can complicate.

Does disabling amplification-specific features (like DNS ANY responses) stop reflection generally? No. Measures like RFC 8482’s minimal ANY responses reduce the amplification factor of a specific protocol, lowering the severity of amplification-specific reflection. They do nothing against reflection techniques — including ICMP and general UDP reflection — that were never dependent on a large response-to-request ratio in the first place.

What role does upstream scrubbing play against reflected ICMP/UDP attacks? Because reflection can aggregate traffic from a very large number of distinct third-party reflectors, the total volume can exceed an origin network’s own uplink capacity even when no single reflector amplifies much. Upstream or distributed edge scrubbing absorbs this aggregate volume before it reaches the origin, which is generally more effective than relying on the origin network’s own, comparatively limited capacity.

Sources

• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38).
• IETF. “Changing the Default for Directed Broadcasts in Routers.” RFC 2644.
• IETF. “Internet Control Message Protocol.” RFC 792.
• CISA. “Understanding Denial-of-Service Attacks.”
• CISA. “UDP-Based Amplification Attacks.”
• CAIDA. “Spoofer Project Results.”