Chrome リモートデスクトップ は手軽に扱えて、ポート開けなども不要で便利ですが、次のようなリスクがあります。
gmail (Google) アカウント漏洩の可能性
gmail アカウントの認証情報が漏洩すれば、簡単に不正アクセスやなりすましが可能です
通信を盗聴される可能性
Chrome リモートデスクトップ はインターネット経由で接続するため、盗聴のリスクをゼロにすることはできません
・リモートデスクトップそのもののリスク
リモートデスクトップはその仕組み上、次のようなリスクがあります
不正アクセス・権限やIDの乗っ取り、なりすまし
盗聴・情報漏洩
情報改ざん
端末の紛失・盗難からの悪用
まず、gmail アカウントとパスワードが漏洩、かつ Chrome リモートデスクトップ の接続用パスコードが漏洩すれば乗っ取りが可能です。
ですが、そもそも gmail アカウント情報が漏洩すること自体が重大事態ですから危惧するほどではないのですが。。。
インターネット空間からのアクセスを除外して LAN 内からのみの接続に限定できればセキュリティ上はより強固になり、盗聴やリモートデスクトップそのもののリスクがなくなります。
端末の紛失や盗難からの悪用は気をつけて、としかいいようがありません。
Chrome リモートデスクトップ を LAN 内に限定するにはレジストリの、
HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\RemoteAccessHostFirewallTraversal
を 0 に設定する、とありますが、これは Chrome Enterprise 向けの設定で、通常版の Chrome では機能しません。
一方、Chrome リモートデスクトップが繋がらないのは次のいずれかが通信不可の場合といいます。
① アウトバウンド UDP トラフィック
② インバウンド UDP 応答
③ TCP ポート 443（HTTPS）のトラフィック
④ TCP と UDP のポート 3478（STUN）のトラフィック
これを逆手にとってトラフィックを制限できれば LAN 内からのみの接続に限定できそうです。
この中で ④ が一番やりやすいのですが、ポート 3478 をルーターで塞ぐと代替ポートに移ってしまうようで、LAN 内に限定化できません。
③ は HTTPS が使えなくなりますので論外です。
② は現在のルーターでの設定が難しい。
① の UDP 発信は、通常はほとんどしませんのでこれを制限することにしました。
ただし、家庭内の WLAN 接続が 53 (domain) /udp のブロックでつながりません。
ほかにも影響ありそうなので Well known port であるポート：1〜1023 を除外します。
よってルーターで、
LAN ⇨ WAN 方向の UDP：1024-65535 を DROP
設定します。
これによって Chrome リモートデスクトップ・ホストが UDP の出側 をグローバル空間に対して塞がれます。
そうすると NAT Traversal が機能しないのでグローバル空間のクライアント側から接続できなくなります。
実際にスマホで接続しようとすると、次のスクリーンショットのようにエラーになります。
ルーターでのドロップなので、LAN 内はドロップ対象外です。
なので、LAN 内でのみクライアント（ウチでは Mac mini M1）から接続できます。
インターネット空間からは VPN で自宅ネットワークに入れば接続できます。
スマホで VPN を使って家庭内 LAN に入り接続したのが次のスクリーンショットです。
【補足説明（推定を含む）】
さるサイトに以下の記述がありましたが、実際に確認してみたところ、いくつか動作が異なっていることが判明しています。
(1) サーバ側
Chromeリモートデスクトップサービスを担っているremoting_host.exeから、chromoting-host.talkgadget.google.comのport 5222にTCP接続されています（プロトコルはXMPPの模様）。また、実際のリモートデスクトップ接続後はランダム（だいたいは60000番台）なポート番号のUDPトラフィックをクライアントとの間で直接やりとりしますが、ここに書いてある設定によってポート番号の範囲を12400～12409に制限できるようです。
(2) クライアント側
ドキュメント読む限りはchrome.exeからchromoting-oauth.talkgadget.google.comのport 443とchromoting-client.talkgadget.google.comのport 5222にTCP接続するようです。ただ、私が試した範囲ではChrome.exeから5222への接続は確認できませんでした。代わりにport 5228へのそれらしい接続は見つかりました（バージョン47.0.2526.28の場合）。一度接続するとUDPトラフィックをサーバ側PCとの間で直接投げ合います（ポート番号はやはり基本ランダムで、設定により制限可能）。
なお実際にはGoogleのサーバは（現在のところ）3種とも全てwildcard-talkgadget.l.google.comへのaliasになっているようです。
まず、 port 5222 ですが、これを 5222-5228 の範囲でアウトバウンドをドロップ設定しても何も起こりませんから、その場合は代替ポートを使うのかも知れません。
また接続後はランダムなポート（だいたいは 60000 番台）、とあり、「ここに書いてある設定によってポート番号の範囲を12400～12409に制限できる」とありますが、60000 番台以降をブロックしても接続されてしまいますし、「ここに書いてある設定」で 12400〜12409 に制限されることはありません。
12400〜12409 をドロップが有効ならば一番いいのですが、いくらブロックしても LAN 外からは接続できてしまうのです。
ポート 32768〜65536 の範囲（実際はもう少し狭い範囲か？）でランダムにポートを使っているように思われますので、ポート 32768〜65535/udp のアウトバウンドをドロップすることがグローバル空間からの接続をできなくしてくれるようです。
試行錯誤の結果 40000 番台以降を使うようです。
ウチでは当初 1024〜65535/udp をドロップしていましたが、改めて 40001〜65535/udp のドロップに設定し直しました。
グローバル空間にあるスマホの Chrome リモートデスクトップアプリから接続を試みると、結果は
「パソコンにアクセスできません。このパソコンの管理者がローカルネットワーク外からの接続を許可しないよう設定しているか、パソコンが外部接続に対応していないネットワーク上にある可能性があります。」
というエラーになりますので、一応 LAN 内のみ接続を許可したことになっています。
ですが、LAN 内の Mac mini M1 でリモートデスクトップ接続中に、グローバル空間のスマホで接続を試みると Mac mini M1 の接続が切れます。
そのあとで上の接続エラーになります。
これは Google の Chrome リモートデスクトップサーバー（STUN を処理している）には「ホスト側は接続可能状態」が登録されていて、このサーバーにスマホ側から接続にくると元々の接続を切るのではないか、と推定しています。
通常版 Chrome リモートデスクトップ の場合は、同時に１接続しかできませんが、後から接続にきた別のクライアントが優先的に接続される仕様で、最初に接続中のクライアントは接続が切られてしまいます。
LAN 内でのみ接続可能にしていても同時１接続で、後からの接続要求が優先するのではないか、と推定しています。
なので、元々の接続が切れてしまうのは止むなしということでしょう。
しかし、ホスト側が通信用ポートを閉じているので、結果的に「接続できませんエラー」になるのではないでしょうか。
Enterprise 版の場合は、同時 n 接続可能なのでこのあたりの動作は異なるでしょう。
0 件のコメント:
コメントを投稿