Wie stelle ich AWS-Ressourcen wieder her, die vom CrowdStrike Falcon-Agent betroffen waren?

Kurzbeschreibung

Am 19. Juli 2024 um 04:09 Uhr UTC führte ein Update des CrowdStrike Falcon-Agent (csagent.sys) dazu, dass auf Windows-basierten Geräten ungeplante Stoppfehler oder Bluescreen-Fehler auftraten. Zu den betroffenen Geräten gehören Amazon Elastic Compute Cloud (Amazon EC2)-Instances und persönliche virtuelle Desktops in Amazon WorkSpaces. Dieses Problem betraf nur Amazon EC2-Windows-Instances und persönliche WorkSpaces, auf denen CrowdStrike installiert ist.

Weitere Informationen findest du unter Remediation and Guidance Hub: Channel File 291 Incident (Behebungs- und Orientierungs-Hub: Vorfall mit dem Channel File 291) auf der CrowdStrike-Website.

Häufig ermöglicht ein Reboot der Instance oder des WorkSpace, dass der CrowdStrike Falcon-Agent erfolgreich aktualisiert wird.

Hinweis: Wenn die Instance Instance-Speicher-Volumes verwendet, bleiben die auf den Volumes gespeicherten Daten nicht erhalten, wenn du die Instance anhältst, in den Ruhezustand versetzt oder beendest. Wenn du die Instance anhältst, in den Ruhezustand versetzt oder beendest, wird das Instance-Speicher-Volume kryptografisch gelöscht. Weitere Informationen findest du unter Instance-Speicher für temporäre Blockspeicher für EC2-Instances.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Wenn ein Reboot die Instance nicht in einen fehlerfreien Zustand zurückversetzt, verwende entweder das AWS Systems Manager Automation-Runbook, um die Instances wiederherzustellen. Oder stelle die Instances manuell wieder her.

Überprüfe zunächst die folgenden Voraussetzungen, um das Runbook verwenden zu können:

• Wenn das Amazon Elastic Block Store (Amazon EBS)-Root-Volume verschlüsselt ist, stelle sicher, dass der Verschlüsselungsschlüssel in deinem Konto vorhanden ist. Stelle außerdem sicher, dass du die Berechtigung hast, ihn zu verwenden.
• Das Runbook AWSSupport-StartEC2RescueWorkflow hält die Instance an. Wenn die Instance Instance-Speicher-Volumes verwendet, verwende die manuelle Wiederherstellungsmethode, um einen Datenverlust zu vermeiden.
• Bevor du das Runbook AWSSupport-StartEC2RescueWorkflow startest, stelle sicher, dass dein AWS Identify and Access Management (IAM)-Benutzer oder deine Rolle über die erforderlichen Berechtigungen verfügt. Weitere Informationen findest du im Abschnitt Erforderliche IAM-Berechtigungen von AWSSupport-StartEC2RescueWorkflow. Du musst der IAM-Rolle auch die Berechtigung kms:CreateGrant hinzufügen.

Identifizieren beeinträchtigter Instances

Führe den AWS-CLI-Befehl describe-instance-status aus, um ausgefallene Instances zu identifizieren:

aws ec2 describe-instance-status --filters Name=instance-status.status,Values=impaired --query "InstanceStatuses[*].InstanceId" --region your-region

Hinweis: Ersetze your-region durch deine AWS-Region.

Verwendung des Systems Manager Automation-Runbooks, um eine einzelne EC2-Instance wiederherzustellen

Um AWSSupport-StartEC2RescueWorkflow zur Automatisierung der Wiederherstellung zu verwenden, öffne das Runbook auf der Systems Manager-Konsole. Wähle dann die Region und Instance aus, die du wiederherstellen möchtest. Wenn das Amazon EBS-Root-Volume verschlüsselt ist, setze AllowEncryptedVolume auf Wahr.

Dieser Runbook-Workflow startet eine temporäre EC2-Instance (Hilfs-Instance) in einer Virtual Private Cloud (VPC). Der Workflow ordnet die Hilfs-Instance automatisch der Standardsicherheitsgruppe der VPC zu. Die Instance muss ausgehende HTTPS-Kommunikation (TCP-Port 443) sowohl zu den Endpunkten in Amazon Simple Storage Service (Amazon S3) als auch in Systems Manager zulassen.

Du musst die Instance in einem der folgenden Subnetze starten, damit die Instance die erforderlichen AWS-Services erreicht, um die Workflow-Aufgaben abzuschließen:

