VxRailのSimShipがvSphereの緊急パッチにどれくらい追随できているのかを調べてみた

 

 

VxRailはVMware社とのシンクロリリースを掲げていることは広く認知されているかと思います。

本記事ではそのシンクロリリースのSLOがどれくらい達成されているのかを確認してみました。

 

VxRailとは？

VxRailはDell Technogologies社とVMware社が共同開発したHCIアプライアンスであり、vSANベースのHCIです。vSANを利用したHCIソリューションは、VxRailだけではなく、各サーバベンダーが提供するvSAN ReadyNodeや、他ベンダーが提供するHCIもあります。（FUJITSU社のPRIMEFLEXなど）

その中でもVxRailはアップグレード機能とサービスが特に充実しており、HCIのメリットである運用管理負荷軽減に大きく寄与できる製品といえます。

 

 

シンクロリリースとは？

VxRailはDell Technologies社とVMware社の共同開発を謳っており、随所に特別な連携が見られます。

シンクロリリースもそのうちの一つであり、VMware社が新しく出したESXiリリースに追随する形で短期間の間に同じリリースを含むVxRailを提供するためのリリースポリシーです。

VxRailシンクロリリースの詳細については以下のKBにて公開されております。

https://www.dell.com/support/kbdoc/000182153

 

 

シンクロリリースについては以下の記事もわかりやすいかと思います。

⑧VxRail のロードマップのキホン - Dell Community

 

 

ランサムウェアに狙われるESXi


昨今ではESXiがランサムウェアに狙われているということもあり、優秀なアップグレード機能によって脆弱性パッチを迅速に適用できるVxRailのメリットが活かしやすくなっていますが、Fixを含む最新のリリースに対応していなければ、自慢のアップグレード機能も意味を成しません。

 

先ほどのKBを確認すると、脆弱性関連の緊急パッチに対するリリースポリシーは14 calendar daysとなっていますので、期待値的には14日以内にリリースされていると考えられますが実際のところはどうなのでしょうか？

 

 

平均追随日数を実績から確認

実際にするにあたって以下の基準を利用しています。

①VMware Security Advisory(VMSA)にて報告のある脆弱性とFixed Versionが対象

VMSAに記載から確認できないものは対象外とします。

 

②緊急性やCVSSスコアが低いものは除外する

CVSSスコア(8.0以上)やVMware社の対応の迅速性やWorkAround有無などから総合的に判断しています。

CVSSスコアはCritical（9.0以上？）とした方が区切りが良いかと思いましたが、それだと対象がなくなってしまうので8.0以上を基準にしています。

 

③vSphere 7 のみを対象とする（ESXi および vCenter）

シンクロリリースが施行されたメジャーリリースであるvSphere7のみを対象とします。vSphere6.xでは途中からの情報しか取れず、また、VMSAで遡れる範囲の兼ね合いもあります。

シンクロリリースではESXiのみが対象とされていますが、今回の確認ではvCenterに対する重要な脆弱性もスコープに含みます。

 

④WorkAroundがないものを対象とする

脆弱性への対処はパッチ適用だけではなく、発表直後はWorkAroundの適用が主流な場合もあります。

WorkAroundがあれば必ずしもパッチ適用をする必要はないため、パッチ適用の緊急性の観点からWorkAroundがあるものは除外します。

 

上記4つの基準に照らし合わせて抽出したVMSA、VMware Fix Version、VxRail Fix Version、VxRailリリースに要した日数を表にしてみました

 

VMSA

VMware

Fix Version

VxRail
Fix Version

Release Delay

VMSA-2020-0026.1 (vmware.com)

ESXi70U1b-17168206

7.0.101

14

VMSA-2021-0010 (vmware.com)

vCenter 7.0 U2b (*1)

7.0.201

10

VMSA-2021-0020.1 (vmware.com)

vCenter 7.0 U2c

7.0.240

15

 

vCenter 7.0 U2d

7.0.241

6

VMSA-2022-0004 (vmware.com)

