
Führen Sie einen dateibasierten Malware-Scan auf Ihren lokalen Servern mit AWS durch.
Für Sicherheitsteams kann es aufgrund von Budget- und Ressourcenbeschränkungen schwierig sein, alle lokalen Server kontinuierlich zu überwachen. Ein signaturbasiertes Antivirenprogramm allein ist nicht ausreichend, da moderne Malware verschiedene Verschleierungstechniken einsetzt. Serveradministratoren haben möglicherweise historisch gesehen keine Transparenz über Sicherheitsereignisse auf allen Servern. Ohne zentralisierte Überwachung und Alarmierung ist es schwierig, kompromittierte Systeme und sichere Backups für die Wiederherstellung bei Vorfällen zu identifizieren. Für Serveradministratoren ist es aufwändig, zusätzliche Sicherheitstools für die erweiterte Bedrohungserkennung einzurichten und zu warten. Die schnelle mittlere Erkennungs- und Behebungszeit von Infektionen ist entscheidend, aber ohne die richtige automatisierte Lösung schwer zu erreichen.
Zu bestimmen, welches Backup-Image während eines Vorfalls ohne umfassende Bedrohungsinformationen sicher wiederhergestellt werden kann, ist ein weiteres schwieriges Problem. Selbst wenn Backups verfügbar sind, ist es riskant, blind aus Backups wiederherzustellen, ohne zu wissen, wann genau ein System kompromittiert wurde. Dies erhöht die Wahrscheinlichkeit, Malware wiederherzustellen und während der Incident-Response noch mehr wertvolle Daten und Systeme zu verlieren. Es besteht Bedarf an einer automatisierten Lösung, die den Zeitpunkt des Eindringens genau bestimmen und sichere Backups für die Wiederherstellung empfehlen kann.
Die Lösung nutzt AWS Elastic Disaster Recovery (AWS DRS), Amazon GuardDuty und AWS Security Hub, um die Herausforderungen der Malware-Erkennung für lokale Server zu bewältigen.
Diese Kombination von Diensten bietet eine kosteneffiziente Möglichkeit, lokale Server kontinuierlich auf Malware zu überwachen, ohne die Leistung zu beeinträchtigen. Sie hilft auch dabei, sichere Wiederherstellungspunkte in der Zeit für Backups zu bestimmen, indem sie den Zeitplan der Kompromittierung durch zentralisierte Bedrohungsanalysen identifiziert.

