VMRC11.Xの仕様変更にご注意を

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

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

■発端

仮想基盤の管理者は通常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

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

以上です。

VMware Toolsの置き場変更

ずいぶんとマニアックな内容になりますが、VMware Toolsの置き場変更についてです。

目的

ESXホストのパッチ適用時期の差で、ESXホストの腹の中のToolsバージョンに違いが出るのを避け、vMotionで移動した前と後でVMで使っているToolsのStatusがCurrent/Old/OutOfDate等の判定がズレるのを避けるのが目的です。

ESXの詳細パラメータ変更

ESXホストの詳細パラメータ(UserVars.ProductLockerLocation)の変更をすると、デフォルトのESXホストの腹の中ではなく、共有ストレージ(データストア)上にVMware Toolsを置くことができます。

ESXホストの再起動は必要か?

UserVars.ProductLockerLocationの変更の反映のためにESXの再起動が必要とされていますが、実はESXホスト上のシンボリックリンク張り替えをすることで、ESXホストの再起動をしないでも済ませることがわかりました。ESXホストは起動時、UserVars.ProductLockerLocationの値を参照先として毎回シンボリックリンクを作り直してるようです。

# ls -l | grep productLocker
lrwxrwxrwx 1 root root 22 Apr 17 12:00 productLocker -> /locker/packages/6.0.0 
#
# rm /productLocker 
#
# ln -s /vmfs/volumes/datastorename/locker/packages /productLocker 
lrwxrwxrwx 1 root root 42 Apr 17 22:41 productLocker -> /vmfs/volumes/datastorename/locker/packages 

まとめ

今回は、ストレージ装置のリプレースでVMware Toolsの置き場を変えたかったのですが、なんとかESXの全台のリブートする作業は避けたかったので、この方法が見つかってよかったです(台数が結構あったので)。

詳細は、こちらのURLのKBに記載があります。 https://kb.vmware.com/s/article/1037405?lang=ja

以上です。

PowerNSXインストール&使用例

はじめに

本記事は、vExperts Advent Calendar 2019 の 12月4日 分の投稿になります。

vExperts Advent Calendarには今回初参戦のスズケンと申します。よろしくお願いいたします。

PowerNSXとは

端的に言えば、NSX-V用のコマンドレット群です。

NSX-TはPowerCLIに標準装備なのですが、NSX-Vはそうではありません。

そこでPowerNSXを入れることで、補完します。

弊社では、NSXのログ等の調査で、セキュリティグループ名とオブジェクトIDの対応付けを知りたくて入れてみました。

PowerNSXのインストール

1) https://github.com/vmware/powernsxにアクセス

f:id:ken1suzu:20191201123053j:plain

弊社の場合、プロキシの設定が厳しくてオンラインでのインストールはできなかったため、オフラインでのインストールを試みました。

弊社と同じようにプロキシのアクセス不許可に引っかかった場合は、下記のやり方が参考になるかと思います。

2) ZIPファイルをダウンロード

f:id:ken1suzu:20191201123114j:plain

3) ZIPファイルを解凍

f:id:ken1suzu:20191201123131j:plain

4) モジュールの手動インストール

PowerCLI C:\> Import-Module C:\Users\*********\Desktop\powernsx-master\module\platform\desktop\PowerNSX\PowerNSX.psd1

5) vCenterと接続

PowerCLI C:\> Connect-VIServer XXX.XXX.XXX.XXX

Name                           Port  User
----                           ----  ----
XXX.XXX.XXX.XXX                443   USERNAME

※XXX.XXX.XXX.XXX:vCenterのIPアドレス

6) NSX Managerと接続

PowerCLI C:\> Connect-NsxServer -NsxServer YYY.YYY.YYY.YYY -Username admin -Password ********
Using existing PowerCLI connection to XXX.XXX.XXX.XXX


Version             : 6.3.4
BuildNumber         : 7087695
Credential          : System.Management.Automation.PSCredential
Server              : YYY.YYY.YYY.YYY
Port                : 443
Protocol            : https
UriPrefix           :
ValidateCertificate : False
VIConnection        : XXX.XXX.XXX.XXX
DebugLogging        : False
DebugLogfile        : C:\Users\*********\AppData\Local\Temp\PowerNSXLog-admin@YYY.YYY.YYY.YYY-2019_MM_DD_hh_mm_ss.log

※YYY.YYY.YYY.YYY:NSX ManagerのIPアドレス

PowerCLIをちょっと使ってみる

セキュリティグループの検索をやってみる

PowerCLI C:\> Get-NsxSecurityGroup | select name, objectid | where { $_.name -match "552c9386-3adb-4bf6-99f1-5cbb7f606aec"}

name                                              objectId
----                                              --------
000000001801_552c9386-3adb-4bf6-99f1-5cbb7f606aec securitygroup-2662

補足情報

詳細は下記URLをご参照ください。

https://powernsx.github.io/get-started

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-automating-vsphere-with-powernsx.pdf

おわりに

以上、PowerNSXインストールと使用例でした。 明日は、Kan Chiyodaさんの記事です。お楽しみに!

ブログ再開

2009年くらいにはてなダイアリーを半年くらいやってたけど、飽きっぽくてすぐやめてしまってましたが、この3月にVMwareのvExpert 2019になることができたので、私なりに知りえたことを公開していこうということで始めます。よろしくお願いいたします。

f:id:ken1suzu:20190421205946p:plain