はじめに
IoT機器のセキュリティに興味を持ったきっかけは、家庭や身近な場所で使われている機器でありながら、内部で何が起きているのかを利用者がほとんど確認できない点に疑問を持ったことでした。
IoT機器は、カメラ、スマートスピーカー、家電、センサーなど用途も構成もさまざまで、OSや実装、通信方式も機器ごとに異なります。そのため、機器の内部を直接調べて、すべての機器を同じ方法で監視することは簡単ではありません。
そこで注目したのが、ネットワーク上に現れる通信です。通信先、利用プロトコル、平文通信の有無、TLSメタデータなどを観測することで、機器の振る舞いやリスクの手がかりを読み取れるのではないかと考えました。
この考えをもとに、IoT機器の通信をパッシブに観測するツール「Quarant」を作りました。
この記事では、Quarantの設計方針、パケット解析の流れ、実際のIoTカメラの通信を観測した結果を通じて、ネットワーク通信から何が分かり、何が分からないのかを整理します。
目次
Quarantとは
Quarantは、IoT機器の通信をパッシブに観測し、ネットワーク上に現れる振る舞いやセキュリティリスクの手がかりを整理するためのツールです。脆弱性診断用のツールではなく、通信観測だけから何が分かり、何が分からないのかを調べるための研究・検証用プロトタイプとして作成しました。
pcapファイルやネットワークインターフェースから取得したパケットをもとにTCPフローを再構成し、HTTP / TLS / MQTT / Telnet などのプロトコル情報を解析しています。通信上で観測できたリスクの分類には、OWASP IoT Top 10 2018を使っています。
解析結果は events.jsonl・flows.jsonl・device_inventory.json などのファイルとして出力されるほか、localhostで動くWeb UIからも確認できます。
ソースコードは以下で公開しています。
設計思想
パッシブ監視では、通信内容や機器の内部状態をすべて確認できるわけではありません。そのためQuarantでは、ネットワーク上で観測できた情報だけをもとに、機器や通信の状態を断定しないようにしています。
各イベントには以下のフィールドを記録しています。
| フィールド | 意味 |
|---|---|
observed_fact |
実際に観測できたこと |
inference |
そこから考えられるリスク |
limitation |
パッシブ監視だけでは断定できないこと |
recommendation |
次に確認・対応すべきこと |
全体の構成
現時点では、取得済みのpcapファイルや、Linux環境のネットワークインターフェースから取得したパケットを解析する形で実装しています。
将来的には、OpenWrtルーターやLinuxゲートウェイを観測点として、家庭内IoT機器の通信をネットワークの境界で観測する構成を想定しています。
[IoT機器]
|
| HTTP / TLS / MQTT / Telnet など
v
[OpenWrtルーター / Linuxゲートウェイ]
|
| pcap / network interface
v
[Quarant]
|
| packet capture
v
[TCPフロー再構成]
|
| protocol analysis
v
[HTTP / TLS / MQTT / Telnet 解析]
|
| rule engine
v
[OWASP IoT Top 10 に関連するリスクシグナル]
|
v
events.jsonl / flows.jsonl / device_inventory.json
|
v
Web UI
Quarantで観測できるもの・できないもの
Quarantで観測できるもの
| 観測する情報 | 例 | リスクの手がかり |
|---|---|---|
| 通信先 | 宛先IPアドレス、ポート番号、ドメイン名、SNI | 不明な外部通信先、普段と異なる接続先 |
| 利用プロトコル | HTTP、TLS、MQTT、Telnet など | 平文通信、安全でない可能性のあるサービス |
| 平文通信 | HTTPリクエスト、URL、Hostヘッダ、Cookie、Authorizationヘッダなど | 認証情報や設定値が平文で送られている可能性 |
| TLSメタデータ | TLSバージョン、SNI、暗号スイート、証明書情報の一部 | 古いTLS設定、弱い暗号スイートの利用可能性 |
| 通信フロー | 送信元/宛先、ポート、通信量、通信回数 | 通信量の急増、特定宛先への継続的な通信 |
| デバイス推定の手がかり | ホスト名、User-Agent、SNI、通信先、ポート番号など | 機器カテゴリやベンダー推定の材料 |
Quarantで観測できないもの
| 観測できない情報 | 理由 |
|---|---|
| HTTPS通信の本文 | TLSで暗号化されているため、復号しない限り内容は見えない |
| 機器内部のOS状態 | プロセス、設定、ログなどはネットワーク上には直接現れない |
| ファームウェア内部の実装 | バイナリやライブラリの内容は通信だけでは確認できない |
| 保存データの状態 | 端末内部にどのように保存されているかは分からない |
| 認証・認可の正しさ | 通信の外側からは、サーバ側の権限検証の実装までは判断できない |
| 脆弱性の確定 | 通信上の手がかりだけでは、実際に悪用可能かまでは断定できない |
OWASP IoT Top 10との対応
Quarantでは、通信上に現れたセキュリティリスクを分類するために、OWASP IoT Top 10 2018を参考にしました。
各カテゴリと、Quarantで扱う主なリスクシグナルの対応は以下の通りです。
| カテゴリ | 内容 | Quarantで扱うリスクシグナル |
|---|---|---|
| I2 | Insecure Network Services | Telnet、FTP、RTSP、MQTT、CoAP などの通信 |
| I3 | Insecure Ecosystem Interfaces | 平文HTTP上のAPI通信、URL内の token や password らしき値 |
| I4 | Lack of Secure Update Mechanism | HTTP経由のファームウェア取得らしき通信、/firmware や /ota などのパス |
| I5 | Use of Insecure or Outdated Components | 通信メタデータやデバイス推定結果と、既知脆弱性候補の関連づけ |
| I6 | Insufficient Privacy Protection | 外部サービスへの通信、履歴・ログ・識別子に関連しそうな通信 |
| I7 | Insecure Data Transfer and Storage | 平文HTTP、Authorizationヘッダ、Cookie、URL内の token、TLSメタデータ |
| I8 | Lack of Device Management | 新しく観測された端末、未登録端末、通信傾向の変化 |
実際に解析してみる
次に、実際にネットワークカメラをQuarantで解析し、どのようなリスクシグナルや通信情報が出力されるかを確認してみました。
検証に用いた機器
検証には、株式会社ハックのWi-Fiライブカメラ「HAC4889A」を使用しました。販売ページではメーカー発売日が2026年3月30日と記載されており、比較的新しい機器だったため、検証対象として選びました。カメラの操作には、スマートフォンアプリ「iCam365」を使用しています。
pcapを解析する
取得したpcapを、Quarantの analyze コマンドに渡して解析します。
./quarant analyze camera.pcap --out events.jsonl --report --open
--report --open を付けると、解析後にローカルの Web Report Viewerを自動で起動できます。
解析結果として、以下の3つのファイルが生成されます。
| 出力ファイル | 内容 |
|---|---|
events.jsonl |
検出されたリスクシグナル |
flows.jsonl |
通信フローの概要 |
device_inventory.json |
観測された端末情報とリスクサマリ |
ここからは、それぞれの出力ファイルの中身を順番に確認していきます。
検出されたリスクシグナル
events.jsonl には、Quarantが検出したリスクシグナルが記録されます。今回の解析では、以下のルールIDが確認できました。
| ルールID | 内容 |
|---|---|
I7_HTTP_PLAINTEXT |
平文HTTP通信が観測された |
I7_TLS_WEAK_CIPHER_OFFERED |
TLS ClientHelloで弱い、または古い暗号スイート候補が提示された |
I7_HTTP_BODY_SECRET |
HTTP body内にsecretらしき値が含まれていた |
I7_HTTP_AUTH |
HTTP上でAuthorizationヘッダが観測された |
I6_HTTP_PRIVACY_EXPOSURE |
プライバシーに関係しそうなHTTP通信が観測された |
I8_UNREGISTERED_DEVICE_ACTIVE |
未登録端末として通信が観測された |
実際に検知された I7_HTTP_PLAINTEXT のイベントは、たとえば以下のような形式で出力されます。
{
"rule_id": "I7_HTTP_PLAINTEXT",
"category": "I7",
"severity": "WARNING",
"observed_fact": "Plaintext HTTP request was observed.",
"inference": "HTTP metadata and contents may be exposed in transit on untrusted networks.",
"limitation": "Passive monitoring does not confirm whether sensitive values were present in this specific request.",
"recommendation": "Enable HTTPS if supported and review device or application settings that still permit plaintext HTTP."
}
通信フローを確認する
flows.jsonl では、pcap内の通信をフロー単位で確認できます。今回観測された主な通信の種類は以下のとおりです。
| 種類 | 観測された内容 |
|---|---|
| DNS |
tange365.com 系ドメインへの名前解決 |
| HTTP | 80番ポートへの平文通信 |
| TLS | 443番ポートへの暗号化通信 |
| UDP | 9001番ポートへのUDP通信 |
DNSクエリを見ると、以下のようなサブドメインが複数確認できました。
ep.tange365.com
device-ea01.tange365.com
reg-ea01.tange365.com
p2p1-ea-01.tange365.com
sg-devi-pvt-02.tange365.com
p2p1- や reg- といったサブドメイン名から、カメラが登録・P2P中継・エンドポイント接続など、複数の役割を持つクラウド基盤と連携している様子が読み取れます。
端末ごとの情報を確認する
device_inventory.json では、観測された端末ごとの通信情報やリスクサマリを確認できます。今回は、カメラのIPアドレス 192.168.2.4 について、使用プロトコル・通信先・関連するOWASPカテゴリ・検出イベント数・推定デバイス情報などが出力されました。
Web UIで解析結果を確認する
Quarantでは、JSONL/JSON形式の出力に加えて、ブラウザで解析結果を確認できるObservation Report UIも用意しています。
UIでは、検出イベントの概要、端末ごとの通信先、端末詳細、イベント一覧などを確認できます。
この結果から分かったこと・分からなかったこと
分かったこと
カメラが外部サーバーへ平文のHTTP通信を行っていることが確認できました。リクエストのURL・Hostヘッダ・Authorizationヘッダ・bodyの一部が、ネットワーク上でそのまま読める状態になっていました。HTTP bodyの中には secret というキー名を含む値もあり、認証情報や識別子に関わるデータが暗号化されずに送信されていた可能性があります。
また、TLS通信・UDP 9001番ポートへの通信・tange365.com 系ドメインへのDNS問い合わせも観測され、カメラが外部のクラウドサービスやP2P通信基盤と連携していることが推測できます。
まだ分からないこと
Authorization ヘッダや secret らしき値が「有効な認証情報なのか」「一時トークンなのか」「単なる端末識別子なのか」は、この段階では判断できません。UDP 9001番ポートのプロトコル仕様、ファームウェア内部の実装、クラウド側の認証・認可の仕組みについても、通信観測だけでは見えてきませんでした。
今後やりたいこと
Quarantを実際に動かしてみて、ネットワーク層から見えることには明確な限界があるとわかりました。通信上に手がかりは現れても、それが何を意味するのかはファームウェアの内部実装やプロトコルスタックを理解しないと判断できない場面が多くありました。
次はその「見えなかった部分」を確かめたいです。binwalk でファームウェアを展開して内部のURL・APIパス・証明書・設定ファイルを抽出し、実際の通信と照合することを考えています。通信として現れた挙動と機器内部の実装を対応させて理解できるようになりたいです。
ネットワーク観測を入口に、IoT機器の動作をより深いレイヤーから理解していくのが今後の目標です。
まとめ
ネットワーク通信の観測だけでも、リスクの手がかりはある程度拾えることがわかりました。ただ、見えない部分も想像以上に多かったです。
「外から観測できること」と「内部を見ないとわからないこと」の境界が、今回少し具体的につかめた気がします。その境界の先を、次は掘り下げていきたいです。
参考資料
本記事およびQuarantの設計・実装にあたり、以下の資料を参考にさせていただきました。
-
OWASP Internet of Things Project
https://owasp.org/www-project-internet-of-things/ -
LAC WATCH「OWASP IoT Top 10 2018が公開されました」
https://www.lac.co.jp/lacwatch/people/20190129_001755.html -
gopacket
https://github.com/google/gopacket -
gopacket package documentation
https://pkg.go.dev/github.com/google/gopacket -
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
https://datatracker.ietf.org/doc/html/rfc8446 -
JA3: A method for profiling SSL/TLS Clients
https://github.com/salesforce/ja3 -
containerlab Documentation
https://containerlab.dev/ -
OpenWrt Wiki: How to capture, filter and inspect packets using tcpdump or Wireshark
https://openwrt.org/docs/guide-user/firewall/misc/tcpdump_wireshark