RoamSwitch Sensor 運用マニュアル
LAN に設置するだけで、同一セグメント上の新規機器出現・なりすましを検知し、RoamSwitch 導入済み端末(Mac / Linux Client / Server Edition)に対しては能動的な脆弱性監査を行うネットワークセンサーの導入・運用ガイドです。apt / dnf パッケージで配布中です。
1. 概要 & 位置づけ
RoamSwitch(Mac / Linux Client / Server Edition)は、いずれもホストに常駐するエージェントという形態です。これには構造的な穴が 2 つあります。
- RoamSwitch を導入できない機器がある: IoT機器(ネットワークカメラ、スマートプラグ、複合機)、来客・BYOD端末、ネットワーク機器自体、組み込み機器など。
- 単独ホストの自己診断には原理的な死角がある: 「外部からは閉じているが、同じLAN上の別端末からは丸見え」という横移動(lateral movement)リスクは、ホスト自身が自分だけを見ていては検知できません。
RoamSwitch Sensor は、LAN に設置する専用ノードとして、この 2 つの穴を埋めることを目指す製品です。現時点で実際に実装・動作確認できているのは、同一 LAN 上の RoamSwitch 導入済み端末に対する能動的な脆弱性監査と、Sensor 自身の ARP テーブルを起点とした新規機器出現・なりすましの受動的検知の 2 つです(§6 の通り、LAN 上の全機器を能動的にスキャンして可視化する機能ではありません)。EDR ではなく、軽量な NDR(Network Detection & Response)と内製の実証型脆弱性スキャナを組み合わせた製品として設計しています。
_roamswitch._tcp.local)によるローカルLAN限定の相互発見で完結し、クラウド登録やアカウント作成は不要です。自己防衛は実装しません(意図的な設計判断)。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テーブル・mDNSマルチキャストを直接観測する必要があるためです)。 - リソース消費: 常駐メモリ数十MB程度、アイドル時CPU負荷は極めて軽量です。
- 任意:
nmap(NSE補完診断を使う場合のみ。未インストールでも他の機能は正常に動作します)。
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
ROAMSWITCH_SENSOR_PASSIVE_CAPTURE_IFACE 環境変数(systemctl edit roamswitch-sensor.service で設定)に対象インターフェース名を指定すると、そのインターフェース上のEthernet/IPv4ヘッダーを観測し、新規機器の出現や既知の悪性IPとの通信を検知します(§6.1参照)。既定では無効です。4. ペアリング(相互信頼)
Sensor は工場出荷時点では何も信頼していません。各 RoamSwitch 端末が Sensor を「能動的な脆弱性監査を受け入れる相手」として明示的に許可し、また Sensor 側も相手の端末を信頼する必要があります(Bluetoothペアリングに類する明示的な相互確認)。
発見はローカル限定の mDNS(_roamswitch._tcp.local)で行われ、クラウドへの登録・アカウント作成は一切不要です。信頼はEd25519公開鍵で識別され、IPアドレスはDHCPで変動しうる補助情報としてのみ扱われます。
4.1 エンドポイント側からのペアリング(Sensorを発見・信頼)
# RoamSwitch for Linux 側で実行
sudo roamswitch sensor discover
sudo roamswitch sensor pair <公開鍵またはその先頭> --confirm
Mac版では、メニューバーの「🔍 RoamSwitch Sensor ペアリング…」からGUIで同様の操作ができます。
4.2 Sensor側からのペアリング(エンドポイントを発見・信頼)
sudo roamswitch-sensor discover
sudo roamswitch-sensor pair <公開鍵またはその先頭> --confirm
相互信頼を完成させるには、両方向のペアリングが必要です。片方向だけでは、その方向の監査プローブしか正当なものとして認識されません。
# エンドポイント側 (roamswitch-linux)
sudo roamswitch sensor pair <完全な公開鍵> --addr <IPアドレス> --confirm
# Sensor側
sudo roamswitch-sensor pair <完全な公開鍵> --addr <IPアドレス> --confirm
自分自身の公開鍵とアドレスは、相手側の手動ペアリングフォームに入力する情報として次のコマンドで確認できます。
# エンドポイント側で自身の公開鍵/アドレスを確認
sudo roamswitch sensor key
# Sensor側で自身の公開鍵/アドレス/MACアドレスを確認
sudo roamswitch-sensor status
5. 能動的脆弱性監査
ペアリング済みのエンドポイントに対し、Sensor から非破壊的な実証型脆弱性診断を実行します。破壊的操作(データの書き込み・削除、サービス停止)は一切行いません。
sudo roamswitch-sensor scan <公開鍵またはその先頭>
sudo roamswitch-sensor scan <公開鍵またはその先頭> --nse
監査は4段階のフェーズで構成されています。
- 全ポート走査: 対象ホストの開いているTCPポートを網羅的に検出します。
- 既知シグネチャ診断: Redis / dockerd / Memcached / MongoDB の認証なし露出確認、SMTPオープンリレー診断(
MAIL FROM/RCPT TOのみ送信、DATAは送信しない安全な手法)、開発サーバーのCORS誤設定・パストラバーサル・オープンリダイレクト診断など、既知の脆弱性パターンに対する非破壊的な実証確認を行います。 - 汎用バナー取得: 上記シグネチャでカバーされていない開放ポートについて、接続のみでバナー文字列を取得します(データの送信は行いません)。
- nmap NSE補完診断(オプトイン、
--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
6. 受動的ARP監視 & LAN可視化
Sensor 自身が保持する ARP テーブル(/proc/net/arp 相当)を定期的にスナップショットし、前回との差分から「これまで見たことのない新規 IP/MAC の出現」と「既知 IP に対する MAC アドレスの変化(ゲートウェイなりすまし等の兆候)」の 2 種類のイベントを検知します。能動的なパケット送信は行わず、Sensor が過去に何らかの形で通信した機器のみが対象になります。機器の種別(IoT機器か否か等)を判別する機能はなく、単に IP/MAC の変化のみを検知します。
roamswitch-sensor arp-events
検知したイベントはTUIの「ARP Events」タブからも一覧できます。「新規機器の出現」と「既知IPのMACアドレス変化(なりすましの疑い)」の2種類を区別して表示します。
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
7. CLI コマンド早見表
| コマンド | 機能概要 |
|---|---|
roamswitch-sensor status |
Sensor自身の公開鍵・IPアドレス・MACアドレス、発見数・ペアリング数・ARPイベント数を表示 |
roamswitch-sensor discover |
mDNSでLAN上のRoamSwitch端末を探索 |
roamswitch-sensor list |
ペアリング済み端末の一覧を表示 |
roamswitch-sensor pair <公開鍵> [--addr <IP>] [--name <名前>] --confirm |
端末をペアリング(mDNS発見済みなら先頭一致可、--addr指定時は完全な公開鍵が必要) |
roamswitch-sensor unpair <公開鍵> |
ペアリングを解除 |
roamswitch-sensor scan <公開鍵> [--nse] |
ペアリング済み端末へ能動的脆弱性監査を実行 |
roamswitch-sensor history [公開鍵] |
監査履歴を表示(公開鍵省略で全端末分) |
roamswitch-sensor report <公開鍵> [--out <ファイル>] |
直近の監査結果をMarkdownレポートとして出力 |
roamswitch-sensor arp-events |
検知したARPイベント(新規機器・なりすまし疑い)を表示 |
CLIは日本語 / 英語のみに対応しています(LANG環境変数に従います)。
8. TUI 操作ガイド
対話型TUI(roamswitch-sensor-tui)は10言語に対応しています。4つのタブ(発見された端末 / ペアリング済み / ARPイベント / 監査履歴)をTabキーで切り替えます。
| キー | 動作 |
|---|---|
Tab | タブを切り替え |
↑↓ / j k | 項目を選択 |
d | mDNSで探索 |
p | 選択中の発見済み端末をペアリング |
m | 公開鍵/アドレスを直接入力して手動ペアリング |
u | ペアリングを解除 |
s | 選択中の端末へ能動的脆弱性監査を実行 |
n | nmap NSE補完診断のON/OFFを切替(既定ON) |
i | このSensor自身の公開鍵/アドレス/MACアドレスを表示 |
Enter | 選択中の監査履歴/ARPイベントの詳細を表示 |
w | (詳細表示中)内容をファイルへ書き出し |
L | 表示言語を選択 |
q | 終了 |
9. 信頼モデル & セキュリティ設計
- TOFU(Trust On First Use): ペアリングの瞬間自体は暗号学的な所有証明ではなく、mDNSでの発見と運用者自身の判断(「このネットワーク上のこのSensorを認識しているか」)による確認です。Bluetoothの「Just Works」モデルと同様です。ペアリング後は、記録された公開鍵で以後のプローブの正当性を検証します。
- 破壊的操作なしでも、破壊的操作を許す穴は発見できる設計: 能動的脆弱性監査はすべて非破壊的です(データの書き込み・削除、サービス停止を一切行いません)。ただし「認証なしで書き込み可能」「オープンリレーとして機能する」といった、悪用されれば破壊的な操作を許してしまう設定不備そのものは検出します。
- 誤検知対策(自己監査の除外): ペアリング済みSensor自身による全ポート監査を、着信ポートスキャン検知ガード(RoamSwitch本体側の機能)が偵察行為と誤認しないよう、送信元IPの照合による除外処理が組み込まれています(IPはあくまで自動遮断を回避するための照合のみに使い、信頼判定そのものには使用しません)。
- Zero-Telemetry: 発見した機器情報、監査結果、ARPイベントはすべてSensor自身のローカルストレージにのみ保存されます。外部サーバーへの送信は一切行いません。
10. トラブルシューティング & FAQ
Q1. discoverしても何も見つかりません。
Sensor から discover した場合、既知の制約により現状発見できません(§4.3参照)。エンドポイント側から discover する方向は動作しますが、一部のWi-Fiアクセスポイントでは、クライアント側から有線側へのマルチキャスト転送が非対称で、mDNSによる相互探索が機能しないことがあります。§4.2の手動ペアリングをお使いください。また、SensorがDockerコンテナのブリッジネットワークで起動している場合、物理LANのマルチキャストが届きません。物理LAN上での検証には必ず--network hostで起動してください。
Q2. --nseを指定しても補完診断の結果が空です。
次の3つのいずれかが原因です: (1) TUIでnキーによるNSE有効化を行っていない(CLIでは--nseフラグの付け忘れ)、(2) コンテナにnmapがインストールされていない、(3) 実行はされたが対象ポートに該当する安全なスクリプトの出力が実際になかった。TUIのタイトルバーには現在のNSE状態(NSE:ON/NSE:OFF)が常時表示されます。
Q3. 監査が完了するまでどのくらい時間がかかりますか?
全ポート走査だけであれば数十秒程度ですが、--nse指定時はnmapの補完診断が加わるため、対象の開放ポート数に応じて最大2分程度かかる場合があります。TUIでは実行中の経過秒数が表示され続けるため、進行状況を確認しながらお待ちいただけます。
Q4. ペアリングしたのに監査ができません。
相互ペアリングが片方向のみになっている可能性があります。エンドポイント側のroamswitch sensor pairとSensor側のroamswitch-sensor pairの両方を実行し、双方のlistコマンドで相手が登録されていることを確認してください。Sensor→エンドポイント方向は§4.3の既知の制約によりdiscoverで自動発見できないため、§4.2の手動ペアリングを使う必要があります。
Q5. Sensor自体はRoamSwitch本体(Client/Server Edition)と併用できますか?
はい。Sensorは自己防衛機能を持たない設計のため、同一マシンにRoamSwitch for Linux Server Editionを併設することを推奨しています。両者は完全に独立したプロセス・データストアで動作し、競合しません。