今回は、
「Spring4Shellの脆弱性について」
というタイトルで、脆弱性情報の共有します。
4/1付でニュースになりましたが、
VMware社のAdvisoryが4/7付で更新されています。
一応対象製品は、コンテナ絡みでTanzu関連ですかね。。
興味はあれども着手できてないので、
オンプレばかりな自分には直接の影響は、、ないんでしょうかね。。
本年も認定?頂きました!
相変わらず、王道なところからは外れた話ばかりですが、
ご覧いただければ幸いです!!
今回は、
というタイトルで、(いつもどおり、、、?)ハマった話をお送りします。
触っていたのはNSX-V(サポート切れますが)の分散FWなのですが、
気づけば単純、気づかないと、、、ということで、
おおよそ1か月間、色々なポイントを調査し、、、たどり着きました。
事象(結論?)としては、
「分散ファイアウォールでブロックされていた」
なんですが、、、
『勿論、普通に許可するポリシーを入れているのに』ブロックされていたので、
分散FWでブロックされていると断定できずに時間が掛かってしまった。。。というわけですね。
そんなわけで、分散FWの、、、というか、
NSXのService Composer?での処理のされ方?という部分で
そういうことか!と知っていれば引っかからない話が分かったので、
共有します。。。
「分散ファイアウォールのルールに仮想マシンオブジェクトを登録しても
想定通りの動作をしない!!」
いつも通り、(ピンポイントな)限定するキーワードを書いてますが、
通信を許可するセキュリティグループに動的に登録されるようにした仮想マシンが、Service Composerから見てもしっかり登録されているのに通信が行えないという不思議な事象が発生しまして、、、分かったことは、
ということです。
勿体ぶった言い回しになりましたが、
VMware Toolsが把握していないIPアドレスは、ESXi、vCenterでも認識されず、、
結果NSXでも「そんなどこの馬の骨だかわからない…」存在として認識されるわけで、
「分散ファイアウォール」くんとしては「聞いてないものは知らないよ」と、しっかりブロックしてくれるわけですねー。。
(暗黙のdenyが最後に入れてあるホワイトリスト方式で運用してる環境なので。。)
うーん、、「忖度」してほしい。。笑
ということで、今回のこの事象、、、
自分はCitrix社のADC(Application Delivery Controler:旧NetScaler)のVPX(Virtual Appliance版)で起こったわけですが、Sub InterfaceとかをLinuxで有効にしても発生するんじゃないですかね。。
↑ADCは管理用のNSIP(これはToolsに拾われる)の他にSNIP(Subnet IP)と
ADCの中の仮想サーバ(LBだったりICAのリバプロにしたり)が持つVIPがあり
このようなことが発生したというわけです。。。
ひとまず解決して良かった。。。
ということで、
ご参考まで。
今回は、
「仮想環境で完全にクローズな疑似テスト環境を作る際に便利なこと」
というタイトルでお送りします。
本番環境のホスト(ESXi)を使って、
その中で完全にクローズな環境にしてしまっていると、
検証用のデータだったり、設定ファイルを本番環境から
どうやって持ち込もう??となりますよね。
そんなときには!
ISOファイルをlinuxで作ってしまいましょう。
mkisofs -r -J -V "xxxxxxx" -o xxxxxxxx.iso /tmp/yyyyyyyy.tgz
上記のコマンドでyyyyyyyyy.tgzを中に仕込んだxxxxxxxx.isoという
ファイルが出来上がります。
このisoファイルをデータストアにuploadして、
該当の仮想マシンにマウントすれば、、、
仮想のNetworkを一切触らずにクローズな検証環境の中にデータが持ち込めます。
まぁ、データ受け渡し用の仮想マシンを作って、、
本番環境のネットワークラベルと検証環境のネットワークラベルを
切り替えてあげればいいだけではありますが。。。
まぁ、設定を変えなくて良いということで、
不測の事故は防げるのではないか、、、と。(汗
IP変え間違えた!とか、
別のマシンのネットワークラベルを変えてしまった!!とか、、
よくやりそうになりますよねー?
そんなことやりそうになるのは、
お前だけだってツッコミが入りそうですが(笑
「本番環境と一緒にやってる検証環境」と縛りを入れたのは、
そういう環境でわざわざリスク背負う必要ない方法がありますよ、と
いうことが言いたかっただけです。
ご参考まで。
今回は、
「vSAN環境のディスク個別の容量の話」
というタイトルでお送りします。
前回、
「vSANデータストアに関する障害の話 - 器用貧乏、仮想化をあつかう
https://masaod94.hatenablog.com/entry/2021/10/23/000000」
で書いた話のときに知ったことで、
以下に記載のコマンドを実行すると、、、
vSANクラスタ内のホストに搭載された
Capacity TierのDiskそれぞれの使用容量が一覧で表示可能です。
cmmds-tool find -t HOSTNAME -f json | egrep "uuid|hostname" | sed -e 's/\"content\"://g' | awk '{print $2}' | sed -e 's/[\",\},\,]//g' | xargs -n 2 | while read hostuuid hostname; do echo -e "\n\nHost Name: $hostname::: Host UUID: $hostuuid\n Disk Name\t\t| Disk UUID\t\t | Disk Usage | Disk Capacity | Usage Percentage" ; cmmds-tool find -f json -t DISK -o $hostuuid | egrep "uuid|content" |sed -e 's/\"content\":|\\"uuid\"://g' | sed -e 's/[\",\},\]//g' | awk '{printf $0}' | sed -e 's/isEncrypted: [0-9]/\n/g'| awk '{print $37 " " $2 " " $5 " " $45}'| while read disknaa diskuuid diskcap maxcomp; do diskcapused=$(cmmds-tool find -f json -t DISK_STATUS -u $diskuuid |grep content |sed -e 's/[\",\},\]//g' | awk '{print $3}'); diskperc=$(echo "$diskcapused $diskcap" | awk '{print $1/$2*100}'); if [ "$maxcomp" != 0 ];then echo -en " $disknaa\t| $diskuuid\t| $diskcapused\t | $diskcap\t | $diskperc%\n"; fi; done; done
ちなみに出力例は、こんな感じになります。
(実データなので固有の情報は省いて転記してますが)
HostName: ESXihostname::: Host UUID:
DiskName|Disk UUID| Disk Usage | Disk Capacity | Usage Percentage
naa. | | 894307540929 | 1515646136320 | 59.005%
naa. | | 945761351297 | 1515646136320 | 62.3999%
naa. | | 1285277856646 | 1820566986752 | 70.5977%
naa. | | 987305565919 | 1515646136320 | 65.1409%
naa. | | 987305565919 | 1515646136320 | 65.1409%
naa. | | 1132718718976 | 1515646136320 | 74.735%
naa. | | 945761351297 | 1515646136320 | 62.3999%
上記の物がクラスタ内のホスト台数分ズラーっと出てくる感じですね。
ご参考まで。
今回は、
「VMware製品の脆弱性(VMSA-2021-0028)について」 と
いうタイトルでお送りします。
脆弱性情報が公開されました
Apache Log4jを使う多くの製品に影響があり、
さらに脆弱性の深刻度としてCVSSv3(Common Vulnerability Scoring System v3.0)
スコアは最大値の10です。
皆さんご注意ください。
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
取り急ぎの情報のみですが、
ご参考まで。
今回は、
「『クラウド』サービスとのL2延伸(結論)」
というタイトルでお送りします。
前回、
「クラウドサービスとのL2延伸(備忘録的要素90%) - 器用貧乏、仮想化をあつかう
https://masaod94.hatenablog.com/entry/2021/08/29/212912」
で書いた話が決着つきました。
簡単に問題点だけ改めて書くと
VMware Cloud にL2延伸している環境で
一部のサーバだけをVMC側に移行した際に
オンプレに残している一部のサーバと
通信を行うとエラーが発生する(ことがある)。
全部がダメではなく、ICMPだったりは大丈夫、、、で
アプリが通信すると駄目になる。
結論、
問題の原因としては、L2延伸によって
Maximum Transmission Unit(MTU)が実質上小さくなることでした。
L2延伸と言ってますが結局VPNですから、
カプセル化する際の余計なヘッダが乗ってくる分
パケットサイズが制限されてしまうことによって、
パケットの断片化が起こりますからね。
(↑断片化されるような環境でも、仕組み上は、自動的に断片化して再結合して通信してくれるんですが、、、)
サーバの設定であったり、アプリケーションの設定で問題が発生することがありますからそこにハマっていたんでしょう。
今回は、ユーザの方で担当していたアプリケーション(DBだからミドルウェア?)の設定で、、、という話だったようです。(細かい設定までは教えてもらえませんでした・・)
そんなわけで、ユーザのDBチームの方で設定を変えて、
リトライした結果、通信の問題は起こらなくなったというわけでした。
まとめ?得られたノウハウ?としては、
アプリ含めてMTU小さくなって問題が出るアプリや
その設定が無いか事前に確認しておかないといけないですねー。
そういえば、余談ですが、
類似の話、、(なのか?)で、
昔もパケット断片化の問題あり、、、
この話はUNIXサーバ(OS)で断片化する際の断片化のやり方がまずくて、
構築していたベンダーさんに「なんでそんな非推奨な設定にしてるの?」と、
話をしましたが、、、。
その際の技術情報はIPAで公開されているこちらですね。
この中の「5) Protocol Stackのセキュア化」の話で、
これによって、うちが構築していた経路上のVPN装置で通信を
ドロップしていたという話だったような、、、。
ご参考まで。