Podman est en train de devenir un moteur de conteneur dont on parle de plus en plus et il possède parmi ces avantages d'être Rootless. Docker travaille également sur cet ajout qui devrait bientôt sortir de son statut expérimental.

Mais dois-je m'intéresser aux containers Rootless ? En quoi est-ce réellement intéressant ?

Cet article a pour but d'expliquer le plus simplement possible, pourquoi je m'intéresse aux containers Rootless. En tout cas une des raisons !

J'espère ainsi que vous pourrez vous faire votre propre idée et décider si ce sujet mérite votre attention ( et votre précieux temps 😀 ).

Une question de sécurité ?

Il s'agit bien sûr - et avant tout - d'une question de sécurité. Bien trop longtemps, l'idée reçue qu’une utilisation des containers pouvait garantir à elle seule la sécurité d'un serveur a circulé. Alors oui, l'isolation permise par les containers permet de mitiger une attaque, mais ...

Trop souvent de mauvaises configurations, de mauvaises options dans les déploiement vont compromettre cette isolation et donc la mitigation liée à l'utilisation des containers.

Et là, ce qui devait nous protéger devient notre pire cauchemar ... en facilitant parfois l'accès à d'autres ressources de votre serveur.

À ce point ?

Une simple recherche sur shodan.io permet d'étayer un peu ces propos :

Effectuez une recherche sur les machines inventoriées et dont le port 2375 est ouvert.

Pour rappel ce port est celui par défaut de l'API Docker. Cette même API que vous contactez à l'aide de votre commande docker afin de créer, stopper ou même relancer des containers.

Ce port est également celui utilisé par défaut pour une utilisation non chiffrée et non authentifiée de l'API. Voici un bref résultat de cette recherche :

Shodan.io search port 2375

Comme vous pouvez le voir, plus de 6000 machines possèdent actuellement ce port ouvert et offrent une possibilité pour un attaquant de lancer un container.

Sans compter qu'un grand nombre de ces machines affichent très clairement une version 18.06.1 de Docker qui date de Janvier 2019. De plus la version 18.06.02 corrigeait par exemple une faille de ce type : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736

Alors oui, cela ne veut pas dire que ces 6000 serveurs sont accessibles. Mais il est important de comprendre en quoi une erreur dans la configuration de votre serveur peut rendre l'intégralité de votre système accessible à une attaque.

L'exemple de la socket Docker

Pour bien comprendre en quoi l'isolation peut-être facilement détournée. Reprenons un article que j'avais écrit il y a quelques temps :

Sécuriser l’accès à sa socket Docker...
Nous avions déjà vu ensemble comment sécuriser son daemon et son hôte Docker. Mais quand est-il de l’API disponible au travers de la socket Docker ?
Loïc FACHELa Grotte du Barbu

Nous allons revoir pourquoi vous devez protéger l'accès à la socket Docker et l'intérêt de cette protection. Mais comment l'accès à ma socket peut permettre de casser l'isolation de mon container ?

Réalisons un simple exemple !

Tout d'abord je vais créer un fichier dans mon $HOME :

touch /home/ubuntu/try_hack.txt

Et lancer un premier container :

docker run -it -d --name try_hack ubuntu:latest bash

Enfin je vais lancer un container que vous auriez pu lancer avec un accès sur la socket Docker :

docker run -it -v /var/run/docker.sock:/var/run/docker.sock debian:latest bash
Ce container héberge une application vulnérable qui a permis à un attaquant de prendre l'accès sur votre conteneur.

Alors il ne me reste plus que quelques commandes afin d’accéder à l'ensemble de vos containers et de votre système :

apt-get update && apt-get install docker.io -y

J'installe effectivement le paquet Docker de la distribution avant d'avoir un accès rapide à la CLI de Docker. Et je vais vérifier les containers en cours de démarrage :

docker ps
c4dc6c884df6        ubuntu:latest       "bash"              About a minute ago   Up 58 seconds                           try_hack
c0ab1b41706d        debian:latest       "sh"                2 minutes ago        Up 2 minutes                            interesting_curran

J'ai bien accès à vos containers ! Et en réalité je peux même en lancer des nouveaux ou en arrêter !

Mais j'ai même déjà un accès plus global à votre hôte, voyons ensemble comment.

Depuis le container compromis, je vais créer un container avec plus de privilèges :

docker run -it --name powned --privileged debian:latest bash

Enfin je regarde les disques présents :

fdisk -l

Et je vais mount celui qui me semble être le disque système :

mount /dev/sda1 /mnt/

Vérifions simplement la présence du fichier que j'ai créé au début de l'exemple :

ls /mnt/home/ubuntu/
try_hack.txt

Bien évidement pour réaliser tout ceci il est nécessaire d'obtenir un premier accès à votre container. Mais cela finira par arriver !

Le Rootless n'empêchera pas l'attaque mais en limitera forcément les conséquences !

Pourquoi ma machine pourrait-elle être la cible d'une attaque ? Pour plein de raison en réalité ...

Les types d'attaques

Je ne vais pas faire une liste exhaustive des attaques possibles. Mais juste vous rappelez quelques unes des raisons qui peuvent pousser à un piratage de vos containers :

  • crypto-monnaie : C'est sûrement l'une des attaques les plus fréquentes mais votre serveur qui ne tourne pas à plein régime est une aubaine pour miner des devises comme par exemple le Monero.
  • Scanner votre réseau, votre cluster Swarm par exemple...
  • Et ainsi compromettre plus de machines dans votre réseau !
  • Glaner des informations, accès aux applications/serveurs, récupérer des données.
  • Lancer de nouvelles attaques depuis votre serveur,
  • Création de botnet ( spam, pishing etc ).

Et oui les motivations sont nombreuses et cette liste n'est clairement pas exhaustive. Plus généralement, ces motivations sont finalement les mêmes que celle qui poussent les pirates à attaquer vos serveurs.

Mais le sentiment de sécurité provoqué par l'isolation des processus nous fait parfois baisser notre garde et va finalement faciliter le travail d'un attaquant.

Alors oui Docker pour ne citer que lui est conçu pour être sûr.

L'utilisation des namespaces pour l'isolation de certaines fonctions  ( processus, points de montage et du réseau ). Mais aussi les Cgroups pour restreindre l'accès des applications aux appels systèmes par exemple, permettent de garantir un niveau de sécurité important.

Mais personne n'est à l'abri d'une erreur, de la configuration de vos containers à l'application hébergée, les potentielles failles de sécurité peuvent être nombreuses.

Comme peut nous le rappeler également le recensement des failles liées à Docker ou des images populaires du Docker Hub :

https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=Docker&search_type=all

Certes le passage en mode Rootless n'est à lui seul pas une garantie de sécurité, mais il viendra mitiger encore plus les effets d'une potentielle faille. C'est à ce titre que je vais continuer les articles sur ce sujet !

En tout cas  n'hésitez pas à m'apporter des remarques ou des commentaires sur Twitter, ou ici 👇