DDoS Attack Types & Mitigation Methods: A Complete Reference

Different DDoS attacks require different defenses. A mitigation rule that stops a UDP flood will do nothing against an HTTP flood. A rate limit that blocks a SYN flood might also block legitimate users during a traffic spike. Understanding the specific characteristics of each attack type is essential for choosing the right mitigation method.

This reference covers every major DDoS attack type, explains how each one works at the protocol level, and pairs it with the specific mitigation techniques that are most effective against it.

Category 1: Volumetric Attacks

Volumetric attacks aim to consume all available bandwidth between your infrastructure and the internet. They are measured in bits per second (bps) and are the most common type of DDoS attack. The goal is simple: send more traffic than your pipe can handle.

UDP Flood

How it works: The attacker sends a massive number of UDP packets to random ports on the target server. For each packet received, the server checks for a listening application, finds none, and sends back an ICMP "destination unreachable" message. As the flood increases, the server becomes overwhelmed processing and responding to these packets.

Mitigation methods:

• Rate limit inbound UDP traffic per source IP
• Drop UDP traffic on ports that should not be receiving it
• Use BGP FlowSpec to filter UDP floods at the upstream router level
• For large floods, activate cloud scrubbing to absorb the volume upstream

# iptables: rate limit UDP and drop excess
iptables -A INPUT -p udp -m limit --limit 500/s --limit-burst 1000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

Flowtriq detects UDP floods within one second by monitoring the sudden spike in UDP PPS. It classifies the attack automatically and can apply iptables rules or escalate to FlowSpec based on your configured mitigation policy.

DNS Amplification

How it works: The attacker sends DNS queries with a spoofed source IP (your IP) to open DNS resolvers. The query requests a large DNS record (like an ANY query), and the resolver sends the much larger response to your server. Amplification factors of 28-54x are common, meaning a 1 Gbps attack stream can generate a 28-54 Gbps flood targeting your infrastructure.

Mitigation methods:

• Block inbound DNS responses (UDP source port 53) if you are not expecting them
• Rate limit DNS traffic from external sources
• Use response rate limiting (RRL) on your own DNS servers
• Deploy BGP FlowSpec rules to filter DNS amplification at the upstream level
• Cloud scrubbing for large-scale amplification attacks

# Block unsolicited DNS responses
iptables -A INPUT -p udp --sport 53 -m state --state NEW -j DROP

NTP Amplification

How it works: Similar to DNS amplification, but exploits the NTP monlist command on misconfigured NTP servers. The attacker sends a small monlist request with your spoofed IP, and the NTP server responds with a list of the last 600 clients that connected, resulting in amplification factors up to 556x.

Mitigation methods:

• Block inbound NTP traffic (UDP source port 123) from external sources if you do not use external NTP
• Rate limit NTP responses
• Disable monlist on any NTP servers you operate
• BGP FlowSpec to filter at the upstream level

Memcached Amplification

How it works: Memcached servers exposed to the internet can be exploited for amplification attacks with factors exceeding 50,000x. The attacker sends a small request to a memcached server with your spoofed IP, and the server responds with a massive data payload.

Mitigation methods:

• Never expose memcached to the public internet (bind to localhost or private IPs)
• Block inbound UDP traffic from port 11211
• Disable UDP on memcached instances entirely
• Upstream filtering via BGP FlowSpec for active attacks

SSDP Amplification

How it works: The Simple Service Discovery Protocol (SSDP) is used by UPnP devices. Attackers send SSDP discovery requests to exposed devices with your spoofed IP. Each device responds with information about its services, producing amplification factors around 30x.

Mitigation methods:

• Block inbound UDP traffic from port 1900
• Disable UPnP on network devices exposed to the internet
• Rate limit SSDP responses at the firewall level

Category 2: Protocol Attacks

Protocol attacks exploit weaknesses in Layer 3 and Layer 4 protocols to consume server resources like connection tables, CPU cycles, and memory. They are measured in packets per second (PPS) and often do not require massive bandwidth to be effective.

SYN Flood

How it works: The attacker sends a flood of TCP SYN packets, initiating thousands of connections without ever completing the three-way handshake. Each half-open connection consumes an entry in the server's connection tracking table. When the table fills up, the server cannot accept new connections from legitimate users.

Mitigation methods:

• Enable SYN cookies (net.ipv4.tcp_syncookies = 1) so the kernel does not allocate resources until the handshake completes
• Increase the SYN backlog size (net.ipv4.tcp_max_syn_backlog)
• Reduce the SYN-RECV timeout (net.ipv4.tcp_synack_retries)
• Rate limit SYN packets per source IP with iptables
• Use connection tracking limits to cap half-open connections

# Enable SYN cookies
sysctl -w net.ipv4.tcp_syncookies=1

# Rate limit SYN packets
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Flowtriq detects SYN floods by monitoring the ratio of SYN packets to completed connections. A sudden spike in SYN packets without corresponding ACKs triggers automatic detection and classification.

TCP ACK Flood

How it works: The attacker sends a flood of TCP ACK packets that do not belong to any established connection. The server must process each packet to determine that it is not part of a valid session, consuming CPU resources.

Mitigation methods:

• Use stateful firewall rules that drop ACK packets not associated with established connections
• Enable net.ipv4.tcp_tw_reuse to handle TIME_WAIT connections more efficiently
• Rate limit ACK packets per source IP

# Drop ACK packets that don't match established connections
iptables -A INPUT -p tcp --tcp-flags ACK ACK -m state --state NEW -j DROP

TCP RST Flood

How it works: The attacker sends spoofed TCP RST (reset) packets to disrupt established connections between your server and its clients. If a RST packet matches an existing connection's sequence number, the connection is torn down.

Mitigation methods:

• Enable TCP sequence number validation
• Use net.ipv4.tcp_rfc1337 = 1 to protect against RST attacks on TIME_WAIT connections
• Rate limit RST packets per source

ICMP Flood (Ping Flood)

How it works: The attacker sends a massive number of ICMP echo request (ping) packets. The server must process each packet and generate an echo reply, consuming CPU and bandwidth.

Mitigation methods:

• Rate limit ICMP traffic at the firewall
• Disable ICMP echo responses if ping is not required for your services
• Use BGP FlowSpec to filter ICMP floods upstream

# Rate limit ICMP
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

GRE Flood

How it works: The attacker sends a flood of GRE (Generic Routing Encapsulation) packets. GRE is used in VPN tunnels, and a GRE flood can overwhelm decapsulation processing on servers or routers that handle GRE traffic.

Mitigation methods:

• Drop GRE traffic (IP protocol 47) if you do not use GRE tunnels
• Rate limit GRE traffic to expected levels
• Filter at the upstream router with BGP FlowSpec

Flowtriq includes GRE flood as one of its eight automatic classification categories, detecting and alerting on GRE-based attacks alongside all other protocol types.

Category 3: Application-Layer Attacks

Application-layer attacks target Layer 7 of the OSI model. They use legitimate-looking requests to overwhelm your web server or application. These attacks are the hardest to detect because each individual request appears valid.

HTTP Flood

How it works: The attacker sends a high volume of HTTP GET or POST requests to your web server. The requests target resource-intensive endpoints like search pages, login forms, or API endpoints that trigger database queries. Each request is valid HTTP, making it hard to distinguish from legitimate traffic.

Mitigation methods:

• Implement rate limiting per IP at the web server or load balancer level
• Use JavaScript challenges or CAPTCHAs to verify human users
• Deploy a Web Application Firewall (WAF) with bot detection
• Cache resource-intensive endpoints to reduce backend load
• Block requests with suspicious User-Agent strings or missing headers

# nginx rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
}

Slowloris

How it works: Slowloris opens multiple connections to your web server and keeps them alive by sending partial HTTP headers, one byte at a time. The server keeps each connection open waiting for the headers to complete, eventually exhausting its maximum connection limit.

Mitigation methods:

• Set aggressive connection timeouts for incomplete requests
• Limit the number of concurrent connections per IP
• Use a reverse proxy (nginx, HAProxy) that buffers requests before forwarding to backend servers
• Increase your web server's maximum connection limit

# nginx: limit connections per IP and set header timeout
limit_conn_zone $binary_remote_addr zone=connlimit:10m;
limit_conn connlimit 20;
client_header_timeout 10s;
client_body_timeout 10s;

DNS Query Flood

How it works: Unlike DNS amplification (which targets the victim with reflected responses), a DNS query flood targets your DNS server directly with a massive number of queries. The queries may be for valid domains or random subdomains, designed to overwhelm your DNS server's processing capacity.

Mitigation methods:

• Deploy response rate limiting (RRL) on your DNS servers
• Use anycast DNS to distribute query load across multiple servers
• Rate limit queries per source IP
• Block queries for obviously fake subdomains (random string detection)

RUDY (R-U-Dead-Yet)

How it works: RUDY sends HTTP POST requests with a legitimate Content-Length header but transmits the body extremely slowly, one byte at a time. The server allocates resources to receive the full body, and many concurrent slow posts can exhaust server capacity.

Mitigation methods:

• Set minimum data transfer rates on your web server
• Implement request body timeout limits
• Use a reverse proxy that buffers the full request before forwarding
• Limit the maximum request body size for endpoints that do not need large uploads

Multi-Vector Attacks

Modern attacks rarely use a single vector. Sophisticated attackers combine multiple attack types simultaneously. They might launch a volumetric UDP flood to distract your operations team while running a low-and-slow HTTP flood against your API. Or they might start with a SYN flood to exhaust your connection table, then follow up with an application-layer attack once your defenses are degraded.

Defending against multi-vector attacks requires detection and mitigation capabilities across all layers. This is where Flowtriq's automatic classification becomes critical. Instead of alerting you to a generic "traffic anomaly," Flowtriq identifies each concurrent attack vector separately, allowing your automated mitigation rules to apply the correct response for each one.

Choosing the Right Mitigation for Your Infrastructure

Your mitigation strategy should be based on two factors: the attack types you are most likely to face, and the resources you have available.

• Web applications: Focus on HTTP flood protection (WAF, rate limiting, CDN), SYN flood defense (SYN cookies), and upstream scrubbing for volumetric attacks
• Game servers: Prioritize UDP flood mitigation (firewall rules, FlowSpec), protocol attack defense, and fast detection to minimize player impact
• DNS infrastructure: Deploy RRL, anycast, and upstream filtering for both amplification and direct query floods
• API services: Layer rate limiting, bot detection, and application-level monitoring on top of network-layer defenses

Regardless of your specific workload, host-level detection with automatic classification gives you the visibility to respond correctly to whatever attack type hits you. Flowtriq's one-second detection and eight-category classification system ensures you always know what you are dealing with.

Back to Blog

Related Articles