Voraussetzungen für die Unterstützung Amazon EC2 Amazon-Instances - Amazon GuardDuty
Machen Sie EC2 Instanzen SSM-verwaltetValidierung der architektonischen AnforderungenValidierung der Servicesteuerungsrichtlinie Ihrer OrganisationBei 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.

Machen Sie EC2 Instanzen SSM-verwaltet

Die EC2 Amazon-Instances, für die Sie Laufzeitereignisse überwachen GuardDuty möchten, müssen AWS Systems Manager (SSM) verwaltet werden. Dies gilt unabhängig davon, ob GuardDuty Sie den Security Agent automatisch oder manuell verwalten. Wenn Sie den Agenten jedoch manuell mithilfe des Handbuchs verwaltenMethode 2 — Verwenden von Linux-Paketmanagern, müssen Ihre EC2 Instances nicht über SSM verwaltet werden.

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

Hinweis für EC2 Fedora-basierte Instances

AWS Systems Manager unterstützt die Fedora OS-Distribution nicht. Verwenden Sie nach der Aktivierung von Runtime Monitoring die manuelle Methode (Methode 2 — Verwenden von Linux-Paketmanagern), um den Security Agent in EC2 Fedora-basierten Instanzen zu installieren.

Informationen zu unterstützten Plattformen finden Sie unter Unterstützte Paketplattformen und Architekturen im Benutzerhandbuch.AWS Systems Manager

Validierung der architektonischen Anforderungen

Die Architektur Ihrer Betriebssystemdistribution 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 folgende Tabelle zeigt die Betriebssystemdistribution, für die verifiziert wurde, dass sie den GuardDuty Security Agent für EC2 Amazon-Instances unterstützt.

    Betriebssystem-Verteilung1 Kernel-Version2 Kernel-Unterstützung CPU-Architektur
    x64 () AMD64 Graviton () ARM64

    AL2 und AL2 023

    Ubuntu 20.04 und Ubuntu 22.04

    Debian 11 und Debian 12

    5.4 3, 5.10 3, 5.15, 6.1, 6.5, 6.8

    eBPF, Tracepoints, Kprobe

    Unterstützt

    Unterstützt

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5,14

    Fedora 34,0 4

    5,11, 5,17

    CentOS Stream 9

    5,14

    1. Support für verschiedene Betriebssysteme — GuardDuty hat die Unterstützung für die Verwendung von Runtime Monitoring auf den in der obigen Tabelle aufgeführten Betriebssystemen überprüft. Wenn Sie ein anderes Betriebssystem verwenden, erhalten Sie möglicherweise alle erwarteten Sicherheitswerte, die für die GuardDuty aufgelisteten Betriebssystemverteilungen verifiziert wurden.

    2. Für jede Kernelversion 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.

    3. 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.

    4. Fedora ist keine unterstützte Plattform für die automatische Agentenkonfiguration. Sie können den GuardDuty Security Agent auf Fedora bereitstellen, indem Sie. Methode 2 — Verwenden von Linux-Paketmanagern

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

    Für Amazon ECS/Amazon empfehlen wir 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

Wenn Sie eine Service Control Policy (SCP) zur Verwaltung von Berechtigungen in Ihrer Organisation eingerichtet haben, stellen Sie sicher, dass die Rechtegrenzen nicht einschränkend sind. 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.

    • Damit die Ausnahmetags funktionieren, aktualisieren Sie die Instance-Konfiguration, sodass das Instance-Identitätsdokument im Instance-Metadaten-Service (IMDS) verfügbar ist. Das Verfahren zur Durchführung dieses Schritts ist bereits Teil Laufzeitüberwachung aktivieren Ihres Kontos.

CPU- und Speicherlimit für den GuardDuty Agenten

CPU-Limit

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.