• Öffentliches Subnetz, bei dem der Parameter AssociatePublicIpAddress auf True gesetzt ist.
• Privates Subnetz mit Internetzugang über NAT.

Die Hilfsinstance mountet das Root-Volume der ausgewählten Instances und führt dann den folgenden Befehl aus, um die betroffene Datei zu löschen:

get-childitem -path "$env:EC2RESCUE_OFFLINE_DRIVE\Windows\System32\drivers\CrowdStrike\" -Include C-00000291*.sys -Recurse | foreach { $_.Delete()}

Führe den folgenden Befehl aus, um den Inhalt der Base64-OfflineScript-Nutzdaten aus dem vorherigen Befehl zu überprüfen:

PS C:\Windows\system32> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("REPLACE_WITH_BASE64_HERE"))

Verwende das Systems Manager Automation-Runbook, um mehrere EC2-Instances wiederherzustellen

Um das Runbook auf mehreren EC2-Instances zu verwenden, verwende entweder Instance-IDs, Tags oder Ressourcengruppen.

Das Runbook startet eine Hilfs-Instance für jede ausgewählte Instance. Stelle sicher, dass du im ausgewählten Subnetz über genügend IP-Adressen für die Instances verfügst. Stelle außerdem sicher, dass du über genügend Instance-Kontingente und EBS-Volume-Kontingente verfügst.

Hinweis: Die Zeit, die die Fertigstellung des Automatisierungs-Runbooks in Anspruch nimmt, hängt vom Parallelitätsumfang ab, den du ausgewählt hast.

Instance-IDs verwenden

Führe die folgenden Schritte aus:

1. Öffne das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems Manager-Konsole.
2. Wähle unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
3. Wähle im Abschnitt Ziele für Parameter die Option InstanceId aus. Wähle für Ziele die Option Parameterwerte aus.
4. Wähle für Eingabeparameter die Instances aus, die du wiederherstellen möchtest.
5. Wähle für Ratenkontrolle die Parallelitätsoption für die Anzahl der Ressourcen aus, die die Automatisierung gleichzeitig ausführen können. Weitere Informationen findest du unter Steuerung von Automatisierungen im großen Stil.
6. Wähle Ausführen aus.

Tags verwenden

Führe die folgenden Schritte aus:

1. Erstelle ein neues, eindeutiges Tag, das nur für die Instances verwendet wird, die du wiederherstellen möchtest. Alle Instances mit diesem Tag sind für die Wiederherstellung vorgesehen und können zu unbeabsichtigtem Datenverlust führen oder die Instance-Verfügbarkeit beeinträchtigen. Weitere Informationen findest du unter Taggen der Amazon-EC2-Ressourcen und Was ist Tag Editor?
2. Verwende den AWS Resource Explorer oder den Tag Editor, um zu überprüfen, ob nur die betroffenen Instances das neue Tag verwenden.
3. Öffne das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems-Manager-Konsole.
4. Wähle unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
5. Wähle im Abschnitt Ziele für Parameter die Option InstanceId aus. Wähle für Ziele die Option Parameterwerte aus.
6. Wähle für Tags die Option Bearbeiten aus. Gib den Tag key und value ein und wähle dann Speichern aus.
7. Wähle für Eingabeparameter die Instances aus, die du wiederherstellen möchtest.
8. Wähle für Ratenkontrolle die Parallelitätsoption für die Anzahl der Ressourcen aus, die die Automatisierung gleichzeitig ausführen können. Weitere Informationen findest du unter Steuerung von Automatisierungen im großen Stil.
9. Wähle Ausführen aus.

Ressourcengruppen verwenden

Führe die folgenden Schritte aus:

1. Erstelle eine neue Ressourcengruppe, die du nur für die Instances verwenden kannst, die du wiederherstellen möchtest. Alle Instances in dieser Ressourcengruppe sind für die Wiederherstellung vorgesehen und können zu unbeabsichtigtem Datenverlust führen oder die Instance-Verfügbarkeit beeinträchtigen. Weitere Informationen findest du unter Erstellen abfragebasierter Gruppen in AWS Resource Groups.
2. Verwende die AWS-Ressourcengruppen-Konsole, um zu überprüfen, ob nur die betroffenen Instances zur neuen Ressourcengruppe gehören.
3. Öffne das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems-Manager-Konsole.
4. Wähle unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
5. Wähle im Abschnitt Ziele für Parameter die Option InstanceId aus. Wähle für Ziele die Option Parameterwerte aus.
6. Wähle für Ressourcengruppen die neue Ressourcengruppe aus.
7. Wähle für Eingabeparameter die Instances aus, die du wiederherstellen möchtest.
8. Wähle für Ratenkontrolle die Parallelitätsoption für die Anzahl der Ressourcen aus, die die Automatisierung gleichzeitig ausführen können. Weitere Informationen findest du unter Steuerung von Automatisierungen im großen Stil.
9. Wähle Ausführen aus.

