Ansible automation for pentesting environments
Je travaillais sur des techniques de privilege escalation dans ma VM quand j’ai tapé tee /etc/passwd au lieu d’autre chose. J’ai appuyé sur Entrée. Le système a freezé. Plus de boot.
Mes fichiers étaient toujours sur le disque, mais sans /etc/passwd fonctionnel, impossible d’accéder à quoi que ce soit. J’ai relancé l’installeur Kali et commencé à compter mentalement tout ce que j’allais devoir refaire : Ghidra avec mes settings custom, Neovim et ses plugins, Tmux, ma structure de dossiers, mes scripts, et probablement cinquante autres petits trucs. Trois à quatre heures de travail pour retrouver un environnement opérationnel.
C’est là que j’ai réalisé que je faisais ça complètement à l’envers.
Réinstaller à la main, c’est du temps perdu à chaque fois. Et ça arrive plus souvent qu’on ne le croit : snapshot raté, snapshot oublié, mise à jour qui casse un outil, VM corrompue, ou simplement une commande mal tapée comme la mienne. Sans compter que pendant une réinstallation, on perd aussi toutes les petites customisations qu’on avait ajoutées au fil du temps et qu’on n’a jamais vraiment documentées.
La solution, c’était d’automatiser l’environnement et de séparer les données du système. Le principe est simple : la VM est jetable, le travail ne l’est pas.
J’ai écrit des playbooks Ansible qui reconstruisent l’intégralité de mon setup depuis zéro. La structure est organisée en rôles, chacun gérant une chose précise.
Le rôle system s’occupe de la config de base : timezone, layout clavier français avec swap de la touche Escape, et sudo sans mot de passe. Le rôle tools installe les outils que j’utilise vraiment — Ghidra, GDB avec pwntools et GEF, Binary Ninja, et tout ce qui va avec. Les rôles nvim et tmux configurent mon environnement de dev exactement comme je l’aime. Le rôle dotfiles gère tous mes fichiers de configuration.
J’ai aussi ajouté le support pour des outils Go comme nuclei et httpx, désactivés par défaut parce que je n’en ai pas toujours besoin. L’idée c’est de pouvoir activer ou désactiver des parties entières selon le contexte — cloud server minimal, poste de travail complet, ou machine dédiée CTF.
Pour lancer tout ça :
git clone https://github.com/kraaakilo/secmachine-buildcd secmachine-buildmake setupDix minutes plus tard, l’environnement est là.
Au-delà des outils de sécurité, ce sont les utilitaires custom qui m’évitent de répéter les mêmes actions manuellement.
shelf est un TUI en Go que j’ai écrit pour gérer mes workspaces CTF et box. Au lieu de créer les dossiers à la main à chaque nouveau challenge, je lance shelf et je navigue dans une interface interactive. Je sélectionne la plateforme, la catégorie, le nom du challenge — les dossiers se créent automatiquement et une session tmux s’ouvre directement dans le bon répertoire.
shelf # mode interactifshelf ctf # mode CTF directementshelf box # mode box directementLa structure générée suit une convention fixe :
~/work/training/challenges/<platform>/<category>/<challenge> # CTF~/work/training/boxes/<platform>/<box> # boxPlus besoin de réfléchir à où mettre les fichiers. Je sais toujours où retrouver le travail de la semaine dernière.
host-entry règle un problème que tous les CTF players connaissent : la gestion de /etc/hosts. Plutôt que d’éditer le fichier à la main à chaque fois et de risquer de casser quelque chose, le script sauvegarde l’original, ajoute les entrées dans une section clairement délimitée, et facilite le nettoyage une fois le challenge terminé.
sudo host-entry add 10.10.10.10 deadcode.thm ctf.deadcode.thmsudo host-entry cleanC’est le vrai changement. Mon répertoire de travail est monté depuis l’hôte dans la VM. Notes, scripts, exploits en cours, rapports — tout ça vit sur l’hôte. La VM ne contient que l’environnement.
Quand je crée une nouvelle machine, je monte ce dossier, je lance make setup, et tout est là : mes notes des challenges précédents, mes scripts, mes projets en cours. La VM peut être supprimée, corrompue, ou reconstruite — le travail ne disparaît pas avec elle.
Voilà comment ça se passe concrètement. Je démarre une VM fraîche, je clone le repo, je lance make setup, je vais faire autre chose. Dix minutes après, l’environnement est opérationnel — terminal, outils, scripts custom, tout.
Une nouvelle machine HTB sort. Je lance shelf box, je navigue dans l’interface, je sélectionne la plateforme et j’entre le nom — une session tmux s’ouvre directement dans le bon répertoire, déjà organisé. Je n’ai pas à réfléchir à où mettre les fichiers.
En fin de session, j’éteins la VM. Le lendemain, même si je dois reconstruire, je remonte le dossier de travail, je relance make setup, et je suis de retour au même point en quelques minutes.
Le setup complet est sur GitHub, et shelf est dispo séparément ici. Ce que j’ai appris de cette erreur stupide sur /etc/passwd : documenter son environnement une seule fois, c’est mieux que de le reconstruire à la main dix fois.