ESXi70U3c-19193900

7.0.320

5

(*1) WorkAround（vSAN Plugin無効化）が存在しますが、  VxRail環境では機能低下につながるため対象に含めています。

 

今回の基準においては平均追随日数は10 Calendar Days となりました。

SLO Miss も一件ありましたが、平均としてはSLO を達成していることが分かりました。

 

 

講評とまとめ

平均追随日数については、リリース前に要するテストや手続きを考慮すると暦日勘定での平均10日の結果は、脆弱性パッチリリースの迅速性の観点では妥当性のある日数ではないかと思います。

今回の確認作業のなかで意外だったのは、思ったよりも対象が少ないことです。当初はCVSSスコアがCritialのものやESXiのみに絞ったフィルターで抽出していましたが、対象がなくなったり母数が少なすぎたりしてしまったので、基準と範囲を調整した背景があります。

 

母数を決定した最も大きな要因はWorkAround有無であったと思います。今回の対象にはここ1年で話題となった重大な脆弱性についてのパッチは含まれておりませんが、その理由はWorkAroundが存在したためです。
最近ESXiへのランサムウェア攻撃で利用されたOpenSLPの脆弱性や、昨年IT業界全体で大きな話題となったLog4jの脆弱性のパッチは発表当初からWorkAroundが存在したため、必ずしもパッチ適用による対処を必要としませんでした。

 

今回の確認ではvSphereでの脆弱性FixリリースからVxRailリリースまでの追随日数を確認しましたが、そもそも脆弱性発見からvSphereのFix リリースまでに日数を要する場合もあります。その場合はWorkAroundが重要な対策になるため、ランサムウェアなどのサイバー攻撃から環境を守るためには、迅速なパッチ適用以上にWorkAroundを適用するだけの柔軟性と余裕のある運用が重要であることを改めて気づかされる結果となりました。

  

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを受信した際の動作を示しています。 Broadcast Packetは仮想スイッチに接続されるVMに対して転送
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた
続きを読む

障害でVDSから切断されたVCSAの復旧方法

この投稿は vExpert Advent Calendarの10日目です。 https://adventar.org/calendars/6689 本記事では以下の状況と、簡易な復旧方法について説明します。 環境 vCSAは自身が管理するvSphere Cluster上に存在する。 vCSAは自身が管理する vDSに接続される vCSAが接続されるdvportgroupはEphemeralではない 該当のvCSA以外にvSphere Clusterを管理できる vCSA は存在しない  障害状況 vCSAは何らかの理由により、もともと存在していたESXiから、別のESXiに再登録されている。 vCSAはvDSから切断されてしまっている。 解説 上記の状況は、ESXiの障害などによって副次的に発生しうる状況です。もともと、vCSA は vDS に接続されていましたが、ESXi の障害などにより、いったん Guest OS から Shutdown され、Host Client を利用して別の ESXi に再登録したうえで起動しています。 この場合、もともとvCSAが接続されていたdvportは別の ESXi 上のポートであるため、起動時にvCSAはvNICを接続することができず、切断状態となります。 vCSAが切断状態になり、かつESXiのHost Clientからは仮想マシンをvDSに接続することができないため（Ephemeral Port を除く）、vCSAの復旧が困難となります。  この状況において有効な解決策としては事前に用意しておいたEphemeral Port を利用するか、もしくは一時的にVSSを作成して復旧する方法が一般的な方法です。 事前にEphemeral Port の準備がない場合には、VSSを作成することになりますが、Uplinkに空きがない場合は、Uplinkを付け替える必要があり、手順は複雑になります。 今回はVSSを利用しない簡易な復旧方法についてご紹介します。 簡易な復旧方法 完結に手順を示すと以下です。 vNICが切断されているVCSAをShutdown  vCSAが存在する ESXi を Maintenance Mode～Reboot  vCSA を再度起動～vNICが接続状態であることを確認  上記に示した通り、ESXiをリブート
続きを読む