Linux & Ingénierie de détection dans le nuage - Démarrer avec Defend for Containers (D4C)

Introduction

Les systèmes Linux restent une base essentielle pour l'infrastructure moderne, en particulier dans les environnements cloud-native où les conteneurs et les plateformes d'orchestration sont la norme. À mesure que les charges de travail passent des hôtes de longue durée aux conteneurs éphémères, les techniques des attaquants évoluent également. L'activité qui laissait autrefois des artefacts persistants sur le disque est de plus en plus confinée à des comportements de courte durée et d'exécution qui peuvent être difficiles à capturer à l'aide des sources de journaux traditionnelles.

Dans ces environnements, l'ingénierie de la détection dépend donc fortement de la visibilité de l'exécution. Il est plus important de comprendre comment les processus s'exécutent dans les conteneurs, comment les fichiers sont accessibles et comment les charges de travail interagissent avec l'hôte que de se fier à des indicateurs statiques ou à des artefacts postérieurs à l'incident.

Elastic fournit plusieurs sources de télémétrie axées sur Linux pour soutenir ce type de travail de détection. Dans les articles précédents de cette série, nous nous sommes concentrés sur la visibilité au niveau de l'hôte à l'aide d'Auditd et d'Auditd Manager, en montrant comment les événements système de bas niveau peuvent être traduits en détections de haute fidélité. Dans ce billet, l'accent est mis sur Defend for Containers d'Elastic : une intégration de sécurité d'exécution conçue spécifiquement pour les charges de travail Linux conteneurisées.

Le but de cet article n'est pas de documenter toutes les fonctionnalités de Defend for Containers, mais de fournir un point de départ pratique pour les ingénieurs de détection : quelles données l'intégration produit et comment raisonner sur ces données. Dans la partie suivante, nous verrons comment il peut être appliqué à des scénarios réalistes d'attaques de conteneurs.

Visibilité rationalisée avec Defend for Containers

Nous sommes heureux d'annoncer l'arrivée de Defend for Containers dans la version 9.3.0. de la libération. Cette intégration apporte une approche rationalisée de la sécurité des conteneurs, offrant une base solide pour la visibilité dans les infrastructures cloud-natives. Les utilisateurs peuvent exploiter une suite de règles de détection adaptées pour se défendre contre les menaces modernes de Kubernetes et les vulnérabilités spécifiques aux conteneurs. L'arrivée de Defend for Containers s'accompagne d'un ensemble de règles de détection spécifiques aux conteneurs, conçues autour de modèles de menaces réalistes pour les conteneurs et Kubernetes.

Au moment de la rédaction de ce document, l'ensemble de règles Defend for Containers fournit une couverture de base pour les techniques d'attaque courantes des conteneurs, y compris les activités de reconnaissance, les tentatives d'accès aux informations d'identification, les attaques par kubelet, l'abus de jetons de comptes de service, l'exécution de processus interactifs, la création et la modification de fichiers, l'abus d'interprètes, l'exécution de charges utiles codées, l'installation d'outils, le comportement de tunnelisation et plusieurs vecteurs d'escalade des privilèges. Il est important de noter que toutes les règles de détection existantes spécifiques aux conteneurs et à Kubernetes ont été rendues compatibles avec Defend for Containers, ce qui permet à la logique précédemment centrée sur l'hôte d'opérer directement sur la télémétrie d'exécution des conteneurs.

Cela fait de Defend for Containers une source de données pratique et immédiatement utilisable pour les ingénieurs de détection Linux qui se concentrent sur la détection d'exécution basée sur le comportement. Le reste de cet article se concentre sur l'aspect pratique de cette télémétrie et sur la manière dont elle peut être appliquée à des scénarios d'attaque de conteneurs réels.

Introduction à Defend pour les conteneurs

Defend for Containers est une intégration de sécurité d'exécution qui offre une visibilité sur les conteneurs Linux lors de leur exécution. Au lieu de s'appuyer sur l'analyse d'images statiques ou de journaux d'exécution, il se concentre sur l'observation du comportement des conteneurs en temps réel.

À un niveau élevé, Defend for Containers capture les événements d'exécution pertinents pour la sécurité à partir des conteneurs en cours d'exécution, tels que l'exécution des processus et l'accès aux fichiers. Ces événements sont enrichis par le contexte du conteneur et de l'orchestration et envoyés à Elasticsearch, où ils peuvent être analysés et utilisés comme entrée pour les règles de détection.

