#状況
「eBPF ランタイムガードが、不審なプロセスを凍結し、ホストを隔離しました」。あなたは当番の運用者です。サーバーには、保守用の SSH(22 番)だけが残っています。
RoamSwitch は、深刻な脅威を検知すると、ネットワークの隔離やプロセスの凍結といった封じ込めを自動で行います。このモジュールでは、そのあとの 1 時間に、何を、どの順番でするかを、シミュレーションで体験します。
画面や操作の細かい説明は、インシデント発生後の最初の1時間 にあります。この教材は、そこに書かれた手順を、「どう判断するか」として身につけるためのものです。扱う機能は、カーネル層の侵入検知と自律隔離、インシデントのタイムライン、封じ込め時の証拠の自動採取、通知の履歴 です。
#最初の 1 時間の、基本の順番
封じ込めは、何か理由があって発動しています。あわてて解除せずに、どの環境でも同じ順番で進めます。
| 順番 | すること | 理由 |
|---|---|---|
| 1. 確認する | 何が、いつ、どの順で検知されたかを、時系列で見る | 封じ込めの理由を、まず知る |
| 2. 記録する | 解除や再起動の前に、ログと証拠を保存する | 解除や再起動のあとでは、動いていたときの状態が分からなくなることがある |
| 3. 判断する | 身に覚えのある操作か、本当に不審な動きかを決める | 誤検知なら再開し、本物なら再開しない |
| 4. 解除する | 安全を確認してから、封じ込めを解除する | 原因が残ったまま解除すると、同じ被害がまた出る |
| 5. 見守る | 解除したあと、同じ検知が再び出ないかを確かめる | 解除の直後は、再発しやすい |
Server Edition では、高信頼度の隔離(カナリアの改ざん、ランサムウェア的な大量書き換え、eBPF の Critical / Emergency / Alert など)は、確認応答(ack)も、原因がなくなったことの確認もないまま、既定で 3600 秒(1 時間)がたつと、縮退(DEGRADED)モードに移ります。縮退モードでは、保守用の SSH ポートと、許可した IP からの管理経路を除いて、新しい通信は遮断されたままです。時間がたっても、自動では開きません。
#平常時に、出力を見慣れておく
危機のさなかに、初めて見る画面を読むのは難しいものです。平常時に一度、読み取りだけのコマンドで、出力に慣れておきます。
roamswitch notifications # 直近 1 週間の通知の履歴
roamswitch frozen list # ガードが凍結しているプロセス
roamswitch timeline # 統合インシデントタイムライン❄️ 凍結中のプロセス
凍結中のプロセスはありません。
🕒 統合インシデントタイムライン
2026-11-03T03:05:32.839736466+00:00 [eBPF Guard] 対応中
Read sensitive file untrusted: Logged & Monitored (guard policy: no containment)
プロセス: gnome-initial-s (pid 5311)
親プロセス系譜: systemd ← systemd
MITRE ATT&CK: T1552 (Unsecured Credentials)
検知→遮断の所要時間: 30ms
実施した対応: Logged & Monitored (guard policy: no containment)出力は、次のように読みます。
- 凍結中のプロセス: 平常時は「ありません」と出ます。凍結されているものがあれば、ここに PID が並びます
- タイムライン: 検知ごとに、プロセス、親プロセスのたどり方、対応する ATT&CK の手法、検知から対応までの時間が出ます。この例は、「封じ込めなし」の方針のもとで、記録だけを残した検知です(
Logged & Monitored) - 時刻は UTC です。日本時間とは 9 時間ずれているので、通知の時刻と突き合わせるときは注意してください
#最初の 1 時間のシミュレーション
次のシミュレーションで、第一報から 1 時間の判断を体験します。行動を選ぶと、その結果と理由が出ます。時刻は、第一報(03:12)からの経過です。
状況は、手順を学ぶための想定で、実在の事件ではありません。サーバーは Web アプリを動かしている Server Edition です。あなたは SSH で入れます。迷ったら、「確認 → 記録 → 判断 → 解除 → 見守る」の順番に戻ってください。
-
03:12 · 経過 0 分1 / 6
通知が届いた
スマートフォンに通知が来ました。隔離は、すでに発動しています。サーバーは外からは応答せず、ノート PC からの SSH だけが届きます。最初に、何をしますか。
- 最善 正解です。封じ込めには理由があります。まず事実を、時系列で見ます。
- 避けたい 原因を確かめる前に解除すると、通信が再開して、同じ影響を受けます。証拠も取れていません。
- 避けたい 再起動のあとでは、動いていたときの状態が分からなくなることがあります。再起動や解除の前に、ログと証拠を保存します。
- 許容 隔離は保たれますが、1 時間後には縮退に移り、確認しないまま時間だけが進みます。事実を知る時間を、無駄にします。
-
03:18 · 経過 6 分2 / 6
何が凍結されているか
通知の履歴には、Web サーバーの実行ユーザーの子プロセスが、
/tmpの下の実行ファイルを動かし、外部へ接続しようとしたため、ガードがそのプロセスを凍結した、とあります。凍結されたプロセスを、どうしますか。- 最善 正解です。凍結は、証拠を記録するまで再開しないための状態です。ここでは触らずに保ちます。
- 避けたい 再開すると、不審なプロセスが動き出します。再開は、心当たりのある操作だと分かった、誤検知のときだけです。
- 避けたい 凍結で、すでに止まっています。急ぐ理由がありません。終了させると、証拠を記録する前に、手がかりが消えます。終了させるのは、証拠を記録したあとです。
-
03:25 · 経過 13 分3 / 6
証拠を記録する
eBPF ガードは、プロセスの封じ込めでも、ホスト全体の隔離でも、証拠保全バンドル(約 30 秒のパケットキャプチャと、PID が分かるときの
/proc/<pid>のスナップショット)を、裏で自動で作ります。ただし、これは「できれば取る」処理です。roamswitch-incident-captureが入っていない環境では、何も作られず、エラーも出ません。パケットキャプチャには約 30 秒かかります。どうしますか。- 最善 正解です。解除や再起動の前に、証拠と時系列を保存します。
- 許容 多くの場合は作られています。ただ、取得用のツールが入っていない環境では何も作られず、失敗しても知らされません。あるかどうかを確認する必要があります。
- 避けたい 証拠は、解除や再起動のあとでは取れなくなることがあります。調査の前に、保存します。
-
03:40 · 経過 28 分4 / 6
心当たりを確かめる
時系列では、03:08 に Web サーバーの子プロセスが
/tmp/.x/updateを実行し、03:09 に外部への接続を試み、03:12 に凍結・隔離されています。保守作業の予定はなく、このファイルを置いた人もいません。アクセスログをsudo accessscope scan --auto --since 24h --report report.mdで調べると、03:07 に、アップロード用のパスへの POST が見つかりました。判断は。- 最善 正解です。本物の攻撃の流れです。再開せず、記録してから終了させます。
- 避けたい 誤検知と判断してよいのは、心当たりのある操作だと分かったときだけです。ここには根拠がなく、攻撃を許可することになります。
- 許容 安全側の選択です。ただし、侵入経路が開いたままで、1 時間後には縮退に移ります。時間の使い方を、考える必要があります。
-
03:50 · 経過 38 分5 / 6
隔離をどうするか
プロセスは止めてあり、証拠も保存しました。ただし、侵入経路(アップロードの口)は、まだ塞いでいません。隔離を解除すれば、新規の通信が戻り、同じ経路から再び入られるおそれがあります。あと 22 分で、隔離は縮退に移ります。隔離を、どうしますか。
- 最善 正解です。原因を除くまでは、隔離を保ちます。確認応答は、対応を引き受けた記録にもなります。
- 避けたい 経路が開いたまま解除すると、通信が戻り、再侵入されるおそれがあります。原因を除いたことを確認してから、解除します。
- 許容 縮退に移っても、保守用の SSH と許可した IP 以外の新規通信は遮断のままで、自動では開きません。大きな問題は起きませんが、運用者が対応を引き受けたことは示されません。
-
04:10 · 経過 58 分6 / 6
解除と、見守り
侵入経路を塞ぎ、不審なファイルを退避し、プロセスを終了させ、証拠を保存しました。原因は取り除かれたと確認できました。解除したあと、どうしますか。
- 最善 正解です。「見守る」までが、最初の 1 時間の手順です。
- 許容 解除の直後は、同じ検知が再び出やすい時間です。見守りは、解除の直後から始めます。
- 避けたい 記録と証拠は、あとから事実を組み立てるための材料です。削除せずに、保管します(古いものは、保持期間を過ぎてから整理します)。
あなたの選択は、次の順番と対応していました。
| 順番 | シミュレーションでの場面 |
|---|---|
| 確認する | 03:12 時系列で確認する / 03:18 凍結中のプロセスを確認する |
| 記録する | 03:25 証拠と時系列を保存する |
| 判断する | 03:40 心当たりを確かめ、再開しないと決める |
| 解除する | 03:50 隔離を保つか決める / 04:10 原因の除去を確かめて解除する |
| 見守る | 04:10 解除の直後から見守る |
つまずきやすい点は、3 つです。早すぎる解除、証拠を取る前の再起動や終了、根拠のない再開(誤検知と決めつけること) です。いずれも、封じ込めが守ってくれていた状況を、自分で壊します。
鍵やパスワードの交換、関係先への連絡、復旧の計画は、RoamSwitch の外で行う対応で、この教材の範囲外です。
#見えない部分
- この教材は机上の演習です。封じ込めの発動そのものは、実機では起こしていません。第一報の内容と、各場面の状況は、手順を学ぶための想定です
- 各場面の製品の挙動は、インシデント発生後の最初の1時間 の記載(2026-10-21 更新)に基づいています。読み取りだけのコマンドの出力は、実機で確かめました
- 手順は Server Edition のものです。Mac と Linux のデスクトップ版は、画面での操作が中心で、手順が異なります。上のページの 3. と 4. を読んでください
- ARP なりすましで隔離されたとき、ランサムウェアの被害を受けたときは、手順が異なります(上のページの 8. と 9.)
隔離の発動から 1 時間、何も操作しませんでした。何が起きますか(Server Edition の高信頼度の隔離)
解説を見る
時間がたっても、自動では開きません。縮退中は、確認応答(
roamswitch server ack)が解除を意味します。そのため、確認応答は、原因を確かめてから返します。
対応する攻撃手法 (ATT&CK): T1685
2026-11-03に確認しました。対象は Linux 1.17.30 (Server Edition) です。手順は『インシデント発生後の最初の1時間』(2026-10-21 更新)に基づく机上の演習。縮退までの上限(3600 秒)、確認応答(ack)の意味、証拠バンドルの作成条件は、製品のコードで確認。読み取りだけのコマンドの出力は、Ubuntu 26.04 の実機で確認。封じ込めの発動は、実機では起こしていない
コマンドの出力は、製品の版や環境によって変わります。違いが出たら、まず製品の版を確かめてください。