DoS and DDoS Attacks

Imagine being able to send a 1 KB request and have it result in 50 KB hitting your victim. That's 50x leverage. Now imagine doing that millions of times per second across thousands of third-party servers. This is the power of amplification attacks—a category of DDoS that weaponizes legitimate Internet infrastructure to multiply attack power by orders of magnitude.

Amplification attacks exploit a fundamental asymmetry in certain protocols: requests are small, but responses are large. By spoofing the source IP address to be the victim's address, attackers redirect those large responses to their target. The amplifying servers—DNS resolvers, NTP servers, memcached instances—become unwitting participants in the attack.

This technique enabled the largest DDoS attacks ever recorded and remains a primary concern for Internet infrastructure security.

Amplification attacks combine two fundamental techniques to achieve their devastating effect: IP spoofing and response amplification. Understanding both components is essential.

IP Spoofing: The Foundation

IP spoofing is the ability to send packets with a forged source IP address. On the Internet, nothing inherently prevents this:

• Most routing decisions are based only on destination address
• Intermediate routers don't verify source addresses
• The attacker crafts packets with the victim's IP as source
• Any responses go to the victim, not the attacker

Why Spoofing Works:

TCP requires a handshake, so spoofed TCP connections are difficult (the victim would receive unexpected SYN-ACKs and send RSTs). But UDP is stateless—servers respond to the source IP in the packet without verification. This is why most amplification attacks use UDP-based protocols.

The Amplification Factor:

The amplification factor (also called bandwidth amplification factor or BAF) measures how much the attack is multiplied:

Amplification Factor = Response Size / Request Size

Different protocols offer different amplification factors:

• Low amplification (2-5x): Still useful for adding volume
• Medium amplification (5-50x): Significant force multiplication
• High amplification (50-500x): Massive attack power from modest resources
• Extreme amplification (500x+): Record-breaking attacks

The Reflection Component:

Amplification attacks are also called reflection attacks because traffic is "reflected" off third-party servers. This provides multiple benefits to attackers:

1. Obscured Origin: Traffic comes from legitimate servers, not attacker's network
2. Distributed Sources: Thousands of amplifiers act like a botnet
3. Difficult Blocking: Can't block all DNS servers, NTP servers, etc.
4. No Botnet Required: Attacker doesn't need compromised hosts
5. Bandwidth Multiplication: Turns small attacker bandwidth into large attack

DNS amplification was one of the first widely-used amplification vectors and remains prevalent today. It exploits the fact that DNS queries are small but DNS responses can be quite large.

Why DNS Is Amplifiable:

1. UDP-Based: DNS primarily uses UDP (port 53), enabling IP spoofing
2. Open Resolvers: Millions of DNS resolvers accept queries from any source
3. Response > Request: DNS responses include complete records, much larger than queries
4. ANY Query Type: The "ANY" query requests all record types, maximizing response size
5. DNSSEC: Signed zones have much larger responses due to cryptographic signatures

Maximizing DNS Amplification:

Attackers choose targets for large responses:

Large Zone Records:

• Zones with many TXT records (SPF, DKIM, verification tokens)
• Zones with many MX hosts
• Zones with multiple A/AAAA records

DNSSEC-Signed Zones:

• RRSIG records add significant size
• DNSKEY records for zone signing keys
• DS records for delegation

ANY Query Type:

• Returns all record types in a single response
• Maximizes response size
• Many resolvers now limit or refuse ANY queries

Open Resolver Population:

Despite security recommendations, millions of open resolvers exist:

• Misconfigured corporate DNS servers
• Open resolvers at ISPs
• Home routers with DNS forwarding enabled
• Cloud instances with default DNS configurations

The Open Resolver Project has identified millions of open resolvers. While the number has decreased through awareness campaigns, adequate amplifier population remains for significant attacks.

NTP (Network Time Protocol) amplification became prominent in 2013-2014 and was responsible for some of the largest attacks of that era. The attack exploits the NTP "monlist" command, which returns a list of up to 600 clients that have recently connected to the NTP server.

The Monlist Command:

monlist (monitoring list) is a debugging feature in older NTP implementations:

• Single small query requests the monitor list
• Response contains up to 600 IP addresses of recent clients
• Each IP address entry consumes significant space
• Response is dramatically larger than request

The 2014 NTP Attack Wave:

In early 2014, massive NTP amplification attacks set records:

• February 2014: 400 Gbps attack against CloudFlare
• Multiple 100+ Gbps attacks against various targets
• Attacks exploited previously unknown amplifier pool

Current NTP Status:

The security community responded aggressively:

• NTP daemon updated to disable monlist by default
• Major scanning efforts identified and notified operators
• Many ISPs blocked public access to NTP
• Population of vulnerable servers significantly reduced

However, legacy systems and slow patching mean some vulnerable NTP servers remain. NTP amplification is less common now but not eliminated.

Other NTP Amplification Vectors:

Beyond monlist, other NTP commands offer amplification:

• ntpdc -c listpeers: Lists configured peers
• ntpdc -c sysinfo: System information
• Amplification factors lower than monlist but still significant

Mode 7 vs Mode 6:

NTP control messages come in two modes:

• Mode 6: Standard control queries (moderate amplification, ~10x)
• Mode 7: Private/debugging queries (monlist, high amplification)

Secure configurations should restrict Mode 7 responses to authenticated clients only.

In February 2018, memcached amplification attacks shattered all previous records. The attack against GitHub reached 1.35 Tbps—the largest DDoS ever recorded at that time. Memcached offered unprecedented amplification factors of up to 51,000x in extreme cases.

What Is Memcached?

Memcached is a distributed memory caching system used to speed up dynamic web applications:

• Stores key-value pairs in RAM for fast retrieval
• Designed for internal/trusted network use
• By default, listens on UDP port 11211
• No authentication in default configuration
• Clients can store arbitrary data and retrieve it later

The Amplification Mechanism:

Why Memcached Amplification Was So Powerful:

1. Extreme Amplification Factor: 10,000x-50,000x typical, far exceeding other vectors
2. Pre-Staged Payloads: Attackers could store multi-MB values for retrieval
3. Significant Population: Tens of thousands of exposed memcached servers existed
4. High Bandwidth Servers: Memcached typically runs on well-connected servers
5. No Authentication: Default configurations accept any request

The GitHub Attack (February 2018):

• Peak traffic: 1.35 Tbps (126.9 million packets per second)
• Duration: ~10 minutes total, ~5 minutes of intense attack
• Mitigated by Akamai Prolexic
• Attack came from over 1,000 autonomous systems (reflected traffic)
• GitHub experienced intermittent unavailability during peak

Community Response:

The memcached disclosure triggered rapid response:

• Urgent security advisories published
• Cloud providers scanned and notified customers
• Memcached developers added safer defaults
• ISPs began blocking port 11211 traffic
• Exposed instance population dropped dramatically within weeks

Current Status:

Aggressive remediation reduced the vulnerable population significantly. However:

• Some servers remain exposed
• New deployments occasionally misconfigured
• Memcached amplification still observed, though rarely at 2018 levels

Beyond DNS, NTP, and memcached, many other protocols offer amplification potential. Attackers continuously discover and exploit new vectors.

SSDP (Simple Service Discovery Protocol):

SSDP is used by UPnP devices to discover services on local networks:

• UDP-based (port 1900)
• Used by routers, smart TVs, gaming consoles, IoT devices
• Single discovery request yields multiple response packets
• Amplification factor: 20-30x typical

Why SSDP Is Problematic:

• Millions of devices have UPnP enabled by default
• Many respond to Internet-sourced requests (should be local only)
• Difficult to patch (consumer devices, rarely updated)

CharGen (Character Generator Protocol):

CharGen is a testing protocol that returns constant stream of characters:

• UDP port 19
• Designed for network testing in early Internet
• Sends characters until connection closes
• Potentially infinite amplification (continuous response)

Modern systems rarely run CharGen, but legacy systems and network testing equipment may still have it enabled.

SNMP (Simple Network Management Protocol):

SNMP is used for network device management:

• UDP port 161
• GetRequest returns device information
• GetBulk can return extensive data
• Amplification factor: 6-10x typical
• Many devices have default community strings (public/private)

Quote of the Day (QOTD):

Another obsolete testing protocol:

