Posted inネットワーキング

FastNetMonで構築するDDoS自動検知・対応システム

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

大規模なDDoS攻撃がサーバーを襲ったとき、1秒1秒が勝負です。正当なトラフィックは途絶え、サーバーは高負荷でパンクし始めます。攻撃が長引けば——完全なサービス停止です。攻撃を検知するだけでは半分しか解決していません。実際にダメージを抑えるために素早く対応できるか——そこで多くの環境が失敗します。

アプローチ比較：大規模DDoSへの3つの対処法

インフラチームが大規模攻撃に対処する方法は大きく3つあります——コストと保護効果のトレードオフは、それぞれで大きく異なります：

1. 手動監視 + 手動対応

担当者がダッシュボードを監視してアラートに対応し、SSHで接続してファイアウォールルールを追加します。攻撃が少ない小規模な環境では機能しますが、対応時間は秒単位ではなく分単位になります。実際の攻撃だと確認できた頃には、すでにダメージが出ています。

2. クラウドベースのDDoSスクラビングサービス

Cloudflare Magic TransitやAWS Shield Advancedといったサービスは、インフラに到達する前にトラフィックをスクラビングセンター経由でルーティングします。効果は高く、サーバー側の設定は不要——ただしコストが問題です。帯域によっては月数百ドルから数千ドルになります。

3. FastNetMonによるオンプレミス自動検知

自前のハードウェアでトラフィック解析デーモンを動かします。異常なトラフィックパターンを検知すると、BGPブラックホール、iptablesルール、またはアップストリームプロバイダーへのAPIコールといった緩和策を自動的にトリガーします。反応時間は10秒以内です。

どのアプローチが自分の環境に合っているか

  • 手動：コストゼロ、完全なコントロール——しかし遅すぎ、ヒューマンエラーが起きやすく、深夜3時の攻撃には全く無力です。
  • クラウドスクラビング：サーバーに触らずに動く——しかし高価で、レイテンシが増加し、ベンダーロックインのリスクがあります。
  • FastNetMon（オンプレミス）：数秒で反応し、自前のインフラで動作、コミュニティエディションは無料——BGPまたはファイアウォールの統合作業が必要ですが、一度だけの投資です。

大半のVPS事業者や中小規模のインフラオーナーには、FastNetMonがちょうどいいバランスです。私自身も本番環境で運用していますが——攻撃は5〜10秒以内に検知され、アップリンクが飽和する前にブロックされます。まだ一度も見逃したことがありません。

なぜ手動検知はプレッシャー下で失敗するのか

数GbpsのUDPフラッドやICMP増幅攻撃では、手動で対応する時間はありません。アラートが発火し、SSHで接続して、本当に攻撃だと確認できた頃には——コネクションテーブルはすでに枯渇しています。何が起きているか把握しようとしている間にも、正当なユーザーが切断されています。信頼できる自動緩和策には3つの要件が必要です：

  • 人間の反応速度より速い——検知からブロックまで理想的には30秒以内
  • 攻撃中に手動介入が不要な完全自動化
  • 攻撃元と一緒に正当なトラフィックをブロックしないだけの精度

FastNetMonはデーモンとして動作し、リアルタイムでトラフィックをキャプチャ・解析します。ルーターからsFlowまたはNetFlowデータを受け取るか、サーバー上でlibpcap/AF_PACKETを使って直接キャプチャすることもできます——基本的な構成では特殊なハードウェアは不要です。

推奨構成

一般的なVPSやベアメタルサーバーでは、最もシンプルな構成はホスト上での直接パケットキャプチャです：

[Internet] → [FastNetMon + iptables を実行中のサーバー]

アップストリームルーターをコントロールできる、より堅牢な構成の場合：

[Internet] → [FastNetMon に sFlow を送るルーター] → [BGP ブラックホール（上流）]

本ガイドでは、AF_PACKETキャプチャとiptablesによる対応を使ったシングルサーバー構成を解説します——BGPピアリングなしに任意のLinuxサーバーで動作します。末尾のBGPブラックホールセクションはオプションのアップグレードです。

実装ガイド

ステップ1：FastNetMon コミュニティエディションのインストール

sudo apt-get update && sudo apt-get install -y wget

wget https://install.fastnetmon.com/installer -O installer
sudo chmod +x installer
sudo ./installer

インストーラーは約5〜10分かかり、すべての依存関係を自動的に取得します。systemdサービスも自動的に登録されます。

ステップ2：トラフィック監視のしきい値設定

sudo nano /etc/fastnetmon.conf
# 監視するネットワークインターフェース
interfaces = eth0

# 保護対象のIPネットワーク（CIDR表記）
networks_list = /etc/networks_list

# しきい値ベースの検知を有効化
ban_for_pps = on
ban_for_bandwidth = on
ban_for_flows = on

# しきい値——自環境のベーストラフィックに合わせて調整
threshold_pps = 20000        # 2万パケット/秒
threshold_mbps = 1000        # 1 Gbps
threshold_flows = 3500       # 3500フロー/秒

# 攻撃者をブロックする時間
ban_time = 3600              # 1時間
# ネットワークリストを作成——実際のIP範囲に置き換えてください
echo "203.0.113.0/24" | sudo tee /etc/networks_list

ステップ3：自動対応スクリプトの作成

