RoamSwitch Sensor 運用マニュアル

LAN に設置するだけで、同一セグメント上の新規機器出現・なりすましを検知し、RoamSwitch 導入済み端末（Mac / Linux Client / Server Edition）に対しては能動的な脆弱性監査を行うネットワークセンサーの導入・運用ガイドです。apt / dnf パッケージで配布中です。

1. 概要 & 位置づけ

RoamSwitch（Mac / Linux Client / Server Edition）は、いずれもホストに常駐するエージェントという形態です。これには構造的な穴が 2 つあります。

• 単独ホストの自己診断には原理的な死角がある: 「外部からは閉じているが、同じLAN上の別端末からは丸見え」という横移動（lateral movement）リスクは、ホスト自身が自分だけを見ていては検知できません。
• RoamSwitch を導入できない機器がある: IoT機器（ネットワークカメラ、スマートプラグ、複合機）、来客・BYOD端末、ネットワーク機器自体、組み込み機器など。

RoamSwitch Sensor は、LAN に設置する専用ノードとして、この 2 つの穴を埋めることを目指す製品です。実装・動作確認できているのは、同一 LAN 上の RoamSwitch 導入済み端末に対する能動的な脆弱性監査、ARP スイープと ARP テーブルの監視による LAN 上の機器の台帳化と、新規機器の出現・なりすましの検知、そしてオプトインの受動キャプチャによる不審な挙動（悪性 IP への接続・ボットネット化・DNS トンネリングの兆候など）の参考情報の提示です（§6 参照）。Sensor は検知と報告のみを行い、通信の遮断はしません。EDR ではなく、軽量な NDR（Network Detection & Response）と内製の実証型脆弱性スキャナを組み合わせた製品として設計しています。

自己防衛は実装しません（意図的な設計判断）。Sensor 自体への攻撃対策が必要な場合は、同一マシンに RoamSwitch for Linux の Server Edition を別途インストールすることを推奨します。両者は完全に独立したプロセスとして共存できます。

2. システム要件

• 対応OS: Debian 12 (bookworm) 以降 / Ubuntu 22.04 以降（apt）、Fedora / RHEL 系（dnf）。x86_64（amd64）のみ対応、arm64 は現時点では未対応です。
• 想定ハードウェア（将来計画）: 実運用時はファンレスの N100/N150系ミニPC等、常時稼働に適した省電力機を想定していますが、専用ハードウェアの調達・出荷は行っておらず、お手持ちの機器または市販の小型 x86_64 機に導入していただく形態です。
• ネットワーク配置: 監視対象LANのセグメントに物理的または論理的に接続されていること（roamswitch-sensor.service はホストネットワークで常駐します — ARPテーブルを直接観測する必要があるためです）。また、端末側からのペアリング・監査リクエストを受け付けるため、固定IPアドレス（静的割り当て、またはDHCPサーバー側でのアドレス予約）での運用が必須です。TCP 50543 番ポートで待受します（既定は全インターフェース。control.bind_addr で変更でき、TLS 1.3 を同一ポートで受け付けます — §4.4）。
• リソース消費: 常駐メモリ数十MB程度、アイドル時CPU負荷は極めて軽量です。
• 推奨: nmap（ARPスイープ・NSE補完診断・定期監査のMAC確認で利用されます。未インストールでも他の機能は動作しますが、ARPスイープは行われず、Sensorが通信した機器のみを見る受動動作になります）。

3. インストール & 起動

公式の署名付きパッケージリポジトリから roamswitch-sensor パッケージをインストールします。インストール後、roamswitch-sensor.service（systemd）が自動的に有効化・起動されます。

3.1 APT（Ubuntu / Debian）

# 1. リポジトリ署名鍵の登録
curl -fsSL https://lafine.net/apt/roamswitch-archive-keyring.asc \
  | sudo gpg --dearmor -o /usr/share/keyrings/roamswitch-archive-keyring.gpg

# 2. リポジトリの追加
echo "deb [signed-by=/usr/share/keyrings/roamswitch-archive-keyring.gpg] https://lafine.net/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/roamswitch.list

# 3. インストール
sudo apt update && sudo apt install roamswitch-sensor

3.2 DNF / RPM（Fedora / RHEL）

# 1. GPG 鍵のインポート
sudo rpm --import https://lafine.net/rpm/RPM-GPG-KEY-roamswitch

# 2. リポジトリ設定ファイルの追加
sudo curl -fsSL -o /etc/yum.repos.d/roamswitch.repo https://lafine.net/rpm/fedora/roamswitch.repo

# 3. インストール
sudo dnf install roamswitch-sensor

3.3 起動確認

systemctl status roamswitch-sensor.service
sudo roamswitch-sensor status

3.4 CLI / TUI の実行

CLI（roamswitch-sensor）と対話型TUI（roamswitch-sensor-tui）はインストール後、そのまま実行できます。

sudo roamswitch-sensor status
sudo roamswitch-sensor-tui

4. ペアリング（ペアリングコード方式）

Sensor は初期状態では何も信頼していません。ペアリングは、Sensorオペレーターが発行する使い捨てのペアリングコードを使って行います。「Sensorが能動的な脆弱性監査を実行してよい相手」という信頼関係は、1回のペアリング操作で双方向に同時に成立します（片方向だけの信頼という状態はありません）。

前提条件: Sensorは固定IPアドレス（静的割り当て、またはDHCPサーバー側でのアドレス予約）で運用してください。端末はペアリング時に確認したSensorのIPアドレスへ以後も直接接続するため（mDNS等による自動探索は行いません）、Sensor側のIPが変わると再ペアリングが必要になります。エンドポイント側は動的IPのままで構いません。

4.1 ペアリングコードの発行（Sensor側）

# Sensor側で実行（TUIでは c キー）
sudo roamswitch-sensor issue-code

8文字（大文字英数字。判読を誤りやすい 0/O/1/I/L は除外）の使い捨てコードが発行されます。発行から10分で失効する1回限りのコードなので、口頭・チャットなど任意のアウトオブバンドな手段で、端末側の操作者へ速やかに伝えてください。あわせて、この Sensor の TLS 証明書フィンガープリント（SHA-256）も表示されます。端末側でピン留めする値なので、コードと一緒に伝えてください（roamswitch-sensor pairing show や TUI の T 画面でもいつでも確認できます）。

4.2 コードを使ったペアリング（エンドポイント側）

# エンドポイント側 (roamswitch-linux)
sudo roamswitch sensor pair --addr <SENSOR_IP> --code <CODE> --fingerprint <SHA256_FINGERPRINT>

Mac版では、メニューバーの「🔍 RoamSwitch Sensor ペアリング…」から、SensorのIPアドレス・ペアリングコード・証明書フィンガープリントを入力してGUIで同様の操作ができます。

ペアリングが成立すると、以後の能動的脆弱性監査・監査結果の取得はすべてEd25519署名で認証されます。Linux版の端末は、入力したフィンガープリントと一致する証明書を持つSensorとだけTLS 1.3で通信し、平文へは自動でフォールバックしません（§4.4）。Sensorが発行したコードを知っている端末側と、そのコードを受け取ったSensor側の双方が、この時点で互いを信頼済みとして扱います。

4.3 手動ペアリング（公開鍵を直接把握している場合）

Sensorオペレーターが端末の公開鍵とアドレスを既に把握している場合は、ペアリングコードの受け渡しを介さず、Sensor側から直接登録することもできます（通常は4.2のコード方式を使い、端末側からペアリングさせる方が簡便です）。自分自身の公開鍵とアドレスは、次のコマンドで確認できます。

# エンドポイント側で自身の公開鍵/アドレスを確認
sudo roamswitch sensor key

# Sensor側で自身の公開鍵/アドレス/MACアドレスを確認
sudo roamswitch-sensor status

# Sensor側
sudo roamswitch-sensor pair <完全な公開鍵> --addr <IPアドレス> --confirm

4.4 制御API（TCP 50543）のセキュリティ: TLS・フィンガープリント・ロックアウト

ペアリング・監査リクエスト・結果取得は、Sensor の制御 API（TCP 50543）で行われます。次の防御が組み込まれています。

• TLS 1.3 と証明書ピン: 設定 control.tls（デーモン再起動で反映）は off（平文のみ）/ optional（既定。TLS 1.3 と旧平文を同一ポートで受け付け、平文を受け付けるたびに警告）/ required（TLS 1.3 のみ）。証明書は自己署名（ECDSA P-256）で、信頼は有効期限や名前ではなく、SHA-256 フィンガープリントのピンで決まります。ピンはネットワーク経由で取得せず、Sensor の画面に表示された値を運用者が端末側へ入力します。
• ペアリング要求のフィンガープリント束縛: 端末は、ピンした証明書のフィンガープリントを自身の秘密鍵で署名してペアリング要求に含めます。別の証明書を持つ中間者を経由した要求は fingerprint_mismatch で失敗し、ペアリングコードは消費されません。
• リプレイ耐性のある署名（v2）: 監査リクエストと結果取得の署名は、時刻（±300秒）と nonce を含む v2 形式で、再送を拒否します。時刻・nonce を持たない旧 v1 署名はリプレイ可能なため、受け付けるか否かを control.allow_legacy_signatures（既定 true＝移行期間用。受け付けるたびに非推奨警告）で設定できます。すべての端末が v2 になったら false にしてください。
• ロックアウト: ペアリングコードの総当たりは、同一送信元IPから10分間に5回失敗すると60秒のロックアウト（繰り返すと最大1時間まで指数的に延長）、全送信元合計で20回失敗すると全体ロックアウトになります。署名の失敗はやや緩く（送信元IPごとに10回、全体で100回）扱います。ロックアウトは通知 control_api_lockout でお知らせします。
• 待ち受けIP: control.bind_addr（既定 0.0.0.0、再起動で反映）を Sensor の LAN 側アドレスに絞ると露出を減らせます。ワイルドカードの間はデーモンが警告を出します。
• 証明書の再生成（ローテーション）: roamswitch-sensor tls rotate（TUI では T 画面で R）は証明書を再生成します。旧フィンガープリントのピンはすべて無効になり、端末側で新しい値を入力し直す（sudo roamswitch sensor repin <公開鍵> --fingerprint <値>）必要があります。ペアリング自体は維持されます。

sudo roamswitch-sensor pairing show                       # mode, fingerprint, warnings
sudo roamswitch-sensor tls rotate                         # regenerate the certificate
sudo roamswitch sensor repin <PUBLIC_KEY> --fingerprint <NEW_FINGERPRINT>   # on each endpoint

5. 能動的脆弱性監査

ペアリング済みのエンドポイントに対し、Sensor から非破壊的な実証型脆弱性診断を実行します。破壊的操作（データの書き込み・削除、サービス停止）は一切行いません。

sudo roamswitch-sensor scan <公開鍵またはその先頭>

監査は4段階のフェーズで構成されています。

1. 全ポート走査: 対象ホストの開いているTCPポートを網羅的に検出します。
2. 既知シグネチャ診断: Redis / dockerd / Memcached / MongoDB / Elasticsearch / CouchDB / Jenkins / VNC の認証なし露出確認、SMTPオープンリレー診断（MAIL FROM/RCPT TOのみ送信、DATAは送信しない安全な手法）、開発サーバーのCORS誤設定・パストラバーサル・オープンリダイレクト診断など、既知の脆弱性パターンに対する非破壊的な実証確認を行います。
3. 汎用バナー取得: 上記シグネチャでカバーされていない開放ポートについて、接続のみでバナー文字列を取得します（データの送信は行いません）。
4. nmap NSE補完診断: nmap --script safeによる幅広いプロトコル対応の補完診断です。ホストにnmapがインストールされている場合に自動的に実行されます（未インストール時は何もしません）。

監査結果は毎回 /var/lib/roamswitch-sensor/scan_history.json に記録され（検出の有無を問わず、その時点でクリーンだったことも記録の価値があるため）、CLIまたはTUIから閲覧できます。

roamswitch-sensor history
sudo roamswitch-sensor report <公開鍵またはその先頭> --out /tmp/report.md

5.1 クライアント側からの監査リクエスト（pull方式）

ペアリング済みの端末側から、Sensorへ能動的脆弱性監査を能動的にリクエストすることもできます。Mac版はメニューバーの「Sensorへ監査をリクエスト」、Linux版は次のコマンドです。

sudo roamswitch sensor request-audit

Sensorが監査を実行した後、端末側はリクエストの5分後から5分おきに最大5回、結果を取得しにいきます（最終確認は最大25分後）。取得できた結果は端末側にもローカル保存されます。

roamswitch sensor results

Mac版では設定画面の「監査結果」一覧、またはMCPツール get_sensor_audit_results 経由でAIエージェントが対応計画を立てる際の入力としても利用できます。ペアリングがSensor側で解除されているなど、結果の提供が明示的に拒否されるケースもあります（§10 Q6参照）。

6. 受動的ARP監視 & LAN可視化

Sensor は 2 つの方法で LAN 上の機器を把握します。(1) ARP テーブルの監視: Sensor 自身の ARP テーブル（/proc/net/arp）を約 10 秒ごとに読み、「これまで見たことのない新規 IP/MAC の出現」と「既知 IP に対する MAC アドレスの変化（ゲートウェイなりすまし等の兆候）」を検知します。(2) 能動 ARP スイープ: nmap -sn -PR で直結サブネット（最大 /22）を洗い出し、IP・MAC・ホスト名・ベンダー・オンライン状態・初回/最終検出・IP 履歴を機器台帳に保存します。スイープは 1 時間ごと・手動（refresh / TUI の r）・TUI 起動時に実行され、nmap が未導入の場合は (1) のみの受動動作に戻ります。MAC の OUI からベンダーと機器分類（IoT 機器か否か等）も推定します。

roamswitch-sensor arp-events

検知したイベントは roamswitch-sensor arp-events や TUI の「ARPイベント」タブ（Enter で詳細）で確認できます。各イベントには、発生時刻・重大度（致命的〜情報。ゲートウェイ IP の MAC 変化は「致命的」）・判断の根拠・関係する機器の素性・具体的な次の手順が付きます。

6.1 受動的LAN可視化の拡張（オプトイン）

上記のARP監視は「Sensor自身が過去に通信した機器」のみが対象ですが、ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE 環境変数で対象インターフェースを指定すると、そのインターフェース上のEthernet/IPv4ヘッダーを観測（ペイロードは見ません）し、以下を検知します。

• 新規機器の受動観測: ARP監視ではカバーできない、Sensor自身が直接通信していない機器の出現。ブロードキャスト・マルチキャストトラフィックから学習します。
• 既知の悪性IPとの通信検知: 宛先IPがローカルの脅威フィード（RoamSwitch本体のEgress Guardと同じ形式）に一致する通信を検知します（検知のみ、遮断は行いません）。

sudo systemctl edit roamswitch-sensor.service
# [Service]
# Environment=ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE=eth0

sudo systemctl restart roamswitch-sensor.service
roamswitch-sensor passive-events

6.2 機器台帳と機器メモ

台帳は roamswitch-sensor device-inventory（TUI の「ネットワーク構成」タブ）で確認できます。device-note（TUI では n）で名前・用途・場所などのメモを登録するとその機器は「把握済み」になり、メモ未登録の機器は「要確認」と表示されます（機器台帳との突き合わせ用）。

sudo roamswitch-sensor refresh
roamswitch-sensor device-inventory
sudo roamswitch-sensor device-note aa:bb:cc:dd:ee:ff "3F copier"

6.3 不審な挙動の参考情報（すべて検知のみ）

受動キャプチャ（§6.1、オプトイン）を有効にすると、次の参考情報を提示します。いずれも検知と表示のみで、Sensor が通信を遮断することはありません。

• IoT機器の挙動（iot-events）: 分類済みの機器から、既知の悪性IPや管理用ポート（SSH/RDP/SMB等）への接続。mDNS/SSDP/DHCP の自己申告による機種特定も併用します。
• 不審な通信（network-threats）: 30秒の窓で多数の宛先への接続（走査・踏み台の疑い）や同一宛先への大量接続（DDoS参加の兆候）、DNSトンネリング/C2の兆候（クエリ名の構造的特徴のみを判定に使い、ドメイン名は保存しません）。
• 脆弱性情報（iot-advisories）: 既知のIoTベンダー製品に関する公開CVEの参考情報（静的に同梱。ネットワーク経由の更新はありません）。

7. CLI コマンド早見表

CLIは日本語 / 英語のみに対応しています（LANG環境変数に従います）。

8. TUI 操作ガイド

対話型TUI（roamswitch-sensor-tui）は10言語に対応し、CLI のすべてのサブコマンド・デーモンのIPC・すべての設定キー・コレクター運用を操作できます（m で機能一覧）。主要な6つのタブを Tab キー（逆順は Shift+Tab）で切り替えます: ペアリング済み（各端末の最新の監査状態）／ネットワーク構成（LAN上の全機器とメモ登録）／ARPイベント／監査履歴／差分（前回の監査からの変化。新規検出は赤、解消は緑、到達不能の疑いは黄）／操作ログ（誰がいつ何を承認・実行したか。上部にハッシュ連鎖の検証結果を表示）。80桁に収まらない画面（受動監視・IoT挙動・不審な通信・IoT脆弱性情報）は m のメニューから開きます。

9. 信頼モデル & セキュリティ設計

• アウトオブバンドの確認（TOFU ではない）: Sensor の画面に表示される証明書フィンガープリントとペアリングコードを、運用者が口頭・チャット等で端末側へ伝えます。端末はネットワーク経由でピンを取得せず（最初の接続を無条件に信頼する TOFU ではありません）、入力した値と一致する証明書を持つ Sensor とだけ通信・ペアリングします。ペアリング成立時に交換された公開鍵で、以後のプローブ・リクエストの正当性を検証します。
• 破壊的操作なしでも、破壊的操作を許す穴は発見できる設計: 能動的脆弱性監査はすべて非破壊的です（データの書き込み・削除、サービス停止を一切行いません）。ただし「認証なしで書き込み可能」「オープンリレーとして機能する」といった、悪用されれば破壊的な操作を許してしまう設定不備そのものは検出します。
• 誤検知対策（自己監査の除外）: ペアリング済みSensor自身による全ポート監査を、着信ポートスキャン検知ガード（RoamSwitch本体側の機能）が偵察行為と誤認しないよう、送信元IPの照合による除外処理が組み込まれています（IPはあくまで自動遮断を回避するための照合のみに使い、信頼判定そのものには使用しません）。あわせて、この端末が Sensor に監査を依頼してから、レポートを受け取るまでの間（レポートが来ない場合は最長約25分間）に限り、Mac 版では Sensor のアドレスからの検知と、送信元を持たない「SYN の大量受信」の警告を、Linux 版では「SYN の大量受信」の警告を、監査によるものと見られる旨の穏やかな文面で通知します。依頼していない時間帯は従来どおりの強い警告のままで、Sensor が自発的に始めた監査はこの対象に入りません。
• 外部送信は限定的で、機器情報は既定で送らない: 発見した機器情報、監査結果、ARPイベントは既定ではSensor自身のローカルストレージにのみ保存され、Lafineや第三者のサーバーへは送信されません。外部への通信は、検知用データ（CVEマップ・nmap NSEデータベース）の取得（updates.fetch_cve_mapで停止可能。機器・監査データは含まれません）と、§11の通知（Webhook・syslog）や中央コレクターへの送信（運用者が送信先を設定した場合にだけ、自組織の宛先へ）だけです。

10. トラブルシューティング & FAQ

Q1. ペアリングコードを入力しても拒否されます。

