Bac à sable
Le serveur contient tes fichiers (~/site, config.env…), un projet Docker dans ~/monsite, le pare-feu ufw et la configuration SSH. Tape help pour la liste des commandes. « Remettre à zéro » repart d'un serveur tout neuf.
Cours › Terminal libre
Terminal libre
Un serveur Debian simulé dans ton navigateur, avec Linux, Docker, le pare-feu, SSH et CrowdSec. Entraîne-toi librement, ou mène l'enquête sur une panne : à toi de trouver ce qui ne va pas et de réparer.
Le site est en panne Facile
Lundi matin, un client t'appelle : « Votre site ne s'affiche plus depuis ce week-end ! » Le serveur web de la machine est nginx. Le serveur a redémarré samedi pour une mise à jour.
Trouve ce qui ne va pas, remets le site en ligne, et fais en sorte que ça ne se reproduise pas au prochain redémarrage.
Objectifs
- nginx est de nouveau en marche
- nginx redémarrera tout seul au prochain démarrage
Panne réparée, bravo ! Un service arrêté ET désactivé : après un redémarrage, il ne revient pas. Le réflexe : systemctl status d'abord, puis enable pour que ça tienne.
Indice 1
Commence par regarder l'état du service : systemctl status nginx.
Indice 2
« inactive (dead) » : il est arrêté. « disabled » : il ne démarre pas tout seul au démarrage de la machine.
Indice 3
sudo systemctl start nginx puis sudo systemctl enable nginx (ou les deux d'un coup : sudo systemctl enable --now nginx).
Voir une solution
systemctl status nginx
sudo systemctl start nginx
sudo systemctl enable nginx
systemctl status nginxUn mot de passe à la vue de tous Facile
En relisant le serveur, tu remarques que le fichier config.env de ton dossier personnel contient le mot de passe de la base de données… et que ses droits ont été changés par erreur.
Vérifie ses droits, puis fais en sorte que toi seul puisses le lire et le modifier.
Objectifs
- config.env n'est lisible et modifiable que par toi (600)
- Le fichier est toujours là, avec son contenu
Panne réparée, bravo ! Un fichier de secrets se met en 600. Pense aussi aux sauvegardes qui contiennent ces fichiers.
Indice 1
ls -l config.env affiche ses droits : -rw-rw-rw- veut dire lecture et écriture pour tout le monde.
Indice 2
Lecture + écriture pour le propriétaire, rien pour les autres : 6 pour toi, 0 pour le groupe, 0 pour les autres.
Indice 3
chmod 600 config.env, puis vérifie avec ls -l config.env.
Voir une solution
ls -l config.env
chmod 600 config.env
ls -l config.envLa base de données refuse de démarrer Moyen
Un collègue a lancé une base PostgreSQL avec Docker, dans un conteneur nommé base. « Elle s'arrête toute seule, je comprends pas. »
Trouve pourquoi, puis relance un conteneur base (image postgres:18-alpine) qui tourne vraiment, et dont les données survivront à sa suppression (volume donnees-base sur /var/lib/postgresql/data).
Objectifs
- Le conteneur base tourne
- Il a un mot de passe (POSTGRES_PASSWORD)
- Ses données sont dans le volume donnees-base
Panne réparée, bravo ! Quand un conteneur s'arrête tout seul, la réponse est presque toujours dans docker logs. Et une base sans volume perd tout à la première suppression.
Indice 1
docker ps -a montre le conteneur arrêté ; docker logs base dit pourquoi.
Indice 2
Il manque la variable POSTGRES_PASSWORD. On ne peut pas l'ajouter à un conteneur existant : supprime-le (docker rm base) et recrée-le.
Indice 3
docker run -d --name base -e POSTGRES_PASSWORD=… -v donnees-base:/var/lib/postgresql/data postgres:18-alpine.
Voir une solution
docker ps -a
docker logs base
docker rm base
docker run -d --name base -e POSTGRES_PASSWORD=Un-Mot-De-Passe-Solide -v donnees-base:/var/lib/postgresql/data postgres:18-alpine
docker psLe pare-feu laisse tout passer Moyen
Un audit de sécurité signale que la base de données MariaDB (port 3306) de ton serveur répond depuis Internet. Pourtant, le pare-feu ufw est actif.
Remets-le en ordre : tout ce qui entre est refusé par défaut, seuls SSH (22), HTTP (80) et HTTPS (443) restent ouverts, et le port 3306 n'est plus autorisé. Attention à ne pas te couper SSH !
Objectifs
- Tout ce qui entre est refusé par défaut
- Le port 3306 n'est plus autorisé
- SSH (22) est toujours autorisé
- HTTP (80) et HTTPS (443) sont autorisés
- Le pare-feu est toujours actif
Panne réparée, bravo ! Un pare-feu « actif » ne protège rien si sa politique par défaut accepte tout. On ferme tout, puis on ouvre le strict nécessaire.
Indice 1
sudo ufw status verbose : regarde la ligne « Default » et la liste des règles.
Indice 2
sudo ufw default deny incoming, puis sudo ufw delete allow 3306/tcp.
Indice 3
Il manque le web : sudo ufw allow 80/tcp et sudo ufw allow 443/tcp. Vérifie avec sudo ufw status verbose.
Voir une solution
sudo ufw status verbose
sudo ufw default deny incoming
sudo ufw delete allow 3306/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verboseQuelqu'un est entré ! Difficile
Ton système de surveillance t'envoie une alerte : « Connexion SSH réussie depuis une adresse inhabituelle ». Quelqu'un a deviné le mot de passe du compte eleve.
Retrouve l'adresse de l'intrus dans le journal des connexions, bannis-la avec CrowdSec (déjà installé), et interdis désormais les connexions SSH par mot de passe (dans un fichier de /etc/ssh/sshd_config.d/). Vérifie la configuration avant de recharger SSH.
Objectifs
- L'adresse de l'intrus est bannie par CrowdSec
- Ton adresse à toi (192.168.1.20) n'est pas bannie
- Les connexions SSH par mot de passe sont interdites
Panne réparée, bravo ! Sur un vrai serveur, il faudrait aussi changer le mot de passe du compte (passwd), chercher ce que l'intrus a modifié, et passer aux clés SSH avec double authentification.
Indice 1
Les connexions réussies sont notées « Accepted » : sudo grep "Accepted" /var/log/auth.log. Laquelle n'est pas toi (ton réseau local est 192.168.1.x) ?
Indice 2
Bannir : sudo cscli decisions add --ip ADRESSE --duration 87600h --reason "intrusion".
Indice 3
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf, puis sudo sshd -t et sudo systemctl reload ssh.
Voir une solution
sudo grep "Accepted" /var/log/auth.log
sudo cscli decisions add --ip 185.220.101.47 --duration 87600h --reason "intrusion"
echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/10-securite.conf
sudo sshd -t
sudo systemctl reload sshRaccourcis : ↑ ↓ historique, Tab compléter, Ctrl + L effacer. Rien n'est exécuté sur un vrai serveur.