Voraussetzungen für die Unterstützung Amazon EC2 Amazon-Instances - Amazon GuardDuty
Machen Sie EC2 Instanzen SSM-verwaltet (nur für automatisierte Agenten)Überprüfen Sie die architektonischen AnforderungenValidierung der Servicesteuerungsrichtlinie Ihrer Organisation in einer Umgebung mit mehreren KontenBei Verwendung der automatisierten AgentenkonfigurationCPU- und SpeicherlimitNächster Schritt

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Voraussetzungen für die Unterstützung Amazon EC2 Amazon-Instances

Dieser Abschnitt enthält die Voraussetzungen für die Überwachung des Laufzeitverhaltens Ihrer EC2 Amazon-Instances. Wenn diese Voraussetzungen erfüllt sind, finden Sie weitere Informationen unter GuardDuty Laufzeitüberwachung aktivieren.

Stellen Sie EC2 Instanzen als SSM-verwaltet fest (nur für die automatische Agentenkonfiguration)

GuardDuty verwendet AWS Systems Manager (SSM), um den Security Agent auf Ihren Instances automatisch bereitzustellen, zu installieren und zu verwalten. Wenn Sie den GuardDuty Agenten manuell installieren und verwalten möchten, ist SSM nicht erforderlich.

Informationen zur Verwaltung Ihrer EC2 Amazon-Instances mit Systems Manager finden Sie im AWS Systems Manager Benutzerhandbuch unter Systems Manager für EC2 Amazon-Instances einrichten.

Überprüfen Sie die architektonischen Anforderungen

Die Architektur Ihrer Betriebssystemverteilung kann sich auf das Verhalten des GuardDuty Security Agents auswirken. Sie müssen die folgenden Anforderungen erfüllen, bevor Sie Runtime Monitoring für EC2 Amazon-Instances verwenden können:

  • Die Kernel-Unterstützung umfassteBPF, Tracepoints undKprobe. Für CPU-Architekturen unterstützt Runtime Monitoring AMD64 (x64) und ARM64 (Graviton2 und höher). 1

    Die folgende Tabelle zeigt die Betriebssystemdistribution, für die verifiziert wurde, dass sie den GuardDuty Security Agent für EC2 Amazon-Instances unterstützt.

    Betriebssystem-Verteilung 2 Kernel-Version 3
    Amazon Linux 2

    5.4 4, 5.10 4, 5.15
    Amazon Linux 2023

    5,4 4, 5,10, 5,15 4, 6,1, 6,5, 6,8, 6,12
    Ubuntu 20.04 und Ubuntu 22.04

    5.4 4, 5.10, 5.15 4, 6.1, 6.5, 6.8
    Ubuntu 24.04

    6.8
    Debian 11 und Debian 12

    5.4 4, 5.10 4, 5.15, 6.1, 6.5, 6.8
    RedHat 9.4

    5,14
    Fedora 34,0

    5,11, 5,17
    Fedora 40

    6.8
    Fedora 41

    6,12
    CentOS Stream 9

    5,14
    Oracle Linux 8.9

    5,15
    Oracle Linux 9.3

    5,15
    Rocky Linux 9.5

    5.14

    1. Runtime Monitoring for Amazon EC2 Resources unterstützt Graviton-Instances der ersten Generation wie A1-Instance-Typen nicht.

    2. Support für verschiedene Betriebssysteme — GuardDuty hat die Runtime Monitoring-Unterstützung für die in der obigen Tabelle aufgeführte Betriebssystemdistribution verifiziert. Der GuardDuty Security Agent kann zwar auf Betriebssystemen ausgeführt werden, die in der obigen Tabelle nicht aufgeführt sind, aber das GuardDuty Team kann den erwarteten Sicherheitswert nicht garantieren.

    3. Für jede Kernel-Version müssen Sie das CONFIG_DEBUG_INFO_BTF Flag auf y (was wahr bedeutet) setzen. Dies ist erforderlich, damit der GuardDuty Security Agent wie erwartet ausgeführt werden kann.

    4. Bei Kernel-Versionen 5.10 und früher verwendet der GuardDuty Security Agent den gesperrten Arbeitsspeicher im RAM (RLIMIT_MEMLOCK), um erwartungsgemäß zu funktionieren. Wenn der RLIMIT_MEMLOCK Wert Ihres Systems zu niedrig ist, GuardDuty empfiehlt es sich, sowohl harte als auch weiche Grenzwerte auf mindestens 32 MB festzulegen. Hinweise zur Überprüfung und Änderung des RLIMIT_MEMLOCK Standardwerts finden Sie unterWerte anzeigen und aktualisieren RLIMIT_MEMLOCK.

  • Zusätzliche Anforderungen — Nur wenn Sie Amazon haben ECS/Amazon EC2

    Für Amazon empfehlen wir ECS/Amazon EC2, die neueste Amazon ECS-optimierte Version AMIs (vom 29. September 2023 oder später) oder die Amazon ECS-Agent-Version v1.77.0 zu verwenden.

Werte anzeigen und aktualisieren RLIMIT_MEMLOCK

Wenn das RLIMIT_MEMLOCK Limit Ihres Systems zu niedrig eingestellt ist, GuardDuty funktioniert der Security Agent möglicherweise nicht wie vorgesehen. GuardDuty empfiehlt, dass sowohl die harten als auch die weichen Grenzwerte mindestens 32 MB betragen müssen. Wenn Sie die Grenzwerte nicht aktualisieren, GuardDuty können die Laufzeitereignisse für Ihre Ressource nicht überwacht werden. Wenn RLIMIT_MEMLOCK es über den angegebenen Mindestgrenzen liegt, ist es für Sie optional, diese Grenzwerte zu aktualisieren.