Du point de vue de l'ingénierie de détection, Defend for Containers se situe à l'intersection du comportement traditionnel de Linux et du contexte des conteneurs. Les processus, les appels de service et l'activité des fichiers restent des signaux essentiels, mais ils sont désormais liés à des conteneurs, à des espaces de noms et à des charges de travail qui peuvent n'exister que brièvement.

Defend for Containers est déployé dans le cadre de l'agent Elastic et s'intègre directement à Elastic Security. Une fois activé, il fournit un flux dédié d'événements d'exécution de conteneurs qui peuvent être interrogés à l'aide de KQL ou ES|QL, ou consommés directement par les analyses de détection. Cela permet aux ingénieurs de détection d'appliquer des techniques d'analyse familières tout en tenant compte des réalités opérationnelles des charges de travail natives du cloud.

Dans les sections suivantes, nous examinerons les événements Defend for Containers plus en détail et nous parcourrons plusieurs scénarios d'attaques de conteneurs pour illustrer comment ces données peuvent être utilisées dans la pratique.

Configuration de la défense des conteneurs

Avant de pouvoir profiter de la visibilité et de l'analyse de l'exécution de Defend for Containers, vous devez déployer l'intégration et configurer une politique qui définit les événements à observer et les actions à entreprendre lorsque des activités correspondantes sont rencontrées. Pour plus d'informations sur l'intégration et sa mise en place, cliquez ici. À un niveau élevé, ce dispositif comprend les éléments suivants

1. Déployer l'intégration Defend for Containers via Elastic Agent dans votre environnement Kubernetes.
2. Configurer ou personnaliser la stratégie Defend for Containers, qui consiste en des sélecteurs définissant les opérations à comparer et des réponses définissant les actions à entreprendre.
3. Valider et affiner la politique en fonction du comportement observé de la charge de travail.

Méthodes de déploiement

Defend for Containers est livré en tant qu'intégration d'Elastic Agent et s'appuie sur Elastic Agent pour collecter et transmettre la télémétrie d'exécution des conteneurs dans votre pile Elastic. Pour les charges de travail Kubernetes, vous installez l'intégration via l'interface utilisateur Elastic Security, puis vous inscrivez des agents sur vos nœuds de cluster.

Le flux de déploiement de base est le suivant :

Dans l'interface utilisateur d'Elastic Security, accédez à Fleet et créez une nouvelle politique d'agent (ou ajoutez l'intégration à une politique existante). Une fois la politique d'agent créée, nous pouvons ajouter l'intégration "Defend for Containers" à la politique.

Donnez un nom à l'intégration et adaptez éventuellement les sélecteurs et les réponses par défaut (nous examinerons les options disponibles plus loin dans cette publication). Une fois que vous avez sélectionné "Ajouter une intégration", une nouvelle politique des agents avec l'intégration correcte devrait être disponible.

Pour cette démonstration, nous nous appuierons sur la méthode de déploiement Kubernetes. Pour déployer cette politique dans une charge de travail, nous pouvons naviguer vers Actions → Ajouter un agent → Kubernetes. Ici, nous voyons des instructions pour copier ou télécharger le manifeste Kubernetes.

Une note importante à prendre en compte est : "Notez que le manifeste suivant contient des limites de ressources qui peuvent ne pas être appropriées pour un environnement de production. Consultez notre guide sur la mise à l'échelle d'Elastic Agent sur Kubernetes avant de déployer ce manifeste."

Pour que le service fonctionne, vous devez inclure le site capabilities sous securityContext dans votre YAML Kubernetes :

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

Après avoir copié ou téléchargé le manifeste elastic-agent-managed-kubernetes.yml fourni, vous pouvez le modifier si nécessaire et l'appliquer avec :

kubectl apply -f elastic-agent-managed-kubernetes.yml

Comme indiqué également dans le manifeste, consultez le guide "Run Elastic Agent on Kubernetes managed by Fleet" pour plus d'informations sur le déploiement.

Attendez que les pods de l'agent Elastic soient planifiés et que les données commencent à affluer dans Elasticsearch.

Une fois déployé, Elastic Agent établira une connexion avec Fleet, s'inscrira dans la politique sélectionnée et commencera à émettre des données télémétriques Defend for Containers qu'Elastic Security pourra utiliser.

Dans la section suivante, nous examinerons les options de configuration de l'intégration et explorerons les fonctionnalités disponibles.

Défendre les politiques relatives aux conteneurs

La politique est au cœur de la configuration de Defend for Containers. Les politiques déterminent les activités à observer et la manière de réagir lorsque des événements correspondants se produisent. Les politiques sont composées de deux éléments fondamentaux :

