はじめに
文書チームは通常 docs.approved.test にファイルをアップロードします。小さなキャプチャには別の送信先へのアップロードもあります。この合成通信に対するオフライン検出器の作成が許可されています。
パケットキャプチャ（PCAP）はネットワークパケットを保存します。Suricata は HTTP 要求を復元してルールをテストします。ここではファイルを読み、これらのホストには接続しません。名称も文書も架空です。平文 HTTP なので本文が見えますが、暗号化された HTTPS の読み取りは実証しません。
コマンドは Analyst タブで実行します。Traffic Reference タブを選択すると参照ページが直接開き、traffic/requests.txt と同じ準備済み要求を確認できます。これらは記録された例であり、ライブの構成図ではありません。必要なのは基本的なコマンド入力とタブ切り替えだけで、IDS の経験は不要です。
アップロード要求を認識する
このステップでは、正常なアップロードも含め POST を見つける最初のルールを作ります。アラートはルールの一致を示すだけで、侵害を証明せず通信も遮断しません。
このステップを始めるには、ラボ画面の Analyst タブを選択してください。
HTTP は要求と応答のプロトコルです。メソッドは操作を表し、POST は内容の送信、GET はリソースの取得です。Host ヘッダーは送信先サイト、URI はルート、本文は送信する文書のフィールドを示します。Traffic Reference タブに切り替え、準備済みの HTTP のやり取りをブラウザーで確認します。ページは参照資料であり、ライブのパケット監視ではありません。その後 Analyst タブに戻り、同じ通信を読んで、以下のすべてのコマンドを実行します。cat はファイルを表示し、パスはその場所を示します。
次のコマンドを実行する前に、Analyst タブに切り替えてください。
cat traffic/requests.txt
docs.approved.test への正当な POST、収集先の GET、classification=internal を含む POST を比べます。組織は承認済み文書サービスへの内部文書送信を許可しています。収集先ルートには公開デモ文書を送れますが、内部文書は送れません。送信先と内容の組み合わせが重要で、未知のホスト名だけでは証拠になりません。
Suricata ルールにはヘッダーと括弧内のオプションがあります。alert http は解析した HTTP へのアラートを選びます。2 組の any any は任意の送信元・送信先アドレスとポートを許容し、-> は送信元から送信先への方向です。flow:established,to_server は接続済みクライアントの要求に限定します。セミコロンでオプションを終えます。msg は一致の説明、sid は数値のシグネチャ識別子、rev は改訂番号です。ルールごとに一意の sid を使います。
スティッキーバッファは、後続の content が検査する HTTP フィールドを選びます。http.method はメソッドです。content:"POST" で文字列を探し、startswith と endswith で部分文字列ではなくフィールド全体の一致にします。次のルールを使ってください。
cat > method.rules は既存内容を置き換えて書き込みます。<<'RULE' は複数行のリテラル入力を開始し、終了の RULE は単独の行に置きます。簡単な編集方法で、誤入力時はブロック全体を再実行できます。
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
キャプチャを再生します。mkdir -p は出力ディレクトリを作り、既存でも使えます。--runmode single はパケット処理を 1 スレッドにし、-c は設定、-S は指定ルールだけの読み込み、-r は PCAP、-l は出力先を選びます。--init-errors-fatal は読み込めないルールがあれば停止します。設定は各本文を最大 64 KB 検査し、提供例はすべて収まります。実環境の制限は別途評価が必要です。
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
オフラインファイルの末尾に達して停止するメッセージは正常です。eve.json はイベントごとに JSON オブジェクトを保存します。JSON の名前付きフィールドのうち、event_type: alert は一致、signature_id はルール、HTTP フィールドは要求を識別します。付属の Python 閲覧プログラムは送信元ポート、メソッド、ホスト、URI、シグネチャ ID を表示します。送信元ポートは参照一覧との対応用で、ポリシー条件ではありません。
結果は Alerts: 10 です。正常な文書 POST と収集先 POST の両方が現れ、GET と PUT は検出されません。この意図的に広い検出器でメソッドの一致を学びます。
付属のチェッカーは変更していないルールを、独立した 2 つの小さなデータセットに対して一時出力先で実行します。保存済みログを無視し、ルールとキャプチャを変更しません。最初のメソッド検出器を確認します。
python3 /opt/c09/check.py method.rules method
両行とも意図した通信 10 件の一致を示します。構文エラーなら引用符、セミコロン、閉じ括弧を確認し、書き直して再試行します。同じ出力先を再利用するとイベントが追記されるため、件数比較には新しいディレクトリを使います。チェッカーは毎回空の出力から始めます。
収集先の送信先を選ぶ
このステップではメソッドとホストを組み合わせ、正常な文書サービスのアップロードを除外します。1 つのルールの各バッファは同じ HTTP トランザクションで一致する必要があります。
このステップを始めるには、ラボ画面の Analyst タブを選択してください。
送信先サイト名は本文ではなく http.host で検査します。文書に収集先の名前があっても、そこへ送ったとは限りません。Suricata はホストを小文字に正規化します。参照内の collector.example.test.other.test は別ホストです。フィールド全体の一致で区別します。
最初の検出器を比較用に残し、新しいファイルを作ります。ヘッダーとメソッド条件を保ち、ホストバッファで送信先条件を追加します。
次のコマンドを実行する前に、Analyst タブに切り替えてください。
cat > destination.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
結果は Alerts: 6 です。承認済みサービスと似た名前のホストが消えます。まだルートを区別しないため、/status と /collect-backup への POST も一致します。これらは調査対象外の動作に一致する、把握できた誤検知です。
python3 /opt/c09/check.py destination.rules destination
両データセットでメソッドとホストの条件に合う 6 件が一致します。許可ホストでも検出される場合は、ホスト内容の後の startswith; endswith; を確認します。保存済み JSON イベントを直しても検出器は直りません。ルールを変更して再生してください。
検出をアップロードルートに限定する
このステップでは、内容に関する制限を認識しつつルート検出器を完成させます。URI は /collect などの要求ルートで、ホストとは異なります。
このステップを始めるには、ラボ画面の Analyst タブを選択してください。
http.uri とフィールド全体の一致で /collect を正確に選びます。/collect-backup は別ルートです。ヘルスチェックや正当な送信先を検出しないよう、メソッドと送信先の制限も保ちます。
次のコマンドを実行する前に、Analyst タブに切り替えてください。
cat > upload.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
結果は Alerts: 4、ポートは 41002、41003、41007、41011 です。参照の本文を比較すると、内部文書 2 件と公開デモ文書 2 件があります。すべて指定ホスト・ルートへの POST です。ルート監視はできますが、機密アップロード件数を過大に示します。
python3 /opt/c09/check.py upload.rules route
両データセットで指定ルートの 4 件が一致します。チェッカーは文書名と送信元ポートも変えます。こうした付随値で検出を決めてはいけません。アラート共有時はルールの目的を明示してください。次のラボでは新しい環境で文書の情報を加え、ノイズ低減をテストします。
まとめ
実際の Suricata 再生でメソッド、送信先、ルートの検出器を作成しました。アラートを記録済み要求と対応付け、機密アップロードの検出と呼ぶ前に公開文書による誤検知を確認しました。
