System Design (HLD)DDoS Protection

DDoS Protection

LevelAdvanced

Duration90 mins

TopicDDoS Protection

2 / 5

Layer 3/4 Protection

Defending at the Network Foundation

When a massive volumetric DDoS attack arrives—hundreds of gigabits or terabits of malicious traffic—there's no application-level cleverness that can save you. Before any HTTP request reaches your web server, before any business logic executes, the raw flood of packets must be absorbed, filtered, and discarded somewhere. That somewhere is Layer 3/4 protection.

Network-layer defense is the first line of defense against DDoS attacks. It operates at the infrastructure level, often before traffic even reaches your origin servers. Without robust L3/L4 protection, even the most secure application will become unreachable under attack.

This page explores the complete spectrum of network-layer protection mechanisms: from on-premises defenses to cloud-based scrubbing centers, from protocol-level hardening to sophisticated traffic analysis.

What You Will Learn

By the end of this page, you will understand how to design network-layer defenses that absorb volumetric attacks, neutralize protocol exploits, and ensure your services remain available even under the most aggressive DDoS campaigns. You'll learn about upstream filtering, scrubbing centers, anycast architectures, and protocol-level hardening.

The Challenge of Volumetric Defense

Defending against volumetric attacks presents a fundamental problem: you cannot filter what you cannot receive. If an attack exceeds your network capacity, legitimate traffic will be dropped before any filtering can occur.

Consider a typical enterprise setup:

Organization has 10 Gbps internet connectivity
Normal traffic: 2 Gbps
Attack traffic: 100 Gbps
Result: 98 Gbps dropped at upstream routers, including legitimate traffic

The organization's firewall never sees most traffic—it's discarded before it arrives. This is why volumetric defense cannot be solved locally; it must be addressed upstream, where capacity exists.

The Capacity Gap:

Most organizations have internet connectivity measured in megabits or single-digit gigabits. Attack capacity available for rent measures in terabits. This 1000x+ asymmetry means organizations cannot simply "buy more bandwidth" as a defense strategy.

Capacity Asymmetry in DDoS Defense
Entity	Typical Capacity	Attack Capacity	Gap
Small Business	100 Mbps	100 Gbps	1000x
Enterprise	10 Gbps	500 Gbps	50x
Large Enterprise	100 Gbps	1 Tbps	10x
Tier 1 ISP	Multi-Tbps	1 Tbps	~Equal
Major CDN	100+ Tbps	1 Tbps	100x advantage

The Economics of Defense

The solution to the capacity gap is to leverage providers who have invested in massive network capacity: CDNs, cloud providers, and specialized DDoS mitigation services. These providers amortize capacity costs across thousands of customers, making enterprise-grade protection economically viable.

Upstream Filtering Strategies

Upstream filtering refers to blocking attack traffic before it reaches your network edge. This is accomplished by working with upstream providers—ISPs, transit providers, and peering partners—to filter or blackhole malicious traffic.

ISP-Level Filtering:

Internet Service Providers can implement filters at their network edge:

Access Control Lists (ACLs) — Block specific source IPs, IP ranges, or protocols
Rate limiting — Throttle specific traffic types (e.g., ICMP, UDP to specific ports)
Protocol filtering — Block traffic that should never originate from certain sources

However, ISP cooperation requires pre-established relationships and may have limited granularity.

Remote Triggered Black Hole (RTBH):

RTBH is a powerful technique for volumetric attack mitigation, though it has significant tradeoffs:

How RTBH Works:

Organization detects attack targeting specific IP address
Organization announces that IP to upstream providers with special community string
Providers route all traffic to that IP to a "black hole" (null route)
Attack traffic is dropped at upstream networks
But so is all legitimate traffic to that IP

RTBH is essentially self-imposed denial of service—you take down the target before the attacker does, but at least you control when it recovers. It's useful for:

Protecting other IPs/services on your network from collateral damage
Sacrificing one service to save others
Buying time to implement more surgical mitigations

Converting Mermaid diagram...

RTBH Tradeoffs

RTBH drops ALL traffic to the targeted prefix—legitimate and malicious alike. It's a last-resort option when the alternative is network-wide degradation. More sophisticated approaches (flowspec, scrubbing) allow selective filtering without complete outage.

BGP Flowspec:

BGP Flowspec extends BGP to distribute traffic filtering rules across networks. Unlike RTBH, it enables granular filtering:

Block traffic matching specific source/destination IP combinations
Filter by protocol, port, packet length, fragment flags
Apply rate limiting instead of dropping
Redirect matching traffic to scrubbing infrastructure

Flowspec requires support from upstream providers and careful implementation to avoid accidentally blocking legitimate traffic.

Scrubbing Centers: Surgical Traffic Filtering

DDoS scrubbing centers are specialized facilities designed to absorb massive traffic volumes, analyze each packet or flow, filter malicious traffic, and forward only clean traffic to protected networks. They represent the gold standard for volumetric attack mitigation.

How Scrubbing Works:

Traffic Diversion — During attack, traffic is redirected to scrubbing center
- BGP route announcements attract traffic to scrubbing infrastructure
- DNS-based diversion for specific hostnames
- GRE tunnels for always-on protection
Deep Packet Inspection — Traffic is analyzed at multiple layers
- Protocol validity checks
- Rate analysis and anomaly detection
- Signature matching for known attack patterns
- Behavioral analysis for suspicious patterns
Filtering — Malicious traffic is dropped
- Stateless filters for obvious attacks (invalid protocols, known bad sources)
- Stateful filters for protocol attacks (SYN flood detection)
- Application-aware filters for L7 attacks
Forwarding — Clean traffic returns to origin
- GRE tunnel back to customer network
- Direct peering at scrubbing facility
- Proxy-based forwarding

Converting Mermaid diagram...

Deployment Models:

Scrubbing Deployment Options

•On-Demand Scrubbing — Traffic flows directly to origin normally; diverts to scrubbing only during detected attacks. Lower cost but introduces diversion latency during attacks. Typically 10-30 second switchover.
•Always-On Scrubbing — All traffic permanently routes through scrubbing infrastructure. Higher cost but zero switchover delay. Best for organizations that cannot tolerate any attack impact.
•Hybrid Model — Low-volume L7 protection always-on; volumetric scrubbing on-demand. Balances cost with protection for most common attack scenarios.

Major DDoS Scrubbing Providers
Provider	Capacity	Global POPs	Key Features
Cloudflare	209+ Tbps	300+	Free tier, integrated CDN/WAF
Akamai Prolexic	Multi-Tbps	25+ scrubbing	Legacy enterprise, dedicated SOC
AWS Shield Advanced	Multi-Tbps	AWS regions	Native AWS integration
Azure DDoS Protection	Multi-Tbps	Azure regions	Native Azure integration
Google Cloud Armor	Google scale	GCP edge	ML-based detection
Neustar/Vercara	12+ Tbps	14 global	Managed service focus

Anycast Architecture: Distributed by Design

Anycast is a networking technique where the same IP address is announced from multiple geographic locations. Routers direct traffic to the nearest (topologically) instance. This architecture provides inherent DDoS resilience.

Why Anycast Helps:

Geographic Distribution — Attack traffic from different regions hits different anycast nodes
Automatic Load Distribution — No single point absorbs all attack traffic
Local Absorption — Each node only handles traffic from its region
Graceful Degradation — Overwhelmed nodes withdraw routes; traffic shifts automatically

Example:

Imagine a 500 Gbps attack distributed globally. With anycast across 10 locations:

Each location receives ~50 Gbps
Each location has 100 Gbps capacity
Attack absorbed without service impact

Without anycast (single location):

One location receives 500 Gbps
Location has 100 Gbps capacity
400 Gbps of legitimate traffic dropped
Complete service outage

Converting Mermaid diagram...

CDNs and Anycast

Major CDNs (Cloudflare, Akamai, Fastly) use anycast extensively. When you put your service behind a CDN, you automatically gain anycast's DDoS resilience benefits. This is one reason CDNs provide excellent DDoS protection without specialized scrubbing—the architecture itself is defensive.

Anycast Limitations:

Anycast isn't a complete solution:

Concentrated attacks — If attack traffic is geographically concentrated (all from one region), that node still overwhelms
Stateful protocols — TCP connections may break if routing changes mid-session
Operational complexity — Requires BGP expertise and multiple network presence
Cost — Multi-location infrastructure is expensive

For most organizations, leveraging CDN or cloud provider anycast is more practical than building custom anycast infrastructure.

Protocol-Level Hardening

