VMware vCenter Serverの複数の脆弱性（CVE-2021-21985、CVE-2021-21986）について

今回は、

「VMware vCenter Serverの複数の脆弱性（CVE-2021-21985、CVE-2021-21986）について」

というタイトルでお送りします。

すでに公開されてから時間が経っておりますが、

・vCenterのプラグインにアクセスしてリモートコードが実行できる脆弱性

が公開されています。

脆弱性の深刻度としてCVSSv3（Common Vulnerability Scoring System v3.0）スコアは順番に9.8で、クリティカルに設定されています。

VMware社からはすでにFixedバージョンが提供されてますので、

そちらにアップデートが推奨されます。

が、基本的にvCenterを外部に公開している環境なんて、OnPremis環境ではほとんどないかな・・・？

とは思うものの、『直近で「色々」あった』ので潰せる問題は潰しておくのが良い。。。ですね・・・。

「外側の障壁を抜けられて、踏み台を掌握されたのが一番の問題」だったりして、、、
「普段攻撃を受けない、その後ろにある部分の脆弱性を突かれ」ても、
槍玉に挙げられるのは、被害の大きさに比例する…可能性が高いかな・・・と、
思う次第です。。

そんなわけで、情報はこちら 

VMware vCenter Serverの複数の脆弱性（CVE-2021-21985、CVE-2021-21986）に関する注意喚起

www.jpcert.or.jp

VMSA-2021-0010: What You Need to Know - VMware vSphere Blog

blogs.vmware.com

一番の対策は、アップデートです。

回避策も公開されていますが、vSAN環境だと弊害の方が大きい気がします。

（今回の対応はvSANプラグインを無効化することで、vSANのステータスが拾えなくなる。。。はず）

Pluginを無効化

https://kb.vmware.com/s/article/83829

ご参考まで。

【環境管理（支援）ツール】Runecastの使い方

今回は、

「【環境管理（支援）ツール】Runecastの使い方」

というタイトルでお送りします。

なんというか、、、

何とも弁解・弁明のしようがないのですが、

エンドユーザにご購入いただいていたのに、

うまく活用できていませんでした。。（2020年9月時点）

↑で書かせて頂いた、、、エンドユーザ様申し訳ありません。

ですので、、、！

その活用方法、事例をちょっとだけ書き残しておきます。

そもそもRunecastとは何か、という話から念のため書いておきますと、

（詳しくはメーカーやプロバイダー、システムインテグレーターのサイトをご覧ください。）

環境において、使用しているバージョンのパッチ情報や設定情報について推奨される情報、、、このパッチ出てますよとか、この仮想スイッチの設定はこうすることが推奨されますよ・・・とか、そういったものを教えてくれるツールです。

そんなわけで、件の使い方という話になりますが、

構築完了後、お客様に引き渡す際の第三者的視点からの品質担保！

そんな形で使えます。

セキュリティ的な部分で推奨される設定方法など、

メーカが公表している設定からずれている部分がピックアップされたりするので、

Runecastでスキャンする前はこうなってました⇒今こうなってます

ということを提示しやすいです。

具体的には

Runecastで1回目スキャン、出てきた結果をPDF化して保存、確認して対策実施。

Runecastで2回目スキャン、出てきた結果をPDF化して保存、1回目で出てきていた項目が消えていることを確認。

環境によっては、運用上消しきれない項目だったりがあるとは思いますが、

ユーザに合意を取るのに一覧化されて出てくるのは結構便利だと思う次第です。

上記はスポットでの使い方として書きましたが、、

定期的に運用していくというのが一番良い話なのは、、、もちろんです（笑

月1回とかでスキャン掛けて、項目が増えてないことを定期的に確認。

増えているなら定期メンテナンスで対応を行っていく・・という感じですね。

ご参考まで。

vSAN環境でのDisk障害対応について

今回は、

「vSAN環境でのDisk障害対応について」

というタイトルでお送りします。

vSANを利用している環境でローカルのストレージに障害が起こった場合、

従来の様にメーカと調整して、フィールドエンジニア（CE）の方に現地に来てもらってディスクを交換してもらうだけでは復旧しません。

そういう意味では、vSAN環境では障害時の復旧作業（運用作業）の難易度は高くなってしまっていると言えますかね。

某ハードウェアメーカの派遣したフィールドエンジニアの言うことを、確認せずに信じてしまったせいで、復旧するのにすごく、、、大変だった＆時間が掛かった。。。というのもありますが・・・笑

そんなわけで、今回は公開されている情報でもありますが、

