Behebung der Erkenntnisse von EKS Audit Log Monitoring

Amazon GuardDuty generiert Ergebnisse, die auf potenzielle Kubernetes-Sicherheitsprobleme hinweisen, wenn EKS Audit Log Monitoring für Ihr Konto aktiviert ist. Weitere Informationen finden Sie unter EKS Audit Log Monitoring. In den folgenden Abschnitten werden die empfohlenen Schritte zur Behebung für alle Szenarien beschrieben. Spezifische Behebungsmaßnahmen werden im Eintrag für diesen spezifischen Erkenntnistyp beschrieben. Sie können auf die vollständigen Informationen zu einem Erkenntnistyp zugreifen, indem Sie ihn aus der Tabelle für aktive Erkenntnistypen auswählen.

Wenn einer der Erkennungstypen von EKS Audit Log Monitoring erwartungsgemäß generiert wurde, können Sie erwägen, Unterdrückungsregeln hinzuzufügen, um zukünftige Warnmeldungen zu verhindern.

Verschiedene Arten von Angriffen und Konfigurationsproblemen können GuardDuty Kubernetes-Erkenntnisse auslösen. Dieser Leitfaden hilft Ihnen dabei, die Ursachen für GuardDuty Erkenntnisse in Ihrem Cluster zu identifizieren und geeignete Anleitungen zur Behebung zu finden. Im Folgenden sind die Hauptursachen aufgeführt, die zu GuardDuty Kubernetes-Ergebnissen führen:

• Mögliche Konfigurationsprobleme

• Behebung potenziell kompromittierter Kubernetes-Benutzer

• Behebung potenziell kompromittierter Kubernetes-Pods

• Behebung potenziell kompromittierter Kubernetes-Knoten

• Behebung potenziell kompromittierter Container-Images

Anmerkung

Vor Kubernetes Version 1.14 war die system:unauthenticated Gruppe system:basic-user ClusterRoles standardmäßig system:discovery und zugeordnet. Dies könnte unbeabsichtigten Zugriff durch anonyme Benutzer ermöglichen. Durch Cluster-Updates werden diese Berechtigungen nicht aufgehoben. Das bedeutet, dass diese Berechtigungen auch dann noch gültig sind, wenn Sie Ihren Cluster auf Version 1.14 oder höher aktualisiert haben. Wir empfehlen, dass Sie die Zuordnung dieser Berechtigungen zu der system:unauthenticated-Gruppe aufheben.

Weitere Informationen zum Entfernen dieser Berechtigungen finden Sie unter Bewährte Methoden für die Sicherheit in Amazon EKS im Amazon-EKS-Benutzerhandbuch.

Mögliche Konfigurationsprobleme

Wenn eine Erkenntnis auf ein Konfigurationsproblem hindeutet, finden Sie im Abschnitt zur Behebung dieses Fehlers Anleitungen zur Lösung dieses speziellen Problems. Weitere Informationen finden Sie unter den folgenden Erkenntnistypen, die auf Konfigurationsprobleme hinweisen:

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• Jede Erkenntnis, die auf endet SuccessfulAnonymousAccess

Behebung potenziell kompromittierter Kubernetes-Benutzer

Eine GuardDuty Erkenntnis kann auf einen kompromittierten Kubernetes-Benutzer hinweisen, wenn ein in der Erkenntnis identifizierter Benutzer eine unerwartete API-Aktion ausgeführt hat. Sie können den Benutzer im Bereich Kubernetes-Benutzerdetails im Erkenntnisfenster der Konsole oder in der resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails der JSON-Datei mit den Erkenntnissen identifizieren. Zu diesen Benutzerdetails gehören user name, uid und die Kubernetes-Gruppen, zu denen der Benutzer gehört.

Wenn der Benutzer mit einer IAM-Entität auf den Workload zugegriffen hat, können Sie den Access Key details-Abschnitt verwenden, um die Details einer IAM-Rolle oder eines IAM-Benutzers zu identifizieren. Sehen Sie sich die folgenden Benutzertypen und deren Anleitungen zur Problembehebung an.

Anmerkung

Sie können Amazon Detective verwenden, um die in der Erkenntnis identifizierte IAM-Rolle oder den IAM-Benutzer genauer zu untersuchen. Wählen Sie beim Anzeigen der Erkenntnisdetails in der GuardDuty Konsole Untersuchen in Detective aus. Wählen Sie dann AWS Benutzer oder Rolle aus den aufgelisteten Elementen aus, um sie in Detective zu untersuchen.

Integrierter Kubernetes-Admin – Der Standardbenutzer, der von Amazon EKS der IAM-Identität zugewiesen wurde, die den Cluster erstellt hat. Dieser Benutzertyp wird durch den Benutzernamen identifiziert kubernetes-admin.

Wie Sie einem integrierten Kubernetes-Administrator den Zugriff entziehen:

• Identifizieren Sie den userType aus dem Access Key details-Abschnitt.

  • Wenn der userType Rolle ist und die Rolle zu einer EC2-Instance-Rolle gehört:

    • Identifizieren Sie diese Instance und folgen Sie dann den Anweisungen unter Behebung einer potenziell gefährdeten Amazon EC2 EC2-Instance.

  • Wenn es sich bei userType um einen Benutzer handelt oder um eine Rolle, die von einem Benutzer übernommen wurde:

    1. Rotieren Sie den Zugriffsschlüssel dieses Benutzers.

    2. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.

    3. Weitere Informationen finden Sie unter Mein AWS Konto ist möglicherweise kompromittiert.

OIDC-authentifizierter Benutzer – Ein Benutzer, dem der Zugriff über einen OIDC-Anbieter gewährt wurde. In der Regel hat ein OIDC-Benutzer eine E-Mail-Adresse als Benutzernamen. Sie können mit den folgenden Befehl überprüfen, ob Ihr Cluster OIDC verwendet: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Um einem OIDC-authentifizierten Benutzer den Zugriff zu entziehen:

1. Rotieren Sie die Anmeldeinformationen dieses Benutzers im OIDC-Anbieter.

2. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.

AWS-Auth ConfigMap -definierter Benutzer – Ein IAM-Benutzer, dem über eine AWS-Auth Zugriff gewährt wurde ConfigMap. Weitere Informationen finden Sie unter Verwalten von Benutzern oder IAM-Rollen für Ihren Cluster im EKS-Benutzerhandbuch. Sie können ihre Berechtigungen überprüfen, indem Sie den folgenden Befehl verwenden: kubectl edit configmaps aws-auth --namespace kube-system

So widerrufen Sie den Zugriff eines AWS ConfigMap-Benutzers:

1. Verwenden Sie den folgenden Befehl, um die zu öffnen ConfigMap.

   kubectl edit configmaps aws-auth --namespace kube-system

2. Identifizieren Sie den Rollen- oder Benutzereintrag im Abschnitt mapRoles oder mapUsers mit demselben Benutzernamen wie dem im Abschnitt Kubernetes-Benutzerdetails Ihrer GuardDuty Erkenntnis gemeldeten. Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer in einer Erkenntnis identifiziert wurde.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         user name: system:node:EC2_PrivateDNSName
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::123456789012:user/admin
         username: admin
         groups:
           - system:masters
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

3. Entfernen Sie diesen Benutzer aus der ConfigMap. Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer entfernt wurde.

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

4. Wenn es sich bei userType um einen Benutzer handelt oder um eine Rolle, die von einem Benutzer übernommen wurde:

   1. Rotieren Sie den Zugriffsschlüssel dieses Benutzers.

   2. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.

   3. Weitere Informationen finden Sie unter Mein AWS Konto ist möglicherweise kompromittiert.

Wenn die Erkenntnis keinen resource.accessKeyDetails-Abschnitt enthält, handelt es sich bei dem Benutzer um ein Kubernetes-Servicekonto.

Servicekonto – Das Servicekonto stellt eine Identität für Pods bereit und kann anhand eines Benutzernamens mit dem folgenden Format identifiziert werden: system:serviceaccount:namespace:service_account_name.

Um den Zugriff auf ein Servicekonto zu widerrufen:

1. Rotieren Sie die Anmeldeinformationen für das Servicekonto.

2. Lesen Sie die Hinweise zur Pod-Kompromittierung im folgenden Abschnitt.

Behebung potenziell kompromittierter Kubernetes-Pods

Wenn Details zu einer Pod- oder Workload-Ressource innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails Abschnitts GuardDuty angibt, wurde diese Pod- oder Workload-Ressource möglicherweise kompromittiert. Eine GuardDuty Erkenntnis kann darauf hinweisen, dass ein einzelner Pod kompromittiert wurde oder dass mehrere Pods über eine übergeordnete Ressource kompromittiert wurden. In den folgenden Kompromissszenarien finden Sie Anleitungen zur Identifizierung des oder der Pods, die kompromittiert wurden.

Kompromittierung einzelner Pods

Wenn es sich bei dem type-Feld innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails-Abschnitts um Pods handelt, identifiziert die Erkenntnis einzelne Pods. Das Namensfeld ist der name der Pods und das namespace-Feld ist sein Namespace.

Informationen zum Identifizieren des Worker-Knotens, auf dem die Pods ausgeführt werden, finden Sie unter Identifizieren der angegriffenen Pods und Worker-Knoten.

Pods wurden über die Workload-Ressource kompromittiert

Wenn das type-Feld innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails-Abschnitts eine Workload-Ressource identifiziert, z. B. eine Deployment, ist es wahrscheinlich, dass alle Pods innerhalb dieser Workload-Ressource kompromittiert wurden.

Informationen zum Identifizieren aller Pods der Workload-Ressource und der Knoten, auf denen sie ausgeführt werden, finden Sie unter Identifizieren der angegriffenen Pods und Worker-Knoten mithilfe des Workload-Namens .