Die Malware-Scan-Lösung geht davon aus, dass lokale Server bereits mit AWS DRS repliziert werden und Amazon GuardDuty und AWS Security Hub aktiviert sind. Der CDK-Stack in diesem Repository wird nur die im Architekturdiagramm als 'DRS Malware Scan' gekennzeichneten Boxen bereitstellen.
Ein AWS-Konto.
Amazon Elastic Disaster Recovery (DRS) konfiguriert, mit mindestens einem synchronisierten Quellserver. Falls nicht, lesen Sie bitte diese Dokumentation. Die Replikationskonfiguration muss EBS-Verschlüsselung mit einem benutzerdefinierten verwalteten Schlüssel (CMK) von AWS Key Management Service (AWS KMS) berücksichtigen. Amazon GuardDuty Malware Protection unterstützt den standardmäßigen von AWS verwalteten Schlüssel für EBS nicht.
IAM-Berechtigungen zur Bereitstellung der Komponenten dieser Lösung.
Amazon GuardDuty aktiviert. Falls nicht, lesen Sie bitte diese Dokumentation
Amazon Security Hub aktiviert. Falls nicht, lesen Sie bitte diese Dokumentation
Warnung
Derzeit unterstützt der Amazon GuardDuty Malware-Scan keine EBS-Volumes, die mit von EBS verwalteten Schlüsseln verschlüsselt sind. Wenn Sie diese Lösung verwenden möchten, um Ihre lokalen (oder andere Cloud-)Server zu scannen, die mit DRS repliziert werden, müssen Sie die DRS-Replikation mit Ihrem eigenen Verschlüsselungsschlüssel in KMS einrichten. Wenn Sie derzeit von EBS verwaltete Schlüssel für Ihre replizierenden Server verwenden, können Sie die Verschlüsselungseinstellungen in der DRS-Konsole ändern, um Ihren eigenen KMS-Schlüssel zu verwenden.
Erstellen Sie eine Cloud9-Umgebung mit einem Ubuntu-Image (mindestens t3.small für bessere Leistung) in Ihrem AWS-Konto. Öffnen Sie Ihre Cloud9-Umgebung und klonen Sie den Code aus diesem Repository. Hinweis: Amazon Linux 2 hat Node v16, das seit dem 11.09.2023 nicht mehr unterstützt wird.
git clone https://github.com/aws-samples/drs-malware-scan
cd drs-malware-scan
sh check_loggroup.sh
Stellen Sie den CDK-Stack bereit, indem Sie den folgenden Befehl im Cloud9-Terminal ausführen und bestätigen Sie die Bereitstellung.
npm install
cdk bootstrap
cdk deploy --all
Hinweis
Die Lösung besteht aus 2 Stacks:
cdk deploy DrsMalwareScanStack ausführen.cdk deploy ScanReportStack ausführen.Wenn Sie beide Stacks bereitstellen möchten, können Sie cdk deploy --all ausführen.
Stellen Sie sicher, dass die DRS-Quellserver kontinuierlich replizieren und sich in einem fehlerfreien Replikationszustand befinden. Dies ist aufgrund einer Einschränkung der GuardDuty-API erforderlich: Zum Zeitpunkt der Erstellung dieses Dokuments gibt es keine öffentliche AWS-API zum Scannen von DRS-Snapshots. Die einzige Möglichkeit, einen Malware-Scan über DRS-Quellserverdaten durchzuführen, besteht darin, einen Scan auf den von AWS DRS verwalteten Replikationsservern (Amazon EC2-Instanzen) durchzuführen. Wenn die Replikation nicht in einem fehlerfreien Zustand läuft, wird Ihr DRS-Malware-Scan möglicherweise nicht erfolgreich abgeschlossen. Sie müssen ReadyforRecovery=Ready bestätigen.
Identifizieren Sie die zu scannenden Quellserver. Aus allen Servern, die mit AWS DRS repliziert werden, müssen Sie die Liste der Kandidatenserver zum Scannen bestimmen. Kopieren Sie aus der AWS DRS-Konsole die Namen der Quellserver, die die Lösung scannen soll, und fügen Sie sie in einen Texteditor ein. Dies wird im nächsten Schritt verwendet.





Optional: Überprüfen Sie die Malware-Scan-Berichtsdatei auf S3. Falls Sie den ScanReportStack bereitgestellt haben, können Sie einen Bericht planen, der so oft wie gewünscht ausgeführt wird. Der Bericht extrahiert den Inhalt der DynamoDB-Tabelle DRSVolumeAnnotationsDDBTable und schreibt ihn in den vom Stack erstellten Amazon S3 Bucket (mit Präfix scanreportstack-scanreportbucket). Dieser Bericht wird jedes Mal überschrieben (und ist kumulativ), wenn die Regel ausgelöst wird.


