Nicolas Engel

Une tendance récurrente en matière de sécurité informatique est l’emploi galvaudé de termes à la mode, qui ne recouvrent pas la même réalité pour le client ou son prestataire. Le SecOps (Security Operations) en est ici le parfait exemple. Afin de clarifier les débats dans le monde professionnel, j’ai donc souhaité reprendre mon prototype de laboratoire de pentest (penetration testing) pour l’améliorer de la façon suivante. Les principes initiaux restent inchangés, à savoir:

• Le prototype doit être hébergé sous Windows : ce système d’exploitation est de loin le plus répandu chez les clients. Pour l’emploi d’outils de sécurité tels que des scanners de vulnérabilité sous Linux, il faudra donc virtualiser un système d’exploitation Linux.
• Le prototype doit héberger des systèmes vulnérables tels que Metasploitable 2 ou encore DVWA en fonction du besoin.

Les améliorations par rapport à la première version sont les suivantes:

• Privilégier des containers Docker légers plutôt que des images Virtualbox plus lourdes
• Disposer d’outils non seulement pour les attaquants (red team) mais aussi pour les défenseurs (blue team) tout en gardant un ou plusieurs systèmes vulnérables (victime).

Quel intérêt de reprendre un sujet existant au prétexte unique d’améliorer l’existant me direz-vous ? L’enjeu ici, est moins de parler de la solution finale que de son hébergement et de ses multiples échecs associés que j’ai pu rencontrer.

Un laboratoire de Pentest aux petits oignons

Une fois n’est pas coutume, commençons par la fin.

La solution de laboratoire de pentest en local mise à disposition par Oliver Wiegers sur Github est une oeuvre d’art. Bravo à lui !

• Pour la Red team est mise à disposition une instance de Kali Linux avec ses outils en dernière version dans une image Docker
• Pour la Blue team est mise à disposition des outils de monitoring tels que Grafana pour la visualisation mais aussi Loki et Prometheus pour fournir les logs et métriques à Grafana.
• Enfin, les services vulnérables exposés sont nombreux et diversifiés (juice-shop, hackazon, tiredful-api, ninjas).

J’ai donc installé le lab sur un PC Ubuntu pour savoir si cela était aussi intéressant qu’il y paraissait.

• Installation des dépendances Ubuntu

sudo apt install docker docker-compose docker.io jq python3-pip

• Installation de la bibliothèque « yq » écrite en Python et non en Go

sudo pip3 install yq

• Génération d’une clé SSH si non existante au préalable

sudo ssh-keygen

• Clonage du répertoire et validation des dépendances satisfaites pour l’installation

$ git clone https://github.com/oliverwiegers/pentest_lab
$ cd pentest_lab
$ ./lab.sh -C

• Normalement, tous les voyants sont verts et nous pouvons procéder à l’installation du lab.

sudo ./lab.sh -u

L’installation prends beaucoup de temps notamment en raison de la mise à jour des outils de Kali Linux. Une fois le processus finalisé, les adresses IPs sont définies de manière statiques pour faciliter la connexion SSH à l’image Kali.

• Les Red team services débutent à l’IP 10.5.0.5
• Les Blue team services débutent à l’IP 10.5.0.50
• Les Victim services débutent à l’IP 10.5.0.100
• Les Monitoring services débutent à l’IP 10.5.0.200

Tout fonctionne à merveille sur une instance Linux non virtualisée. Profitez-en bien !

Une fois cette étape passée, l’idée est de déterminer comme virtualiser ce laboratoire sous Windows. C’est là où les ennuis commencent.

Les options de virtualisation et leurs limites techniques

Le prototype étant fonctionnel, je me suis mis à tester plusieurs méthodes de virtualisation.

Pour rappel, 2 architectures principales existent. Les machines virtuelles (VM) ainsi que les conteneurs tels que la solution Docker permettent de virtualiser des applicatifs sur un système hôte tel que Microsoft Windows, Linux ou MacOS.

• L’avantage de Docker étant sa légèreté car le système d’exploitation client n’est pas entièrement virtualisé comme dans une VM.
• L’avantage d’une VM est sa configurabilité en matière de ressource matérielle mais à contrario de Docker, c’est une solution plus lourde et plus gourmande en ressources.

Pour compléter ce panorama technique, attardons-nous un instant sur 2 briques techniques de virtualisation sous Windows, WSL2 et Hyper-V:

• Hyper-V, également connu sous le nom de Windows Server Virtualisation, est un système de virtualisation permettant à un serveur physique de devenir Hyperviseur et ainsi gérer et héberger des machines virtuelles.
• Windows Subsystem for Linux (WSL) est une couche de compatibilité permettant d’exécuter des exécutables binaires Linux de manière native sur Windows 10, Windows 11 et Windows Server 2019. La 2nde version de WSL, WSL2 est sortie en Mai 2019.

En résumé, Hyper-V est la brique technique permettant de faire fonctionner des machines virtuelles dans Windows. WSL2 est la brique technique permettant de faire fonctionner des conteneurs Docker. Le fait que WSL2 repose lui-même sur une partie de l’architecture d’Hyper-V pour fonctionner permet d’assaisonner ce plat de spaghetti, que constitue le monde passionnant de la virtualisation.

Les options de virtualisation du prototype d’Oliver Wiegers sont donc les suivantes:

1. L’installation d’une image Ubuntu directement dans Windows via l’usage de WSL 2
2. L’installation d’une image Ubuntu via l’éditeur Canonical et sa solution Multipass (qui utilise WSL2)
3. L’usage de Docker Desktop sous Windows reposant soit sur Hyper-V soit sur WSL2.

Concernant la première option, l’installation de l’image Ubuntu dans Windows via WSL2 s’est bien déroulée. Lancer le script d’installation est possible mais je ne suis jamais parvenu à finaliser son installation. Le script bloque systématiquement dans la mise à jour de Kali Linux sans que je ne parvienne à avoir des logs d’erreurs détaillés du problème.

Concernant la seconde option, l’utilisation de la solution Multipass de Canonical fonctionne de manière similaire à Docker. Ainsi, le lancement de l’outil en ligne de commande via Powershell sous Windows fonctionne bien (cf. l’article de Stephane Robert bien utile sur le sujet). Malheureusement, dès que j’essaye de générer une image avec une taille de disque suffisamment importante pour le prototype, la génération de l’image rentre en conflit avec Hyper-V et il m’est impossible de générer une adresse IP pour l’image.

Ma troisième et dernière option est donc l’usage de Docker Desktop avec WSL 2 pour générer une image Ubuntu comportant elle-même un Docker-compose permettant de builder le prototype. Pour que Docker-compose fonctionne, il est nécessaire de prendre une image avec SystemD installé, ce qui n’est pas le cas dans l’image par défaut d’Ubuntu fournie dans Docker.

• Lancer l’image comme un Daemon

$ docker run -d --name systemd-ubuntu --privileged -v /sys/fs/cgroup:/sys/fs/cgroup:ro jrei/systemd-ubuntu

• Entrer dans le conteneur puis mise à jour de ce dernier

$ docker exec -it systemd-ubuntu /bin/bash
$ apt update && apt full-upgrade
$ systemctl start docker

Finalement, cette troisième et dernière solution fonctionne et me permet d’utiliser le lab de pentest en local !

En synthèse, ce prototype m’aura permis de creuser les solutions de virtualisation Linux sous Windows afin d’héberger le laboratoire de Pentest créé par Oliver Wiegers. Ces solutions multiples et variées sont intéressantes à explorer pour comprendre la philosophie des outils mais aussi les compromis à réaliser entre légèreté et capacités de configurer les outils. Les échecs rencontrés ont été au final formateurs et instructifs pour comprendre l’état actuel du marché dans le domaine.