FastNetMonは攻撃を検知またはクリアするたびにスクリプトを呼び出します。ここで実際の緩和アクションを定義します：

sudo nano /usr/local/bin/fastnetmon_notify.sh
#!/bin/bash

ACTION=$1      # "ban"（ブロック）または "unban"（解除）
IP=$2
DIRECTION=$3   # "incoming"、"outgoing"、"both" のいずれか

LOG_FILE="/var/log/fastnetmon_actions.log"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

case "$ACTION" in
  ban)
    iptables -I INPUT -s "$IP" -j DROP
    iptables -I FORWARD -s "$IP" -j DROP
    echo "$TIMESTAMP - ブロック済み $IP (方向: $DIRECTION)" >> "$LOG_FILE"

    # オプション：Telegram通知を送信
    # curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \
    #   -d "chat_id=${CHAT_ID}&text=DDoS blocked: ${IP}"
    ;;

  unban)
    iptables -D INPUT -s "$IP" -j DROP 2>/dev/null
    iptables -D FORWARD -s "$IP" -j DROP 2>/dev/null
    echo "$TIMESTAMP - ブロック解除 $IP" >> "$LOG_FILE"
    ;;
esac
sudo chmod +x /usr/local/bin/fastnetmon_notify.sh

スクリプトをFastNetMonの設定に組み込むには、以下の行を追加します：

# /etc/fastnetmon.conf に追加
notify_script_path = /usr/local/bin/fastnetmon_notify.sh

ステップ4：FastNetMon の起動とトラフィックキャプチャの確認

sudo systemctl enable fastnetmon
sudo systemctl start fastnetmon
sudo systemctl status fastnetmon

組み込みクライアントでリアルタイムのトラフィック統計を確認します：

sudo fastnetmon_client

数秒ごとに更新される、以下のような出力が表示されます：

FastNetMon v1.2.7 client
受信トラフィック: 235 Mbps / 45K pps
送信トラフィック:  45 Mbps /  8K pps

パケット数上位ホスト（受信）：
203.0.113.45    UDP    12450 pps    450 Mbps  ← 攻撃候補
198.51.100.22   TCP      234 pps     12 Mbps

統計にトラフィックが表示されていれば、キャプチャは正常に動作しています。しきい値を超えたIPは自動的に通知スクリプトをトリガーします——基本的な保護のためにそれ以上の介入は不要です。

ステップ5：上流での緩和策としてのBGPブラックホール（上級者向け）

ホスティングプロバイダーがブラックホール用のBGPコミュニティをサポートしている場合——主要プロバイダーのほとんどが対応しています——FastNetMonはBGP経由で攻撃対象のIPをアナウンスできます。トラフィックはISPのエッジで破棄され、自分のネットワークに届く前に遮断されます：

# /etc/fastnetmon.conf に追加
gobgp = on
gobgp_next_hop = 192.0.2.1           # ブラックホールのネクストホップ（プロバイダー固有）
gobgp_announce_host = on
gobgp_community = 65000:666          # ISPのブラックホールコミュニティ

BGPアナウンスは通常60秒以内に伝搬します。それ以降、攻撃対象のIPへのトラフィックはサーバーに一切届かなくなります。これがiptablesとの決定的な違いです：カーネルレベルのルールはNICの容量までトラフィックを吸収しますが、BGPブラックホールはフラッドをハードウェアに到達する前に上流で遮断します。

チューニングと誤検知の回避

数日間運用したら、正当なIPが誤ってブロックされていないかアクションログで確認しましょう：

grep "ブロック済み" /var/log/fastnetmon_actions.log | awk '{print $5}' | sort | uniq -c | sort -rn

そのリストにCDNプロバイダー（Cloudflare、Fastly、Akamai）が繰り返し現れる場合は要注意です。それらのIP範囲からの正当なトラフィックスパイクは攻撃と区別がつかないことがあります。CIDRをホワイトリストに追加してください——しないと、繁忙期に自前のCDNをブロックしてしまうことになります：

# 信頼できるIPまたはCIDRをホワイトリストに追加
echo "103.21.244.0/22" | sudo tee -a /etc/white_list   # Cloudflareの例
sudo systemctl restart fastnetmon

また、実際のベーストラフィックに対してしきい値を見直しましょう。通常の業務時間中に15K ppsを処理するサーバーでは、20Kのしきい値は攻撃だけでなく繁忙な午後にも発火します。数値を決める前に、1週間分のトラフィック統計を確認してください：

# FastNetMonログで現在のピークトラフィックを確認
grep "pps" /var/log/fastnetmon.log | tail -100

実際の攻撃時の動作

一連の動作は素早く進みます。FastNetMonは1サンプリング期間——通常2〜5秒以内——に異常を検知します。通知スクリプトが発火し、攻撃元はカーネルレベルでブロックされます。攻撃者と同じサブネットの送信元を含む、その他すべてのIPからのトラフィックは影響を受けずに継続します。

コミュニティエディションは最も遭遇しやすいシナリオをカバーしています：UDPフラッド、ICMP増幅、SYNフラッドです。プレフィックス単位の分析、ハードブロックではなくレート制限、より詳細なレポートが必要な場合はFastNetMon Advancedが対応しています。商用予算なしで純粋な大規模攻撃への対策が必要であれば、コミュニティエディションで実際のサーバーが遭遇するほとんどの攻撃に十分対応できます。

Share:
Tags: