前回記事から時間軸がズレるお話をします。
つい先日の出来事について触れていきます。
序章
本日は土曜日。仕事は休みです。
今日は嫌な夢を見たせいか、6時過ぎに目が覚めてから寝られなくなり、
午前中はブログのお勉強と執筆、Youtube、ソシャゲのローテーションで気が付けばお昼過ぎ。
ふと、みんどらを見ると、浜の町近辺にめったに枠のモンスターが湧いている事を確認👍
平日の運動不足解消も兼ねて、いざ出陣しようとした時です。
東京の統括マネージャーからの電話（LINE）
100%トラブル発生の連絡です。
これからドラクエウォークに行こうとしていた気持ちも相まって一回無視してみます笑
数分後、今度は直電にかかってきました。
流石にこれはスルーできないと思い、受話すると、
緊急の脆弱性が出たので、顧客さんが話したがっているのでONLINEになってくれと。
あらゆる感情を押し殺して、在宅ワーク用のノートPCを開き、
顧客環境へログインしていきます。
程度メールチェックしてみると、
JAVA実行環境で利用されるlog4jでヤバい脆弱性が検知された模様。
Teamsを開くと、顧客から数件とチャットが。
一先ずリモート会議に参加し、話を聞いていきます。
要件定義
会議の参加者は顧客の部長、課長、係長クラスの方に対し、弊社の参加者は私のみ。
現在の現場ではこのような事は良くあります。
話を聞いてみると、現在の顧客はグルーバル企業さんなので、
アメリカからの指示でlog4jの脆弱性は極めて重篤な脆弱性と認定され、
即時に対応を進めなければならないとのこと。
軽く調べたところ、JAVA実行環境で動く拡張プラグインなので、
JAVAがインストールされているサーバにlog4jのJARファイル(*log4j*jar)
が存在するかどうかを全検索してみるのはどうかと提案してみます。
流石に全サーバに対して全検索かけるのは途方もない時間がかかる為、
ある程度あたりを付けて調査した方が良いと考え、提案してみます。
感触としては悪くありませんが、どの程度時間がかかるのかが分からないので、
まずは10台程度テスト環境のサーバに対して特定ファイル（*log4j*jar ）の
全検索をし、かかった時間×総台数で完了時間を試算しましょうという話に落ち着きました。
スクリプト作成
マニュアルで１つ１つ対応していては効率が悪いので、
スクリプトをパパっと作成し、リモートコマンドでデータ採取していきます。
顧客は具体的な方策については興味がなく、そもそも具体的な指示もあるわけもなく、
吉野家の格言の如く、
早い・安い・美味い
が実現できれば良いので、結果にコミットできれば良いのです。
という事で、軽く調査＋検証を経てパパっとスクリプト作成。
▼Linux用
find / -name “*log4j*jar” -type f
▼Windows用
dir c:\ /s /b
一先ず、これらのコマンドをリモートコマンドで検証サーバに流していきましたが、
結果は良い感じで取得出来ており、Linux/Windows共に1台あたり1分程度で取得出来ています。
ただ、全検索となるので、環境依存（各サーバのファイル数に依存する）
であることは明白なので、そこだけは顧客と認識相違ないよう念押ししていきます。
データ取得
検証も終えたので、顧客に報告し、そそくさとデータ取得作業に移ることを提案します。
顧客も上位層への提示報告があり、スピード感命の状況であることは察知している為
難なくOK頂きましたので、一先ずJAVAがインストールされている対象サーバを
先行してデータ取得スクリプトを仕掛けていきます。
Linux： 約300台
Windows： 約150台
スクリプト仕掛けた後、4時間程度で全台データ取得完了し、
logフォルダ内でgrepかけて顧客へデータを提出。
中身を見てみると、ファイル名でバージョンがわかるものが結構ありました。
脆弱性情報によると、バージョン1.x台は本脆弱性の影響は受けず、
脆弱性の対象は2.x台となります。
ファイル名から推察するに、大体1.x台のものばかりでしたので、
若干顧客の温度感が下がり、こちらも安堵します。
初日クロージング
顧客側の上位層への報告が土曜日の22時に設定されているとのことで、
それまでは一次休憩です。
実際にLog4jの機能を利用しているのはアプリ担当者側なので、
アプリ担当者側の意見も聞いたところ、調査にも時間がかかるとの事で、
土曜日の時点では後続対応は発生せず、休日明けの月曜日から本格的に
後続対応が発生する見込みとの事で話が落ち着いた模様です。
ただ今回はJAVAインストール環境にのみフォーカスをあてて調査してきましたが、
念のため、全台のサーバ約3500台に対してスクリプトを仕掛けて本日はクローズとなりました。
翌日編
規則正しく、今日も8時起床です。
休日だからといって昼過ぎまで寝る事もなくなりました。
年ですかね(´・ω・｀)
先日、顧客からは今日の対応は無しの見込みと聞いていますので、
午前中はブログの勉強＋執筆、午後からはガッツリドラクエウォークを楽しもうと計画し、
ブログの執筆中の出来事です。
AM9:30に鳴り止まない電話
着信は顧客の係長から・・・
流石にこれは無視できないので受話します。
話を聞いてみると、サーバだけではなくvCenterにもLog4jの脆弱性が検知されたとの事で
対応が必要そうなので、メンバーのアサインをお願いしたいとのこと。
連日の休日緊急対応ですか・・・
昨日に引き続き、心を無にして一先ず在宅ワーク用のノートPCを開き、
顧客環境にログインしていきます。
それと同時に弊社統括マネージャーへ電話をし、
VMware担当者のアサインをお願いしていきます。
つか電話に出ねぇｗｗｗ
顧客からはアサイン状況の催促が来るので、
副統括マネージャーにも連絡を入れていきますが、
副統括マネージャーはレスポンス抜群の方なので即応してくれます👍
弊社営業経由でVMware担当者のアサインをお願いしていきます。
本当は私がアサインした方が早いのですが、協力会社ごとに
契約上の決まりごとがあって面倒なんですよね。
協力会社のメンバーを休日緊急呼び出しをする場合は
弊社の特定メンバーからしか受け付けない的な。
中々人が捕まらず、顧客から電話を受けてから1時間半が経過してようやく
VMware担当者がONLINEになり、背景事情を説明していきます。
vCenterへのワークアラウンド対処
調査の結果、顧客環境で脆弱性対処が必要なのは、
アプライアンス版のvCenter計5台と、Windows版のvCenter6台である事が判明。
VMware社でも情報公開されていますが、
本日時点ではアプライアンス版のワークアラウンドは提供済み、
Windows版のワークアラウンドは調査中のステータスとなっています。
⇒12/13追記： 現時点ではWindows版のワークアラウンドも公開されています。
出来るところを進める方針となり、一先ずアプライアンス版の対応を進めていきます。
検証環境⇒DR環境⇒本番環境の順序で順繰りにワークアラウンド適用していきましたが、
大体、1台あたり30分程度の作業時間で完了し、特段影響も出る事もありませんでした。
具体的な対応手法はVMware社公開のワークアラウンドを実施した形となります。
編集後記
その後、前日のデータ取得の流れで、ファイル名からバージョン判断が可能なもの以外に
バージョン判別が出来ないファイルがいくつか存在したため、
該当ファイルの提供依頼を受け、パパっと取得し本日の対応を終えました。
翌日以降はWindows版のワークアラウンド適用や、
データ精査中のWindows/Linuxサーバの対処が発生する可能性が高いですが、
一先ず休日2連荘の対応は完了です。
休日2日潰した怒りが収まらず、
その後、管理人は思案橋へ飲みに繰り出したとさ。
コメント