Unterdrückungsregeln in GuardDuty - Amazon GuardDuty
Häufige Anwendungsfälle für Unterdrückungsregeln und Beispiele

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.

Unterdrückungsregeln in GuardDuty

Eine Unterdrückungsregel ist eine Reihe von Kriterien, die zum Filtern von Erkenntnissen verwendet werden, indem neue Erkenntnisse, die den angegebenen Kriterien entsprechen, automatisch archiviert werden. Unterdrückungsregeln können verwendet werden, um Ergebnisse mit niedrigem Wert, falsch positive Ergebnisse oder Bedrohungen zu filtern, auf die Sie nicht reagieren möchten, sodass die Sicherheitsbedrohungen mit den meisten Auswirkungen auf Ihre Umgebung leichter zu erkennen sind.

Nachdem Sie eine Unterdrückungsregel erstellt haben, werden neue Ergebnisse, die den in der Regel definierten Kriterien entsprechen, automatisch archiviert, solange die Unterdrückungsregel gültig ist. Sie können einen vorhandenen Filter verwenden, um eine Unterdrückungsregel zu erstellen, oder einen neuen Filter für die Unterdrückungsregel definieren, während Sie sie erstellen. Sie können Unterdrückungsregeln so konfigurieren, dass ganze Ergebnistypen unterdrückt werden, oder detailliertere Filterkriterien definieren, damit nur bestimmte Instances eines bestimmten Ergebnistyps unterdrückt werden. Sie können die Unterdrückungsregeln jederzeit bearbeiten.

Unterdrückte Ergebnisse werden nicht an AWS Security Hub Amazon Simple Storage Service, Amazon Detective oder Amazon gesendet, wodurch der Geräuschpegel reduziert wird EventBridge, wenn Sie GuardDuty Ergebnisse über Security Hub, einen Drittanbieter SIEM oder andere Alarm- und Ticketing-Anwendungen nutzen. Wenn Sie diese Option aktiviert habenMalware-Schutz für EC2, lösen die unterdrückten GuardDuty Ergebnisse keinen Malware-Scan aus.

GuardDuty generiert weiterhin Ergebnisse, auch wenn sie Ihren Unterdrückungsregeln entsprechen. Diese Ergebnisse werden jedoch automatisch als archiviert markiert. Das archivierte Ergebnis wird 90 Tage lang gespeichert und kann in GuardDuty diesem Zeitraum jederzeit eingesehen werden. Sie können unterdrückte Ergebnisse in der GuardDuty Konsole anzeigen, indem Sie in der Tabelle mit den Ergebnissen die Option Archiviert auswählen oder die GuardDuty API ListFindingsAPImit dem findingCriteria Kriterium „service.archivedGleich“ oder „Wahr“.

Anmerkung

In einer Umgebung mit mehreren Konten kann nur der GuardDuty Administrator Unterdrückungsregeln erstellen.

Häufige Anwendungsfälle für Unterdrückungsregeln und Beispiele

Die folgenden Findetypen werden häufig für die Anwendung von Unterdrückungsregeln verwendet. Wählen Sie den Namen des Befundes aus, um mehr über dieses Ergebnis zu erfahren. Lesen Sie die Beschreibung des Anwendungsfalls, um zu entscheiden, ob Sie eine Unterdrückungsregel für diesen Befundtyp erstellen möchten.

Wichtig