Optional: Für Multiaccount-Konfiguration. Falls Sie ein dediziertes Sicherheitskonto haben, um alle Sicherheitserkenntnisse im Rahmen einer Multiaccount-Strategie zu zentralisieren, funktioniert diese Lösung ebenfalls. Das Sicherheitsteam kann dieselbe Analyse über das Sicherheitskonto durchführen; die in den verknüpften Konten gemeldeten Security Hub- und GuardDuty-Erkenntnisse werden automatisch in das zentralisierte Sicherheitskonto kopiert.
Alle Lambda-Funktionen leiten Logs an Amazon CloudWatch weiter. Sie können die Ausführung jeder Funktion überprüfen, indem Sie die entsprechenden CloudWatch-Loggruppen für jede Funktion inspizieren. Suchen Sie nach dem Muster /aws/lambda/DrsMalwareScanStack-*.
Die Dauer des Malware-Scan-Vorgangs hängt von der Anzahl der zu scannenden Server/Volumes (und deren Größe) ab. Wenn Amazon GuardDuty Malware findet, generiert es ein SecurityHub-Finding: Die Lösung fängt dieses Ereignis ab und führt die Lambda-Funktion $StackName-SecurityHubAnnotations aus, um das SecurityHub-Finding mit einer Notiz zu ergänzen, die den/die Namen des/der DRS-Quellservers mit Malware enthält.
Die SQS-FIFO-Warteschlangen können mit den Metriken Messages available und Message in flight aus der AWS SQS-Konsole überwacht werden.
Die DynamoDB-Tabellen für DRS-Volume-Annotationen verfolgen den Status jedes Malware-Scan-Vorgangs.
Amazon GuardDuty hat dokumentierte Gründe, Scan-Vorgänge zu überspringen. Weitere Informationen finden Sie unter Reasons for skipping resource during malware scan.
Um Logs von Amazon GuardDuty-Malware-Scan-Vorgängen zu analysieren, können Sie die Amazon CloudWatch-Loggruppe /aws/guardduty/malware-scan-events überprüfen. Die standardmäßige Aufbewahrungsdauer für diese Loggruppe beträgt 90 Tage, danach werden die Log-Ereignisse automatisch gelöscht.
Führen Sie die folgenden Befehle in Ihrem Terminal aus:
cdk destroy --all
(Optional) Löschen Sie die mit Lambda-Funktionen verbundenen CloudWatch-Loggruppen.
Für diese Analyse haben wir ein fiktives Szenario als Beispiel angenommen. Die folgenden Kostenschätzungen basieren auf Diensten in der Region Nord-Virginia (us-east-1).
| Monthly Cost | Total Cost for 12 Months |
|---|---|
| 171.22 USD | 2,054.74 USD |
| Dienstname | Beschreibung | Monatliche Kosten (USD) |
|---|---|---|
| AWS Elastic Disaster Recovery | 2 Quellserver / 1 Replikationsserver / 4 Festplatten / 100 GB / 30 Tage Aufbewahrungszeitraum für EBS-Snapshots | 71.41 |
| Amazon GuardDuty | 3 TB Malware-Scan pro Monat | 94.56 |
| Amazon DynamoDB | 100 MB 1 Lesevorgang/Sekunde 1 Schreibvorgang/Sekunde | 3.65 |
| AWS Security Hub | 1 Konto / 100 Sicherheitsprüfungen / 1000 erfasste Erkenntnisse | 0.10 |
| AWS EventBridge | 1 Mio. benutzerdefinierte Ereignisse | 1.00 |
| Amazon Cloudwatch | 1 GB erfasst/pro Monat | 0.50 |
| AWS Lambda | 5 ARM Lambda-Funktionen - 128 MB / 10 Sek. | 0.00 |
| Amazon SQS | 2 SQS-FIFO | 0.00 |
| Gesamt | 171.22 |
Hinweis Die hier dargestellten Zahlen sind Schätzungen basierend auf den oben beschriebenen Annahmen, abgeleitet vom AWS Pricing Calculator. Weitere Details finden Sie in diesem Pricing Calculator als Referenz. Sie können die Dienstkonfigurationen im genannten Rechner anpassen, um Ihre eigene Schätzung zu erstellen. Diese Schätzung enthält keine möglichen Steuern oder zusätzlichen Gebühren, die anfallen könnten. Es ist wichtig zu beachten, dass die tatsächlichen Kosten je nach Nutzung und allen zusätzlichen, nicht in dieser Analyse abgedeckten Diensten variieren können. Für kritische Umgebungen wird empfohlen, den Business Support Plan einzuschließen (in der Schätzung nicht berücksichtigt).
Weitere Informationen finden Sie unter CONTRIBUTING.
Dieser Beispielcode ist unter der MIT-0-Lizenz lizenziert. Siehe die Datei LICENSE.