• Sélecteurs : définissent les événements intéressants en spécifiant des opérations et des conditions ;
• Réponses : définissent les actions à entreprendre lorsque les conditions d'un sélecteur sont remplies.

Les politiques Defend for Containers peuvent être éditées avant le déploiement ou modifiées après le déploiement via l'éditeur de politiques de l'interface utilisateur Elastic Security.

Structure de la politique

Chaque politique doit contenir au moins un sélecteur et au moins une réponse. Un sélecteur typique spécifie une ou plusieurs opérations (telles que des événements de processus ou des activités de fichiers) et utilise des conditions (telles que le nom de l'image du conteneur, l'espace de noms ou l'étiquette du pod) pour restreindre le champ d'application. Les réponses font référence à des sélecteurs et indiquent l'action à entreprendre lorsque les événements correspondent.

La politique Defend for Containers par défaut comprend deux paires sélecteur-réponse : "Threat Detection" et "Drift Detection & Prevention".

Détection des menaces : Un site selector nommé allProcesses correspond à tous les événements fork et exec provenant de conteneurs.

L'action de l'adresse response est définie sur Log, ce qui garantit que les événements sont pris en compte et peuvent être analysés.

Détection des dérives & prévention : Un sélecteur nommé executableChanges correspond aux opérations createExecutable et modifyExecutable.

La réponse est configurée pour créer des alertes (et peut être modifiée pour bloquer ces opérations).

Elles peuvent être modifiées via l'interface utilisateur, mais sous le capot, ces politiques sont de simples fichiers de configuration YAML qui peuvent être facilement modifiés et utilisés dans n'importe quel flux CI|CD :

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

Ensuite, nous examinerons quelques exemples de sélecteurs et de réponses et nous discuterons des options dont vous disposez pour configurer l'intégration à votre convenance.

Exemple d'extrait de sélecteur

Les sélecteurs permettent une correspondance fine en utilisant des conditions sur des champs tels que

• containerImageFullNameLes noms d'images complets comme docker.io/nginx;
• containerImageName: noms d'images partielles ;
• containerImageTag: balises spécifiques telles que latest ;
• kubernetesClusterId: ID des clusters Kubernetes ;
• kubernetesClusterName: Noms des clusters Kubernetes ;
• kubernetesNamespaceLes espaces de noms dans lesquels la charge de travail s'exécute ;
• kubernetesPodNamenoms de pods, avec prise en charge des caractères génériques de fin ;
• kubernetesPodLabel: paires clé/valeur d'étiquettes, avec prise en charge des caractères génériques.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

Dans cet exemple, le sélecteur nommé nodeExports correspond aux événements de fichiers qui créent ou modifient des exécutables dans les conteneurs dont les noms d'image contiennent "nginx" et dont l'espace de noms Kubernetes commence par “prod-”.

Exemple de réponse

Les réponses déterminent ce qui se passe lorsque les conditions du sélecteur sont remplies. Les actions les plus courantes sont les suivantes :

• logLe système de télémétrie : envoie l'événement en tant que télémétrie à des fins d'analyse ;
• alertCréer une alerte dans Elastic Security : créer une alerte dans Elastic Security ;
• block: empêcher l'opération (pour les types pris en charge).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

Ici, la réponse nommée alertAndBlockNodeExports fait référence au sélecteur nodeExports défini précédemment et va à la fois générer une alerte et bloquer l'opération.

Jokers et correspondance

Les sélecteurs de Defend for Containers prennent en charge les caractères génériques de fin dans les conditions basées sur des chaînes (telles que les noms de pods ou les balises d'images). Cela permet d'obtenir une large correspondance sans avoir à énumérer toutes les valeurs possibles. Par exemple, un sélecteur de pods de backend-* correspondra à tous les pods dont le nom commence par backend-, tandis qu'une condition d'étiquette telle que role:api* correspondra aux valeurs d'étiquette qui commencent par api.

Cette fonction est essentielle dans les environnements dynamiques où les charges de travail évoluent et changent rapidement.

En plus de la simple correspondance de chaînes, les sélecteurs de Defend for Containers prennent également en charge la sémantique des caractères génériques basés sur les chemins d'accès lors de la correspondance des chemins de fichiers. Considérez l'exemple de sélecteur suivant :

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

Dans l'exemple utilisé pour cet article :

• /usr/bin/echo ne correspond qu'au binaire echo qui se trouve à ce chemin d'accès exact.
• /usr/sbin/* correspond à tout ce qui est un enfant direct de /usr/sbin.
• /usr/local/** correspond à tout ce qui se trouve récursivement sous /usr/local, y compris les chemins tels que /usr/local/bin/something.

Ces distinctions permettent de délimiter avec précision les sélecteurs basés sur les fichiers, en équilibrant la couverture et le bruit. En pratique, elles permettent aux ingénieurs de détection de cibler des binaires spécifiques, des répertoires entiers ou des arborescences de répertoires profondes, en fonction du cas d'utilisation, sans avoir recours à des règles trop permissives.

Le lien entre les deux

Jusqu'à présent, nous avons examiné les sélecteurs Defend for Containers, la sémantique des caractères génériques, les types d'événements et la façon dont ils font apparaître le comportement des attaquants au moment de l'exécution. La dernière étape consiste à comprendre comment ces éléments s'assemblent au sein d'une politique pour exprimer une véritable logique de détection.

Considérez le fragment de politique suivant :

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

Cette politique définit trois sélecteurs. Deux sélecteurs (binDirExeMods et etcFileChanges) décrivent l'activité du système de fichiers qui nous intéresse, tandis que le troisième sélecteur (nginx) décrit un contexte de conteneur à exclure.

La section réponse relie ces sélecteurs entre eux. Les sélecteurs énumérés sous match sont logiquement OR'd, ce qui signifie que l'une ou l'autre condition suffit à déclencher la réponse. Le sélecteur répertorié sous exclude agit comme un NOT logique, en supprimant les événements correspondants lorsque l'image du conteneur est nginx.

Lue en langage clair, la politique exprime la logique suivante :

Si un exécutable est créé ou modifié n'importe où sous /usr/bin, ou si un fichier est créé, modifié ou supprimé sous /etc, et que l'activité ne provient pas d'un conteneur nginx, générez une alerte et bloquez l'action.

Sous forme booléenne, cela peut s'exprimer comme suit :

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

C'est là que les politiques Defend for Containers deviennent puissantes. Plutôt que d'écrire une logique de détection complexe dans un langage de requête, les sélecteurs vous permettent de décomposer le comportement en petits éléments réutilisables, puis de les combiner de manière déclarative. En combinant les sélecteurs basés sur les chemins, les types d'opérations, le contexte du conteneur et les exclusions, vous pouvez exprimer une logique de détection nuancée qui reste lisible et facile à maintenir.

Dans la pratique, ce modèle permet aux ingénieurs de détection de traduire les hypothèses de menace directement en logique de politique : quel comportement est important, où il se produit, dans quelles charges de travail, et ce qui doit se produire lorsqu'il se produit.

Validation et affinement de la politique

Une fois qu'une politique est déployée, il est essentiel de la valider par rapport au comportement réel de la charge de travail avant d'activer des réponses agressives telles que le blocage. Les politiques trop restrictives peuvent perturber le fonctionnement normal des conteneurs ; les politiques trop permissives peuvent permettre à des activités indésirables de passer inaperçues.

Le flux de travail recommandé est le suivant :

1. Déployez la politique par défaut en mode surveillance (par exemple, avec des sélecteurs enregistrant les événements).
2. Observez les événements qui apparaissent dans Elasticsearch pour comprendre les modèles de charge de travail normaux.
3. Renforcez progressivement les sélecteurs et les réponses, en passant du journal uniquement → alerte → bloc, en effectuant des tests à chaque étape.
4. Utilisez un cluster de test pour valider les comportements de blocage avant de les appliquer en production.

Limites de la version bêta de Defend for Containers

A l'heure où nous écrivons ces lignes, Defend for Containers est disponible en tant qu'intégration Beta, et ses capacités actuelles ainsi que la prise en charge de la plateforme reflètent ce statut.

Defend for Containers supporte officiellement Amazon EKS et Google GKE. Bien que l'intégration puisse être déployée sur Azure AKS, cette configuration n'est pas officiellement prise en charge. En particulier, les déploiements d'AKS manquent actuellement de télémétrie des événements de fichiers, ce qui limite la couverture de détection des techniques d'attaque basées sur les fichiers dans ces environnements.

La version actuelle de Beta ne capture pas non plus les événements du réseau. Par conséquent, les détections liées aux connexions sortantes, aux mouvements latéraux du réseau ou à l'exfiltration de données doivent s'appuyer sur des sources de données complémentaires, telles que l'intégration Network Packet Capture ou Packetbeat, plutôt que sur la seule télémétrie de Defend for Containers.

Pour l'activité des fichiers, Defend for Containers enregistre intentionnellement les événements d'ouverture de fichiers uniquement lorsqu'ils sont ouverts avec une intention d'écriture. Ce choix de conception réduit le bruit et se concentre sur le comportement qui modifie l'état du système. Cependant, cela signifie également que l'accès en lecture seule aux fichiers sensibles, tel que la découverte de secrets, le grattage de configuration ou les tentatives d'accès infructueuses, n'est pas observable actuellement.

Cette limitation a une incidence sur les cas d'utilisation de la détection tels que

• Recherche et lecture des jetons de compte de service Kubernetes,
• Recherche de fichiers ou de documents d'identification sur le site .env.

Ce sont des domaines dans lesquels les futures itérations de Defend for Containers pourront fournir une télémétrie plus granulaire pour prendre en charge les cas d'utilisation de l'ingénierie de détection avancée.

Activation des règles de détection préconstruites de Defend for Containers

Defend for Containers est livré avec un ensemble de règles de détection prédéfinies qui fournissent une couverture de base pour les techniques d'attaque de conteneurs les plus courantes. Une fois l'intégration activée, ces règles peuvent être activées directement à partir d'Elastic Security sans configuration supplémentaire.

L'activation des règles prédéfinies est recommandée comme point de départ, car elles sont conçues pour s'aligner sur la télémétrie d'exécution de Defend for Containers et couvrent l'exécution, la modification de fichiers, la persistance et le comportement post-compromis à l'intérieur des conteneurs. À partir de là, les règles peuvent être étendues ou affinées pour correspondre aux charges de travail et aux modèles de menace spécifiques à l'environnement.

En filtrant pour "Data Source : Elastic Defend for Containers", vous pouvez trouver toutes les règles associées à cette intégration.

Remarque : si aucune règle ne s'affiche, assurez-vous que votre pile fonctionne avec la version 9.3.0, car ces règles ne sont déployées que sur la version 9.3.0+.

Avec toutes les limitations Beta importantes cartographiées, l'intégration déployée, les règles de détection préconstruites installées et activées, et une politique opérationnelle en place, l'étape suivante consiste à explorer la sémantique des événements que Defend for Containers produit, y compris les champs couramment utilisés dans la logique de détection, les considérations de performance, et la façon dont ces événements diffèrent des événements Elastic Defend.

Analyse des événements de Defend for Containers

Maintenant que Defend for Containers est déployé et que les politiques sont en place, l'étape suivante consiste à comprendre les événements qu'il génère. Comme pour Elastic Defend ou Auditd Manager, la télémétrie de Defend for Containers devient beaucoup plus précieuse une fois que vous avez développé un modèle mental de la façon dont les événements sont structurés et quels champs sont les plus pertinents pour l'ingénierie de la détection.

Defend for Containers produit plusieurs types d'événements, notamment des événements de processus et de fichiers, chacun enrichi du contexte du conteneur, de l'hôte et de l'orchestration. Si les signaux sous-jacents restent ancrés dans le comportement Linux, les métadonnées supplémentaires de Kubernetes et des conteneurs vous permettent de raisonner sur l'activité d'une manière qui n'est pas possible avec la télémétrie de l'hôte uniquement.

Les sections suivantes passent en revue les groupes de champs et les types d'événements les plus importants, en utilisant des événements Defend for Containers réels comme points de référence.

Domaines communs

Avant de plonger dans les catégories d'événements spécifiques, il est utile de comprendre les champs qui apparaissent systématiquement dans la télémétrie de Defend for Containers. Ces champs fournissent la colle contextuelle qui relie les actions individuelles d'exécution aux politiques, aux sélecteurs et aux points d'exécution sous-jacents à l'intérieur du noyau.

Bien que les événements de processus et de fichiers diffèrent dans leurs détails, les champs décrits ci-dessous sont présents dans les flux de données de Defend for Containers et sont souvent le premier endroit à regarder lors de la validation des détections ou du dépannage du comportement de la politique.

Défendre le contexte spécifique aux conteneurs

Defend for Containers ajoute plusieurs champs spécifiques à la collecte des événements et à l'application des politiques.

Le champ cloud_defend.hook_point indique à quel endroit du noyau l'événement a été capturé. Dans l'exemple présenté, des valeurs telles que tracepoint__sched_process_fork et tracepoint__sched_process_exec révèlent que l'événement a été généré par des tracepoints du noyau associés à la création et à l'exécution de processus.

Le champ cloud_defend.matched_selectors indique les sélecteurs de la politique active qui correspondent à l'événement. Dans l'exemple, la valeur allProcesses indique que cet événement correspond à un sélecteur large qui capture toutes les activités du processus. Lors de l'élaboration de politiques ou de l'examen d'alertes, ce champ est essentiel pour comprendre pourquoi un événement a été capturé.

Les champs cloud_defend.package_policy_id et cloud_defend.package_policy_revision permettent de relier l'événement à une politique spécifique d'Elastic Agent et à sa révision. Il est ainsi possible d'établir une corrélation entre les événements et les changements de configuration au fil du temps et de vérifier quelle version d'une politique était active lorsque l'événement s'est produit.

Métadonnées de l'événement

Les événements Defend for Containers suivent les conventions Elastic Common Schema et incluent des métadonnées d'événement standard qui décrivent le type et le cycle de vie de l'activité.

Le champ event.category identifie le type d'activité de haut niveau, tel que process ou file, et est généralement le premier champ utilisé lors du filtrage des données de Defend for Containers. Le champ event.action décrit ce qui s'est produit, par exemple fork ou exec pour l'activité d'un processus, ou open, creation, modification, et deletion pour les événements liés à un fichier.

Le champ event.type ajoute le contexte du cycle de vie, tel que start pour l'exécution du processus, et est souvent utilisé avec event.action pour distinguer les différentes phases de l'activité. Le champ event.dataset indique le flux de données Defend for Containers d'origine, tel que cloud_defend.process, ce qui est utile lors de l'élaboration de requêtes ou de détections portant sur des ensembles de données.

Les champs de métadonnées supplémentaires tels que event.id, event.ingested et event.kind sont principalement utilisés pour la corrélation, l'ordonnancement et le dépannage plutôt que pour la logique de détection.

Informations de l’hôte

Les événements Defend for Containers incluent le contexte complet de l'hôte, comme Elastic Defend et Auditd Manager. Cela permet de corréler l'activité d'exécution des conteneurs avec le nœud Kubernetes sous-jacent.

Le champ host.name identifie le nœud sur lequel le conteneur est exécuté, tandis que host.os.* fournit des détails sur le système d'exploitation, tels que la distribution et la version du noyau. Le champ host.architecture indique l'architecture du processeur, ce qui peut être utile lors de l'analyse de l'exécution binaire ou du comportement spécifique du noyau.

Un champ particulièrement utile est host.pid_ns_ino, qui identifie l'espace de noms PID. Ce champ permet de corréler l'activité des conteneurs avec la télémétrie des processus et du noyau au niveau de l'hôte. Il est particulièrement utile pour enquêter sur les tentatives d'évasion des conteneurs ou sur l'impact au niveau des nœuds.

Le contexte de l'hôte est essentiel lors de l'analyse des attaques natives du nuage, car plusieurs conteneurs partagent souvent le même hôte et le même noyau, et le comportement d'exécution d'un conteneur peut avoir des implications au-delà de ses limites.

Contexte du conteneur et de l'orchestrateur

La principale force de Defend for Containers réside dans sa connaissance des conteneurs. Chaque événement d'exécution est enrichi de métadonnées de conteneur et d'orchestration, ce qui permet d'analyser l'activité dans le contexte de ce qui s'exécute, où il s'exécute et avec quels privilèges.

Au niveau du conteneur, des champs tels que container.id et container.name identifient de manière unique le conteneur en cours d'exécution, tandis que container.image.name, container.image.tag et le hachage de l'image permettent de connaître l'origine et la version de la charge de travail. Ceci est particulièrement utile pour faire la distinction entre les images utilitaires attendues et les charges de travail inattendues ou ad hoc.

L'un des domaines clés de l'évaluation des risques est container.security_context.privileged. Ce champ indique explicitement si un conteneur fonctionne en mode privilégié. Lorsque l'exécution privilégiée est combinée à d'autres signaux tels que des shells interactifs ou des capacités Linux étendues, le profil de risque de toute activité détectée augmente considérablement.

Defend for Containers enrichit également les événements avec un contexte d'orchestration. Des champs tels que orchestrator.cluster.name, orchestrator.namespace, et orchestrator.resource.name (généralement le nom du pod) relient le comportement d'exécution aux charges de travail Kubernetes. Les étiquettes exposées via orchestrator.resource.label permettent en outre aux détections d'intégrer l'intention et la propriété de la charge de travail.

Pour l'ingénierie de la détection, ce contexte permet de délimiter précisément le champ d'application des détections :

• des espaces de noms spécifiques (par exemple, kube-system),
• les conteneurs privilégiés ou à haut risque,
• les charges de travail avec des étiquettes sensibles,
• ou des images utilitaires connues telles que netshoot, kubectl, ou curl.

Cette couche d'enrichissement permet d'exprimer directement la logique de détection des conteneurs, sans avoir à déduire indirectement l'intention à partir des chemins d'accès au système de fichiers, des cgroups ou des identifiants d'espace de noms.

Événements du processus

L'exécution du processus est l'un des types de signaux les plus importants fournis par Defend for Containers. Les événements de processus capturent les activités fork, exec, et end dans les conteneurs et exposent des informations détaillées sur le cheminement, essentielles pour comprendre comment l'exécution se déroule au moment de l'exécution.

Plusieurs domaines sont particulièrement importants pour l'ingénierie de la détection. La combinaison de process.name et process.executable permet d'identifier ce qui a été exécuté et à partir de quel endroit, tandis que process.args permet de savoir comment cela a été invoqué. Les champs tels que process.pid, process.start, process.end et process.exit_code décrivent le cycle de vie du processus et sont utiles pour l'analyse du temps et la reconstruction du flux d'exécution. Le site process.entity_id fournit un identifiant stable qui permet de suivre les processus dans le cadre de plusieurs événements connexes.

Defend for Containers capture également de riches informations sur les ancêtres. Les champs sous process.parent.* décrivent le processus parent immédiat, ce qui permet de détecter des relations parent-enfant suspectes, telles que des shells créés par des binaires inattendus. En outre, les sites process.entry_leader.* et process.session_leader.* fournissent des points d'ancrage de plus haut niveau dans l'arbre de processus.

Tout comme Elastic Defend, Defend for Containers modélise les processus comme un graphe plutôt que comme des événements isolés. Le leader d'entrée est particulièrement utile dans les environnements de conteneurs, car il représente souvent le processus initial lancé par l'exécution du conteneur (par exemple, containerd, runc, ou un shell spécifié comme point d'entrée du conteneur). L'ancrage des détections au leader d'entrée permet d'interpréter les arbres de processus de manière cohérente, même lorsque les conteneurs génèrent de nombreux processus enfants de courte durée.

Les champs de l'en-tête de session fournissent un contexte supplémentaire sur l'exécution interactive et les limites de la session, ce qui permet de distinguer les services d'arrière-plan des activités interactives ou menées par des attaquants.

Ensemble, ces champs permettent d'exprimer une logique de détection qui va au-delà des exécutions individuelles et qui raisonne plutôt sur les chaînes d'exécution, le lignage et l'intention, ce qui est essentiel pour détecter les techniques d'attaque des conteneurs dans le monde réel.

Capacités et contexte des privilèges

L'un des aspects les plus puissants des événements du processus Defend for Containers est l'inclusion d'informations sur les capacités de Linux. Pour chaque processus, Defend for Containers expose les ensembles de capacités effectives et autorisées via :

• process.thread.capabilities.effective
• process.thread.capabilities.permitted

Ces champs décrivent ce qu'un processus est réellement autorisé à faire au moment de l'exécution, indépendamment de son ID utilisateur ou de la limite du conteneur.

Dans les conteneurs privilégiés, les processus exposent souvent un large éventail de capacités effectives, y compris des capacités très sensibles telles que CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO et CAP_BPF. La présence de ces capacités modifie considérablement le profil de risque de toute commande exécutée, car elles permettent des actions qui peuvent avoir un impact direct sur le noyau de l'hôte ou sur d'autres charges de travail.

Du point de vue de l'ingénierie de la détection, ce contexte est essentiel. Il permet aux détections d'aller au-delà de la simple correspondance nom-processus et de raisonner en termes d'impact. La même exécution binaire peut avoir des conséquences très différentes selon qu'elle s'exécute avec un ensemble de capacités minimales ou avec des privilèges proches de ceux de l'hôte.

En pratique, les données de capacité permettent aux ingénieurs de détection de.. :

• Identifier les outils suspects exécutés dans des conteneurs trop permissifs.
• Établir une corrélation entre le comportement en cours d'exécution et les combinaisons de capacités dangereuses.
• Hiérarchisez les alertes en fonction du potentiel d'exploitation réel plutôt que de l'activité de surface.

Cela est particulièrement important pour la recherche sur l'évasion de conteneurs, où la présence ou l'absence de capacités spécifiques détermine souvent la viabilité d'un exploit.

Exécution interactive

Le champ process.interactive indique si un processus est associé à une session interactive. Dans les environnements de conteneurs, l'exécution interactive est relativement rare pour les charges de travail de production et correspond souvent à une activité post-compromission ou à une activité au clavier.

Defend for Containers expose l'interactivité non seulement au niveau du processus, mais aussi à travers les contextes d'exécution connexes, y compris process.parent.interactive, process.entry_leader.interactive, et process.session_leader.interactive. Il est ainsi possible de déterminer si une chaîne d'exécution entière est interactive, plutôt que de se fier à un seul indicateur de processus pris isolément.

Parmi les exemples courants d'exécution interactive dans des conteneurs, on peut citer la création d'un shell bash ou sh, l'exécution d'utilitaires interactifs tels que curl, kubectl ou busybox, ou la reconnaissance par l'opérateur d'un Pod compromis. Si ces actions peuvent être légitimes lors du débogage, elles sont peu courantes dans les charges de travail de production stables.

Combinée à l'image du conteneur, à l'espace de noms et au contexte des privilèges, l'exécution interactive devient un signal d'anomalie fort. Il permet à la logique de détection de faire la distinction entre le comportement automatisé attendu d'un conteneur et l'activité qui correspond davantage à une intervention manuelle ou à une exploration menée par un attaquant.

Événements liés aux dossiers

Les événements de fichiers Defend for Containers capturent l'activité du système de fichiers à l'intérieur des conteneurs, et sont émis pour une variété d'opérations. Contrairement à la surveillance traditionnelle de l'intégrité des fichiers, ces événements sont sensibles au temps d'exécution et adaptés aux charges de travail des conteneurs, ce qui permet de savoir comment et pourquoi les fichiers sont modifiés.

Defend for Containers peut détecter l'activité des fichiers tels que les ouvertures de fichiers avec intention d'écriture, les modifications de contenu, les créations de fichiers, les renommages, les changements d'autorisation et les suppressions. En se concentrant sur les opérations d'écriture, Defend for Containers met l'accent sur les comportements qui modifient l'état du système plutôt que sur l'accès passif aux fichiers.

Cela permet aux ingénieurs de détection de raisonner sur les schémas d'utilisation des fichiers au moment de l'exécution, et pas seulement sur le résultat d'une modification.

Plusieurs champs sont particulièrement importants lors de l'élaboration de détections basées sur des fichiers. Les champs file.path et file.name identifient le fichier concerné et son emplacement, tandis que le champ file.extension permet de distinguer les fichiers binaires, les scripts et les fichiers de configuration. Les champs event.action et event.type décrivent l'opération qui s'est produite et la manière dont elle doit être interprétée dans le cycle de vie de l'événement.

Ensemble, ces champs permettent à Defend for Containers de distinguer les accès bénins aux fichiers des schémas de modification suspects, tels que l'écriture de binaires ou la modification des autorisations dans des répertoires sensibles.

La mise en commun

Comme pour toute autre source de données, la télémétrie de Defend for Containers devient vraiment précieuse une fois que vous comprenez comment combiner les champs dans les domaines du processus, du fichier, du conteneur et de l'orchestration. Plutôt que de s'appuyer sur des indicateurs statiques, Defend for Containers permet une ingénierie de détection basée sur le comportement d'exécution, le contexte des privilèges et l'identité de la charge de travail.

Conclusion

Défendre les conteneurs dans Elastic Stack 9.3.0 inclut la détection de l'exécution des conteneurs en tant que composante essentielle de l'ingénierie de détection de Linux. Il se caractérise par une portée claire, un modèle de configuration axé sur les politiques et une télémétrie d'exécution conçue spécifiquement pour les charges de travail conteneurisées.

Dans cet article, nous avons examiné comment déployer Defend for Containers, comment son modèle de politique est structuré, et comment les événements d'exécution sont générés et enrichis avec le contexte du conteneur et de l'orchestration. Nous avons étudié la structure des événements relatifs aux processus et aux fichiers, les métadonnées de capacité, les signaux d'exécution interactive et les champs spécifiques aux conteneurs qui permettent d'exprimer les détections d'une manière adaptée à la charge de travail.

Il en ressort qu'une détection efficace des conteneurs nécessite un raisonnement sur le comportement de l'exécution dans son contexte : les processus, les modifications de fichiers, les privilèges et l'identité de la charge de travail doivent être évalués ensemble. Defend for Containers fournit la télémétrie nécessaire pour rendre cela possible.

Dans le prochain article, nous nous appuierons sur cette base en parcourant un scénario réaliste d'attaque de conteneurs et en démontrant comment la télémétrie de Defend for Containers couvre chaque étape de la compromission dans la pratique.