Pods wurden über das Servicekonto kompromittiert

Wenn eine GuardDuty Erkenntnis ein Servicekonto im resource.kubernetesDetails.kubernetesUserDetails Abschnitt identifiziert, ist es wahrscheinlich, dass Pods, die das identifizierte Servicekonto verwenden, kompromittiert werden. Der durch eine Erkenntnis gemeldete Benutzername ist ein Servicekonto, wenn er das folgende Format hat: system:serviceaccount:namespace:service_account_name.

Informationen zum Identifizieren aller Pods mithilfe des Servicekontos und der Knoten, auf denen sie ausgeführt werden, finden Sie unter Identifizieren der fehlerhaften Pods und Worker-Knoten mithilfe des Servicekontonamens .

Nachdem Sie alle kompromittierten Pods und die Knoten identifiziert haben, auf denen sie ausgeführt werden, lesen Sie den Leitfaden für bewährte Methoden von Amazon EKS, um den Pod zu isolieren, seine Anmeldeinformationen zu rotieren und Daten für forensische Analysen zu sammeln.

So beheben Sie einen potenziell kompromittierten Pod:

1. Identifizieren Sie die Schwachstelle, durch die die Pods gefährdet wurden.

2. Implementieren Sie das Update für diese Schwachstelle und starten Sie neue Ersatz-Pods.

3. Löschen Sie die anfälligen Pods.

   Weitere Informationen finden Sie unter Kompromittierte Pod- oder Workload-Ressource erneut bereitstellen.

Wenn dem Worker-Knoten eine IAM-Rolle zugewiesen wurde, die es Pods ermöglicht, Zugriff auf andere AWS Ressourcen zu erhalten, entfernen Sie diese Rollen aus der Instance, um weitere Beschädigungen durch den Angriff zu verhindern. Wenn dem Pod eine IAM-Rolle zugewiesen wurde, sollten Sie ebenfalls prüfen, ob Sie die IAM-Richtlinien sicher aus der Rolle entfernen können, ohne andere Workloads zu beeinträchtigen.

Behebung potenziell kompromittierter Container-Images

Wenn eine GuardDuty Erkenntnis auf eine Pod-Kompromittierung hinweist, kann das zum Starten des Pods verwendete Image potenziell bösartig oder kompromittiert sein. GuardDuty Erkenntnis identifizieren das Container-Image im resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image Feld . Sie können feststellen, ob das Image bösartig ist, indem Sie es auf Malware scannen.

So beheben Sie ein potenziell kompromittiertes Container-Image:

1. Beenden Sie sofort die Verwendung des Images und entfernen Sie es aus Ihrem Image-Repository.

2. Identifizieren Sie alle Pods, die das potenziell kompromittierte Image verwenden.

   Weitere Informationen finden Sie unter Identifizieren von Pods mit potenziell anfälligen oder kompromittierten Container-Images und Worker-Knoten.

3. Isolieren Sie die potenziell gefährdeten Pods, rotieren Sie die Anmeldeinformationen und sammeln Sie Daten für die Analyse. Weitere Informationen finden Sie im Leitfaden zu bewährten Methoden für Amazon EKS.

4. Löschen Sie alle Pods mit dem potenziell kompromittierten Image.

Behebung potenziell kompromittierter Kubernetes-Knoten

Eine GuardDuty Erkenntnis kann auf eine Knotenkompromittierung hinweisen, wenn der in der Erkenntnis identifizierte Benutzer eine Knotenidentität darstellt oder wenn die Erkenntnis die Verwendung eines privilegierten Containers anzeigt.

Die Benutzeridentität ist ein Worker-Knoten, wenn das Feld für den Benutzernamen das folgende Format hat: system:node:node name. Beispiel: system:node:ip-192-168-3-201.ec2.internal Dies weist darauf hin, dass der Angreifer Zugriff auf den Knoten erhalten hat und die Anmeldeinformationen des Knotens verwendet, um mit dem Kubernetes-API-Endpunkt zu kommunizieren.

Eine Erkenntnis weist auf die Verwendung eines privilegierten Containers hin, wenn für einen oder mehrere der in der Erkenntnis aufgelisteten Container das Erkenntnisfeld resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged auf True gesetzt ist.

So beheben Sie einen potenziell kompromittierten Knoten:

1. Isolieren Sie den Pod, rotieren Sie seine Anmeldeinformationen und sammeln Sie Daten für die forensische Analyse.

   Weitere Informationen finden Sie im Leitfaden zu bewährten Methoden für Amazon EKS.

2. Identifizieren Sie die Servicekonten, die von allen Pods verwendet werden, die auf dem potenziell kompromittierten Knoten ausgeführt werden. Überprüfen Sie ihre Berechtigungen und rotieren Sie die Servicekonten bei Bedarf.

3. Beenden Sie den potenziell kompromittierten Knoten.