Bonjour à toi moussaillon ! Nous voici déjà à la quatrième étape de notre aventure ensemble !
Si tu arrives par hasard sur ce guide ou que tu souhaites relire les précédents chapitres de notre épopée, n’hésite pas à consulter les liens suivants :
- Sécurité et conteneurs – Introduction
- Sécurité et conteneurs – Comment éviter le suply chain poisonning ?
- Sécurité et conteneurs – Technique d’analyse et de patch de CVE
Trois, deux, un … c’est parti !
Aujourd’hui nous verrons ensemble comment faire des détections sur des éléments conteneurisés en cours d’exécution. En effet, c’est un point qu’il arrive de négliger ou d’oublier pour les conteneurs, mais sans une véritable solution de monitoring, il est difficile de parler de sécurité.
Dans notre cas de figure, nous allons traiter de la détection de comportement suspect sur des conteneurs en cours d’exécution.
Voici un petit scénario de mise en bouche :
« L’équipe dans laquelle tu interviens s’est mise assez récemment aux technologies de conteneurisation et d’orchestration. Tu te rends compte qu’il y a une mise en place de pratiques DevOps, avec une prise en compte des aspects sécu (scan de code, scan d’images …). Seulement, quand tu poses la question de la détection d’intrusion ou de comportement suspect sur la partie runtime … personne ne te répond ! Comment détecter ce type d’évènement ? »
C’est à cette notion de RASP (Runtime Application Security Protection), que nous allons aborder au cours des prochaines lignes.
Il existe de nombreux outils pour répondre à ce besoin (la plupart sous licence payante), mais un projet open source et gratuit subsiste : Falco de Sysdig. C’est cet outil que nous allons utiliser pour qu’une majorité puisse nous suivre tout au long de cet article.
Je t’invite à suivre les manipulations de cet article pas à pas pour mettre en pratique les notions que nous développerons au fil de notre voyage (c’est toujours plus parlant en manipulant).
Comment ça marche cette magie ?
Commençons par le principe de fonctionnement de Falco ainsi que ce qui est détecté.
Cet outil détecte tout simplement les appels système Linux qui sont effectués. Cette détection est couplée à un nombre de règles (que l’on peut éditer) permettant la détection d’évènement suspect au sein du système. Je précise bien du système, car il possible d’utiliser Falco sur une machine Linux classique et faire les mêmes détections.
Mise en place de l’environnement
Les opérations suivantes ont été réalisées sur une machine virtuelle Ubuntu 20.04 (il va vous falloir 4vCPU et 8 Go de RAM pour être à l’aise).
Mise en place du cluster
Une fois sur ta machine, ouvre un terminal pour y saisir les commandes :
sudo apt-get update -y && sudo apt-get upgrade -y sudo snap install microk8s --classic sudo microk8s.status --wait-ready
Il faut maintenant s’assurer que les éléments que nous allons utiliser seront disponibles :
sudo microk8s.enable dashboard dns helm helm3
Mise en place de Falco
Il va falloir dans un premier temps mettre en place Falco sur la machine (le guide officiel est disponible ici).
Deux solutions dans notre cas : le déploiement manuel ou l’utilisation d’outil de déploiement facile. Nous allons utiliser la seconde option en nous servant de l’outil Helm.
Il faut donc l’installer :
sudo snap install helm --classic
Remarque : J’ai rencontré un souci lors de la création de cet article, helm ne semblait pas avoir accès au cluster. C’était dû au fait que j’effectuais ces manipulations sur VM, avec microk8s (l’adressage IP diffère). Tu rencontreras probablement le même problème, et il a été résolu en utilisant les lignes suivantes :
mkdir /home/$USER/.kube sudo microk8s.kubectl config view --raw > ~/.kube/config
Il ne reste plus qu’à ajouter Falco et à le déployer :
helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update
Charge à monitorer
Pour faire une détection, il vaut mieux avoir un élément à monitorer J
Nous allons maintenant créer un conteneur Nginx sur lequel la détection va avoir lieu :
sudo microk8s.kubectl run --image=nginx nginx
Pour vérifier que tout s’est bien déroulé, tu peux utiliser la commande :
sudo microk8s.kubectl get all
Tu devrais alors obtenir quelque chose de similaire à ceci :
Utiliser Falco
Tout est près, place à la pratique !
Détection d’un évènement
Nous allons nous intéresser à la détection d’un évènement, l’exec sur un conteneur. Dans un premier temps, nous allons vérifier les logs présents dans Falco. Il faut simplement le nom du pod associé (obtenu avec la commande sudo microk8s.kubectl get all) que tu vas utiliser dans la commande suivante (dans mon cas le pod s’appelle falco-b4kc8) :
sudo microk8s.kubectl logs pod/falco-b4kc8
Voici à quoi devrait ressembler le prompt :
Il ne reste plus qu’à faire un exec dans le conteneur nginx :
sudo microk8s.kubectl exec nginx exit
Il ne reste plus qu’à observer à nouveau les logs de Falco (sudo microk8s.kubectl logs pod/falco-b4kc8) et tu devrais obtenir un résultat similaire à celui-ci :
Et voilà nous avons un nouveau log nous prévenant qu’un shell a été lancé sur le conteneur nginx !
Lecteur : « Ah oui, tout ça pour un exec ? »
Et oui, mais nous sommes capables d’avoir des logs associés à cet évènement. De plus, cela peut sembler anodin, mais il faut éviter un maximum le ‘drift’ des conteneurs par rapport à l’image de laquelle ils sont issus. L’un des facteurs clefs de drift est l’intervention humaine sur des conteneurs en cours d’exécution (donc en passant par des exec).
Conclusion
Falco est un outil puissant, qui répond parfaitement à notre problématique : détecter des comportements sur des conteneurs en cours d’exécution. Un tel outil est un incontournable si vous avez à travailler dans les environnements conteneurisés, car c’est grâce à ce dernier que la détection de compromission peut se faire. C’est d’ailleurs pour cette raison que certains éditeurs logiciels CWPP intègrent (Sysdig le premier) ce type de détection dans leur outillage.
Tiens bon la barre moussaillon et garde le cap vers la sécurité jusqu’à notre prochaine aventure !
par Cédric PAOLI, Consultant Cybersécurité