Beyond upstream filtering and traffic absorption, servers and load balancers must be hardened against protocol attacks. These defenses operate at your network edge.

SYN Cookie Protection:

SYN cookies defend against SYN flood attacks without allocating state for half-open connections:

Server receives SYN
Instead of allocating connection state, server encodes connection info in the initial sequence number (the "cookie")
Server sends SYN-ACK with encoded sequence number
If legitimate client responds with ACK, the ACK number contains the encoded info
Server reconstructs connection state only for completing connections

This transforms the attack from a state exhaustion attack to a bandwidth attack, which is easier to handle.

Linux SYN Cookie Configuration
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Enable SYN cookies (usually default in modern kernels)
sysctl -w net.ipv4.tcp_syncookies=1
 
# Increase SYN backlog for high-traffic servers
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
 
# Reduce SYN-ACK retries (faster cleanup of half-open connections)
sysctl -w net.ipv4.tcp_synack_retries=2
 
# Enable TCP timestamps (required for SYN cookies with options)
sysctl -w net.ipv4.tcp_timestamps=1
 
# Increase connection tracking table size
sysctl -w net.netfilter.nf_conntrack_max=1000000
 
# Reduce connection tracking timeout for established connections
# (be careful with long-lived connections)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600

Connection Limits:

Limit resources any single source can consume:

iptables Connection Limiting
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Limit new connections per source IP per minute
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j DROP
 
# Rate limit new connections globally
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
 
# Limit ICMP to prevent ping floods
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
 
# Block invalid packets (common in flood attacks)
iptables -A INPUT -m state --state INVALID -j DROP
 
# Block common amplification source ports
iptables -A INPUT -p udp --sport 19 -j DROP  # chargen
iptables -A INPUT -p udp --sport 53 -j DROP  # DNS (if not needed)
iptables -A INPUT -p udp --sport 123 -j DROP # NTP (if not needed)
iptables -A INPUT -p udp --sport 1900 -j DROP # SSDP

Additional Protocol Hardening

•Disable unused protocols — If you don't need ICMP, UDP on specific ports, or legacy protocols, block them entirely
•Enable strict source validation — Use reverse path filtering (rp_filter) to drop packets with spoofed sources
•Configure TCP keepalive — Detect and close dead connections faster
•Tune listen backlog — Increase for high-traffic servers to handle connection bursts
•Use hardware NICs with offloading — Modern NICs can handle SYN cookies and rate limiting in hardware

Load Balancer DDoS Features

Modern load balancers include extensive DDoS mitigation capabilities. Properly configured, they provide a critical defense layer.

AWS Network Load Balancer (NLB):

Handles millions of connections per second
Built-in SYN flood protection
Integrates with AWS Shield
Scales automatically with traffic

AWS Application Load Balancer (ALB):

HTTP-layer processing with connection queuing
Integration with WAF for L7 protection
Automatic scaling across multiple AZs
Pre-warming available for expected traffic spikes

NGINX Rate Limiting Configuration
nginx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Define rate limiting zones
limit_req_zone $binary_remote_addr zone=global:10m rate=100r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=50r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;
 
# Main server configuration
server {
    listen 80;
    
    # Connection limits per IP
    limit_conn addr 50;
    
    # Global rate limit with burst capability
    limit_req zone=global burst=200 nodelay;
    
    # Stricter rate limit for API endpoints
    location /api/ {
        limit_req zone=api burst=100 nodelay;
        
        # Return 429 instead of 503 for rate limits
        limit_req_status 429;
        limit_conn_status 429;
        
        proxy_pass http://backend;
    }
    
    # Timeout configurations to mitigate slow attacks
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 30s;
    send_timeout 10s;
    
    # Limit request body size
    client_max_body_size 10m;
    
    # Buffer sizes to prevent slow attacks
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}

Cloud Load Balancer DDoS Capabilities
Feature	AWS ELB/ALB	GCP Load Balancer	Azure Load Balancer
SYN Flood Protection	Yes (NLB)	Yes	Yes
Connection Limits	Configurable	Configurable	Configurable
Auto-scaling	Yes	Yes	Yes
DDoS Service Integration	AWS Shield	Cloud Armor	Azure DDoS Protection
Anycast	Yes (Global)	Yes	Limited
WebSocket Protection	ALB only	Yes	App Gateway

Traffic Analysis and Attack Detection