考えられる原因は次の4つです: (1) コード発行から10分が経過して失効した（Sensor側オペレーターにissue-codeでの再発行を依頼してください）、(2) コードの入力ミス（判読しづらい 0/O/1/I/L は発行時点で除外されているため、コードにこれらの文字が含まれることはありません）、(3) --addr に指定したIPアドレスが、Sensorの現在の固定IPアドレスと一致していない、(4) --fingerprint がSensorの証明書と一致していない（pin_mismatch / fingerprint_mismatch。roamswitch-sensor pairing show の値を確認してください。誤りが続くとロックアウトされ rate_limited が返ります）。

Q2. NSE補完診断の結果が空です。

次の2つのいずれかが原因です: (1) コンテナにnmapがインストールされていない、(2) 実行はされたが対象ポートに該当する安全なスクリプトの出力が実際になかった。nmap NSE補完診断は、ホストにnmapがインストールされている場合に自動的に実行されます。

Q3. 監査が完了するまでどのくらい時間がかかりますか？

全ポート走査だけであれば数十秒程度ですが、ホストにnmapがインストールされている場合はNSE補完診断が自動的に加わるため、対象の開放ポート数に応じて最大2分程度かかる場合があります。TUIでは実行中の経過秒数が表示され続けるため、進行状況を確認しながらお待ちいただけます。

Q4. ペアリングしたはずなのに監査ができません。

考えられる原因は次のとおりです: (1) エンドポイント側でsensor_pairing_enabled: trueが設定されていない（既定OFF）、(2) ペアリング後にSensorの固定IPアドレスが変わり、端末側が保持している古いアドレスへ接続できなくなっている（再ペアリングが必要です）、(3) Sensor側でunpairによりペアリングが解除されている、(4) Sensorが証明書を再生成（tls rotate）したため、端末側のピンが古い（roamswitch sensor repinで新しいフィンガープリントを入力）。roamswitch sensor list（端末側）とroamswitch-sensor list（Sensor側）の両方で、相手が登録されていることを確認してください。

Q5. Sensor自体はRoamSwitch本体（Client/Server Edition）と併用できますか？

はい。Sensorは自己防衛機能を持たない設計のため、同一マシンにRoamSwitch for Linux Server Editionを併設することを推奨しています。両者は完全に独立したプロセス・データストアで動作し、競合しません。

Q6. roamswitch sensor results が「ペアリングが解除されています」と表示します。

Sensor側で、この端末のペアリングがunpairにより解除されています。Sensorオペレーターに新しいペアリングコードを発行してもらい、roamswitch sensor pair --addr <IP> --code <コード> --fingerprint <SHA-256>で再度ペアリングしてください。

11. 組織向けの監査運用機能（オプトイン）

大規模な組織のセキュリティ担当者が、監査の証跡と変化の把握のために使う機能群です。どれも初期状態では無効で、Lafineや第三者へは何も送信されません。通知先・集約先はすべて運用者が設定した自組織のものです。設定は sudo roamswitch-sensor config set <キー> <値>（デーモンの再起動不要。変更は操作ログに記録されます）で行い、config show で現在値を確認できます。

11.1 定期監査と前回との差分

schedule.enabled を true にすると、ペアリング済みの全端末を自動で定期監査します（既定24時間ごと: schedule.interval_hours。実行してよい時間帯: schedule.window_start_hour / window_end_hour、ローカル時刻で日跨ぎ可。同時実行数: schedule.max_parallel）。監査のたびに前回と比較し、新規検出（リグレッション）・解消・新たに開いたポートを roamswitch-sensor diff で確認できます。以前開いていたポートが全て見えなくなった場合は「解消」ではなく到達不能の疑いとして扱います（停止中の機器と、全ポートを閉じた機器は外から区別できないためです）。

無人の監査でも「合意した端末だけを監査する」保証は崩しません。端末のIPはDHCPで別の機器に割り当てられ得るため、端末が最後に認証（ペアリング、または署名付き監査リクエスト）した時点のMACアドレスを保存し、定期監査の前後で同じMACがそのIPで応答することを、nmapの実際のARP要求で確認します。一致しなければ監査せず（または結果を破棄し）、通知します。手動の scan も、別の機器に渡ったという証拠がある場合は拒否します。この確認にはnmapが必要です。また、この機能の導入前にペアリングした端末は、再ペアリングするか署名付き監査リクエストを送るまで定期監査の対象になりません。対象は同一L2セグメント上の端末です。

11.2 通知（Webhook・syslog）

notify.webhook_urls（Slack・Discord・TeamsなどのIncoming Webhook、または汎用のJSON受信口）と notify.syslog.host / port / protocol（RFC 5424、UDPまたはTCP）に、リグレッション・新規機器・ARPなりすまし・不審な通信などを送ります。notify.min_severity（info / medium / high / critical）と notify.cooldown_minutes（同じイベントの再送間隔）で絞れます。roamswitch-sensor notify-test で送信先ごとの疎通を確認できます。

11.3 監査証跡のエクスポート

roamswitch-sensor export <scans|inventory|audit-log|all> --format csv|json|html [--out ファイル] [--endpoint 公開鍵の先頭] [--since 日付]。html は単体のファイルで、ブラウザで開いて「PDFとして保存」すれば提出用のPDFにできます。CSVは表計算ソフトの数式注入への対策済みです。機器台帳（inventory）には各機器がRoamSwitch管理下（ペアリング済み）かどうかの列が付きます。出力ファイルは所有者のみ読み取り可（0600）で、エクスポートしたこと自体も操作ログに記録されます。TUI の e キーでは同じ指定をフォームで行え、レポート・エクスポートは表示言語（10言語）で作成されます（CLI は日本語・英語）。

11.4 操作・承認ログ（改ざん検知付き）

ペアリング・解除・監査の開始と完了・設定変更・拒否されたアクセスを、実行者（UID／端末の公開鍵／接続元IP）付きで記録します。各行が直前の行のSHA-256を含むハッシュ連鎖のため、編集や削除は roamswitch-sensor audit-log verify で検知できます（異常があれば終了コード2）。一覧は roamswitch-sensor audit-log [--limit N]。Webhook URLはトークンを含みがちなため、設定変更ログには値を残しません。連鎖だけでは末尾の削除を検知できないので、コレクター（§11.6）には先頭（連番とハッシュ）も送られます。

11.5 保持期間

retention.scan_history_days・retention.audit_log_days・retention.inventory_stale_days に日数を設定すると、古い監査履歴・操作ログ・長期間見えない機器を自動で削除します（0 = 期間では削除しない。既定）。メモを登録した機器は台帳から削除されません。

11.6 複数Sensorの集約（中央コレクター、任意）

複数拠点で複数のSensorを動かす場合、別のホストで roamswitch-sensor-collector（パッケージに同梱、既定では無効）を動かし、各Sensorから署名付きの要約を集めます。

# On the collector host (a separate host from the Sensor is recommended)
sudo systemctl enable --now roamswitch-sensor-collector   # listens on 127.0.0.1:8443 by default
sudo roamswitch-sensor-collector token                     # read token for the dashboard
sudo roamswitch-sensor-collector enroll <Sensor public key> --name Tokyo --site Tokyo

# On each Sensor
sudo roamswitch-sensor config set collector.url https://collector.example.org:8443
sudo roamswitch-sensor config set collector.enabled true

• 登録（enroll）したSensorのEd25519署名付きリクエストだけを受け付けます。タイムスタンプで再送も拒否します。
• LAN外へ公開する場合はTLSが必要です。/etc/default/roamswitch-sensor-collector の COLLECTOR_ARGS に --bind 0.0.0.0:8443 --tls-cert … --tls-key … を指定するか、TLSを終端するリバースプロキシの背後で --allow-plain-http を指定してください。TLSなしで127.0.0.1以外に待ち受けようとすると起動を拒否します。
• ダッシュボードはトークンで保護され、拠点別の絞り込み・重大度別のイベント・CSV出力ができます。無応答のSensorと、監査ログの切り詰め・巻き戻し・分岐を検知したSensorを強調表示します（調査後に clear-anomaly <公開鍵> で解除）。
• collector.send_unmanaged_devices（既定 true）が有効だと、Sensor はペアリングされていない機器（管理外デバイス）を要約に含めます。各機器は「未ペアリングのRoamSwitchホスト」（mDNS/SSDPの自己申告に RoamSwitch が現れた場合。collector.probe_control_port を有効にすると制御ポート 50543 への TCP 接続確認も行います。既定は無効）か「不明な機器」に分類され、MAC・ベンダー・機器クラス・初回検出のみを送ります（通信内容は含みません）。TUI では O でコレクター管理画面を開けます。

11.7 検知データの取得（updates.fetch_cve_map）

Sensor は、署名付きの CVE マップ（能動診断で使う既知脆弱性のデータ）と nmap NSE データベースを、更新サービスから毎日取得します。この通信に機器・監査データは含まれません。完全オフラインで運用する場合は sudo roamswitch-sensor config set updates.fetch_cve_map false を実行してください（変更は再起動なしで次の周期から反映され、以後は同梱データだけを使います）。

11.8 設定キー一覧

roamswitch-sensor config show で現在値を確認し、config set <キー> <値> [<キー> <値> …] で変更します（複数キーは原子的に保存され、TUI では C の設定エディタでも変更できます）。「再起動」列が「要」のキーだけ、デーモンの再起動（sudo systemctl restart roamswitch-sensor）で反映されます。

12. 不正DHCPサーバー・IPv6の検知

ネットワークに持ち込まれた別のルーターや攻撃者の機器が、正規のふりをして端末の通信経路を乗っ取る攻撃を見つけます。検知と通知だけで、Sensorが通信を遮断することはありません。既定で有効で、受動キャプチャの設定は要りません。結果は roamswitch-sensor network-threats、TUIの「不審な通信」タブ（m から）、通知（dhcp_rogue_server ipv6_rogue_router ndp_spoof ipv6_unknown_device）、操作・承認ログ、エクスポートに出ます。

12.1 不正なDHCPサーバー（IPv4・DHCPv6）

1時間ごと（と roamswitch-sensor refresh のたび）に、ランダムなMACアドレスから DHCP の探索パケット（DHCPv6 は SOLICIT）を1つだけ送り、応答したすべてのサーバーを数えます。要求（REQUEST）は送らないので、IPアドレスの貸出しは受けません。受動キャプチャが見た DHCP 応答も同じ判定にかけます。最初に見つけたサーバーを正規として学習し、後から現れた別のサーバーを知らせます。正規のサーバーと違うゲートウェイや DNS を配るサーバーは、それを受け取った端末の通信の経由先を乗っ取るため、最も重い critical です。最初の探索で複数のサーバーが同時に応答した場合は、どれが正規か判断できないので、どれも学習せず全部を報告します。

12.2 IPv6（不正なルーター広告・NDPなりすまし・IPv6でしか見えない機器）

不正なルーター広告: IPv6 のルーターは、LAN の誰でも名乗れます。カーネルの近隣テーブル・デフォルト経路・受動キャプチャが見たルーター広告・ルーター要請への応答を突き合わせ、IPv4 のデフォルトゲートウェイと別の機器がルーターとして振る舞っていれば通知します（ipv6.allowed_routers に登録すると正規として扱います。IPv6 のルーターと IPv4 のゲートウェイが別の機器という構成は正常な場合があるため、その場合は登録してください）。ホップリミットが 255 でない広告は、ルーターを越えて来た偽造なので無視します。NDPなりすまし: ある IPv6 アドレスの持ち主の MAC が別の MAC に入れ替わると知らせます（ルーターのアドレスなら high）。IPv6でしか見えない機器: ARP では見えず、近隣テーブルにだけ現れた機器を、ARP 掃引を1回またいでから報告します。機器台帳（CSVの ipv6 列、JSONの ipv6_addrs）にも IPv6 アドレスが載ります。

12.3 誰を正規とみなすか・設定

dhcp.allowed_servers と ipv6.allowed_routers（MAC または IP）を設定すると、それ以外の応答をすべて報告します。空のままなら、最初に見つけたものを学習します。dhcp.active_probe と ipv6.active_probe（既定 true）で能動検査を、ipv6.enabled で IPv6 の監視全体を止められます。制御API（50543）の IPv6 待ち受けは control.listen_ipv6（既定 false、再起動で反映）で追加します。グローバル IPv6 アドレスは、ルーターに IPv6 のファイアウォールが無いとインターネットから届き得るため、既定では有効にしていません。接続数とロックアウトは、IPv6 を /64 単位で数えます。リンクローカルアドレスの端末は、スコープ ID なしでは接続し直せないため、監査先として記憶しません。

13. RoamSwitch未導入機器の軽量監査（オプトイン）

§5 の能動的脆弱性監査は、ペアリングして合意した端末だけが対象です。ペアリングしていないプリンター・カメラ・NAS などについても「何が外に開いているか」を確認したい場合のために、はるかに限定された別の検査があります。OpenVAS のような深い診断、ログインの試行、脆弱性の悪用、nmap NSE、全ポートの走査は、合意した端末にしか行いません。

13.1 行うこと

決まった54ポート（Telnet・FTP・RDP・VNC・SMB・Redis・MongoDB・Docker API・MQTT・RTSP など）への TCP 接続確認、開いていたポートがサービスから自分から送る表示（バナー）の読み取り（Web 用ポートには HEAD / を1回）、ベンダーに公開済みの脆弱性（IoT 脆弱性情報の表）の注記だけです。結果は「このサービスに LAN から届く」であり、「脆弱だ」とは言いません（認証が有効かどうかは調べていない、と各検出に明記されます）。

13.2 有効にする

unmanaged_audit.enabled を有効にするには、先に unmanaged_audit.authorization（誰が承認したか。氏名・チケット番号・規程名など）と unmanaged_audit.allowed_cidrs（監査してよい範囲。IPv4 は /16、IPv6 は /48 より広い範囲は拒否）を設定します。定期実行は interval_hours（既定168時間）ごとで、schedule の時間帯に従います。手動では、二段階目の同意として --confirm が必要です。

sudo roamswitch-sensor config set unmanaged_audit.authorization "IT policy 2026-07, approved by A. Suzuki"
sudo roamswitch-sensor config set unmanaged_audit.allowed_cidrs 192.168.10.0/24
sudo roamswitch-sensor config set unmanaged_audit.exclude 192.168.10.1
sudo roamswitch-sensor config set unmanaged_audit.enabled true
sudo roamswitch-sensor audit-unmanaged 192.168.10.40 --confirm
roamswitch-sensor unmanaged-audits --detail

13.3 守られていること

allowed_cidrs の外、unmanaged_audit.exclude（IP・範囲・MAC）の機器、ペアリング済みの端末、Sensor 自身は、何があっても調べません。実行の前後に、そのアドレスにいる機器の MAC を生の問い合わせ（IPv4 は ARP＝nmap が必要、IPv6 は近隣要請）で確認し、別の機器に変わっていたら中止、または結果を破棄して通知します。authorization の文面は、実行のたびに操作・承認ログへ記録され、エクスポート（export unmanaged、JSON、HTML レポート）にも載るので、「誰が許可して調べたか」を示せます。