Instances manuell wiederherstellen

Führe die folgenden Schritte aus:

1. Erstelle einen Snapshot des EBS-Root-Volumes der Instance.
2. Erstelle ein neues EBS-Volume aus dem Snapshot in derselben Availability Zone.
3. Starte eine neue Windows-Instance in derselben Availability Zone.
4. Füge das neue EBS-Volume als Daten-Volume an die neue Instance an.
5. Lade das EC2Rescue-Tool für Windows Server auf die Hilfs-Instance herunter.
6. Klicke mit der rechten Maustaste auf EC2Rescue.exe und wähle dann Als Administrator ausführen aus.
   Wähle auf der Seite mit der Lizenzvereinbarung Ich stimme zu aus.
   Wähle auf dem Willkommensbildschirm die Option Weiter aus.
   Wähle auf dem Bildschirm Modus auswählen die Option Offline-Instance aus.
   Wähle das Offline-Laufwerk aus und klicke dann auf Weiter. Wenn du dazu aufgefordert wirst, wähle Ja und dann OK aus.
   Führe EC2Rescue weiterhin aus.
   Hinweis: Wenn deine ursprüngliche Instance BitLocker zum Verschlüsseln des EBS-Root-Volumes verwendet, befolge die Prompts auf dem Bildschirm, um das Passwort oder den BitLocker-Wiederherstellungsschlüssel einzugeben. Oder verwende manage-bde unlock von der Befehlszeile aus. Weitere Informationen findest du unter manage-bde unlock auf der Microsoft-Website. Nachdem du das Laufwerk entsperrt hast, wiederhole Schritt 6.
7. Navigiere zum Ordner X:\Windows\System32\drivers\CrowdStrike\ auf dem angefügten Volume und lösche dann C-00000291*.sys.
   Hinweis: In diesem Beispiel ist X: der Laufwerksbuchstabe, der dem sekundären EBS-Volume der betroffenen Instance zugewiesen wurde. In deiner Umgebung könnte es sich um einen anderen Buchstaben handeln.
8. Gehe zurück zu EC2 Rescue.
   Wähle Diagnose und Rettung und dann Weiter aus.
   Behalte alle Standardoptionen bei.
   Wähle Weiter und dann erneut Weiter aus.
   Wenn du dazu aufgefordert wirst, wähle Rescue (Rettung) aus. Wähle OK und dann Weiter aus.
   Wähle Fertigstellen aus.
   Wähle im Popupfenster die Option Fix disk signature (Festplattensignatur korrigieren) und dann OK aus.
   Wenn Festplattensignatur korrigieren ausgegraut ist, wähle OK aus.
9. Trenne das EBS-Volume von der neuen Linux-Instance.
10. Erstelle einen Snapshot des getrennten EBS-Volumes.
11. Wähle denselben Volume-Typ (z. B. gp2 oder gp3) wie die betroffene Instance aus und erstelle ein Amazon Machine Image (AMI) aus dem Snapshot.
12. Ersetze das Root-Volume auf der ursprünglichen EC2-Instance und gib das AMI an.

WorkSpaces

Wenn mehrere Neustarts deinen WorkSpace nicht wieder in einen fehlerfreien Zustand versetzen, setze den WorkSpace auf einen früheren Snapshot zurück. Wenn die WorkSpace-Wiederherstellung deinen WorkSpace nicht in einen fehlerfreien Zustand zurückversetzt, erstelle den WorkSpace neu.

Problembehandlung

Wenn die vorherigen Schritte deine Verbindungsprobleme nicht lösen, gehe wie folgt vor:

Systems Manager Automation-Runbook

Problem: Die Hilfsinstance kann keine Verbindung zu den AWS-Serviceendpunkten herstellen. Dieses Problem kann zu einem Fehler im Automatisierungs-Workflow-Schritt waitForEc2RescueInstanceToBeManaged führen.

