【2024年7月19日に発生したWindowsサーバー障害に関する記事】レスキュー用Windows EC2インスタンスを作成し、復旧対象のWindows EC2インスタンスから不要なファイルを削除する方法

こんにちは😺
カスタマーサクセス部の山本です。

2024 年 7 月 20 日 00:00 (日本時間) の情報です。

2024年7月19日に発生したWindowsサーバーの障害

2024年7月19日に発生したWindowsサーバーの障害について、弊社は情報を以下のURLで随時発信しています。

• 2024年7月19日に発生したWindowsサーバーの障害による影響について - 株式会社サーバーワークス

最新情報は、AWS サービスヘルスダッシュボードのアナウンスを参照することをお勧めします。ダッシュボードは現在も更新されており、最新情報を確認するためにリンク先を参照することを強く推奨します。アナウンスの内容が変更されることもあるので、定期的な確認が重要です。

現時点では、Windows OSを再起動することで復旧する可能性が高いとされています。しかし、再起動で解決しない場合もありますので、もしよろしければ、以下の手順を試してみてください。本記事では、アナウンスされている手順を実際に試してみた結果を記載しています。

一部の環境では、本記事の方法で実際に復旧できました。 ただし、本記事の執筆環境では、CrowdStrikeがインストールされているWindowsマシンを用意できなかったため、削除対象のファイルがない状態で手順を実施しています。ご了承ください。

参考にさせていただいた、サービスヘルスダッシュボードの手順を抜粋します。（2024 年 7 月 20 日 00:00 (日本時間) の情報です。）

CrowdStrike Falcon Agent Issue


Starting at 9:30 PM PDT on July 18th 2024 some Windows Instances, Windows Workspaces and Appstream Applications experienced connectivity issues and reboots due to a recent update of the CrowdStrike Falcon agent (csagent.sys). This update caused a stop error (BSOD) within the Windows operating system. Windows instances and Workspaces that do not use CrowdStrike, were not affected by this issue. AWS services and network connectivity were also not affected by this event and continued to operate normally.

While the issue was triggered by the CrowdStrike Falcon agent update within the Windows guest operating system, AWS has taken steps to mitigate the issue for as many Windows instances, Windows Workspaces and Appstream Applications as possible. For the remaining Windows instances, Windows Workspaces and Appstream Applications that are still affected by this issue, customers need to take action to restore connectivity.

For EC2 instances, there are currently three paths to recovery.

First, in some cases, a reboot of the instance may allow for the CrowdStrike Falcon agent to be updated to a previously healthy version, resolving the issue. However, this is not successful in all cases, in which case an alternative recovery strategy will be needed.

Second, the following steps can be followed to delete the CrowdStrike Falcon agent file on the affected instance:

1. Create a snapshot of the EBS root volume of the affected instance
2. Create a new EBS Volume from the snapshot in the same availability zone
3. Launch a new Windows instance in that availability zone using a different version of Windows
4. Attach the EBS volume from step (2) to the new Windows instance as a data volume
5. Navigate to \windows\system32\drivers\CrowdStrike\ folder on the attached volume and delete "C00000291*.sys"
6. Detach the EBS volume from the new Windows instance
7. Create a snapshot of the detached EBS volume
8. Replace the root volume of the original instance with the new snapshot
9. Start the original instance

Finally, customers can relaunch the EC2 instance from a snapshot or image taken before 9:30 PM PDT. We have been able to confirm that the update that caused the CrowdStrike Falcon agent issue is no longer being automatically updated, so the relaunched instance will no longer be affected by the issue.

For Amazon Workspaces, we recommend a reboot of the affected Workspaces. As with EC2, this may recover the instance but it does not work in all cases. Alternatively, we would recommend restoring to a recent backup of the workspace.

If you need assistance with any of these actions please contact AWS Support via the AWS Support Center.

検証は AWS マネジメントコンソールで実施しました。

2024 年 7 月 21 日 00:00 (日本時間) の追加情報

AWSから新しい復旧手順が公開されました。

• How do I recover AWS resources that were affected by the CrowdStrike Falcon agent?

関連して、弊社の荒川がブログ記事を書いています。本記事の手順と併せてご参照いただけると幸いです。

• 2024年7月19日に発生したWindowsサーバー障害に関する記事 - AWSナレッジセンターに公開された手順でルートボリューム置き換えによる回復を実施しました

では、手順を記載します。

1. 復旧対象の EC2 インスタンスの EBS ルート ボリュームのスナップショットを作成します

復旧対象の EC2 インスタンスにチェックを入れ、「ストレージ」タブに遷移します。
デバイス名が、/dev/sda1 のボリューム ID をクリックします。
補足： ルートボリューム用に予約済みのデバイス名に関する参考：Amazon EC2 インスタンス上のデバイス名

右上にある「アクション」内の「スナップショットの作成」をクリックします。

任意の説明を記入し、「スナップショットの作成」を押してください。

画面上部に「スナップショットが正常に作成されました snap-xxxxxxxxx 」とテロップが出ます。
snap-xxxxxxxxx の部分をクリックします。

スナップショットが作成完了になるのを待ちます。

「利用可能 (100%)」になりました。

2. 1 のスナップショットから新しい EBS ボリュームを、同じアベイラビリティゾーンに作成します

右上にある「アクション」ボタンから、「スナップショットからボリュームを作成」をクリックします。

復旧対象の EC2 インスタンスと同じアベイラビリティゾーンを選択します。

参考： 復旧対象の EC2 インスタンスのアベイラビリティゾーン確認箇所

「ボリュームの作成」をクリックします。

「ボリュームが正常に作成されました vol-xxxxxxxxx.」とテロップがでます。 vol-xxxxxxxxx の部分をクリックします。

「使用可能」になっています。

