MQTTとセキュリティ

ふらっと見ていたら、こんな記事を発見した。

刑務所のドア開放や電車の不正操作も? 無防備なMQTTのM2M接続

2分くらいで読める内容だからチェックしてみた方が良いと思われ。自分も端末向けにMQTT(TLS)を出していて、現時点で平文とTLS(暗号/認証)で利用されているアプリケーションの比率は…

MQTT(平文) 44.94K
MQTT(TLS) 1.69K

約26倍もの利用で平文の方が圧倒的に多い。これは、それぞれのライブラリを使っているアプリの数で、実際に端末に配布されている数はもっと多いだろうから、凄く多くの端末が平文で通信を行っているということになる。別に平文を使ってはいけない!!という訳じゃなく、このほぼIoT的なシステムでデファクト気味になっているMQTTを、IoT的な端末で安全に使う方法を少し書いておこう。

1) GWを使う構成
そもそもMQTTは産業向けのプロトコルで使われる想定だったようで、インターネットから閉ざされた閉空間またはセキュリティが担保されたルータやスイッチ配下の端末間ネットワークを構成するために利用される、という方法がメインだったろう。こういったネットワークの場合、内部に悪意のあるモノが無いという前提のもと、平文でやりとりされるのもアリ。
(このような方法に似たもので、Load BalancerでTLS(443)をインターネット側から終端して、バックエンドの通信は平文で行うことでTLSの負荷を軽くする、といった方法はよくある)

MQTT Broker上ではメッセージを終端して、外部との通信はセキュアに行うといったもの。
まぁ、この場合は平文でもOKかなと。ただ、内部に侵入された時も守りたい!!という時は暗号化/認証すればOK。まぁ侵入された時点でノックアウトされているようなもんだけど。

2) インターネット上のサーバに直接接続
これは端末が直接WiFiやルータと接続して、外部と通信を行うものになる。これは当然、暗号/認証をTLSのようなもので行ってセキュアに通信を行う必要がある。ルータ以下はセキュアに守られていても、インターネット上に平文の通信を流すというのは行ってはいけないですね。

3) せめて暗号化
これは、本文のメッセージを平文でインターネット上に流して使いたい…というワガママさんに、どうしても&しょうがなく…といったケースでは仕方なく(本当はダメ)。
この場合の問題点は、認証をどうするよ…ということだ。データを暗号化しても認証を行わないと、不正にデータを取られたり予想外の攻撃を受けたりする。よく証明書を利用すれば、”暗号化されてOK!!”というのを聞いたりするけど、証明書の利用はもちろん暗号化も一つだけど、”相手を認証する”という部分もある。”相手が誰か証明”するってことね。例えば、誰かと話そうと思っている時、その誰かは本当にその人ですか?という時に証明書を取り出して、”自分が本当にその人ですよ”と証明をする。丁度、パスポートや免許で自分の証明をするのと同じような感じ。
この部分的に暗号化を行うとデータ自体は守られそうだけど、接続する時にどうやって認証するのか?というリスクが発生する。MQTT BrokerとID/Passwordで認証すれば?と思うかもしれないけど、このときTLSを利用していないとID/Passwordが平文で流れて見事にヤバい、というか被害が悪化する。これは接続する時はIDだけを変えて、データを垂れ流す時だけだろうか…気合でPub/Subでアプリケーション間で認証するのは出来なくは無いけど。

■ 本当に暗号&認証って必要?
「暗号化とか認証とかめんどくせーし、やってられないし、いいよ平文で見れても気にしないし」という人も居ると思われ。鍵なんか使って暗号化しなくても大丈夫!!ネットを使う人が盗聴とか攻撃を一切しない幸せな世の中だと良いね!!、と自分自身思っているけど、理想と現実は違う。現実は攻撃・盗聴・搾取…etc何でもありで痕跡も消して…というカヲス状態だ。便利なネットだけど、光には影が出来る、というのに似ている。正しいことは、一方からの風景にしか過ぎない。

セキュリティとか必要ないし〜と思う人には、実際にリスクを目の前に見せたりもするんだけど、それで対応するかどうかは…そこ次第。リスクをよくよく理解した上で対応しない、という選択肢もアリ。問題を分かっているという事と、知らないことは大きな差があるからね。まぁ普通は流しているデータを見られてもOK!!という人はあまり居ないと思うのと、本当に理解していたら大抵は後回しでも対応するんだけどね。ま、別に他人事だしどーでもいいけど。

ということで、冒頭の記事が本当なのか、オープンになっているMQTTサーバに接続して、全トピックをSubscribeしてみることにしよう。これはハックでもクラックでも無い。MQTTとして普通にSubscribeしているだけ。これらは平文で流れているもので、ぼーっと見ていただけで何もしていないし、情報にはマスクをしている。というか全部マスクしているw

1) AWSの情報が流れている…
{“arn:XXX:XXX:XX-XXXX-1:xxxxxxx:XXXXXXXXX/XXXX/XXXXXXXXXXXXXX/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx”,….

2) WiFiに接続する証明書が流れている
{“XXXXX”:”XXXXXXXXXXXXXX”,”XXXX”:”XXXXXXXX”}
以下証明書のPEM

3) 某社のIDと入管記録
{“XXXXX” : “XXXXX” ,
“XXXXXX” : “XXX XXX XXX XXX ” ,
“XXXXXX_XXXX” : “XXXX-XX-XX XX:XX:XX” ,
“XXXXXX_XXXX” : “XXXX-XX-XX XX:XX:XX”}

4) 某デバイスや車の位置情報
{latitude”:xx.xxxxxxx,”longitude”:xxx.xxxxxxxxx”,….}

6) その他もろもろ(メアド、環境センサのデータ、 端末名、MAC、IP、PC(Mac/Win)、スマホのデータ、WiFiのデータ、ドアの開閉状態…etc)

あと、この辺の落とし穴として…MQTTサーバだと1883(平文)、8883(TLS)になっていて、8883の方に接続していて暗号化をしていても、1883(平文)の方にもサクットそのまま接続できて、8883側に流しているデータを1883側でSubscribeできる。つまり…オープンなMQTTサーバにヤバいデータは流すな!!ということに尽きるし、余計なポートは閉じれ!!といった感じ。
この皆さんの問題点はデータが見れる他に、トピック名も分かるから偽装のデータを投げたり、当該トピックに大量に流して溢れさせたり(大抵、この手の端末はスペックが低くて大量に投げると止まる)、外部から端末制御…といった、冒頭の記事で言っている内容と同じことが出来る。

こういう平分で全部見れちゃうぜー!!とか眺めていると、もう暗号化しなくてオール平文でも良いんじゃね?って気が、0.0001nmくらい感じてくる。感じるだけで、自分はやらないけどね。
結果…暗号&認証は必要でつ


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください