# Études de cas pour l'exercice Z10.2 (cours VPS et administration de serveurs Linux)

Pour chaque cas, choisissez de quelle erreur il s'agit et quelle est la meilleure première étape. Tous les noms et adresses sont des exemples.

**Erreurs (tirées de la leçon 10.2) :**
A. Connexion root avec un mot de passe
B. Une base de données, un cache ou un cluster de recherche ouvert sur Internet
C. L'API Docker ouverte ou `docker.sock` dans un conteneur
D. `chmod 777` pour faire disparaître un message d'erreur
E. `curl ... | bash` et des logiciels venus de n'importe où
F. Pas de mises à jour, ou des mises à jour "plus tard"
G. Pas de sauvegarde, ou une sauvegarde jamais testée
H. Panneau d'administration ouvert à tous, sans authentification à deux facteurs
I. Des secrets dans Git ou dans votre fichier compose
J. Désactiver "juste un instant" le pare-feu, tout faire en root, aucune note

---

**Cas 1.** Sur `web1.example.com`, le fichier `compose.yaml` contient pour le service `redis` : `ports: - "6379:6379"`. `ufw status` n'affiche que 22, 80 et 443. Un scan depuis l'extérieur trouve le port 6379 ouvert.
Première étape : (a) redémarrer ufw (b) supprimer la règle de port ou la remplacer par `"127.0.0.1:6379:6379"`, puis relancer `docker compose up -d` (c) attribuer un autre numéro de port à Redis (d) redémarrer le serveur

**Cas 2.** Le développeur d'une application web sur `app.example.net` signale que les envois de fichiers ne fonctionnaient pas. Il a "résolu" le problème et désormais tous les fichiers de `/var/www/app` sont en `-rwxrwxrwx`.
Première étape : (a) laisser ainsi, cela fonctionne maintenant (b) donner à l'utilisateur du serveur web les droits d'écriture uniquement sur le dossier d'envoi, remettre le reste en 644/755 avec un autre propriétaire (c) faire tourner le serveur web en root (d) désactiver AppArmor

**Cas 3.** Depuis hier, un dépôt public contient un fichier `.env` avec `MAIL_API_KEY=...` du serveur `web2.example.org`.
Première étape : (a) supprimer le fichier du dépôt (b) révoquer la clé auprès du service de messagerie et en créer une nouvelle, puis ajouter `.env` dans `.gitignore` (c) renommer le dépôt (d) ne rien faire

**Cas 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` renvoie `permitrootlogin yes` et `passwordauthentication yes`. Le journal montre des tentatives sur root toutes les minutes.
Première étape : (a) installer fail2ban et rien d'autre (b) installer une clé pour un administrateur ordinaire avec sudo, tester, puis désactiver la connexion par mot de passe et la connexion root par mot de passe (c) mettre SSH sur le port 2222 (d) conserver le mot de passe root dans un fichier texte

**Cas 5.** `cat /etc/os-release` affiche une version d'Ubuntu dont le support standard a pris fin il y a trois ans, sans ESM. `apt list --upgradable` est vide.
Première étape : (a) se réjouir, il n'y a pas de mises à jour (b) planifier une mise à niveau ou un nouveau serveur vers une LTS prise en charge, avec instantané et sauvegarde (c) réinstaller unattended-upgrades (d) redémarrer le serveur

**Cas 6.** Un conteneur `portainer` dispose du volume `/var/run/docker.sock:/var/run/docker.sock` et est accessible sur `https://beheer.example.com` avec le mot de passe `admin123`, sans authentification à deux facteurs.
Choisissez l'erreur qui permet les dégâts les plus importants si le mot de passe est deviné. Première étape : (a) placer le panneau derrière un tunnel SSH ou une adresse fixe et définir un mot de passe robuste avec authentification à deux facteurs (b) redémarrer le conteneur (c) choisir un autre sous-domaine (d) réinstaller Docker

**Cas 7.** Après l'échec d'une mise à jour de la base de données, il s'avère que la seule sauvegarde est un instantané vieux de deux mois, sur le même stockage que le serveur. Personne n'a jamais essayé de restauration.
Première étape pour l'avenir : (a) créer davantage d'instantanés (b) mettre en place des sauvegardes chiffrées hors du serveur (par exemple restic), avec surveillance et un test de restauration (c) ne plus jamais mettre à jour la base de données (d) un deuxième disque dans le même serveur

**Cas 8.** Le serveur contient `/usr/local/bin/tool` et une source de paquets inconnue `extra.list` avec l'option `[trusted=yes]`. Personne ne sait d'où elles viennent ; l'ancien administrateur installait "tout avec une seule ligne copiée sur un site web".
Première étape : (a) laisser en place, cela fonctionne (b) déterminer ce que sont la source et le programme, désactiver la source avec `trusted=yes`, et n'installer désormais que depuis la distribution ou la source officielle de l'éditeur avec `Signed-By` (c) redémarrer le serveur (d) supprimer tous les paquets

Indiquez pour chaque cas : l'erreur (A-J) et la première étape (a-d).