Sie können den RLIMIT_MEMLOCK Standardwert entweder vor oder nach der Installation des GuardDuty Security Agents ändern.

Um RLIMIT_MEMLOCK Werte anzuzeigen

  1. Führen Sie ps aux | grep guardduty. Dadurch wird die Prozess-ID (pid) ausgegeben.

  2. Kopieren Sie die Prozess-ID (pid) aus der Ausgabe des vorherigen Befehls.

  3. Führen Sie den Befehl aus, grep "Max locked memory" /proc/pid/limits nachdem Sie den pid durch die aus dem vorherigen Schritt kopierte Prozess-ID ersetzt haben.

    Dadurch wird der maximal gesperrte Speicher für die Ausführung des GuardDuty Security Agents angezeigt.

Um RLIMIT_MEMLOCK Werte zu aktualisieren

  1. Wenn die /etc/systemd/system.conf.d/NUMBER-limits.conf Datei existiert, kommentieren Sie die Zeile von DefaultLimitMEMLOCK aus dieser Datei aus. Diese Datei legt einen Standard RLIMIT_MEMLOCK mit hoher Priorität fest, der Ihre Einstellungen in der /etc/systemd/system.conf Datei überschreibt.

  2. Öffnen Sie die /etc/systemd/system.conf Datei und entfernen Sie den Kommentar zu der Zeile, in der sich der Eintrag befindet. #DefaultLimitMEMLOCK=

  3. Aktualisieren Sie den Standardwert, indem Sie sowohl feste als auch weiche RLIMIT_MEMLOCK Grenzwerte von mindestens 32 MB angeben. Das Update sollte so aussehen:DefaultLimitMEMLOCK=32M:32M. Das Format ist soft-limit:hard-limit.

  4. Führen Sie sudo reboot.

Validierung der Servicesteuerungsrichtlinie Ihrer Organisation in einer Umgebung mit mehreren Konten

Wenn Sie eine Service Control Policy (SCP) zur Verwaltung von Berechtigungen in Ihrer Organisation eingerichtet haben, überprüfen Sie, ob die Rechtegrenze die Aktion zulässt. guardduty:SendSecurityTelemetry Sie ist erforderlich GuardDuty , um Runtime Monitoring für verschiedene Ressourcentypen zu unterstützen.

Wenn Sie ein Mitgliedskonto sind, stellen Sie eine Verbindung mit dem zugehörigen delegierten Administrator her. Informationen zur Verwaltung SCPs für Ihre Organisation finden Sie unter Richtlinien zur Servicesteuerung (SCPs).

Bei Verwendung der automatisierten Agentenkonfiguration

Dazu Verwenden Sie die automatische Agentenkonfiguration (empfohlen) AWS-Konto müssen Sie die folgenden Voraussetzungen erfüllen:

  • Wenn Sie Inclusion-Tags mit automatisierter Agentenkonfiguration verwenden, GuardDuty um eine SSM-Zuordnung für eine neue Instance zu erstellen, stellen Sie sicher, dass die neue Instance SSM-verwaltet wird und in der https://console.aws.amazon.com/systems-manager/Konsole unter Fleet Manager angezeigt wird.

  • Wenn Sie Ausschlusstags mit automatisierter Agentenkonfiguration verwenden:

    • Fügen Sie das false TagGuardDutyManaged: hinzu, bevor Sie den GuardDuty automatisierten Agenten für Ihr Konto konfigurieren.

      Stellen Sie sicher, dass Sie Ihren EC2 Amazon-Instances das Ausschluss-Tag hinzufügen, bevor Sie sie starten. Sobald Sie die automatische Agentenkonfiguration für Amazon aktiviert haben EC2, wird jede EC2 Instance, die ohne Ausschluss-Tag gestartet wird, von der GuardDuty automatisierten Agentenkonfiguration abgedeckt.

    • Aktivieren Sie die Einstellung „Tags zulassen“ in den Metadaten für Ihre Instances. Diese Einstellung ist erforderlich, da das Ausschluss-Tag aus dem Instanz-Metadatendienst (IMDS) gelesen werden GuardDuty muss, um festzustellen, ob die Instanz von der Agenteninstallation ausgeschlossen werden soll. Weitere Informationen finden Sie unter Aktivieren des Zugriffs auf Tags in Instance-Metadaten im EC2 Amazon-Benutzerhandbuch.

CPU- und Speicherlimit für den GuardDuty Agenten

CPU-Grenze

Das maximale CPU-Limit für den GuardDuty Security Agent, der EC2 Amazon-Instances zugeordnet ist, beträgt 10 Prozent der gesamten vCPU-Kerne. Wenn Ihre EC2 Instance beispielsweise über 4 vCPU-Kerne verfügt, kann der Security Agent maximal 40 Prozent der insgesamt verfügbaren 400 Prozent verwenden.

Speicherlimit

Aus dem Speicher, der Ihrer EC2 Amazon-Instance zugeordnet ist, steht ein begrenzter Speicher zur Verfügung, den der GuardDuty Security Agent verwenden kann.

Die folgende Tabelle zeigt das Speicherlimit.

Speicher der EC2 Amazon-Instance

Maximaler Arbeitsspeicher für den GuardDuty Agenten

Weniger als 8 GB

128 MB

Weniger als 32 GB

256 MB

Mehr als oder gleich 32 GB

1 GB

Nächster Schritt

Der nächste Schritt besteht darin, Runtime Monitoring zu konfigurieren und auch den Security Agent (automatisch oder manuell) zu verwalten.