VMRC11.Xの仕様変更にご注意を - A certain IT engineer's tweet

スズケンです。久々の投稿です。

今回は、仕事でハマったネタを書いてみたいと思います。

■発端

仮想基盤の管理者は通常WebClientを使っていますが、仮想マシンの利用者向けのインターフェイスとしては多機能すぎます。権限を仮想マシンに限定したとしても、仮想マシンの利用者に使わせるには見えてほしくない情報とかも見えてしまいます（タスクとかイベントとか）。

f:id:ken1suzu:20200609214207j:plain

そこで、一部の仮想マシン利用者向けにコンソール機能を提供するVMRCというプログラムを利用しています。

f:id:ken1suzu:20200609214219j:plain

VMRCにより、仮想マシンに対するコンソール接続、電源操作、CDマウント機能に限定して、利用者に提供をしております。

今回は、そのVMRCのセキュリティ脆弱性対応をするところから話が始まります。

■対応すべきセキュリティ脆弱性

昨今、セキュリティ脆弱性対応をやらないことで万が一問題が出てしまうと、会社の信頼失墜につながるため、セキュリティ脆弱性が出る都度、弊社で影響があるかどうか？対応が必要がどうかについて早急に検討をし、対応が必要となったら、なる早で対応が求められております。

今回対応すべきセキュリティ脆弱性は、VMSA-2020-0004というものになります。下記、2020/3/12にVMware社から発行されたものになります。

www.vmware.com

3c. VMware Horizon Client, VMRC and Workstation privilege escalation vulnerability (CVE-2019-5543)

が対応すべきと判断した部分となります。これにより、VMRCというコンソール接続のためのプログラムを11.0以降にしないといけないことが分かりました。仮想マシン利用者が使っているVMRCから権限昇格されるリスクがあるため、対応することにしました。

■あれ？おかしいぞ？

検証を始めると、どうもVMRCを11.0にすると、仮想マシンへのコンソール接続が出来なくなっていることが分かりました。いろいろ調査や試行錯誤をしていると、下記情報にたどり着きました。

kb.vmware.com

あれ？使用するポートが、902/tcpから443/tcpに変わったのか！ということが分かりました。え、そんな仕様変更、シレっとされるのは辛いぞ！と思いました。

VMRC11.0のリリースノートを見てみても、使用するポートが変更になるなんて、一言も書いてないし。。。

docs.vmware.com

11.0.1（Mac版）や11.1.0のリリースノートには、このように書いてありました。

VMware Remote Console 11.0.1 では、ESXi ホストのポート 443 への直接アクセスが必要になります。詳細については、VMware ナレッジベースの記事 KB76672 を参照してください。

ここで、既に見つけていたKBの情報を照合できました。

■仕様変更に従ってやってみる

早速ネットワーク機器で、ESXホストへの443/tcpの穴あけを実施し、無事コンソール接続ができることを確認しました。

4月下旬に、なんとかセキュリティ脆弱性対応が完了しました。 902/tcpは、セキュリティ強化の見地からネットワーク機器で閉塞しました（今回のセキュリティ脆弱性に902/tcpが関連しているのでは？という推測もあり）。

■とある利用者からの申告

5月下旬になって、ある利用者の仮想マシンが、ESXホストのサーバHW故障でvSphereHAで再起動した際に破損したようで、NWにつながらなくなったとのことでした。どうやら、ゲストOS的に壊れてしまったようです。仮想マシンの仮想HWとしては問題ない状態でした。

この仮想マシンを復旧するためには、利用者が取ったバックアップをリストアする必要があります。ここで、コンソール機能でバックアップソフトのBootCDからの起動を行い、システムリストアするという流れになりますが、なんとVMRCでCDマウントできない状況になっておりました。

すぐに、関係者が集まり（このご時世なのでリモートで）、原因を議論している中、「まさか、CDマウントだけ従来の902/tcpを使ってたりしないよねぇ？」という推測に至りました。

試しに、評価環境の仮想マシンに対してコンソール接続をし、そこでCDマウントを試みてみた状態で、DOSプロンプトでnetstatを実行すると、

> netstat -ant | findstr ESXホストのIP
  TCP         PCのIP:52949   ESXホストのIP:443      ESTABLISHED     ????
  TCP         PCのIP:53077   ESXホストのIP:902      SYN_SENT        ????

ってことで、902/tcpに通信しに行っているじゃないですか！

急いでネットワーク機器で902/tcpの穴あけをしたら、VMRCでCDマウントできるようになりました。

穴あけ後のnetstatはこんな感じでした。

> netstat -ant | findstr ESXホストのIP
  TCP         PCのIP:59073   ESXホストのIP:443      ESTABLISHED     ????
  TCP         PCのIP:59191   ESXホストのIP:902      ESTABLISHED     ????   ★

ちゃんと通信できていることを確認できました。利用者が仮想マシンのリカバリで急いでいるときに足を引っ張ってしまって、大変申し訳なかったと思っております。

■反省

今回、KBの情報を見て、使用するポートが902/tcp → 443/tcp に変更になって、旧ポートは使わなくなると思い込んでしまって、CDマウントの動作確認を端折ってしまったことが敗因でした。まさか一部機能だけ旧ポートを使うという罠があるとは思わなかったです（言い訳）。

コンソール機能は、仮想マシンが壊れたりした際に使うことが多い機能で、いざってときに動かないのはまずいため、CDマウント機能の動作確認がとても大事だと痛感しました。

今回のような使用ポートが変わるような大きめの仕様変更がある場合は、使用している機能については漏れなくテストをするなどの対応が必要であるということに尽きると思います。大変お恥ずかしい例で恐縮でしたが、テストが大事だという1つの例として、皆様への注意喚起に役に立てば幸いです。

■後日談

VMware社に再度確認をしたところ、VMRC11.0以降が通信で使うポートが、接続先ESXホストのバージョンによって異なるとのことでした。使用されるvSphereバージョン、VMRCバージョンでも動作が異なるので注意が必要です。

VMRC11.0の場合

項番	通信	vSphere6.X	vSphere7.0
①	vCenter, ESXiとの管理用通信	443	443
②	仮想マシンを操作するMKS通信	443	443
③	isoイメージなどのリモートデバイス用のNFC通信	902	902

VMRC11.1の場合

項番	通信	vSphere6.X	vSphere7.0
①	vCenter, ESXiとの管理用通信	443	443
②	仮想マシンを操作するMKS通信	443	443
③	isoイメージなどのリモートデバイス用のNFC通信	902	443

※ 本記事で記載されている会社名、製品名は、各社の登録商標または商標です。

■お知らせ

VMwareユーザ会（VMUG）に興味のある方は、

https://www.vmug.com/membership/membership-benefits

から入会していただけると幸いです。部会でお会いできるのを楽しみにしております。

以上です。