Effective L3/L4 protection requires detecting attacks quickly and accurately. This demands sophisticated traffic analysis.

NetFlow/IPFIX Analysis:

NetFlow (Cisco) and IPFIX are protocols for exporting traffic metadata from network devices:

Source/destination IP and port
Protocol, packet count, byte count
Timestamps and flow duration

Analyzing flow data enables:

Baseline establishment (normal traffic patterns)
Anomaly detection (deviations from baseline)
Attack signature matching
Post-incident forensics

Detection Indicators:

L3/L4 attacks exhibit characteristic patterns that automated systems can detect:

Volumetric Attack Indicators

•Sudden spike in bits/packets per second
•UDP traffic volume increase
•Traffic from unusual geographic sources
•High amplification protocol traffic
•Interface saturation

Protocol Attack Indicators

•SYN packet rate spike
•Half-open connection growth
•Connection timeout rate increase
•ACK/RST packet anomalies
•Fragmentation anomalies

Baseline is Everything

Attack detection depends on knowing what 'normal' looks like. Invest in traffic baselining before you need it. Understand your traffic patterns by day of week, time of day, and seasonal variations. Without a baseline, you can't distinguish a marketing campaign from an attack.

Machine Learning Detection:

Modern DDoS detection increasingly uses ML:

Supervised learning — Train on labeled attack/normal traffic
Unsupervised learning — Detect anomalies without labeled data
Deep learning — Complex pattern recognition in flow sequences

ML enables detection of novel attacks that don't match known signatures, but requires careful tuning to avoid false positives that disrupt legitimate traffic.

L3/L4 Defense Architecture Best Practices

Combining the techniques we've covered, here's a comprehensive L3/L4 defense architecture:

Converting Mermaid diagram...

Architecture Principles

•Lead with capacity — First defense layer must have more capacity than expected attacks (CDN/cloud)
•Filter early — Drop obvious bad traffic as close to source as possible
•Layer defenses — Each layer catches what previous layers missed
•Automate detection — Humans can't react fast enough; automation must trigger defenses
•Plan for failure — Each layer should degrade gracefully if overwhelmed
•Test regularly — Simulate attacks to validate defenses before real attacks occur
•Hide origins — Don't expose origin server IPs; all traffic through defensive layers

Never Expose Origin Servers

A common mistake is exposing origin server IPs directly. If attackers discover your origin IP, they can bypass CDN/scrubbing by attacking it directly. Use private connectivity (AWS PrivateLink, GCP Private Service Connect) between edge and origin. Regularly audit DNS history and SSL certificates for leaked origins.

Summary: Layer 3/4 Protection

Layer 3/4 protection forms the foundation of DDoS defense. Without it, all other protections fail when volumetric attacks saturate your network capacity.

Key Takeaways

•Capacity gap is fundamental — Most organizations cannot absorb large attacks locally; leverage providers who can
•Upstream filtering is essential — Work with ISPs and use RTBH/Flowspec for pre-network filtering
•Scrubbing centers provide surgical mitigation — On-demand or always-on, they analyze and filter attack traffic
•Anycast architecture distributes load — Geographic distribution prevents any single point from overwhelming
•Protocol hardening protects edge — SYN cookies, connection limits, and proper kernel tuning defend against protocol attacks
•Load balancers add defense layers — Cloud and on-premises load balancers provide built-in DDoS features
•Detection requires baselines — You can't detect attacks without understanding normal traffic patterns
•Defense in depth is non-negotiable — Layer multiple protection mechanisms; no single layer is sufficient

What's Next:

L3/L4 protection handles volumetric and protocol attacks, but sophisticated L7 attacks require application-layer defenses. The next page explores Layer 7 protection—Web Application Firewalls, rate limiting, bot detection, and application-aware filtering that defends against attacks that volumetric protections cannot stop.

Page Complete

You now understand the full spectrum of Layer 3/4 DDoS protection mechanisms, from upstream filtering to protocol hardening. Combined with proper architectural design, these defenses ensure your infrastructure can absorb and filter massive attack volumes while keeping services available.

2 / 5

Loading learning content...

System Design (HLD)DDoS Protection

DDoS Protection

LevelAdvanced

Duration90 mins

TopicDDoS Protection

2 / 5

Layer 3/4 Protection

Defending at the Network Foundation

What You Will Learn

The Challenge of Volumetric Defense

Consider a typical enterprise setup:

Organization has 10 Gbps internet connectivity
Normal traffic: 2 Gbps
Attack traffic: 100 Gbps
Result: 98 Gbps dropped at upstream routers, including legitimate traffic

The Capacity Gap:

Capacity Asymmetry in DDoS Defense
Entity	Typical Capacity	Attack Capacity	Gap
Small Business	100 Mbps	100 Gbps	1000x
Enterprise	10 Gbps	500 Gbps	50x
Large Enterprise	100 Gbps	1 Tbps	10x
Tier 1 ISP	Multi-Tbps	1 Tbps	~Equal
Major CDN	100+ Tbps	1 Tbps	100x advantage

The Economics of Defense

Upstream Filtering Strategies

ISP-Level Filtering:

Internet Service Providers can implement filters at their network edge:

Access Control Lists (ACLs) — Block specific source IPs, IP ranges, or protocols
Rate limiting — Throttle specific traffic types (e.g., ICMP, UDP to specific ports)
Protocol filtering — Block traffic that should never originate from certain sources

However, ISP cooperation requires pre-established relationships and may have limited granularity.

Remote Triggered Black Hole (RTBH):

RTBH is a powerful technique for volumetric attack mitigation, though it has significant tradeoffs:

How RTBH Works:

Organization detects attack targeting specific IP address
Organization announces that IP to upstream providers with special community string
Providers route all traffic to that IP to a "black hole" (null route)
Attack traffic is dropped at upstream networks
But so is all legitimate traffic to that IP

RTBH is essentially self-imposed denial of service—you take down the target before the attacker does, but at least you control when it recovers. It's useful for:

Protecting other IPs/services on your network from collateral damage
Sacrificing one service to save others
Buying time to implement more surgical mitigations

Converting Mermaid diagram...

RTBH Tradeoffs

BGP Flowspec:

BGP Flowspec extends BGP to distribute traffic filtering rules across networks. Unlike RTBH, it enables granular filtering:

Block traffic matching specific source/destination IP combinations
Filter by protocol, port, packet length, fragment flags
Apply rate limiting instead of dropping
Redirect matching traffic to scrubbing infrastructure

Flowspec requires support from upstream providers and careful implementation to avoid accidentally blocking legitimate traffic.

Scrubbing Centers: Surgical Traffic Filtering

How Scrubbing Works:

Traffic Diversion — During attack, traffic is redirected to scrubbing center
- BGP route announcements attract traffic to scrubbing infrastructure
- DNS-based diversion for specific hostnames
- GRE tunnels for always-on protection
Deep Packet Inspection — Traffic is analyzed at multiple layers
- Protocol validity checks
- Rate analysis and anomaly detection
- Signature matching for known attack patterns
- Behavioral analysis for suspicious patterns
Filtering — Malicious traffic is dropped
- Stateless filters for obvious attacks (invalid protocols, known bad sources)
- Stateful filters for protocol attacks (SYN flood detection)
- Application-aware filters for L7 attacks
Forwarding — Clean traffic returns to origin
- GRE tunnel back to customer network
- Direct peering at scrubbing facility
- Proxy-based forwarding

Converting Mermaid diagram...

Deployment Models:

Scrubbing Deployment Options

•On-Demand Scrubbing — Traffic flows directly to origin normally; diverts to scrubbing only during detected attacks. Lower cost but introduces diversion latency during attacks. Typically 10-30 second switchover.
•Always-On Scrubbing — All traffic permanently routes through scrubbing infrastructure. Higher cost but zero switchover delay. Best for organizations that cannot tolerate any attack impact.
•Hybrid Model — Low-volume L7 protection always-on; volumetric scrubbing on-demand. Balances cost with protection for most common attack scenarios.

Major DDoS Scrubbing Providers
Provider	Capacity	Global POPs	Key Features
Cloudflare	209+ Tbps	300+	Free tier, integrated CDN/WAF
Akamai Prolexic	Multi-Tbps	25+ scrubbing	Legacy enterprise, dedicated SOC
AWS Shield Advanced	Multi-Tbps	AWS regions	Native AWS integration
Azure DDoS Protection	Multi-Tbps	Azure regions	Native Azure integration
Google Cloud Armor	Google scale	GCP edge	ML-based detection
Neustar/Vercara	12+ Tbps	14 global	Managed service focus

Anycast Architecture: Distributed by Design

Why Anycast Helps:

Geographic Distribution — Attack traffic from different regions hits different anycast nodes
Automatic Load Distribution — No single point absorbs all attack traffic
Local Absorption — Each node only handles traffic from its region
Graceful Degradation — Overwhelmed nodes withdraw routes; traffic shifts automatically

Example:

Imagine a 500 Gbps attack distributed globally. With anycast across 10 locations:

Each location receives ~50 Gbps
Each location has 100 Gbps capacity
Attack absorbed without service impact

Without anycast (single location):

One location receives 500 Gbps
Location has 100 Gbps capacity
400 Gbps of legitimate traffic dropped
Complete service outage

Converting Mermaid diagram...

CDNs and Anycast

Anycast Limitations:

Anycast isn't a complete solution:

Concentrated attacks — If attack traffic is geographically concentrated (all from one region), that node still overwhelms
Stateful protocols — TCP connections may break if routing changes mid-session
Operational complexity — Requires BGP expertise and multiple network presence
Cost — Multi-location infrastructure is expensive

For most organizations, leveraging CDN or cloud provider anycast is more practical than building custom anycast infrastructure.

Protocol-Level Hardening

Beyond upstream filtering and traffic absorption, servers and load balancers must be hardened against protocol attacks. These defenses operate at your network edge.

SYN Cookie Protection:

SYN cookies defend against SYN flood attacks without allocating state for half-open connections:

Server receives SYN
Instead of allocating connection state, server encodes connection info in the initial sequence number (the "cookie")
Server sends SYN-ACK with encoded sequence number
If legitimate client responds with ACK, the ACK number contains the encoded info
Server reconstructs connection state only for completing connections

This transforms the attack from a state exhaustion attack to a bandwidth attack, which is easier to handle.

Linux SYN Cookie Configuration
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Enable SYN cookies (usually default in modern kernels)
sysctl -w net.ipv4.tcp_syncookies=1
 
# Increase SYN backlog for high-traffic servers
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
 
# Reduce SYN-ACK retries (faster cleanup of half-open connections)
sysctl -w net.ipv4.tcp_synack_retries=2
 
# Enable TCP timestamps (required for SYN cookies with options)
sysctl -w net.ipv4.tcp_timestamps=1
 
# Increase connection tracking table size
sysctl -w net.netfilter.nf_conntrack_max=1000000
 
# Reduce connection tracking timeout for established connections
# (be careful with long-lived connections)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600

Connection Limits:

Limit resources any single source can consume:

iptables Connection Limiting
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Limit new connections per source IP per minute
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j DROP
 
# Rate limit new connections globally
iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
 
# Limit ICMP to prevent ping floods
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
 
# Block invalid packets (common in flood attacks)
iptables -A INPUT -m state --state INVALID -j DROP
 
# Block common amplification source ports
iptables -A INPUT -p udp --sport 19 -j DROP  # chargen
iptables -A INPUT -p udp --sport 53 -j DROP  # DNS (if not needed)
iptables -A INPUT -p udp --sport 123 -j DROP # NTP (if not needed)
iptables -A INPUT -p udp --sport 1900 -j DROP # SSDP

Additional Protocol Hardening

•Disable unused protocols — If you don't need ICMP, UDP on specific ports, or legacy protocols, block them entirely
•Enable strict source validation — Use reverse path filtering (rp_filter) to drop packets with spoofed sources
•Configure TCP keepalive — Detect and close dead connections faster
•Tune listen backlog — Increase for high-traffic servers to handle connection bursts
•Use hardware NICs with offloading — Modern NICs can handle SYN cookies and rate limiting in hardware

Load Balancer DDoS Features

Modern load balancers include extensive DDoS mitigation capabilities. Properly configured, they provide a critical defense layer.

AWS Network Load Balancer (NLB):

Handles millions of connections per second
Built-in SYN flood protection
Integrates with AWS Shield
Scales automatically with traffic

AWS Application Load Balancer (ALB):

HTTP-layer processing with connection queuing
Integration with WAF for L7 protection
Automatic scaling across multiple AZs
Pre-warming available for expected traffic spikes

NGINX Rate Limiting Configuration
nginx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Define rate limiting zones
limit_req_zone $binary_remote_addr zone=global:10m rate=100r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=50r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;
 
# Main server configuration
server {
    listen 80;
    
    # Connection limits per IP
    limit_conn addr 50;
    
    # Global rate limit with burst capability
    limit_req zone=global burst=200 nodelay;
    
    # Stricter rate limit for API endpoints
    location /api/ {
        limit_req zone=api burst=100 nodelay;
        
        # Return 429 instead of 503 for rate limits
        limit_req_status 429;
        limit_conn_status 429;
        
        proxy_pass http://backend;
    }
    
    # Timeout configurations to mitigate slow attacks
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 30s;
    send_timeout 10s;
    
    # Limit request body size
    client_max_body_size 10m;
    
    # Buffer sizes to prevent slow attacks
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
}

Cloud Load Balancer DDoS Capabilities
Feature	AWS ELB/ALB	GCP Load Balancer	Azure Load Balancer
SYN Flood Protection	Yes (NLB)	Yes	Yes
Connection Limits	Configurable	Configurable	Configurable
Auto-scaling	Yes	Yes	Yes
DDoS Service Integration	AWS Shield	Cloud Armor	Azure DDoS Protection
Anycast	Yes (Global)	Yes	Limited
WebSocket Protection	ALB only	Yes	App Gateway

Traffic Analysis and Attack Detection

Effective L3/L4 protection requires detecting attacks quickly and accurately. This demands sophisticated traffic analysis.

NetFlow/IPFIX Analysis:

NetFlow (Cisco) and IPFIX are protocols for exporting traffic metadata from network devices:

Source/destination IP and port
Protocol, packet count, byte count
Timestamps and flow duration

Analyzing flow data enables:

Baseline establishment (normal traffic patterns)
Anomaly detection (deviations from baseline)
Attack signature matching
Post-incident forensics

Detection Indicators:

L3/L4 attacks exhibit characteristic patterns that automated systems can detect:

Volumetric Attack Indicators

•Sudden spike in bits/packets per second
•UDP traffic volume increase
•Traffic from unusual geographic sources
•High amplification protocol traffic
•Interface saturation

Protocol Attack Indicators

•SYN packet rate spike
•Half-open connection growth
•Connection timeout rate increase
•ACK/RST packet anomalies
•Fragmentation anomalies

Baseline is Everything

Machine Learning Detection:

Modern DDoS detection increasingly uses ML:

Supervised learning — Train on labeled attack/normal traffic
Unsupervised learning — Detect anomalies without labeled data
Deep learning — Complex pattern recognition in flow sequences

ML enables detection of novel attacks that don't match known signatures, but requires careful tuning to avoid false positives that disrupt legitimate traffic.

L3/L4 Defense Architecture Best Practices

Combining the techniques we've covered, here's a comprehensive L3/L4 defense architecture:

Converting Mermaid diagram...

Architecture Principles

•Lead with capacity — First defense layer must have more capacity than expected attacks (CDN/cloud)
•Filter early — Drop obvious bad traffic as close to source as possible
•Layer defenses — Each layer catches what previous layers missed
•Automate detection — Humans can't react fast enough; automation must trigger defenses
•Plan for failure — Each layer should degrade gracefully if overwhelmed
•Test regularly — Simulate attacks to validate defenses before real attacks occur
•Hide origins — Don't expose origin server IPs; all traffic through defensive layers

Never Expose Origin Servers

Summary: Layer 3/4 Protection

Layer 3/4 protection forms the foundation of DDoS defense. Without it, all other protections fail when volumetric attacks saturate your network capacity.

Key Takeaways

•Capacity gap is fundamental — Most organizations cannot absorb large attacks locally; leverage providers who can
•Upstream filtering is essential — Work with ISPs and use RTBH/Flowspec for pre-network filtering
•Scrubbing centers provide surgical mitigation — On-demand or always-on, they analyze and filter attack traffic
•Anycast architecture distributes load — Geographic distribution prevents any single point from overwhelming
•Protocol hardening protects edge — SYN cookies, connection limits, and proper kernel tuning defend against protocol attacks
•Load balancers add defense layers — Cloud and on-premises load balancers provide built-in DDoS features
•Detection requires baselines — You can't detect attacks without understanding normal traffic patterns
•Defense in depth is non-negotiable — Layer multiple protection mechanisms; no single layer is sufficient

What's Next:

Page Complete

2 / 5