Lösung: Vergewissere dich, dass die Standardsicherheitsgruppe zulässt, dass ausgehender Datenverkehr (TCP-Port 443) die Systems-Manager- und S3-Endpunkte erreicht. Stelle außerdem sicher, dass das ausgewählte Subnetz eine Verbindung zu diesen Endpunkten herstellen kann. Um eine benutzerdefinierte Sicherheitsgruppe zu verwenden, aktualisiere den Parameterwert HelperInstanceSecurityGroupId mit deiner Sicherheitsgruppen-ID. Wenn du ein öffentliches Subnetz ausgewählt hast, setze den Parameter AssociatePublicIpAddress auf True. Du kannst auch alternativ den Parameter SubnetId auf CreateNewVPC festlegen, damit die Automatisierung eine neue VPC mit der erforderlichen Konnektivität erstellt.

Problem: Die betroffene Instance kann nicht gestoppt werden, da der Stoppschutz aktiviert ist.

Lösung: Deaktiviere den Stoppschutz für die betroffene Instance und führe dann die Automatisierung erneut aus.

Hinweis: Wenn die Instance Instance-Speicher-Volumes verwendet, bleiben Daten, die auf diesen Volumes gespeichert sind, nicht erhalten, wenn du die Instance stoppst.

Problem: Die Hilfs-Instance kann nicht gestartet werden.

Lösung: Der für die EC2Rescue-Instance ausgewählte Instance-Typ ist möglicherweise nicht in der Availability Zone des Subnetzes der Hilfs-Instance verfügbar. Verwende einen unterstützten Instance-Typ in derselben Availability Zone wie die Hilfs-Instance.

Problem: Wenn die Automatisierung bestätigt hat, dass die Erstellung des AWS-CloudFormation-Stacks abgeschlossen wurde, schlägt die Automatisierung mit dem folgenden Fehler fehl: „Stack AWSSupport-EC2Rescue-{UUID} entered unexpected state: DELETE_IN_PROGRESS“.

Lösung: Um festzustellen, warum der Stack ausgefallen ist, rufe die UUID ab und verwende die CloudFormation-Konsole. Ein Stack-Fehler kann auftreten, wenn du nicht über die Berechtigungen zum Erstellen der Stack-Ressourcen verfügst. Weitere Informationen findest du im Abschnitt Erforderliche IAM-Berechtigungen für AWSSupport-StartEC2RescueWorkflow und Wie kann ich Fehler bei verweigertem Zugriff oder nicht autorisiertem Betrieb mithilfe einer IAM-Richtlinie beheben?

Problem: Das Runbook schlägt im Schritt assertInstanceRootVolumeIsNotEncrypted des Automatisierungs-Workflows aufgrund eines verschlüsselten EBS-Volumes fehl.

Lösung: Wenn das Volume die EBS-Verschlüsselung verwendet, setze den Parameter AllowEncryptedVolume auf Wahr.

Problem: Die Standard-VPC wurde gelöscht.

Lösung: Lege den Parameter SubnetId auf CreateNewVPC fest, um eine neue VPC zu erstellen, die eine erfolgreiche Wiederherstellung der Instance ermöglicht.

Problem: Der Schritt detachInstanceRootVolume des Automatisierungs-Workflows schlägt mit der folgenden Fehlermeldung fehl: „error occurred (IncorrectState) when calling the DetachVolume operation: Unable to detach root volume“.

Lösung: Wenn du die Automatisierung ausführst, belasse die Instance im Status Angehalten.

Manuelle Instance-Wiederherstellung

Problem: Die Instance startet nicht und gibt die folgende Fehlermeldung aus: „The application or operating system couldn't be loaded because a registered file is missing or contains errors“.

Lösung: Wenn du die Option Festplattensignatur korrigieren nicht ausgewählt hast, ist möglicherweise eine Kollision mit der Festplattensignatur aufgetreten. Um dieses Problem zu beheben, befolge Schritt 8 in den Schritten zur manuellen Wiederherstellung. Wenn du die Instance ohne EC2Rescue wiederhergestellt hast, finde weitere Informationen unter Problembehandlung bei Amazon-EC2-Windows-Instances.

Hinweis: Wenn die vorherigen Schritte zur Fehlerbehebung die Konnektivität zu deiner EC2-Instance nicht lösen, wende dich an den AWS Support. Stelle sicher, dass du einen Screenshot der unerreichbaren Instance aufnimmst.

Ähnliche Informationen

Ausführen des EC2Rescue-Tools auf nicht erreichbaren Instances