手順 4 でこの画面での操作を行うため、このウインドウはそのまま開いておくことをお勧めします。
または、ボリューム ID をメモしてください。

3. 異なるバージョンの Windows を使用して、レスキュー用の Windows インスタンスを起動します

必ず、復旧対象のEC2インスタンスのWindows Serverとは異なるバージョンのWindows Serverを作成してください。

作成手順の詳細は省略します。以下のポイントに注意してください：

• RDP接続またはSystems Manager Fleet Managerで接続できる状態であれば問題ありません。

効率的に作業するため、復旧対象のEC2インスタンスと同じアベイラビリティゾーンに配置するサブネットを選択しました。

4. 手順 ２ の EBS ボリュームをデータ ボリュームとして、レスキュー用の Windows インスタンスに接続します

手順２で作成・メモしたボリュームを参照します。
「アクション」内の「ボリュームのアタッチ」をクリックします。

手順３で作成した レスキュー用の EC2 インスタンスを選択します。
デバイス名はデータ領域としてマウントするため、 xvdb としました。

手順３で作成した Windows Server 2022 の EC2 インスタンスにボリュームを追加できました。
インスタンス画面です。

5. レスキュー用の Windows インスタンスで \Windows\System32\drivers\CrowdStrike\ フォルダーに移動し、「C-00000291*.sys」を削除します

CrowdStrikeがインストールされているWindowsマシンを用意できなかったため、削除対象のファイルはありません。 また、英語版のインスタンスを立ててしまいましたので、適宜読み替えてください。

「Windows 管理ツール」を起動します。

「コンピュータの管理」を起動します。

左ペインの「ディスクの管理」を選択します。 アタッチしたボリュームがあります。

右クリックして「オンライン」をクリックします。

D ドライブとして参照・編集可能になりました。

対象のファイルを削除します。

今回、CrowdStrike の入っている Windows マシンを用意できなかったので、削除対象のファイルはない状態です。

本手順を実施した後の確認のため、 D ドライブの一番上の階層に test.txt を作成しておきます。

「オフライン」にします。

6. レスキュー用の Windows インスタンスから 手順２で作成した EBS ボリュームをデタッチします

レスキュー用の Windows インスタンスから EBS ボリュームをデタッチします。
手順２で作成したボリュームを再度参照します。
「アクション」内の「ボリュームのデタッチ」をクリックします。

「デタッチ」をクリックします。

デタッチが終わるとボリュームは「利用可能」状態になります。

7. バックアップ用に、デタッチした EBS ボリュームのスナップショットを作成します

このスナップショットは、バックアップのために取得します。もし不要であれば次の手順に進んでください。
「アクション」内の「スナップショットの作成」をクリックします。

任意の説明を記載し、「スナップショットの作成」をクリックします。

スナップショットができました。 ID をメモしておきます。

8. 復旧対象の EC2 インスタンスのルート ボリュームを置き換えます

復旧対象の EC2 インスタンスを停止します。

停止できました。

停止したら、現在のルートボリュームをデタッチします。 復旧対象の EC2 インスタンスにチェックを入れ、「ストレージ」タブに遷移します。
デバイス名が、/dev/sda1 のボリューム ID をクリックします。

デタッチします。

手順 ６で、レスキュー用の Windows インスタンスから デタッチした新しいEBS ボリュームを、復旧対象の EC2 インスタンスにアタッチします。
ルートボリュームであるため、/dev/sda1 を選択します。

9. 復旧対象の EC2 インスタンスの起動と動作確認

復旧対象の EC2 インスタンスを起動します。

ログインすると、検証用に作成したテキストファイルがありました。

手順は以上です。

補足事項

ルートボリュームの付替機能は使えません

EC2 にはルートボリュームの付替機能があります。
しかし、本手順においては使用できませんでした。
理由としては以下の制約に当てはまるためです。

インスタンスの現在のルートボリュームと同じ系統に属するスナップショットのみを使用できます

ご参考：EC2 インスタンスのルートボリュームを置き換える - Amazon Elastic Compute Cloud

本手順でこの機能を利用するには、スナップショットを２回取得する必要があり、系統が変わってしまうようでした。

レスキュー用EC2インスタンスの作成

レスキュー用のEC2インスタンスには、必ず復旧対象のEC2インスタンスのWindows Serverとは異なるバージョンのWindows Serverを使用してください。

以下の文章はActive Directoryのディレクトリサービス復元モード（DSRM）に関するものですが、内容が似ているため参考にしてください。

別のバージョンのWindowsを使用するインスタンスタイプを選択します。例えば、インスタンスがWindows Server 2016である場合、Windows Server 2019のインスタンスを選択します。

参考リンク：Active Directoryのディレクトリサービス復元モードに関する情報

まとめ

本記事では、レスキュー用Windows EC2インスタンスを作成し、復旧対象のWindows EC2インスタンスから不要なファイルを削除する方法をご紹介しました。何かの役に立てば幸いです。

更新履歴

2024/7/20 10:01 手順の分かり易さ向上のため、手順８に画像を１枚追加しました。 2024/7/21 01:40 見出し「2024 年 7 月 21 日 00:00 (日本時間) の追加情報」を追加しました。

山本 哲也 (記事一覧)

カスタマーサクセス部のエンジニア。2024 Japan AWS Top Engineers に選んでもらいました。

今年の目標は Advanced Networking – Specialty と Machine Learning - Specialty を取得することです。

山を走るのが趣味です。今年の目標は 100 km と 100 mile を完走することです。 100 km は Gran Trail みなかみで完走しました。残すは OSJ koumi 100 で 100 mile 走ります。実際には 175 km らしいです。「草 100 km / mile」 もたまに企画します。

基本的にのんびりした性格です。座右の銘は「いつか着く」