Blog

  • Raspberry PiとESP32でMQTT設定ミスを発見

    Raspberry PiとESP32でMQTT設定ミスを発見

    今回やること

    今回のLessonでは、Raspberry Pi上にMQTTブローカー(Mosquitto)を構築し、ESP32などのクライアントを使用してMQTT通信の設定ミスやセキュリティ問題を検出・修正する方法を学びます。仮想環境でも一定の理解が可能ですが、実機でパケットキャプチャやTLS設定を体験することを推奨します。作業は必ず自分が管理するネットワーク内で、安全ルールを守って実施してください。

    実施環境の概要:

    • 実機ラボ:Raspberry Pi(Mosquittoブローカー)、ESP32開発ボード、監査PC(tcpdump/Wireshark使用可)
    • 仮想ラボ:コマンド入力と通信ログ確認のみ可能
    • 安全範囲:他者ネットワークに影響を与えず、テスト用ダミーデータを用いること

    先に知っておく専門用語

    本Lessonで扱う重要な専門用語を説明します。

    • MQTT:IoT機器間で使われる軽量メッセージ通信プロトコル。
    • Broker(ブローカー):メッセージ伝達経路の中心、ここではMosquittoというソフト。
    • ACL(アクセス制御リスト):ユーザごとのトピックアクセス権限を制限する設定。
    • TLS(Transport Layer Security):通信の暗号化と認証を行う安全技術。
    • tcpdump / Wireshark:ネットワーク通信パケットを捕まえて解析するソフトウェア。

    仕組みを理解する

    MQTT通信は次の仕組みで成り立っています。IoT端末はすべてブローカーを介してメッセージを送受信します。初期状態のMosquittoは認証無しで誰でも接続・購読でき、通信は暗号化されません。これにより以下のリスクが生じます。

    • allow_anonymous設定がtrueの場合、ネットワーク内の誰でも接続・発行可能。
    • ACL未設定だと全トピックが自由に見え、操作できる状態になる。
    • TLSが未設定だと通信内容が平文で通信経路上に漏洩する可能性がある。

    これらのリスクは次の設定変更で軽減可能です。

    1. allow_anonymousをfalseに設定し、匿名接続を禁止
    2. ユーザ認証とACLでトピックアクセスを最小限に制限
    3. TLS証明書を導入して通信の暗号化を実施

    下図(図1)は、Raspberry Pi上のMosquittoブローカーとESP32クライアント構成および設定項目の関係を示しています。

    MQTT通信構成と設定要素の関係:ブローカー設定で匿名接続禁止、ACL設定、TLS暗号化を行い安全性を確保する
    MQTT通信構成と設定要素の関係

    Interactive Lab

    記事の内容をもとにした仮想教材です。操作し、表示された結果を確認してください。

    以下はラボで順番に実施する操作の説明です。実機環境と仮想環境で少し異なります。

    1. Mosquittoブローカーのインストールと起動
      Raspberry PiにMosquittoをインストールし、サービスを自動起動設定します。
      成功条件:ポート1883でブローカーが起動し、待機状態になる。
    2. 匿名接続による接続・購読テスト
      ESP32やコマンドラインツールでパスワードなしに接続し、メッセージ受信を試みます。
      成功条件:接続でき、トピックが取得できること(実機ではセキュリティ上望ましくない動作)。
    3. 通信パケットのキャプチャ
      監査用PCやRaspberry Piでtcpdumpを起動し、ポート1883のMQTT通信をファイルに保存。Wiresharkで解析します。
      成功条件:パケット内のMQTTメッセージが平文で読み取れること。
    4. ユーザ認証・ACLの設定追加
      mosquitto_passwdでパスワードファイルを作成し、設定ファイルに認証とACL制御を追加します。
      成功条件:匿名接続が拒否され、許可したユーザのみ接続やトピック操作が可能になること。
    5. TLS通信設定
      opensslで自己署名証明書を作成し、Mosquitto設定でTLSポート(8883)を開設。クライアントもCA証明書を使って接続テストします。
      成功条件:TLS接続が成功し、tcpdumpの通信は暗号化されたパケットになっていること。

    仮想環境では、画面表示に沿ってコマンド入力と設定変更を行い、通信ログの反応を確認してください。

    結果を確認する

    ラボで得られる結果の見方と注意点です。

    • tcpdump・Wireshark解析結果
      非TLS環境では通信ペイロードが平文で解析表示されるため、重要情報やメッセージ内容が漏洩していることがわかります。
    • ACL設定の確認
      ACLにより特定ユーザだけが必要最小限のトピック操作を行えるかを検証します。ワイルドカードの誤用などで過剰権限がないか注意が必要です。
    • TLS通信の確認
      TLS設定済みの通信はWiresharkでは暗号化され、内容が読めなくなることを確認します。

    下図(図2)では、パケットキャプチャの様子とACLおよびTLS設定による通信状態の違いをビジュアルに表現しています。

    通信パケットの解析とセキュリティ設定効果:設定により通信の安全性とアクセス制御が向上し、盗聴・不正操作を防止できる
    通信パケットの解析とセキュリティ設定効果

    まとめ

    1. MQTTブローカーは初期状態では匿名接続や平文通信によりセキュリティリスクが高い。
    2. ユーザ認証設定とACLで権限最小化し、不正アクセスを防止できる。
    3. TLS導入により通信内容の盗聴を防ぎ、安全なIoT通信環境を構築可能。
    4. tcpdumpやWiresharkで実際の通信を監査し、問題発見や設定効果を確認できる。
    5. 安全な環境・自己管理下での実験を徹底し、他者や公共ネットワークへの影響を避ける。

    次に習得すべきは、MQTT応用例やクラウド連携、ESP32でのTLS接続実装や高度なACL管理などです。

    参考資料・元記事のリンク

    今回使った機材

    • Raspberry Pi 3 または 4 シリーズ: Mosquittoブローカーの安定稼働とtcpdump実行に適した性能を持つ。
    • Espressif ESP32 開発ボード(DevKitCなど): Wi-Fi通信テストやシリアルデバッグに便利な開発用ハードウェア。
    • 監査用PC: tcpdumpやWiresharkでパケットをキャプチャ・解析するためのLinux推奨PC。Raspberry Piと同じネットワークに接続する。
    • openssl(ソフトウェア): TLS証明書作成に使用。OS標準やパッケージマネージャ経由で導入可能。

    実機での検証を推奨しますが、仮想環境での演習にも対応しています。

    Raspberry Pi 4 Model B 4GB

    ローカルMQTTブローカー(Mosquitto)やパケットキャプチャ、TLS生成を安定して実行でき、GPIO/USBでESP32やUSB‑Ethernetアダプタを接続できるためラボの核に最適。

    Espressif ESP32 DevKitC V4 (ESP‑WROOM‑32)

    実験用クライアントを短時間で作れる汎用開発ボード。Wi‑Fi接続の再現、シリアルログの確認、簡易ファームアップが容易で検証に便利。

    TP‑Link Kasa HS100 スマートプラグ

    市販スマートプラグの代表例としてローカル/クラウド接続の違いやトピック命名ルールの問題を再現しやすい実機サンプルになるため。

    本記事にはアフィリエイト広告を含みます。