Reflected DDoS attacks should be treated as a spoofing and amplification problem first, not just a traffic volume problem. An attacker hides behind misconfigured public services, tricks them into replying to a victim, and turns small requests into floods of unwanted traffic. The smartest defense combines source validation, rate limits, traffic profiling, Anycast capacity, and fast filtering at the network edge.
TLDR: A reflected DDoS attack sends forged requests to third-party servers, which then “reflect” replies toward the victim. In one common DNS amplification case, a 60-byte query can trigger a response of 3,000 bytes or more, creating a 50x increase in traffic. A mid-sized e-commerce site hit with 40 Gbps of reflected UDP traffic could see checkout latency jump from 300 ms to 12 seconds within minutes. Strong filtering, upstream coordination, and hardened exposed services reduce both the blast radius and recovery time.
What Is a Reflected DDoS Attack?
A reflected distributed denial of service attack uses two tricks: IP spoofing and third-party responders. The attacker sends packets with the victim’s IP address as the fake source. Public servers then send their replies to the victim, not to the attacker.
This makes attribution harder. The victim sees traffic from DNS resolvers, NTP servers, Memcached nodes, CLDAP services, or other exposed systems. The real attacking machines remain hidden behind the forged source address.
Reflection also creates scale. A botnet does not need to connect directly to the target. It only needs to spray forged packets at services that will reply. If those services send larger responses than the original requests, the attack becomes an amplification attack.
How Amplification Works
Amplification is the reason reflected DDoS attacks can become so destructive. The attacker sends a small request. The reflector sends a much larger response. That difference becomes free attack traffic.
Common amplification sources include:
- DNS: Open resolvers can return large records, especially when abused with ANY queries or oversized DNSSEC responses.
- NTP: Older servers with the monlist command enabled have produced huge response sets.
- Memcached: Exposed UDP Memcached servers have caused amplification rates far above 10,000x in past attacks.
- CLDAP: Directory services exposed to the internet can generate large UDP replies.
- SSDP: Consumer devices and routers may reply to discovery requests from outside networks.
- Chargen and QOTD: Legacy protocols still create avoidable risk when left exposed.
The goal is simple. The attacker wants traffic to be cheap to create and expensive to absorb. Honestly, it feels like a cruel joke when one forgotten UDP service on a poorly maintained server helps knock another company offline.
Why Reflected Attacks Are Hard to Stop
These attacks are tough because the packets often come from real servers. A firewall cannot simply block all DNS or NTP replies without breaking normal functions. Attackers also rotate protocols, packet sizes, ports, and reflector pools.
The attack may last only minutes. That is enough to disrupt logins, payments, gaming sessions, streaming, VoIP calls, or API traffic. Short bursts can also be used as cover for fraud, credential stuffing, or data theft attempts.
Another pain point is upstream congestion. If the attack saturates an internet circuit, local firewalls and load balancers may never see clean traffic. Filtering must often happen at the ISP, scrubbing center, CDN, or cloud edge.
Detection Methods That Work
Detection depends on baselines. A network team needs to know what normal traffic looks like before it can spot abuse. Key signals include sudden spikes in UDP traffic, unusual source port patterns, abnormal packet-per-second rates, and reply traffic with no matching internal request.
Useful detection methods include:
- NetFlow and IPFIX analysis: These show traffic volume, protocol mix, source networks, and attack direction.
- Packet sampling: Sampled packets reveal protocol abuse, payload traits, and spoofed behavior.
- Baseline alerts: Alerts should trigger when DNS, NTP, CLDAP, or SSDP traffic rises beyond normal ranges.
- Connection-state checks: Replies that do not match expected sessions can be flagged.
- ASN and geo analysis: Large shifts in source networks may expose reflector clusters.
- DNS telemetry: Abnormal query types, response codes, and record sizes may point to abuse.
It drives security teams crazy that some monitoring tools show “UDP spike” and little else. During an active attack, vague labels waste precious minutes. Clear protocol tagging can cut triage time from 15 minutes to under 3 in a well-prepared SOC.
Network Defense Strategies
Defense starts with stopping spoofing wherever possible. The internet still suffers because many networks fail to block packets with forged source addresses.
1. Apply Source Address Validation
Networks should use BCP 38 and uRPF filtering to block spoofed packets leaving or entering their infrastructure. If more providers enforced this, reflected attacks would lose much of their power.
2. Harden Public Services
Organizations should audit exposed UDP services. Open DNS resolvers should be closed or restricted. NTP should be patched and monlist disabled. Memcached should not listen on the public internet, especially over UDP. CLDAP and SSDP should be filtered unless there is a clear business need.
3. Use Rate Limits and Response Controls
DNS Response Rate Limiting can reduce abuse. Firewalls and routers can cap traffic from risky protocols. Service owners should limit oversized responses and block unauthenticated requests from the public internet when possible.
4. Deploy DDoS Scrubbing
Scrubbing centers inspect traffic at scale, strip attack packets, and forward clean traffic to the origin. This is vital when attacks exceed local bandwidth. Anycast routing can spread traffic across multiple sites, reducing pressure on one data center.
5. Prepare Upstream Filtering
Providers can apply ACLs, RTBH routing, FlowSpec rules, and protocol-specific filters. A runbook should include ISP contacts, escalation paths, allowed prefixes, critical services, and emergency filter templates.
6. Protect Applications Too
Reflected attacks target networks, but application impact matters. CDNs, WAFs, caching layers, queue systems, and graceful error handling help services stay usable when traffic is degraded.
Image not found in postmetaOperational Checklist
- Map exposed UDP services across cloud, branch, and data center networks.
- Disable unnecessary public services and restrict admin interfaces.
- Confirm ISP DDoS contacts before an emergency occurs.
- Test traffic baselines for normal hours, peak hours, and seasonal spikes.
- Create packet captures during drills so analysts know what to expect.
- Review logs after every event and update filters based on real attack traits.
A reflected DDoS attack is not only a victim problem. Every exposed reflector helps attackers hurt someone else. Cleaner networks, tighter service configuration, and faster shared response make these attacks less profitable and less disruptive.
FAQ
What makes a DDoS attack “reflected”?
It is reflected when attackers send spoofed requests to third-party servers, causing those servers to send replies to the victim.
What is amplification in a reflected DDoS attack?
Amplification happens when a small request creates a much larger response. The victim receives far more traffic than the attacker sends.
Which protocols are often abused?
DNS, NTP, Memcached, CLDAP, SSDP, Chargen, and other UDP-based services are common targets for abuse.
Can a firewall stop a reflected DDoS attack?
A firewall can help with filtering, but it may fail if the internet link is saturated first. Upstream filtering or scrubbing is often required.
How can organizations reduce the risk?
They should block spoofed traffic, restrict exposed UDP services, use rate limits, monitor baselines, and arrange DDoS mitigation with their providers.
Why do attackers prefer UDP?
UDP does not require a handshake. That makes source spoofing easier and allows attackers to trigger replies toward a victim.