Posted inホームラボ

DockerでNetAlertXをデプロイ：自宅ラボ（HomeLab）の自動ネットワークスキャンと不正デバイス検知アラート

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

現実の課題：静かに潜む侵入者とネットワークの死角

週末に自宅クラスタの定期ストレージ移行を行っていた際、見慣れないIPアドレスが目に留まりました。192.168.1.184です。MACアドレスを調べてみると、ノーブランドのTuya製Wi-Fiスマートプラグが4秒おきにリモートのAWSエンドポイントへpingを送信していることが判明しました。

家族が3週間前にベッドサイドランプの裏側に接続し、そのまま忘れ去られていたのです。21日間もの間、クローズドソースのファームウェアを搭載した格安IoTデバイスが、メインの管理サブネット上に直接配置されていました。Proxmoxハイパーバイザー、TrueNASのバックアッププール、さらにはIPMIのアウトオブバンド管理インターフェースと同じLayer 2ブロードキャストトラフィックを共有していたのです。

多くのセルフホスティング実践者が、まさにこの死角に直面しています。私たちはハイパーバイザーを運用し、無数のコンテナを起動し、ゲストWi-Fiを設定して、スマートホーム機器を隔離されたスイッチに収容します。しかし、ターミナルで手動スキャンを常時実行していない限り、深夜2時に物理ネットワークや無線ネットワークへ何が接続されたかを把握することはできません。未検証のIoTデバイス、不正な静的IP、来客のノートPC、あるいは侵害されたマイコンなどが、気づかれないまま何週間もサブネット内に潜み続ける可能性があるのです。

根本原因の分析：一般的なルーターでは検知できない理由

なぜ市販のルーターはこれらのデバイスを即座に検知できないのでしょうか？一般的なコンシューマー向けゲートウェイは、標準的でないネットワーク動作を見逃すパッシブな仕組みに依存しています。

  • パッシブで一時的なDHCPリース：多くの家庭用ルーターやエントリーレベルのファイアウォールは、アクティブなDHCP割り当てしか表示しません。DHCPプール外の未割り当て静的IPでデバイスが起動した場合、ルーターのテーブルには一切登録されません。また、既存のリース期間が切れると、監査ログは完全に消滅してしまいます。
  • Layer 3ゲートウェイからのLayer 2分離：同一ローカルサブネット上のデバイスは、アドレス解決プロトコル（ARP）を使用してLayer 2イーサネットスイッチ経由で直接通信します。デバイス間のトラフィックがデフォルトゲートウェイを経由して別サブネットへ向かわない限り、ルーターがそれらのローカルフレームを検査することはありません。
  • Webhook機能の完全な欠如：標準的なルーターのファームウェアは、接続イベントを揮発性のRAMリングバッファに書き込むだけです。未知のMACアドレスがアクセスポイントに関連付けられても、ルーターはスマートフォンにWebhookを送信する代わりに、内部のカウンターを静かにインクリメントするだけです。

検知手法の比較：自作スクリプト vs ファイアウォールルール vs NetAlertX

自宅ラボの運用者がネットワーク検出を行う場合、通常は次の3つのアプローチのいずれかを採用します。

  • カスタムCronスクリプト（Nmap / Arp-scan）：軽量なBashスクリプトを作成し、5分ごとにarp-scan --localnetを実行して結果をテキストファイルと比較し、差分があればcurlでWebhookを叩く手法です。動作はしますが、すぐに破綻します。モバイルデバイスがディープスリープに入ると誤切断のアラートが頻発し、MACベンダーの解決や稼働履歴ログも失われます。
  • ファイアウォールネイティブプラグイン（OPNsense / pfSense / MikroTik）：ファイアウォール上の組み込みスクリプトやパッケージを使用して、ARPテーブルとDHCPイベントを監視するアプローチです。信頼性は高いものの、通知パイプラインがコアのルーティングハードウェアと密結合してしまいます。また、負荷の高いNmapスキャンは、エッジゲートウェイの貴重なCPUリソースを消費します。
  • 専用ネットワーク監視ツール（NetAlertX）：Pi.Alertの近代的な後継ツールであるNetAlertXは、軽量なスタンドアロンデーモンとして動作します。アクティブなARPスイープ、ICMP ping、DNSルックアップを自動MACベンダー識別と組み合わせて実行します。未承認のMACアドレスが最初のフレームをブロードキャストすると、NetAlertXはそのイベントを記録し、Discord、Telegram、Pushoverなどに即座にアラートをプッシュ通知します。メモリ消費量は約120MBにとどまり、Intel N100ミニPC上でのCPUオーバーヘッドは2%未満を維持します。

解決策：Docker上にNetAlertXをデプロイする

NetAlertXをコンテナ化することで、ベースOSを汚すことなく、クリーンな永続性と容易なバージョンアップグレードが実現できます。ただし、ネットワーク検出ツールには絶対に譲れないルールが1つあります。それは、ホストネットワークモードを有効にする必要があるという点です。