自分が今後対応しやすくするための備忘録的なことも含めて...な投稿です。

まず、、、どんなことを言われても、『交換対象のディスクをホストするvSANホスト』は、オフラインにしましょう。

（ここまで、ディスク、、、と書いてましたが、SSDだったらディスクじゃなくドライブですね。。笑）

状況によっては、ハードウェアとしてはオンラインのまま交換出来て、
IPMI系のツールだったりでは認識できたりするのですが、、、
ハイパーバイザーで交換したドライブを認識しないことが多々あります。

そうしたら、どうなるか、、、

一度ハイパーバイザーを再起動しなければいけないわけです。

で、、、あれば、最初から「再起動必要です。」というのと、vSANでの話なので
「クラスタの中の他のハイパーバイザーにゲストOSは逃がしますから。」と、
言って、ユーザとの調整を図るべきかと思いますね。

（↑の話をするには、こういう時に使えなくて何のために
　「冗長性を持った構成で可用性を担保しているのか、、？」
　という話をユーザにも啓蒙活動しておいて、理解しておいてもらう必要はあるとは
　思いますが、、、。）

まぁ、ハードウェア故障の予兆検知だったりした場合には、
ドライブを手動でオフラインにしないといけないですから、、
安全性を考えたらこの意味でもハイパーバイザー的にもvSANとしての意味でも
ホストはメンテナンスモードにしてオフライン化しておくべきですね。。

そんなこんなで、グダグダ書かせて頂き、くどいですが結論は、

vSAN環境のハードウェア障害は当然のことながら、
サービス停止は無く（ゲストOSの停止は無く）行えます。

ユーザ様へは、最初からホストだけは停止します、というのは伝えておくべきでしょうね。

ちなみに、実際に交換時にやることは、

○ Capacity Tierの場合

• 交換前に故障したドライブをvSAN管理画面から削除する
• 交換する
• （ホストの再起動も含めて）交換したドライブを認識したら
  Diskグループに組み込む

○ Cache Tierの場合

• 交換前に故障したドライブが担当（？）していたディスクグループを削除する
• 交換する
• （ホストの再起動も含めて）交換したドライブを認識したらDiskグループを作り直して、CacheとCapacityを登録する

です。

ちなみに、多分、この作業は、、1時間で物理的な交換までやるには厳しいと思いますので、

VSAN.ClomRepairDelayの値を事前に変えておくことをお勧めします。

KBはこちらですね。

kb.vmware.com

ご参考まで。

バックアップ製品＋バックアップ専用ストレージ

今回は、

「バックアップ製品＋バックアップ専用ストレージ」

というタイトルでお送りします。

上記のタイトルで書き始めましたが、

具体的に言ってしまって...最近はvSphereの仮想環境バックアップで鉄板な感じの...

『Veeam社のVeeam Backup ＆ Replication と、

DELL EMC社のData Domain』の話です。

Veeam Backup ＆ Replication が、比較的、、vSphere仮想環境にメリットが
あると思っているし、

DataDomainも動き始めれば、、比較的問題もないし、、、

ということで、
さらにVeeamがどちらかというと仮想マシンのバックアップに良い製品だと
思っているので、

仮想環境のバックアップについては特に良い組み合わせだと思ってます。

と、メーカの太鼓持ちしても仕方ないので、、、
この組み合わせで色々と、、、苦労した件・・・してる件・・・＋α（メーカと揉めた件・・・笑）を書いておきます。

まず！、この組み合わせ、

普通に使えば問題は起こりづらいです。（個人的私見）

が、

問題点その1：

（早速＋αから書いてます）：
たしかに、

使い始められれば...、問題は起こりづらいです...。

と書いたのは、DataDomainが認定ベンダーにしか資料を提供しないという旧E社（D社ではなく）の方針？に基づいて行動されるので...、ファームウェアアップデート時に失敗したりすると、メーカからはサポート情報どころか…マニュアル等の一般的情報も得られません。

これは、納入された直後にファームウェアのバージョン変更に失敗した経験があるのですが…エンドユーザとして聞いてみても何の情報もくれませんでした...（ほんとにどういう風にメーカとしてサポートするつもりなのか・・・？？？）。

最終的に中間販社が認定ベンダーだったために、ドキュメント内の情報を教えてくれて復旧が叶い、納期までに無事納入でき…事なきを得たという状況でした。

（メーカには…『2度と売らないからな！』と、捨て台詞を吐きましたけどね（笑...）

問題点1は私怨が多々に含まれましたが…、ちゃんと製品的な話をここから…

問題点その２：

両製品ともに、容量の削減機能を持っているためにどこでどっちの機能が利いているのかよく判らなくなる。。。

問題点その３：

両製品のフィージビリティの問題。

それぞれでバージョンが変わるときに足並みそろえて対応してくれない。。

2018年くらいの時でした...が、自分の場合には、DataDomain側が予想外に早くDDOSの新バージョンを公開した際に（4か月間）待ちに待っていたバグが修正されたというのに、Veeamが対応してくれず...、
しばらく放置せざるを得なかったという経験があります。
（他の製品も一緒ですね、これは。）

そんなわけで、問題点、、というか、
いつも通りハマった記録になってしまいました（笑

ご参考まで。

VMware製品の脆弱性（VMSA-2021-0002）について

今回は、

「VMware製品の脆弱性（VMSA-2021-0002）について」

というタイトルでお送りします。

すでに公開されてから数時間経っておりますが、

・vCenterのプラグインにアクセスしてリモートコードが実行できる脆弱性、
・ESXiのOpenSLPサービスでヒープオーバーフローからリモートコードが実行できる脆弱性

・vCenterにSSRF（Server Side Request Forgery）を仕掛けることができる脆弱性
この3点が公開されています。

脆弱性の深刻度としてCVSSv3（Common Vulnerability Scoring System v3.0）スコアは順番に9.8、8.8、5.3で、1個目はクリティカルに設定されています。

VMware社からはすでにFixedバージョンが提供されてますので、

そちらにアップデートが必要です。

ソースはこちら

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

www.vmware.com

回避策も公開されていますが、

vCenterはvROpsのPluginを無効化

https://kb.vmware.com/s/article/82374

ESXiはCIMを無効化

https://kb.vmware.com/s/article/76372

弊害としては、Opsで情報が表示できなくなる。。

まぁ、当たり前ですね。

うーん、Ops使ってなければ、まずは回避策を実装しましょう。

ご参考まで。

手順なども後ほど整理して追記するかもしれません。

VMware Cloud on AWS と AWS EC2の接続について

今回は、

「VMware Cloud on AWS と AWS EC2の接続について」

というタイトルでお送りします。

今回も実際の案件で改めて感じた、

「あ、こういうことなんだ」ということに気が付いたことを書いておきます。

今回のタイトルの話、、、クラウド間の接続について書かせて頂きますが、、

VMC on AWS（以下VMC）とEC2をVPCで接続した場合、、、

VPC以降、、、1HOPしか超えられません。。。

これは、、、
具体的に言うとどういうことかというと、EC2から通信する際、VPCを超えて1HOP目に当たるVMCのセグメントには通信ができるけれども、そこから更に（VMCへのDirect Connectなど・・・）ルータ（L3装置）を超えては通信ができないんです。。。

要するに、

VMCとEC2は接続・・・、通信できるけれども、、、

VMCに接続しているお客さんの既存環境からは、この経路を使って直接接続できないのです。。。

残念でした。。。。

終了。

なんて、いうわけにもいかないので、

どうしたら良いか。

それを書かなければ、存在意義？存在価値？が無いので（笑、

勿論書きます。

オンプレから、AWS側に接続する必要があるならば、

AWSに対して、別途直接接続をやるしかなさそうな感じです。

追加費用を掛けずにどうにかする・・・、というのは無理っぽい。

というのは、非常に残念なんですが、

クラウドサービスを使う以上、カスタマイズできない部分として仕方がない、、、のは、こういう所なのでしょう。。。

ということで、結論、

マルチクラウド・・・な時代になったとは言え、「サービス同士が直接つながれる」とか、「サービス間の接続をそのまま使える」とは限らない。

オンプレと、VMCと、EC2を相互で自由？に利用するのに必要なものは

・オンプレからVMCへの接続と、

・オンプレからEC2に接続するための接続

この二つが必要になりそうだ・・・。

ということです。

これは、ランニングコストに関わってくる話にもなりますので、

本当にサービスに必要（不可欠）なのか、、、もともとのサービスの通信経路も含めて本当・・・に整理できないのか？・・・を考えることも必要かなと思います。

ここまで、書かせて頂きましたが、

ご参考・ご検討いただく際の助力になれば幸いです。

ご興味があれば、ご相談・ご連絡ください。

VMware vExpert 2021

これまで、仮想化製品を扱っている中で、

気づいたことなどを書かせて頂いていましたが、

VMware様よりめでたくvExpert 2021に選んで頂きました。

今後も現場レベルの情報共有・提供もしていくので、

引き続き足を運んでもらえれば幸いです。

vExpert 2021