いまさらNSX-Vマネージャをデプロイ

今回は、

「いまさらNSX-Vマネージャをデプロイ」した際に気が付いたことを

正に．．．今更ですが、書いておきます。

DeepSecurity（TrendMicroさん．．．）のRelay問題で

とりあえず場凌ぎをする方がいるかもしれませんからね！！
（お前だけだ。というツッコミが聞こえてくる気はしますけど。。。）

そんなわけで、故有ってNSX-Vの6.4のマネージャを

デプロイする話がありました。

っが、フィージビリティを確認しても問題なく、

Install（Startup？）Guideなどを確認しても要件的にクリアしているし

問題無いはずなのに、デプロイ後IPが設定されない
（Staticで設定した値が反映されない）という状態が発生しました。

最初に疑ったのは、Deepを延命させるための環境なので

基盤としては古いのでフィジが取れてないのか・・・？でしたが、

デプロイするNSX-Vのマネージャバージョンは対応しているし、

うーん。。。と、

3時間ほど眺めていて悩んだ結果。。

「あ」

と、気が付きました。

6.4.xのNSX-Vマネージャをデプロイする際に

スタティックなIPを割り当てるためには、

IPとネットマスク（サブネットマスク）を設定しますが、

ネットマスクのところで、Prefix Length的に入れられるかと

入れていたのが原因でした。。。

これ、入力エラーを出してくれないので、

デプロイ処理は動いてしまって、

パッと見た目何が悪いのか判らずに

正常に動かないという状態に陥ります。

何度か試していて、おや？と気が付いたので

何とかなりましたが、、、。

入力項目でエラーチェックが有ったり無かったり、、、勘弁してほしい。。

似たような話で、悩まれてる方が居たら、

参考になれば。。。

ご参考まで。

2023-03-16

Workspace ONE UEMのアドレス

今回は、

「Workspace ONE UEMのアドレス」

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

VMware社より
「MUST READ: VMware Best Practices Update – Workspace ONE UEM SaaS IP update for CNｘｘｘｘ」

というタイトルのメールが来てたので、

「？？？」と思いながら、MUST READ...と書いてあるし読まないといけないよなーと、

中身を見たところUEMのアドレス範囲が変わる、、、ということの様ですね。

って、タイトルにも書かれてましたが。。。

原因としては、こちらのKBに書かれていますが、英語しかないんですよね。。

kb.vmware.com

拙い英語力で読んでますが

VMC on AWSで動作させている全てのUEMでAWS CloudFrontを導入していて、

AWSが提示している推奨事項に準拠するため・・・？なんですかね。

docs.aws.amazon.com

ひとまず、影響は

「IP変わるから接続先を明示的に許可しなければいけない環境なら変更してね。

　やらないと、Workspace ONE UEM の利用に影響がでるかもしれないよ。

　ちなみに、こういうことがあるからIPではなくDNSで解決できるように
　することを推奨してるよ。

　（さらにちなみに）CLOUDFRONTは頻繁にIP変わるよ！！」

ということですね。

ということで、次は対策。

許可が推奨されるDNSを以下の場所から確認して許可をする。

「Groups & Settings > All Settings > System > Advanced > Site URLs.」

うーん、、、環境によってですが、

こういう端末管理系の部門とネットワーク管理系の部門が分かれてしまっていたら

影響出てからでは変更に時間が掛かるでしょうし、

結構インパクト大きい気がしますね。

ご参考まで。

2023-03-07

Workspace ONE でのMDM

今回は、

「Workspace ONE でのMDM」というタイトルでお送りします。

勿論いつもの、、バグ的な話です。

エンドユーザ様の環境において、

iOSデバイス（iPhone、iPad）を管理していこうと展開を始めていた所だったのですが、、、

デバイスに配信されたIntelligent HUBが

「起動できない。起動しても一瞬でとじられてしまう。」

という問題が発生し、お問合せを頂きました。

上記の件で調査したところ、

iOS14.xでは、特定条件下において

Intelligent Hubがクラッシュするというバグがある様でした。。。

Crash seen when launching Workspace ONE applications on iOS and iPadOS 14 (90871)

kb.vmware.com

どうも、

iOS14.xでIntelligent Hubの23.02をUEMから配信して使用している環境の場合、

適合する話で、対応方法は以下の様です。

解決策：Resolution

デバイスを15にバージョンアップする。。。

回避策：Workaround

デバイスから一旦Intelligent Hubを削除し、App StoreからIntelligent Hubをインストールする。。

ひとまず、上記で解決する話ではあるのですが、この環境では、

Workspace ONE UEMに接続できないと、

Workspace ONE UEMで配信してインストールさせているアプリを

消すように設定している環境なので、気づかずに発生するとかなりのインパクトな話、、、なんですよね。

似たようなお話で悩まれてる方がいればご参考になれば。

2023-02-20

ESXiArgs...の影響度

今回は

「ESXiArgs...はどの程度影響があるのか？」

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

世間様に喧嘩を売るようなタイトルで始めましたが、、、

影響があるというのは間違いありません。

少なくとも、Work Aroundは、、、「最優先タスクとして」実装しましょう。

とはいえ、2年前に対応しているWork Around...なので今更感バリバリですけどね。。。

ただ、、、このような脆弱性に対して、

どこまで緊急度を上げて対応するか、

というのは、メーカの方からは絶対にいってくれない話なので、

敢えて、『チャレンジ』して、どうなのか？？というのは議論をしたいと、

いつも思っています。

と、いうのも、

今回のようなハイパーバイザーの脆弱性。。。

これまでも当然ありましたが、

『いつも思うこと』がありまして。

「この脆弱性...管理インターフェイス叩けなければ、
干渉の仕様がないですよね？？？」

みたいな話です。

脆弱性がある製品は、その脆弱性を修正するようにするのが

当然なのですが、、、

その対応までにどこまで急がなければいけないのか？？

です。

「今すぐ、パッチを当てろ！！！」

確かに、正論です。

が、できますか？と聞かれて、「今すぐできます！とは言えません」よ。。。

という訳で、

前書きが長くなりました...が、

今回の件を例にどう考えるべきかの一助になれば、と思って書いてます。

ということで、考えるべきは、

下記だと思います。

・アタック方法

・利用する脆弱性

・アタック経路

（＋アタックされるインタフェース）

ここからは環境的な話...

・上記のアタックされるインタフェースにアクセスできる通信元

・アタック対象インタフェースとアクセス可能な通信元の間にあるネットワーク障壁

少なくともこの辺が判れば、

（少し。。。）待てるのか？、本当に危ないのか？が判定できるので、

この辺が整理された資料を見て、判断しましょう。

今回、言いたかった話はこの辺なんですが。

結論として、

大前提ですが、この辺を整理できていないようなら、

有事に備えて整理してください。

整理されていれば、これまでの苦労を無駄にしないように

有効に活用しましょう。

今回のESXiArgsは、、、

ハイパーバイザーの構造としても、管理インタフェースからしか侵入する経路はないと思うんですが、、、

侵入された上で攻撃されれば同じですが、直接攻撃されるよりは時間が稼げると思います。

ESXiをターゲットにしたランサムということで、

ニュースとしては視聴率？閲覧数？稼げるし、

話題にしたがるのはわかるんですけど、

日本のように社外に管理インタフェース基本出さない環境でどれだけの影響があるのか、、、とはいえ、放っておいていいとは絶対に言えませんが。

今回はここまで。

ご参考になれば。

2023-02-01

NortonセーフWEBに危険と認定されてました笑

今回は

「NortonセーフWEBに危険と認定されてました笑」

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

先日、普段アクセスするのに使用するタブレットを

リプレースしたせいで、自サイトにアクセスする際に

久々にPCから自分のところのサイト名でアクセスした際の話です。

なんと。。。

。。

。

掲題のNorton先生にて『危険フラグ』が

立てられてました(ﾟＡﾟ;)ｺﾞｸﾘ

確かに個人的経験（主観？）で記事を書いてますので

出どころ不明？、ぁゃしいサイトと取られてしまうのかもしれません。。。笑

うーむ。。。

とはいえ、事実無根の話は書いてませんしね。。。

『疑わしい』カテゴリのものではないですよー

と、先生に上申した結果、

オレンジ判定から外してもらえました（汗

うーむ

自分自身の素性の怪しさが滲み出たのか。。。

という冗談はさておき、当サイトは実績ベースの話がメインですので

疑わしい(詐欺的な)。。。話はほぼありません！！

安心して、コイツ『よく引くから、なにかの参考になるかも』と

いう観点でご覧いただければ幸い？？です。

2023-01-27

NSX-Vはすでに。。。

今回は

「NSX-Vはすでに。。。」

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

2023年1月16日でテクニカルガイダンスも終了しました。

。。。。。。

。。。

。

と、いうか、してました。。。という話です。。

lifecycle.vmware.com

※Unsupported Productsにチェックをいれて、「Product Rlease」のフィルタで

