FirewallおよびIDS/IPS検証における現場の課題
新しいFirewallクラスタを構築したり、SnortやSuricataのルールをチューニングしたりする際、多くのNetOpsエンジニアが共通の難題に直面します。それは、「正規ユーザーの正常なトラフィックを誤ってドロップすることなく、ルールが確実に攻撃を検知・遮断できているかをどうやって検証するか」という点です。
curlやpingによるテストでは単純すぎます。また、iperf3のような負荷生成ツールは純粋なスループット（L4）しか生成できず、実際のペイロードや異常なTCPフラグ、マルウェアのシグネチャなどが完全に欠落しています。一方で、検証環境でエクスプロイトスクリプトを直接実行しようとしても、送信レートの制御が難しく、不具合が発生したセッションを100%正確に再現することはほぼ不可能です。
筆者自身、過去にある決済ゲートウェイで間欠的なパケットロス障害に悩まされた経験があります。その不具合は、トラフィックが約5,000 CCUに達する14時から16時のピーク時間帯にしか発生しませんでした。夜間になるとトラフィックは激減しますが、デバッグのために深夜2時に数千人のユーザーを一斉に操作させることなど不可能です。その際に最も効果的だった解決策が、tcpreplayを使用して輻輳時にキャプチャしたpcapファイルをそのまま再送することでした。
tcpreplayツール群の構成と動作の仕組み
tcpreplayは単一のコマンドではなく、.pcapファイルからトラフィックを処理・再現するための専門的なツールスイートです。
- tcpreplay: キャプチャファイルからパケットを読み込み、NIC（ネットワークカード）のLayer 2（データリンク層）へ直接流し込みます。カーネルのTCP/IPスタック全体をバイパスするため、NICの性能に応じて数百Mbpsから数十Gbpsもの高速送信が可能です。
- tcprewrite: パケットヘッダーを直接編集します。MACアドレスの変更、送信元/宛先IPアドレス範囲の修正、チェックサムの再計算などが可能です。本番環境で取得したpcapをラボ環境に持ち込むと、元のIPやMACアドレスがラボのトポロジーと一致しなくなるため、このツールでマッピングを書き直す必要があります。
- tcpprep: トラフィックの流れをクライアント側とサーバー側の双方向に分離します。生成された
.cacheファイルを利用することで、tcpreplayが2つの独立したネットワークインターフェース（例: クライアント用eth1、サーバー用eth2）から同時にパケットを送出できるようになります。
仕組みは非常にシンプルです。実際のトラフィックを一度キャプチャし、ラボ環境に合わせてIPやMACアドレスを修正した上で、FirewallやIDS/IPSに向けて直接送信してその挙動を検証します。
パケットの収集・編集・再送を行う5つのステップ
ステップ1：Linuxへのツールのインストール
主要なLinuxディストリビューションのほとんどで、公式リポジトリにtcpreplayが含まれています。
Ubuntu / Debianの場合：
sudo apt update
sudo apt install -y tcpreplay
RHEL / Rocky Linux / AlmaLinuxの場合：
sudo dnf install -y epel-release
sudo dnf install -y tcpreplay
インストール後のバージョン確認：
tcpreplay -V
ステップ2：サンプルトラフィック（.pcap）の収集
tcpdumpを使用して、ネットワークインターフェース上の疑わしいパケットを1,000個キャプチャします。
sudo tcpdump -i eth0 -c 1000 -w attack_sample.pcap
キャプチャしたファイルの概要情報をcapinfoで素早く確認します。
capinfo attack_sample.pcap
このコマンドにより、キャプチャ期間、総パケット数、平均ビットレートなどを確認できます。
ステップ3：tcprewriteによるMAC・IPアドレスの変更とチェックサムの再計算
インターネット上の実IPアドレスをそのまま使用すると、ラボ内のL3スイッチやFirewallでルーティング不整合やARP解決の失敗が発生し、即座にパケットがドロップされてしまいます。そのため、ヘッダーを適切にマッピングし直す必要があります。
次のようなラボ環境の構成を想定します。
- 送信元マシンのNIC:
eth1 - 擬似クライアントIP（送信元）:
192.168.10.50、MAC:00:11:22:33:44:55 - Firewall/IDSのGateway IP（宛先）:
192.168.10.1、MAC:aa:bb:cc:dd:ee:ff
以下のコマンドを実行して変換を行います。
tcprewrite --enet-smac=00:11:22:33:44:55 \
--enet-dmac=aa:bb:cc:dd:ee:ff \
--srcipmap=0.0.0.0/0:192.168.10.50/32 \
--dstipmap=0.0.0.0/0:192.168.10.1/32 \
--fixcsum \
--infile=attack_sample.pcap \
--outfile=ready_to_send.pcap
重要な技術的ポイント： IPヘッダーやポート番号を変更すると、元のチェックサム値との不整合が発生します。--fixcsumオプションを指定することで、tcprewriteにIPv4、TCP、UDPのすべてのチェックサムを再計算させることができます。このオプションを忘れると、SnortやSuricataなどのIDSはチェックサムの検証失敗により、ネットワークインターフェース層でパケットをサイレントドロップしてしまいます。
ステップ4：ネットワークカード経由でのトラフィック再送
テストの目的に応じて、以下の3つのトラフィック送信シナリオから選択します。
シナリオ1：リアルタイム再生（Real-time replay）
IDS/IPSの検知感度をテストするのに適しています。キャプチャ時の実際のパケット間隔を忠実に再現して送信します。
sudo tcpreplay --intf1=eth1 --realtime ready_to_send.pcap
シナリオ2：帯域制限およびループ再生（Rate limiting & Loop）
耐障害性や負荷耐性の測定に適しています。例えば、50 Mbpsの帯域に固定し、20回ループ再生する場合は次のように指定します。
sudo tcpreplay --intf1=eth1 --mbps=50.0 --loop=20 ready_to_send.pcap
シナリオ3：ハードウェア限界速度での送信（Top speed）
Firewallのハードウェアストレステスト専用のシナリオです。
sudo tcpreplay --intf1=eth1 --topspeed ready_to_send.pcap
ステップ5：IDS/IPSでのログ確認と結果の検証
SuricataまたはSnortが動作しているマシンで別のSSHセッションを開き、アラートをリアルタイムで監視します。
# Suricataの場合:
sudo tail -f /var/log/suricata/fast.log
# Snortの場合:
sudo tail -f /var/log/snort/alert
ルールがシグネチャを正しく捉えていれば、パケットの送信に合わせてアラートログがリアルタイムに出力されます。もしアラートが記録されない場合は、ルールの構文に誤りがないか、あるいは解析エンジンに届く前にNICでパケットがドロップされていないかの2点を確認する必要があります。
まとめ
パケットリプレイを活用することで、勘や推測に頼ったデバッグ作業から完全に脱却できます。tcprewriteとtcpreplayを組み合わせれば、安全な検証環境で過去のあらゆるネットワーク障害を正確に再現可能です。一般的な攻撃パターン（SYN flood、SQLインジェクション、特定のCVEなど）を収集したpcapライブラリをあらかじめ構築しておけば、新しいルールを追加した際にも、本番環境へ適用する前にわずか数分でテストスイートを実行・検証できます。