Dockerのデフォルトブリッジネットワーク（docker0）は、コンテナをNAT（ネットワークアドレス変換）の背後にある隔離された仮想名前空間に配置します。ARPリクエストはルーティング不可能なLayer 2ブロードキャストパケットであるため、ブリッジの境界を越えることができません。network_mode: "host"を設定することで、NetAlertXが物理ネットワークインターフェース（eth0やenp3s0など）に直接バインドされ、スキャナーがローカルネットワーク上のブロードキャストトラフィックに直接アクセスできるようになります。

ステップ1：ディレクトリの作成と権限設定

Dockerホスト（Debian 12やUbuntu 24.04 LTSなど）にSSH接続し、永続データ、SQLiteデータベース、ログ用のディレクトリ構造を作成します。

mkdir -p ~/netalertx/config
mkdir -p ~/netalertx/db
mkdir -p ~/netalertx/log
cd ~/netalertx

ステップ2：Docker Compose設定ファイルの作成

composeファイルを作成します。

nano docker-compose.yml

以下の設定を貼り付けます。スキャナーがDockerの仮想ブリッジをバイパスし、物理ネットワークアダプターを直接参照できるように、network_mode: "host"が指定されている点に注目してください。

services:
  netalertx:
    image: jokobsk/netalertx:latest
    container_name: netalertx
    restart: unless-stopped
    network_mode: "host"
    environment:
      - TZ=America/New_York
      - PORT=20211
      - SCAN_SUBNETS=192.168.1.0/24
    volumes:
      - ./config:/app/config
      - ./db:/app/db
      - ./log:/app/log

SCAN_SUBNETSをご自身のLAN環境に合わせて調整してください（例：隔離された管理サブネットをスキャンする場合は10.0.10.0/24）。TZにはお住まいの地域のtz-databaseタイムゾーン文字列（例：Asia/Tokyo）を指定します。

ステップ3：NetAlertXの起動とログの確認

バックグラウンドでコンテナを起動します。

docker compose up -d

初期起動シーケンスを監視し、SQLiteのマイグレーションが完了し、RAWソケットのバインドが成功したことを確認します。

docker compose logs -f netalertx

データベースが初期化され、バックグラウンドのARPデーモンが起動したことを示す確認メッセージが表示されるはずです。ブラウザを開き、次のURLにアクセスしてください。

http://<DOCKER_HOST_IP>:20211

ステップ4：ネットワークベースラインの確立とプッシュ通知の有効化

初回のスキャンでは、NetAlertXは検出したすべてのデバイスを未知の資産としてフラグ付けします。頻繁な通知を有効にする前に、20分ほど時間を取ってこの一覧を精査してください。各ホストに分かりやすい名前を付け（例：「リビング Apple TV 4K」や「Dell R730 iDRAC」）、適切なデバイスタイプを割り当てて、ハードウェアをConnected / Known（接続済み／既知）としてマークします。

信頼できるベースラインが確定したら、今後未知のデバイスが検出された際に即座にアラートが届くよう通知を設定します。

  1. NetAlertXのWebインターフェースで、Settings > Alertingを開きます。
  2. 通知先のプラットフォーム（Telegram、Discord Webhook、Gotifyなど）を選択します。
  3. Telegramの場合は、Bot Tokenと数値のChat IDを入力し、テストボタンをクリックして受信確認を行います。
  4. Alert on New Devices Found（新しいデバイス検出時にアラート）のチェックボックスをオンにします。
  5. Settings > Coreに移動し、スキャン間隔を設定します。3分間隔に設定すると、標準的な/24サブネットでARPブロードキャスト量を毎秒15パケット未満に抑えつつ、未知のハードウェアを迅速に検知できます。

ステップ5：アラートパイプラインのテスト

未登録のデバイスを接続してセットアップを検証します。スマートフォンを用意し、Wi-Fi設定を開いて「プライベートWi-Fiアドレス」をオフ（またはMACランダム化を切り替え）にして、LANに再接続します。あるいは、別のノートPCに未使用の静的IPを一時的に割り当てても構いません。

2回のスキャンサイクル以内に、NetAlertXは未知のMACアドレスを検知し、ベンダーのOUIプレフィックスを識別して、スマートフォンに直接通知をプッシュ送信します。

[NetAlertX アラート]
ステータス: 新しいデバイスを検出
IPアドレス: 192.168.1.184
MACアドレス: 4A:2B:11:89:C4:02 (ベンダー: ランダム化 / 不明)
ネットワークインターフェース: eth0
初回検出日時: 2026-10-14 11:15:00

これで、自宅ラボの物理ネットワークセグメントに対する継続的な可視性が確保されました。未知のハードウェアが密かに接続されることはなくなり、不正なデバイスが内部サービスを調査する前に通知を受け取ることができます。

Share:
Tags: