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

Kurzbeschreibung

Am 19. Juli 2024 um 04:09 UTC führte ein Update des CrowdStrike Falcon-Agenten (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 betrifft nur Windows-Amazon EC2-Instances und persönliche WorkSpaces, auf denen CrowdStrike installiert ist.

Weitere Informationen finden Sie unter Remediation and Guidance Hub: Falcon Content Update for Windows Hosts auf der CrowdStrike-Website.

Normalerweise ermöglicht ein Neustart Ihrer Instance oder Ihres WorkSpace, dass der CrowdStrike Falcon-Agent erfolgreich aktualisiert wird.

Hinweis: Wenn Ihre Instance Instance-Speicher-Volumes verwendet, bleiben Daten, die auf diesen Volumes gespeichert sind, nicht erhalten, wenn die Instance gestoppt, in den Ruhezustand versetzt oder beendet wird. Wenn die Instance gestoppt, in den Ruhezustand versetzt oder beendet wird, wird das Instance-Speicher-Volume kryptografisch gelöscht. Weitere Informationen finden Sie unter Amazon-EC2-Instance-Speicher für temporäre Blockspeicher für Amazon-EC2-Instances.

Lösung

Wenn ein Neustart die Instance nicht in einen fehlerfreien Zustand zurückversetzt, verwenden Sie entweder das AWS-Systems-Manager-Automation-Runbook, um Ihre Instances wiederherzustellen. oder stellen Sie Ihre Instances manuell wieder her.

Wenn Sie das Runbook verwenden möchten, führen Sie zunächst die folgenden Aktionen aus:

• Wenn Ihr Amazon Elastic Block Store (Amazon EBS)-Root-Volume verschlüsselt ist, stellen Sie sicher, dass der Verschlüsselungsschlüssel in Ihrem Konto vorhanden ist. Außerdem müssen Sie die Erlaubnis haben, es zu verwenden.
• Das Runbook AWSSupport-StartEC2RescueWorkflow stoppt Ihre Instance. Wenn Ihre Instance Instance-Speicher-Volumes verwendet, verwenden Sie die manuelle Wiederherstellungsmethode, um einen Datenverlust zu vermeiden.
• Bevor Sie das Runbook AWSSupport-StartEC2RescueWorkflow starten, stellen Sie sicher, dass Ihr AWS Identify and Access Management (IAM)-Benutzer oder Ihre Rolle über die erforderlichen Berechtigungen verfügt. Weitere Informationen finden Sie im Abschnitt Erforderliche IAM-Berechtigungen von AWSSupport-StartEC2RescueWorkflow. Sie müssen der IAM-Rolle auch die Berechtigung kms:CreateGrant hinzufügen.

Identifizieren beeinträchtigter Fälle

**Hinweis:**Wenn bei der Ausführung von AWS Command Line Interface (AWS CLI)-Befehlen Fehler auftreten, finden Sie weitere Informationen unter Troubleshoot AWS CLI errors. Stellen Sie außerdem sicher, dass Sie die neueste Version von AWS CLI verwenden.

Führen Sie 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: Ersetzen Sie your-region durch Ihre AWS-Region.

Verwenden Sie das AWS-Systems-Manager-Automation-Runbook, um eine einzelne EC2-Instance wiederherzustellen

Um AWSSupport-StartEC2RescueWorkflow zur Automatisierung der Wiederherstellung zu verwenden, öffnen Sie das Runbook in der Systems-Manager-Konsole und wählen Sie die Region und die Instances aus, die Sie wiederherstellen. Wenn Ihr EBS-Root-Volume verschlüsselt ist, setzen Sie AllowEncryptedVolume auf True.

Dieser Runbook-Workflow startet eine temporäre EC2-Instance (Hilfsinstance) in einer Virtual Private Cloud (VPC). Die Hilfsinstance wird automatisch der Standardsicherheitsgruppe der VPC zugeordnet. 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.

Sie müssen 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ühren Sie den folgenden Befehl aus, um den Inhalt der Base64-OfflineScript-Nutzlast aus dem vorherigen Befehl zu überprüfen:

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

Verwenden Sie das AWS-Systems-Manager-Automation-Runbook, um mehrere EC2-Instances wiederherzustellen

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

Hinweis:

• Das Runbook startet eine Hilfsinstance für jede ausgewählte Instance.
• Stellen Sie sicher, dass Sie im ausgewählten Subnetz über genügend IP-Adressen für Ihre Instances verfügen.
• Stellen Sie sicher, dass Sie über genügend Instance-Kontingente und EBS-Volumenkontingente verfügen.
• Die Zeit, die die Fertigstellung des Automatisierungs-Runbooks in Anspruch nimmt, hängt vom ausgewählten Parallelitätsbetrag ab.

Instance-IDs verwenden

Führen Sie die folgenden Schritte aus:

1. Öffnen Sie das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems-Manager-Konsole.
2. Wählen Sie unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
3. Wählen Sie im Abschnitt Ziele für Parameter die Option InstanceId aus, und wählen Sie dann für Ziele Parameterwerte aus.
4. Wählen Sie für Eingabeparameter die Instances aus, die Sie wiederherstellen möchten.
5. Wählen Sie für Ratenkontrolle Ihre Parallelitätsoption für die Anzahl der Ressourcen, die die Automatisierung gleichzeitig ausführen dürfen. Weitere Informationen finden Sie unter Maßstabsgetreue Steuerung von Automatisierungen.
6. Wählen Sie Ausführen.

Verwenden Sie Tags

Führen Sie die folgenden Schritte aus:

1. Erstellen Sie ein neues, eindeutiges Tag, das nur für die Instances verwendet wird, die Sie wiederherstellen möchten. 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 finden Sie unter Taggen Ihrer Amazon-EC2-Ressourcen und Verwenden des Tag-Editors.
2. Verwenden Sie den AWS Resource Explorer oder den Tag Editor, um zu überprüfen, ob nur die betroffenen Instances das neue Tag nutzen.
3. Öffnen Sie das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems-Manager-Konsole.
4. Wählen Sie unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
5. Wählen Sie im Abschnitt Ziele für Parameter die Option InstanceId aus, und wählen Sie dann für Ziele Parameterwerte aus.
6. Wählen Sie für Tags die Option Bearbeiten, geben Sie den Schlüssel und Wert des Tags ein und wählen Sie dann Speichern.
7. Wählen Sie für Eingabeparameter die Instances aus, die Sie wiederherstellen möchten.
8. Wählen Sie für Ratenkontrolle Ihre Parallelitätsoption für die Anzahl der Ressourcen, die die Automatisierung gleichzeitig ausführen dürfen. Weitere Informationen finden Sie unter Maßstabsgetreue Steuerung von Automatisierungen.
9. Wählen Sie Ausführen.

Ressourcengruppen verwenden

Führen Sie die folgenden Schritte aus:

1. Erstellen Sie eine neue Ressourcengruppe, die Sie nur für die Instances verwenden können, die Sie wiederherstellen möchten. 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 finden Sie unter Erstellen abfragebasierter Gruppen in AWS Resource Groups.
2. Verwenden Sie die AWS-Ressourcengruppen-Konsole, um zu überprüfen, ob nur die betroffenen Instances zur neuen Ressourcengruppe gehören.
3. Öffnen Sie das Runbook AWSSupport-StartEC2RescueWorkflow auf der Systems-Manager-Konsole.
4. Wählen Sie unter Automatisierungs-Runbook ausführen die Option Ratenkontrolle aus.
5. Wählen Sie im Abschnitt Ziele für Parameter die Option InstanceId aus, und wählen Sie dann für Ziele Parameterwerte aus.
6. Wählen Sie für Ressourcengruppen die neue Ressourcengruppe aus.
7. Wählen Sie für Eingabeparameter die Instances aus, die Sie wiederherstellen möchten.
8. Wählen Sie für Ratenkontrolle Ihre Parallelitätsoption für die Anzahl der Ressourcen, die die Automatisierung gleichzeitig ausführen dürfen. Weitere Informationen finden Sie unter Maßstabsgetreue Steuerung von Automatisierungen.
9. Wählen Sie Ausführen.

Stellen Sie Ihre Instances manuell wieder her

Führen Sie die folgenden Schritte aus:

1. Erstellen Sie einen Snapshot des EBS-Root-Volumes der Instance.
2. Erstellen Sie ein neues EBS-Volume aus dem Snapshot in derselben Availability Zone.
3. Starten Sie eine neue Windows-Instance in derselben Availability Zone.
4. Hängen Sie das neue EBS-Volume als Datenvolume an die neue Instance an.
5. Laden Sie das Tool EC2Rescue für Windows Server auf die Hilfsinstance herunter.
6. Klicken Sie mit der rechten Maustaste auf EC2Rescue.exe und wählen Sie dann Als Administrator ausführen.
   Wählen Sie auf der Seite mit der Lizenzvereinbarung Ich stimme zu.
   Wählen Sie auf dem Willkommensbildschirm Weiter aus.
   Wählen Sie auf dem Bildschirm Modus auswählen die Option Offline-Instance aus.
   Wählen Sie das Offline-Laufwerk aus und klicken Sie dann auf Weiter. Wenn Sie dazu aufgefordert werden, wählen Sie Ja und dann OK.
   Führen Sie EC2 Rescue weiterhin aus.
   Hinweis: Wenn Ihre ursprüngliche Instance BitLocker zum Verschlüsseln des EBS-Root-Volumes verwendet, folgen Sie den Anweisungen auf dem Bildschirm, um Ihr Passwort oder Ihren BitLocker-Wiederherstellungsschlüssel einzugeben. Oder Sie können manage-bde unlock von der Befehlszeile aus verwenden. Weitere Informationen finden Sie unter manage-bde unlock auf der Microsoft-Website. Nachdem das Laufwerk entsperrt ist, wiederholen Sie Schritt 6.
7. Navigieren Sie zum Ordner X:\Windows\System32\drivers\CrowdStrike\ auf dem angehängten Volume und löschen Sie dann C-00000291*.sys.
   Hinweis: In diesem Beispiel ist X: der Laufwerksbuchstabe, der dem sekundären EBS-Volume der betroffenen Instance zugewiesen wurde. In Ihrer Umgebung könnte es sich um einen anderen Buchstaben handeln.
8. Gehen Sie zurück zu EC2 Rescue.
   Wählen Sie ** Diagnostizieren und retten** und dann Weiter aus.
   Behalten Sie alle Standardoptionen bei.
   Wählen Sie Weiter und dann erneut Weiter.
   Wenn Sie dazu aufgefordert werden, wählen Sie Retten, dann OK und dann Weiter.
   Wählen Sie Fertigstellen.
   Wählen Sie im daraufhin angezeigten Popup-Fenster die Option Festplattensignatur korrigieren und wählen Sie dann OK.
   Wenn Festplattensignatur korrigieren ausgegraut ist, wählen Sie OK.
9. Trennen Sie das EBS-Volume von der neuen Linux-Instance.
10. Erstellen Sie einen Snapshot des getrennten EBS-Volumes.
11. Wählen Sie denselben Volume-Typ (z. B. gp2 oder gp3) wie die betroffene Instance aus und erstellen Sie ein Amazon Machine Image (AMI) aus dem Snapshot.
12. Ersetzen Sie das Root-Volume auf der ursprünglichen EC2-Instance und geben Sie das AMI an.

Amazon WorkSpaces

Wenn mehrere Neustarts Ihren WorkSpace nicht wieder in einen fehlerfreien Zustand versetzen, setzen Sie den WorkSpace auf einen früheren Snapshot zurück. Wenn die WorkSpace-Wiederherstellung Ihren WorkSpace nicht in einen fehlerfreien Zustand zurückversetzt, erstellen Sie den WorkSpace neu.

Fehlerbehebung

Wenn die vorherigen Schritte die Konnektivität zu Ihrer EC2-Instance nicht lösen, folgen Sie diesen Schritten zur Fehlerbehebung für Ihre Wiederherstellungsoption.

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: Vergewissern Sie sich, dass die Standardsicherheitsgruppe zulässt, dass ausgehender Datenverkehr (TCP-Port 443) die Systems-Manager- und S3-Endpunkte erreicht. Stellen Sie außerdem sicher, dass das ausgewählte Subnetz eine Verbindung zu diesen Endpunkten herstellen kann. Um eine benutzerdefinierte Sicherheitsgruppe zu verwenden, aktualisieren Sie den Parameterwert HelperInstanceSecurityGroupIdmit Ihrer Sicherheitsgruppen-ID. Wenn Sie ein öffentliches Subnetz ausgewählt haben, setzen Sie den Parameter AssociatePublicIpAddress auf True. Sie können 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: Deaktivieren Sie den Stoppschutz für die betroffene Instance und führen Sie dann die Automatisierung erneut aus.
Hinweis: Wenn Ihre Instance Instance-Speicher-Volumes verwendet, bleiben Daten, die auf diesen Volumes gespeichert sind, nicht erhalten, wenn die Instance gestoppt wird.

Problem: Die Hilfsinstance 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 Hilfsinstance verfügbar. Verwenden Sie einen unterstützten Instance-Typ in derselben Availability Zone wie die Hilfsinstance.

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, rufen Sie die UUID-ID ab und verwenden Sie die CloudFormation-Konsole. Dieser Fehler kann auftreten, wenn Sie nicht über die Berechtigungen zum Erstellen der Stack-Ressourcen verfügen. Weitere Informationen finden Sie im Abschnitt Erforderliche IAM-Berechtigungen für AWSSupport-StartEC2RescueWorkflow und Wie kann ich Fehlern bei verweigertem Zugriff oder nicht autorisiertem Betrieb mithilfe einer IAM-Richtlinie beheben?

Problem: Das Runbook schlägt im Schritt assertInstanceRootVolumeIsNotEncrypted des Automatisierungsworkflows aufgrund eines verschlüsselten EBS-Volumes fehl.
Lösung: Wenn das Volume EBS-Verschlüsselung verwendet, setzen Sie den Parameter AllowEncryptedVolume auf True.

Problem: Die Standard-VPC wurde gelöscht.
Lösung: Legen Sie 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 Automatisierungsworkflows schlägt mit der folgenden Fehlermeldung fehl: „error occurred (IncorrectState) when calling the DetachVolume operation: Unable to detach root volume“. 
Lösung: Wenn Sie die Automatisierung ausführen, belassen Sie die Instance im Status Gestoppt.

Manuelle Instance-Wiederherstellung

Problem: Die Instance kann nicht gestartet werden und gibt den folgenden Fehler zurück: „the application or operating system couldn't be loaded because a registered file is missing or contains errors“.
Lösung: Wenn Sie die Option Festplattensignatur korrigieren nicht ausgewählt haben, ist möglicherweise eine Kollision mit der Festplattensignatur aufgetreten.
Um dieses Problem zu beheben, folgen Sie Schritt 8 in den Schritten zur manuellen Wiederherstellung. Wenn Sie die Instance ohne EC2 Rescue wiederhergestellt haben, finden Sie weitere Informationen unter Problembehandlung mit Amazon-EC2-Windows-Instances.

Hinweis: Wenn die vorherigen Schritte zur Fehlerbehebung die Konnektivität zu Ihrer EC2-Instance nicht lösen, wenden Sie sich an den AWS Support. Stellen Sie sicher, dass Sie einen Screenshot der unerreichbaren Instance aufnehmen.

Ähnliche Informationen

Ausführen des EC2Rescue-Tools auf nicht erreichbaren Instances