「NSX Data Center for vSphere 6.4」を入力して検索してください

うーん、、まだ5年たってないシステムのところもあると思うんですけどね。。。

ということで（？）、塩漬けにしないなら

NSX-Vを使っている方は、NSX-Tに移行しないといけないです。

うーん、、

以前の記事に書きましたが、

masaod94.hatenablog.com

概念がそもそも違うんですよね。

NSX-Vが物理ネットワークが判ってれば理解しやすい製品だったのに対し、

NSX-Tはネットワークが理解できていることを前提に

オーバレイ、アンダーレイを考慮するための概念を頭に入れないといけないんです。

「仮想環境内部だけ」の機能以降だけ、なら使ってないセグメント割り当てて、

新規にNSX-Tのレイヤリングネットワーク（？）を作るだけでできると思いますが、

既にNSX-Vでオーバレイとかを曲がりなりにも作ってしまっていると、、、

なかなか簡単にできないような気がしますね。。。

うーん、

移行のやり方、、、ちゃんと調べて纏めますかねー。

そういえば

NSX-Tでも今後、日本で一番使われている機能が廃止されるとか言う話も聞きました。

そうなると。。。

日本ではある意味訴求力がなくなる気がしますが、どうなるんでしょうねー。。。

と、考えるのは自分の技術力(＋想像力)が足りないのでしょうねーきっと笑

ご参考まで。

（NSX-VがTGも終わってることを、、、参考に。。。です）

2022-12-21

Workspace ONE Accessの脆弱性。。。

今回は、

「Workspace ONE Accessの脆弱性。。。」

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

今回の話題、、、は、これです。

www.vmware.com

いつもながらソースは、VMware社様のSecurity Advisory （VMSA）です。。。

うーん、、、（また、）WS1Accessですか。。。

。。。。。。

。。。

。

今回は自分に影響がある事象、、、だと気が付いていて、

（自分のユーザ様に関係ある話、、、だったので）

脆弱性の情報提供だけでなくて、対応した話まで纏めておきたい、、、

と思い、若干時間が掛かってのお話です。（言い訳（笑）

そんなこんなで、勿体ぶっていても仕方ないので。。。

直近（2022年の10月上旬）において、脆弱性対応のために

バージョンアップ対応を行い、その時点での最新版（21.08.01）を

紆余曲折。。。（×2）くらいで導入したはず...だったのですが、

よくよく調べてみて、、

。。。。。。

。。。

？？

『おや？22.09なるバージョンがでていたのですか？？？』

しかも、その現在（2022年12月時点）においての最新版も

今回の「VMSA-2022-0032」の影響を受ける...と...？？

うーん、、、やはり、、、

これだけの頻度でVMSAの対象として扱われるコンポーネントは、

オンプレで面倒見切れない......です。。

と改めて再認識しました。。

同じWS1括りにされているUEMの方も同様なのかもしれませんが、

オンプレに置くならDMZに置かないといけないものは、、、

（オンプレ版はオンプレ版で、構成に自由が利くなど、、あるとは思うんですが、、、）

脆弱性公開の頻度とその対策工数、、、

さらにその対策をしなかった時のリスクを考えると、

クラウド版に移行していただくべきなのかも、、、しれないですね。。

と、前置き的なお話を長々としてきましたが、、、

弊社で導入しているWS1は、、自分が対応しているユーザ様以外は

全部クラウドだということでこの脆弱性の対象外でした。

さて、、本題の

今回（VMSA-2022-0032）の対応ですが、、、

21.08.01においてはパッチが提供されましたので、

パッチ適用だけで凌げそうです。。

適用方法としては、今回のユーザ様と同様に、、、

WS1Accessは複数台でクラスタを構成していると思いますので、

一台ずつクラスタから外してあげて、

パッチ適用して組み込む。そして動作確認。

というのを繰り返すだけです。

実のところ、

22.09については、パッチが提供されていないようなので、

これを導入している場合については、バージョンアップのために

一手間、、、を考えないといけないと思います。

（ちなみに自分は9月時点で21.08.01にバージョンアップした際には、、
　バージョンアップではなく、新規構築でデータを同期させなおしました。。）

ということで、

パッチ適用については、今回全台問題なく「予定通り」完了となりました。

※懸念していたのは、、構築時にバグとして引き当てていた、、

　クラスタに組み込めなくなる、、、という話だったのですが、

　パッチ適用においては、設定した値は元に戻るということはありませんでした。

masaod94.hatenablog.com

ご参考まで。