ルーターでIoT機器の脆弱性を自動診断・隔離する仕組みを作ってみた

開発のきっかけ

私がIoTセキュリティに興味を持ったきっかけは、2018年に流行したマルウェア「Mirai」です。
Miraiは、工場出荷時のID・パスワードがそのまま使用されているIoT機器に侵入し、遠隔操作を行うマルウェアです。このような単純な攻撃であるにもかかわらず、世界中で多くの機器が影響を受け、大きな被害が発生しました。
この背景には、ネットワークカメラや家庭用ルーターなどのIoT機器は、ネットワークに接続するだけで利用でき、また、乗っ取られても、Botnetやクリプトジャッキングなど利用者が直接被害を受けずに悪用されるケースが多いため、セキュリティ対策が後回しになりがちなことが挙げられます。
そこで、私は利用者にセキュリティ対策を委ねるネットワーク側で機器を保護する仕組みが必要であると考えました。具体的には、攻撃者が行うスキャンや辞書型攻撃と同様の確認を、ネットワークの入口であるルーター上で事前に実施し、脆弱性がある場合は、IoT機器がネットワークに接続されることを防ぐ仕組みです。

このような考えのもと、ネットワーク側でIoT機器の安全性を確認・隔離できるQuarantを開発しました。

Quarantによる自動診断の仕組み

Quarantは、ネットワークに接続されたIoT機器に対して、ルーター上で以下の3つの診断を行います。3つのうち、いずれかで脆弱性や不審な挙動が確認された場合、即座に通信を遮断し、公式LINEを通してユーザー通知をします。

1. SSH (22) / Telnet (23) への辞書型認証チェック

22番ポートおよび23番ポートが開放されているかを確認し、開放されている場合は、攻撃でよく利用される初期認証情報でログインを試みます。認証に成功した場合、その機器は外部から不正にアクセスされ、乗っ取られる可能性があると判断します。

2. 2323番ポートを用いたハニーポットによる感染検知

外部からの攻撃や、既にマルウェアに感染した機器を検知するため、簡易的なハニーポットを実装しました。2323番ポートへの接続が確認された場合、そのデバイスが攻撃を試みている、またはマルウェアに感染している可能性があると判断します。
（ルーターの通信制御を利用して、Telnetへのアクセスを2323番ポートへ転送しています。）

3. Web管理画面の脆弱性と設定漏洩スキャン

Web管理画面（80, 8080, 37215番ポート）に対して、特定のリクエストを送信し、既知の脆弱性や設定漏洩の有無を診断します。具体的には、以下のようなリスクを検査します。

• 認証なしで設定ファイルやユーザー情報を取得できてしまう既知の脆弱性
• OSコマンドインジェクションのリスク

これらのリクエストに対して本来取得できないはずの情報が返された場合や、任意コマンドの実行が可能な場合は、対象機器を危険な状態とみなします。

使用した技術

• 開発言語
  Go言語
• ハードウェア
  NEC製 Aterm WG1800HP2
• OS・ファームウェア
  OpenWrt
  Metasploitable2
• 外部サービス
  LINE Developers

ソースコードはGitHubで公開しています
https://github.com/SaeYoshizaki/Quarant

開発環境の構築

本システムの実装には、自宅にあった約14年前のルーター Aterm WG1800HP2 を使用しました。PCとの通信経路を確保するため、基板上のUARTにピンヘッダをはんだ付けし、USBシリアル変換アダプターを接続しました。

もともと入っていたNEC純正のファームウェアではroot権限が取得できなかったため、シリアルコンソール経由でOSをOpenWrtに書き換えました。

検証環境の設計と構築

Quarantの動作検証をするにあたり、Web管理画面の脆弱性検知やハニーポットによる挙動検知は、意図的に脆弱性を持たせた環境が必要となるため、仮想環境上での再現が適していました。一方、Telnetを用いた診断では、実際の家庭内ネットワークに近い構成で動作させることで、正常な端末が誤って検知されないことを同時に確認する必要がありました。

Quarantの動作検証を行うにあたり、Web管理画面の脆弱性検知やハニーポットによる挙動検知については、意図的に脆弱性を持たせた環境が必要となるため、仮想環境上で再現する構成としました。一方で、Telnetを用いた診断については、実際の家庭内ネットワークに近い構成で動作させることで、正常な端末が誤って検知されないかを併せて確認する必要がありました。

そのため本検証では、目的に応じて以下の2つの環境を使い分けました。

• 仮想環境（192.168.64.x）
  Web管理画面の脆弱性検知およびハニーポット挙動の検証
• 実ネットワーク環境（192.168.1.x）
  Telnetを用いた診断と、正常端末が検知されないことの確認

仮想環境（192.168.64.x）

Web管理画面の脆弱性およびSSHの初期認証チェックを再現するため、Metasploitable2を用いた検証用デバイスを仮想環境上に構築しました。

用意したターゲット端末

• ターゲットA（IP: 192.168.64.13）
  • 開放ポート: 80番（HTTP）
  • 再現した脆弱性:
    特定のURLパスにアクセスすることで、認証なしで機密情報が取得できるWeb管理画面の脆弱性
• ターゲットB（IP: 192.168.64.14）
  • 開放ポート: 22番（SSH）
  • 再現した脆弱性:
    工場出荷時の初期ID / パスワードでログイン可能な状態

実行結果

1. 仮想環境での検知ログ（192.168.64.x）

仮想環境上に構築したターゲットAおよびBをQuarantでスキャンした際の、標準出力ログは以下のようになりました。それぞれのIPアドレスに対して擬似的な攻撃が行われて、Web管理画面およびSSHの脆弱性が正しく検知されています。

2. 実ネットワーク環境での検知ログ（192.168.1.x）

検証用の物理ルーター(192.168.1.1)のTelnetを意図的に開放し、スマートフォンなどの安全な端末と混在させた状態で診断を行いました。結果は、安全な端末は検知対象とならず、Telnetが開放されている危険なルーターのみがDANGERと判定されました。

3. 管理者へのLINE通知

脆弱性を検知したタイミングで、検知日時・対象IPアドレス・検知理由が、連携済みのLINEアカウントへ送信されます。

おわりに

本記事では、家庭内ネットワークに接続されたIoT機器を対象に、ルーター側でリスクを自動的に検知・隔離する仕組みとして、Quarantを設計・実装し、その動作を検証しました。
今回は、ユーザーが公式LINEの登録を行う画面を用意することはできませんでした。今後の展望としては、ネットワークに新たな機器が接続された際、PCやスマートフォンなどブラウザを備えた端末に対してポップアップを表示し、公式LINEとの連携を促す仕組みを実装したいと考えています。

参考資料