Ce projet installe et configure automatiquement un environnement Kali Linux conteneurisé sur un serveur Debian headless.
L’objectif est de disposer d’un environnement Kali isolé, simple à administrer, sans interface graphique, destiné à un usage de laboratoire, d’administration, de diagnostic réseau ou de pentest explicitement autorisé.
L’environnement repose sur :
- Debian 12 ou Debian 13 comme système hôte ;
- Docker Engine installé depuis le dépôt officiel Docker ;
- Docker Compose ;
- Kali Linux Rolling dans un conteneur ;
- UFW pour le filtrage réseau ;
- Fail2ban pour la protection SSH ;
- WireGuard tools ;
- rotation des logs Docker ;
- répertoires persistants pour le workspace et les logs.
Le conteneur Kali est volontairement limité :
- pas de mode
--privileged; - pas de montage du socket Docker ;
- pas de
network_mode: host; - suppression des capacités Linux par défaut ;
- ajout uniquement de
NET_RAW; no-new-privilegesactivé ;- limitation CPU, mémoire et nombre de processus.
Testé/conçu pour :
- Debian 12 Bookworm
- Debian 13 Trixie
- serveur sans interface graphique
- architecture amd64/arm64 compatible avec Docker et Kali
Avant de lancer l’installation :
- disposer d’un accès SSH fonctionnel ;
- disposer d’un utilisateur avec droits
sudo; - disposer d’une connexion Internet ;
- conserver une deuxième session SSH ouverte pendant l’installation.
Cette deuxième session est fortement recommandée au cas où une règle firewall empêcherait temporairement l’accès SSH.
Créer le script :
nano install-kali-docker.shY coller le script d’installation puis le rendre exécutable :
chmod +x install-kali-docker.shLancer ensuite :
sudo ./install-kali-docker.shÀ la fin de l’installation, déconnectez puis reconnectez votre session SSH afin que l’appartenance au groupe docker soit prise en compte :
exitPuis reconnectez-vous normalement.
L’installation crée l’arborescence suivante :
/opt/redteam/
├── kali/
│ ├── compose.yaml
│ ├── workspace/
│ └── logs/
├── engagements/
├── scripts/
└── backups/
Le répertoire :
/opt/redteam/kali/workspace
est monté dans le conteneur sous :
/workspace
Les fichiers créés dans /workspace sont donc persistants sur l’hôte.
Le répertoire :
/opt/redteam/kali/logs
est monté dans le conteneur sous :
/logs
La commande principale est :
kali-labElle ouvre un shell interactif dans le conteneur Kali.
Commande équivalente :
docker exec -it kali-lab bashVous devriez obtenir un shell ressemblant à :
root@kali-lab:/workspace#
Afficher l’état du conteneur Kali :
kali-statusOu directement :
docker psAfficher les statistiques de ressources :
docker stats kali-labUtiliser :
kali-updateCette commande effectue notamment :
apt-get update
apt-get full-upgrade
apt-get autoremove
apt-get cleandans le conteneur.
Démarrer :
docker start kali-labArrêter :
docker stop kali-labRedémarrer :
docker restart kali-labAfficher les logs :
docker logs kali-labSuivre les logs en temps réel :
docker logs -f kali-labLe fichier Compose se trouve ici :
/opt/redteam/kali/compose.yaml
Pour redémarrer l’environnement après modification :
cd /opt/redteam/kali
docker compose down
docker compose up -dLe conteneur utilise :
kalilinux/kali-rolling:latest
Le script installe ensuite :
kali-linux-headless
ainsi que plusieurs utilitaires courants.
Le conteneur inclut notamment :
kali-linux-headlesscurlwgetgitjqpython3python3-pippython3-venviproute2iputils-pingdnsutilsnet-toolsprocpsvimnanotmuxfilezipunzip
Le métapaquet kali-linux-headless installe également de nombreux outils Kali utilisables sans interface graphique.
Le conteneur n’est pas lancé avec :
--privileged
Il ne monte pas :
/var/run/docker.sock
Il n’utilise pas :
network_mode: host
Toutes les capacités Linux sont retirées :
cap_drop:
- ALLSeule la capacité suivante est ajoutée :
cap_add:
- NET_RAWCela permet notamment certaines opérations réseau comme ping et certains outils de diagnostic.
Certaines fonctions avancées de Kali peuvent nécessiter des capacités supplémentaires comme :
NET_ADMIN
Il est préférable de ne les ajouter que lorsqu’elles sont réellement nécessaires.
Exemple :
cap_add:
- NET_RAW
- NET_ADMINNe pas utiliser privileged: true par défaut.
Afficher l’état :
sudo ufw status verboseLe script :
- refuse les connexions entrantes par défaut ;
- autorise les connexions sortantes ;
- conserve l’accès SSH ;
- active UFW.
Exemple :
Default: deny (incoming), allow (outgoing)
Docker manipule directement les règles Netfilter.
Cela signifie que des ports publiés via Docker peuvent ne pas se comporter exactement comme attendu avec UFW.
Exemple à éviter sans configuration supplémentaire :
ports:
- "8080:8080"Dans la configuration actuelle, aucun port Kali n’est publié vers Internet.
Si vous ajoutez des ports plus tard, vérifiez également :
iptables -S DOCKER-USERou, selon la configuration système :
nft list rulesetAfficher l’état général :
sudo fail2ban-client statusAfficher l’état de la jail SSH :
sudo fail2ban-client status sshdConfiguration créée :
/etc/fail2ban/jail.d/sshd.local
Paramètres par défaut :
maxretry = 5
findtime = 10m
bantime = 1h
Le script essaie de détecter automatiquement le port SSH utilisé par le serveur.
Pour vérifier :
sudo sshd -T | grep '^port 'Exemple :
port 22
L’utilisateur ayant exécuté le script via sudo est ajouté au groupe :
docker
Cela permet d’exécuter :
docker pssans sudo.
Attention :
l’appartenance au groupe
dockerdonne pratiquement des privilèges root sur le serveur.
Pour vérifier :
groupsDocker est configuré avec :
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "5"
}
}Cela évite que les logs Docker grossissent indéfiniment.
Configuration :
/etc/docker/daemon.json
Le conteneur est configuré avec des limites par défaut :
mem_limit: 4g
cpus: 2.0
pids_limit: 512Adaptez-les aux ressources de votre serveur.
Exemple pour un petit VPS :
mem_limit: 2g
cpus: 1.0Sauvegarder :
sudo tar -czf kali-workspace-backup.tar.gz \
/opt/redteam/kali/workspaceRestaurer :
sudo tar -xzf kali-workspace-backup.tar.gz -C /Sauvegarder les fichiers importants :
sudo tar -czf redteam-config-backup.tar.gz \
/opt/redteam \
/etc/docker \
/etc/fail2ban/jail.d/sshd.localTélécharger la dernière image :
docker pull kalilinux/kali-rolling:latestPuis recréer le conteneur :
cd /opt/redteam/kali
docker compose down
docker compose up -dAttention : les paquets installés manuellement dans le conteneur devront être réinstallés si l’image est recréée à partir de zéro.
Les données présentes dans les volumes :
/workspace
/logs
restent persistantes.
Docker :
docker --versionDocker Compose :
docker compose versionDebian :
cat /etc/os-releaseKali :
docker exec kali-lab cat /etc/os-releaseVérifier :
docker ps -aPuis :
docker logs kali-labsudo systemctl status dockerPuis :
sudo journalctl -u docker -n 100 --no-pagerVérifier :
which kali-labPuis :
ls -l /usr/local/bin/kali-labVérifier :
groupsSi docker n’apparaît pas, reconnectez votre session SSH.
Vous pouvez aussi temporairement utiliser :
sudo docker psdocker inspect kali-lab | jq '.[0].HostConfig.CapAdd'Arrêter et supprimer le conteneur :
cd /opt/redteam/kali
docker compose downSupprimer l’image Kali :
docker rmi kalilinux/kali-rolling:latestSupprimer l’environnement :
sudo rm -rf /opt/redteamSupprimer les helpers :
sudo rm -f \
/usr/local/bin/kali-lab \
/usr/local/bin/kali-status \
/usr/local/bin/kali-updateDocker peut être conservé si d’autres conteneurs l’utilisent.
Un conteneur Kali Docker n’est pas identique à une machine virtuelle Kali complète.
En particulier :
- il partage le noyau Linux de l’hôte Debian ;
- il n’a généralement pas un
systemdcomplet ; - certaines opérations bas niveau nécessitent des capacités supplémentaires ;
- les périphériques USB/Wi-Fi ne sont pas automatiquement accessibles ;
- certaines fonctions de pentest réseau avancées sont mieux adaptées à une VM dédiée.
Pour les tâches classiques en CLI, automatisation, analyse, scripts et outils réseau, cette architecture reste légère et pratique.
Cet environnement est destiné à :
- vos propres systèmes ;
- vos laboratoires ;
- vos environnements de test ;
- des infrastructures pour lesquelles vous disposez d’une autorisation explicite.
Ne l’utilisez pas contre des systèmes tiers sans autorisation.
# Entrer dans Kali
kali-lab
# État
kali-status
# Mise à jour Kali
kali-update
# Voir les conteneurs
docker ps
# Logs Kali
docker logs -f kali-lab
# Redémarrer Kali
docker restart kali-lab
# Firewall
sudo ufw status verbose
# Fail2ban
sudo fail2ban-client status sshd
# Docker
sudo systemctl status dockerArchitecture finale :
Internet
|
v
+---------------------------+
| Debian Server |
| |
| SSH + UFW + Fail2ban |
| |
| +---------------------+ |
| | Docker | |
| | | |
| | +---------------+ | |
| | | Kali Linux | | |
| | | Headless | | |
| | +---------------+ | |
| +---------------------+ |
| |
| /opt/redteam |
+---------------------------+
Ce projet est fourni comme base d’administration et de laboratoire.
L’administrateur reste responsable :
- de la sécurité du serveur ;
- des règles firewall ;
- des identifiants SSH ;
- des services exposés ;
- des outils utilisés dans Kali ;
- du respect des lois et autorisations applicables.
Je vous conseille de le placer à côté de votre script :
kali-debian-lab/
├── README.md
└── install-kali-docker.sh
Puis, si vous utilisez Git :
git init
git add README.md install-kali-docker.sh
git commit -m "Initial Debian Kali Docker lab"