IDSとNetFlowの「点と線」を結べ：侵害の痕跡を逃さない現場の相関分析術
「IDSのアラートが鳴った。でも、シグネチャベースの検知だけでは、それが単なるポートスキャンの残骸なのか、それとも致命的な侵入の予兆なのか判断がつかない」
インシデントレスポンスの現場で、若いエンジニアからこんな嘆きを聞くことは少なくありません。IDS/IPSは優秀な「番犬」ですが、彼らは断片的なパケットしか見ていません。一方で、NetFlow（フローデータ）は、誰が、いつ、どこへ、どれだけのデータを運んだかという「物流の記録」です。
この二つを脳内で（あるいはSIEM上で）連結できない限り、あなたは攻撃者が描く「侵入から持ち出しまでのストーリー」を見誤ることになります。今日は、IDSの検知とフローデータを突き合わせ、攻撃者の足取りを完全に追跡するための思考法と実装を解説します。
—
1. なぜ「シグネチャ検知」だけでは不十分なのか
攻撃者は賢いです。彼らはWAFやIDSを回避するために、断続的な通信（Low and Slowな攻撃）や、正規のプロトコルに偽装したビーコン通信を多用します。
例えば、攻撃者が脆弱なWebアプリのパラメータに sqlmap を走らせ、同時にバックグラウンドでリバースシェルを仕込んだとしましょう。IDSは SQL Injection のシグネチャを検知してアラートを上げますが、その後の「外部のC2サーバーとの持続的な通信」は、個別のパケットとしては「ただのHTTP/HTTPS通信」に見えるため、IDSだけではスルーされることが多々あります。
ここでNetFlowを重ね合わせると、「IDSのアラートが出た直後に、Webサーバーから見慣れない外部IPへ、小さなパケットが規則的に送信されている」という異常な相関が浮かび上がります。これが「侵害の動かぬ証拠」です。
—
2. 現場で使える「検知ロジック」の実装
ログを収集するだけでは意味がありません。SIEMや自作の分析基盤で「相関」をとるためのロジックが必要です。ここでは、Pythonを使ってIDSログとフローデータを結合し、異常な通信を抽出するイメージをコード化します。
import pandas as pd
# IDSログ（CSV想定）とNetFlowログを読み込む
# 実際にはElasticsearchやBigQueryから抽出したデータフレームを想定してください
ids_alerts = pd.read_csv('ids_alerts.csv') # カラム: timestamp, src_ip, dest_ip, signature
flows = pd.read_csv('network_flows.csv') # カラム: timestamp, src_ip, dest_ip, bytes, duration
def detect_malicious_correlation(ids_df, flow_df, time_window_sec=300):
"""
IDSアラート発生後の5分以内に、異常な通信量が発生したフローを特定する
"""
suspicious_activities = []
for _, alert in ids_df.iterrows():
# IDSで検知されたIPに関連するフローを時系列で絞り込み
related_flows = flow_df[
(flow_df['src_ip'] == alert['src_ip']) &
(flow_df['timestamp'] >= alert['timestamp']) &
(flow_df['timestamp'] <= alert['timestamp'] + time_window_sec)
]
# 閾値を超えるデータ転送（持ち出しの兆候）を検知
exfiltration = related_flows[related_flows['bytes'] > 1000000] # 1MB以上の通信
if not exfiltration.empty:
suspicious_activities.append((alert, exfiltration))
return suspicious_activities
# 分析実行
results = detect_malicious_correlation(ids_alerts, flows)
print(f"怪しい通信を {len(results)} 件検出しました。調査を開始してください。")—
3. Webアプリ側の「無防備」を叩き直す
攻撃者が侵入の足掛かりにするのは、多くの場合「甘い設定」です。特に、アプリケーション層で防ぐべきことをOSやネットワークに丸投げするのは危険です。
例えば、PHPアプリでユーザー入力をそのまま実行してしまうような脆弱な設計は即座に修正すべきです。以下は、コマンドインジェクションを物理的に防ぐための最小限の防衛実装です。
<?php
// ユーザーからの入力を受け取る想定
$userInput = $_POST['filename'] ?? '';
// 【重要】シェル実行関数（system, exec, shell_exec）は極力避ける
// どうしても必要な場合でも、入力をホワイトリストで厳格に検証する
$allowedFiles = ['report.pdf', 'data.csv'];
if (!in_array($userInput, $allowedFiles, true)) {
// ログに記録し、管理者に通知を送る（インシデントの予兆）
error_log("攻撃試行検知: 不正なファイルアクセス - " . $userInput);
die("アクセスが拒否されました。");
}
// 安全な方法で処理を実行
// escapeshellarg を使って引数をエスケープする
$command = "cat " . escapeshellarg("/var/www/data/" . $userInput);
echo shell_exec($command);
?>—
4. インフラ側での「出口対策」：Nginxでの制限
攻撃者が侵入に成功した後、最もやりたいことは「情報の持ち出し（Exfiltration）」です。これを防ぐには、アプリケーション層だけでなく、Nginxなどのリバースプロキシで、不審な通信先へのリクエストをブロックする設定も有効です。
/etc/nginx/conf.d/security.conf に以下のような設定を入れることで、意図しないドメインへのリクエストを抑制できます。
# 外部へのリクエストを制限する（WAFの代替として機能させる）
location /api/proxy {
# 許可されたドメイン以外への通信を遮断する設定（簡易例）
# 実際にはLuaモジュール等で動的なフィルタリングを行うとより強力
if ($arg_url !~* "^https://trusted-api\.example\.com") {
return 403; # 許可されていないドメインへの通信を拒否
}
proxy_pass $arg_url;
}—
最後に：フォレンジックは「想像力」である
技術的なツールやコードはあくまで手段です。インシデントレスポンスにおいて最も重要なのは、「攻撃者はこの脆弱性を突いた後、次に何をするか？」という想像力です。
IDSのアラートが出たとき、「シグネチャを更新して終わり」にするのは、犯人の指紋を見つけただけで逃走ルートを追いかけない警察と同じです。NetFlowで通信の「線」を追い、アプリケーション層のコードを疑い、インフラの境界で遮断する。この多層的な視点こそが、被害を最小限に留める唯一の道です。
さあ、ログを開いてください。あなたのサーバーは、今この瞬間も何かを語りかけているはずです。
コメント