• UDP port 17
• Returns a short quote/message
• Minimal amplification but combined with other vectors
• Rarely encountered in modern networks

TFTP (Trivial File Transfer Protocol):

TFTP is a simple file transfer protocol:

• UDP port 69
• Used for network booting, firmware updates
• Read request can return large files
• Potential for significant amplification if files are large

Emerging Vectors:

Researchers continuously discover new amplifiable protocols:

• Protocol-specific services (gaming, IoT)
• Misconfigured microservices responding to UDP
• New Internet protocols with response asymmetry
• Research papers regularly document new vectors

Amplification attacks depend on the existence of responding servers—the "amplifiers" that reflect traffic to victims. Understanding this infrastructure reveals why the problem persists.

Why Amplifiers Exist:

Misconfiguration:

• Default configurations often too permissive
• Administrators unfamiliar with security implications
• "Works out of the box" prioritized over security

Legacy Systems:

• Old systems running outdated software
• Embedded devices never designed for security
• Firmware updates not applied or unavailable

Design Decisions:

• Protocols designed for trusted network environments
• Security added as afterthought (if at all)
• Convenience over security in consumer devices

Operational Inertia:

• "It's working, don't touch it"
• Security updates seen as risky
• No incentive to fix (amplifier owners rarely targeted directly)

Scanning for Amplifiers:

Attackers build amplifier lists through Internet scanning:

Masscan/Zmap: High-speed scanners can cover entire IPv4 space in hours Shodan/Censys: Search engines index Internet-facing services Custom Scanners: Protocol-specific probes identify vulnerable instances

The same tools used by security researchers are used by attackers. The difference is intent.

The Notification Challenge:

Security researchers attempt to notify amplifier operators:

Challenges:

• Identifying responsible parties from IP addresses
• Getting notifications to the right person
• Recipients dismissing notifications as spam/scam
• No legal requirement to remediate
• International operators beyond legal reach

Success Patterns:

• Major cloud providers respond quickly
• ISPs vary widely in responsiveness
• Consumer device operators often unreachable
• Coordinated disclosure through CERT programs

The Externality Problem:

Amplifier operators face a classic externality:

• Their misconfigured server works fine for its intended purpose
• The harm (DDoS attacks) affects someone else
• They bear no cost from the attacks
• Only social pressure or ISP requirements motivate fixing

This economic misalignment is why voluntary remediation is incomplete. Some propose regulatory requirements for network hygiene, but implementation remains challenging.

Defense against amplification attacks requires action at multiple layers: preventing attacks from being launched, reducing amplification potential, and absorbing attack traffic.

Source-Side Prevention (BCP38/BCP84):

The most effective mitigation is preventing IP spoofing:

BCP38 (Network Ingress Filtering):

• Networks filter outgoing packets with spoofed source addresses
• If universally adopted, reflection attacks become impossible
• Current adoption: ~70-75% of networks (insufficient)

Implementation:

Amplifier-Side Mitigations:

Reducing the pool of available amplifiers:

Protocol Updates:

• NTP: Disable monlist, use newer versions
• DNS: Implement Response Rate Limiting (RRL)
• Memcached: Disable UDP, require authentication

Network Restrictions:

• Restrict UDP services to known clients
• Use firewalls to limit source IPs
• Deploy services on non-default ports (obscurity, not security)

Victim-Side Defenses:

When attacked, victims have several options:

Upstream Filtering:

• ISP/transit provider blocks attack traffic
• Requires cooperative relationship with providers
• May affect legitimate traffic from amplifier networks

Scrubbing Services:

• Route traffic through DDoS mitigation provider
• Provider absorbs and filters attack traffic
• Clean traffic forwarded to origin

Anycast Distribution:

• Deploy services across multiple locations
• Attack traffic distributed across locations
• Each location handles portion of attack

Rate Limiting:

• Limit response rates to any single source
• Reduces amplification effectiveness
• May affect legitimate high-volume clients

Amplification attacks represent one of the most powerful tools in the DDoS attacker's arsenal. Let's consolidate the essential knowledge:

Looking Ahead:

With a comprehensive understanding of attack mechanics—including amplification—the final page of this module explores defense strategies in depth: the practical approaches organizations use to detect, mitigate, and recover from DDoS attacks.