GuardDuty empfiehlt, dass Sie Unterdrückungsregeln reaktiv und nur für Ergebnisse erstellen, für die Sie in Ihrer Umgebung wiederholt falsch positive Ergebnisse festgestellt haben.

  • UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS— Verwenden Sie eine Unterdrückungsregel, um automatisch Ergebnisse zu archivieren, die generiert werden, wenn das VPC Netzwerk so konfiguriert ist, dass der Internetverkehr so weitergeleitet wird, dass er von einem lokalen Gateway und nicht von einem VPC Internet Gateway ausgeht.

    Dieses Ergebnis wird generiert, wenn das Netzwerk so konfiguriert ist, dass Internetverkehr so weitergeleitet wird, dass er von einem lokalen Gateway und nicht von einem VPC Internet Gateway () ausgeht. IGW Allgemeine Konfigurationen, wie z. B. die Verwendung von VPC VPN Verbindungen AWS Outposts, können dazu führen, dass der Datenverkehr auf diese Weise weitergeleitet wird. Wenn dieses Verhalten zu erwarten ist, empfiehlt es sich, Unterdrückungsregeln zu verwenden und eine Regel zu erstellen, die aus zwei Filterkriterien besteht. Das erste Kriterium ist der Ergebnistyp, der UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS sein sollte. Das zweite Filterkriterium ist die APIIPv4Anruferadresse mit der IP-Adresse oder dem CIDR Bereich Ihres lokalen Internet-Gateways. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Suchtyp anhand der IP-Adresse des API Anrufers zu unterdrücken.

    Finding type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS API caller IPv4 address: 198.51.100.6
    Anmerkung

    Um mehrere API Anrufer einzubeziehen, können IPs Sie für jeden Anruferadressfilter einen neuen API IPv4 Anruferadressfilter hinzufügen.

  • Recon:EC2/Portscan – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse automatisch zu aktivieren, wenn Sie eine Anwendung für Schwachstellenanalysen verwenden.

    Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Ergebnistyp mit dem Wert Recon:EC2/Portscan verwenden. Das zweite Filterkriterium sollte den Instances entsprechen, die diese Tools zur Schwachstellenanalyse hosten. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Findetyp auf der Grundlage von Instanzen mit einem bestimmten Wert zu unterdrücken. AMI

    Finding type: Recon:EC2/Portscan Instance image ID: ami-999999999

  • UnauthorizedAccess:EC2/SSHBruteForce – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse, die sich auf Bastion-Instances beziehen, automatisch zu archivieren.

    Wenn das Ziel des Brute-Force-Versuchs ein Bastion-Host ist, kann dies ein erwartetes Verhalten für Ihre AWS Umgebung darstellen. In diesem Fall sollten Sie für dieses Ergebnis eine Unterdrückungsregel einrichten. Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Ergebnistyp mit dem Wert UnauthorizedAccess:EC2/SSHBruteForce verwenden. Das zweite Filterkriterium sollte den Instances entsprechen, die als Bastion-Host eingesetzt werden. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten Instance-Tag-Wert zu unterdrücken.

    Finding type: UnauthorizedAccess:EC2/SSHBruteForce Instance tag value: devops

  • Recon:EC2/PortProbeUnprotectedPort – Verwenden Sie eine Unterdrückungsregel, um Erkenntnisse automatisch zu archivieren, wenn sie auf absichtlich exponierte Instances ausgerichtet ist.

    In einigen Fällen werden Instances absichtlich exponiert, weil sie beispielsweise Web-Server hosten. Wenn dies in Ihrer AWS Umgebung der Fall ist, empfehlen wir Ihnen, eine Unterdrückungsregel für dieses Ergebnis einzurichten. Die Unterdrückungsregel sollte aus zwei Filterkriterien bestehen. Das erste Kriterium sollte das Attribut Ergebnistyp mit dem Wert Recon:EC2/PortProbeUnprotectedPort verwenden. Das zweite Filterkriterium sollte den Instances entsprechen, die als Bastion-Host eingesetzt werden. Sie können entweder das Attribut Instance-Image-ID oder das Attribut Tag verwenden, abhängig davon, welches Kriterium mit den Instances identifiziert werden kann, die diese Tools hosten. Das folgende Beispiel stellt den Filter dar, den Sie verwenden würden, um diesen Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten Instance-Tag-Schlüssel in der Konsole zu unterdrücken.

    Finding type: Recon:EC2/PortProbeUnprotectedPort Instance tag key: prod

Empfohlene Unterdrückungsregeln für Ergebnisse von Runtime Monitoring

  • PrivilegeEscalation:Runtime/DockerSocketAccessed wird generiert, wenn ein Prozess in einem Container mit dem Docker-Socket kommuniziert. Möglicherweise gibt es Container in Ihrer Umgebung, die aus legitimen Gründen auf den Docker-Socket zugreifen müssen. Der Zugriff von solchen Containern aus wird generiert PrivilegeEscalation:Runtime/DockerSocketAccessed finden. Wenn dies in Ihrer AWS Umgebung der Fall ist, empfehlen wir Ihnen, eine Unterdrückungsregel für diesen Befundtyp einzurichten. Das erste Kriterium sollte das Attribut Erkenntnistyp mit dem Wert PrivilegeEscalation:Runtime/DockerSocketAccessed verwenden. Das zweite Filterkriterium ist das Feld Ausführbarer Pfad mit einem Wert, der dem Wert des Prozesses executablePath in der generierten Erkenntnis entspricht. Alternativ kann das zweite Filterkriterium das Feld Executable SHA -256 verwenden, dessen Wert dem Wert des Prozesses executableSha256 im generierten Ergebnis entspricht.

  • Kubernetes-Cluster betreiben ihre eigenen DNS Server als Pods, wie z. coredns Daher werden bei jeder DNS Suche in einem Pod zwei DNS Ereignisse GuardDuty erfasst — eines vom Pod und das andere vom Server-Pod. Dadurch können Duplikate für die folgenden DNS Ergebnisse generiert werden:

    Die doppelten Ergebnisse umfassen Pod-, Container- und Prozessdetails, die Ihrem DNS Server-Pod entsprechen. Sie können mithilfe dieser Felder eine Unterdrückungsregel einrichten, um diese doppelten Erkenntnisse zu unterdrücken. Bei den ersten Filterkriterien sollte das Feld Suchtyp mit einem Wert verwendet werden, der einem DNS Befundtyp aus der Liste der Ergebnisse entspricht, die weiter oben in diesem Abschnitt bereitgestellt wurde. Das zweite Filterkriterium könnte entweder der Pfad der ausführbaren Datei mit einem Wert sein, der dem Wert Ihres DNS Servers entspricht, executablePath oder die ausführbare Datei SHA -256 mit einem Wert, der dem Wert Ihres DNS Servers executableSHA256 in der generierten Suche entspricht. Als optionales drittes Filterkriterium können Sie das Kubernetes-Container-Image-Feld verwenden, dessen Wert dem Container-Image Ihres DNS Server-Pods im generierten Ergebnis entspricht.