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, SIEM eines Drittanbieters 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 über die GuardDuty API mithilfe der ListFindingsAPI mit einem findingCriteria Kriterium, das service.archived gleich wahr ist.

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, die automatisch Erkenntnisse archiviert, die generiert werden, falls das VPC-Netzwerk so konfiguriert ist, dass der Internet-Datenverkehr über ein On-Premises-Gateway anstelle eines VPC-Internet-Gateways weitergeleitet wird.

    Diese Erkenntnis wird generiert, wenn das Netzwerk so konfiguriert ist, dass der Internetverkehr von einem On-Premises-Gateway und nicht von einem VPC Internet Gateway (IGW) ausgeht. Geläufige Konfigurationen, z. B. die Verwendung von AWS Outposts, oder VPC-VPN-Verbindungen, können dazu führen, dass 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 IPv4 API-Anruferadresse 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 Erkenntnistyp auf der Grundlage der IP-Adresse des API-Aufrufers zu unterdrücken.

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

    Um mehrere API-Aufrufer einzubeziehen, können IPs Sie für jeden einen neuen IPv4 API-Anrufer-Adressfilter 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 Erkenntnistyp auf der Grundlage von Instances mit einem bestimmten AMI zu unterdrücken.

    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 das erwartete Verhalten für Ihre Umgebung darstellen. AWS 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 aus solchen Containern 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 Ausführbare SHA-256 verwenden, dessen Wert dem executableSha256 des Prozesses in der generierten Erkenntnis entspricht.

  • Kubernetes-Cluster führen ihre eigenen DNS-Server als Pods aus, z. B. 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-Erkenntnisse generiert werden:

    Die doppelten Erkenntnisse 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. Die ersten Filterkriterien sollten das Feld Erkenntnistyp verwenden, dessen Wert einem DNS-Erkenntnistyp aus der Liste der Erkenntnisse entspricht, die weiter oben in diesem Abschnitt bereitgestellt wurde. Das zweite Filterkriterium könnte entweder ausführbarer Pfad mit einem Wert sein, der dem Wert Ihres DNS-Servers entspricht, executablePath oder Ausführbare SHA-256 mit einem Wert, der dem Wert Ihres DNS-Servers executableSHA256 in der generierten Erkenntnis entspricht. Als optionales drittes Filterkriterium können Sie das Feld Kubernetes-Container-Image verwenden, dessen Wert dem Container-Image Ihres DNS-Server-Pods in der generierten Erkenntnis entspricht.