13.4 製品の確認（KEV 掲載製品かどうか。オプトイン）

unmanaged_audit.product_check（既定はオフ）を有効にすると、軽量監査の中で、機器が普通に返す Web 画面から製品名を読み取り、その製品に CISA の KEV に載った脆弱性があるかを知らせます。送るのは、接続できた Web 用ポート（80・8080・8181・443・8443・10443）への GET / と、機器自身が示す同じアドレスへのリダイレクト（最大2回）、HTTPS の証明書の発行者・主体の名前の読み取りだけです。ログイン、パスワードの試行、推測したパス、脆弱性を突く入力は送りません。1台あたり最大12要求、150ミリ秒間隔です。同意の条件（enabled・authorization・allowed_cidrs・exclude・ペアリング済み機器の除外・MAC の再確認）は §13.2〜13.3 のままで、軽量監査が止まっていれば product_check が有効でも何も送りません。

製品の名指しは、その製品の画面の目印が同じ応答で揃ったときだけです。機器が自分で表示した版を読めて、NVD の影響範囲に入る CVE があるときだけ「該当」（high）とします。版が読めないときは「この製品には KEV 掲載の脆弱性がある。版は読めなかったので、該当するかは未確認」という注意（medium）にとどめ、脆弱だとは言いません。版を画面に出す製品は現在 MikroTik RouterOS だけなので、ほかの製品は通常「未確認」の注意になります。対応は Fortinet FortiGate、Ivanti Connect Secure、Citrix NetScaler、Cisco（ASA の SSL VPN と IOS XE の Web UI）、UniFi OS、GeoVision、TerraMaster、Check Point の Security Gateway、MikroTik RouterOS です（Aruba の機器は KEV に項目が無く対象外）。製品の目印は公開の検出シグネチャに基づくもので、実機での確認は済んでいません。合わない目印は、検出しない側に倒れます。KEV の写しは製品に同梱され、product_check と updates.fetch_cve_map がどちらも有効なときだけ、24時間ごとに CISA の公開フィード1ファイルを取得して更新します（LAN の情報は一切送りません）。

14. 紛失・盗難・廃棄したとき

Sensor には、端末ごとの脆弱性の一覧、ペアリング済み端末のアドレス、署名鍵が入っています。また、ペアリングした端末は、この Sensor を「ポートスキャンを許可した相手」として扱うため、盗まれた Sensor が同じ LAN につながると、その相手として振る舞えてしまいます。次の仕組みで止めます。

14.1 コレクターでの失効とロックダウン

roamswitch-sensor-collector revoke <公開鍵> --reason 理由 を実行すると、以後その Sensor の送信は 403 sensor_revoked で拒否されます（署名が正しい要求にだけ返すので、鍵を持つ本人だけが知ります）。失効した Sensor は、次の送信でそのことを知り、自分で停止（ロックダウン）します。停止中は、制御APIは sensor_locked_down としか答えず、ペアリング・監査（定期・手動）・コレクターへの送信・通知・ネットワークへの探査をすべて止めます。停止はファイルに残るので再起動後も続き、状態ファイルが読めない場合も停止側に倒れます。データは残るので、持ち主の手元にあると確実な場合だけ roamswitch-sensor lockdown off で解除できます（TUI は K）。コレクターで失効されたままだと、次の送信で再び停止します。revoke は、その Sensor とペアリングしていた端末の一覧と、各端末での解除手順も表示します。

14.2 消去・廃棄・オフライン検知

security.on_revoked を wipe にすると、失効時に鍵・TLS 鍵・設定（Webhook URL を含む）・ペアリング済み端末の一覧・監査結果・機器台帳を 0 で上書きして削除します。操作・承認ログだけは証跡として残します。lockdown（既定）は停止してデータを残し、none は通知だけです。手元の Sensor を手動で廃棄するには roamswitch-sensor decommission --confirm（停止と消去。元に戻せません）を使います。security.lockdown_after_offline_days に日数を入れると、コレクターに長期間送信できなかった Sensor が自分で停止します（盗まれて別のネットワークで使われる場合の備え。コレクター送信が有効で、過去に一度は成功している場合だけ働き、既定は 0＝無効）。

14.3 この仕組みでできないこと

ペアリングしていた端末は、各自がペアリングを解除するまで、この Sensor を信頼したままです。Sensor から端末へ通知する経路は無いため、revoke と decommission が表示する一覧の各端末で、Linux は roamswitch sensor unpair <この Sensor の公開鍵>、Mac は 設定 > Sensor > ペアリング解除 を実施してください。電源が切られたまま、またはネットワークに出ないまま持ち去られた Sensor には、停止の指示が届きません。ディスクの暗号化（LUKS など）が実際の防御です。上書き消去は、フラッシュ記憶装置や CoW ファイルシステムでは完全な消去を保証しません。