🐧 Administration Linux — comptes, permissions et SSH

Introduction (10 min)

Accroche — Dirty Pipe (CVE-2022-0847) : en 2022, une vulnérabilité du noyau Linux a permis, dans certains cas, une escalade locale de privilèges vers root en modifiant le contenu d'un pipe et en écrivant dans des pages mappées en lecture seule. Ce scénario illustre un principe pédagogique fondamental : même une faiblesse basse couche exposée localement suffit pour compromettre un service si les privilèges sont trop larges. Cette séance insiste sur la règle de moindre privilège : créer des comptes et des services avec uniquement les droits nécessaires, vérifier les permissions, et verrouiller l'accès distant.

🎯 Objectifs de la séance

• Créer, modifier et supprimer des utilisateurs et groupes sur Debian 12, et vérifier leur existence via id / getent.
• Gérer les permissions et la propriété des fichiers (chmod octal et symbolique, chown), comprendre umask, sticky bit, SUID/SGID et leurs implications de sécurité.
• Sécuriser l'accès SSH (clés Ed25519, sshd_config), configurer sudoers restreint et déployer fail2ban pour limiter les brute-force.

1. Gestion des comptes et des groupes (70 min)

La gestion des identités locales est le premier pilier de la sécurité système. Sous Debian 12, les comptes sont décrits dans /etc/passwd, les mots de passe chiffrés dans /etc/shadow et les groupes dans /etc/group. On manipule ces objets via useradd / usermod / userdel et groupadd.

Exemples pratiques — à faire en salle sur debian-srv01 dans le contexte InnovatTech :

# Créer un utilisateur 'admin' avec répertoire personnel, shell bash et membre du groupe sudo
sudo useradd -m -s /bin/bash -G sudo -c "Admin InnovatTech" admin
# Définir le mot de passe (interactif)
sudo passwd admin

# Vérifier l'utilisateur
id admin
# Sortie attendue :
# uid=1001(admin) gid=1001(admin) groups=1001(admin),27(sudo)

# Créer un groupe 'webops' et un utilisateur 'webmaster' membre de webops (sans sudo global)
sudo groupadd webops
sudo useradd -m -s /bin/bash -G webops -c "Service web" webmaster
sudo passwd webmaster

# Ajouter un utilisateur existant dans un groupe
sudo usermod -aG webops alice

# Supprimer un utilisateur et son répertoire
sudo userdel -r olduser

# Requêtes utiles
getent passwd admin
getent group webops

2. Permissions, umask, sticky bit, SUID/SGID (50 min)

Les permissions Unix sont la pierre angulaire du contrôle d'accès : lecture (r), écriture (w), exécution (x) pour le propriétaire, le groupe et les autres. On les manipule en notation octale (ex : 644, 755, 600) ou symbolique (u+x, g-w).

# Permissions typiques pour fichiers et répertoires
chmod 644 fichier.txt          # rw-r--r--  → lecture publique, pas d'exécution
chmod 755 /usr/local/bin/monscript.sh  # rwxr-xr-x → exécutable par tous
chmod 600 /root/.ssh/id_ed25519        # rw------- → clé privée, propriétaire seul

# Ajouter le bit exécutable pour l'utilisateur
chmod u+x script.sh

# Changer propriétaire et groupe
sudo chown alice:webops /srv/data

# Vérifier
ls -l /srv/data
# Sortie annotée :
# -rw-r--r-- 1 alice webops 1234 2026-02-20 09:00 /srv/data

umask

Le umask est un masque appliqué lors de la création des fichiers. La valeur par défaut 0022 donne des fichiers en 644 et des répertoires en 755.

umask
# Sortie : 0022

# Pour rendre plus strict (ex : 0027 — refuser l'accès aux "others") :
sudo sed -i '/^UMASK/s/.*/UMASK\t027/' /etc/login.defs \
  || echo 'UMASK\t027' | sudo tee -a /etc/login.defs

Sticky bit

Le sticky bit sur /tmp empêche un utilisateur d'effacer un fichier dont il n'est pas le propriétaire dans un répertoire partagé.

# Vérifier /tmp
ls -ld /tmp

# Mettre le sticky bit
sudo chmod 1777 /tmp
ls -ld /tmp
# Sortie attendue : drwxrwxrwt  (t = sticky bit)

SUID / SGID

Les binaires SUID s'exécutent avec l'UID du propriétaire (souvent root). Exemple : /usr/bin/passwd est SUID root pour pouvoir modifier /etc/shadow. Les scripts shell ne doivent pas être rendus SUID (ignoré par le noyau pour des raisons de sécurité). Le SGID sur un dossier fait hériter le groupe propriétaire aux nouveaux fichiers créés dedans.

# Voir un binaire SUID légitime
ls -l /usr/bin/passwd
# Sortie attendue : -rwsr-xr-x 1 root root ... /usr/bin/passwd

# Dossier collaboratif avec SGID (groupe webops hérité)
sudo chown root:webops /srv/shared
sudo chmod 2775 /srv/shared   # 2 = SGID

3. sudo et configuration sudoers (visudo) (25 min)

sudo permet d'élever des commandes précises. Modifier /etc/sudoers directement est risqué : utilisez visudo (ou visudo -f /etc/sudoers.d/fichier) qui vérifie la syntaxe avant d'enregistrer.

Exemple : restreindre l'utilisateur webmaster à redémarrer Apache sans mot de passe.

# Créer un fichier sudoers pour webmaster (édition sûre)
sudo visudo -f /etc/sudoers.d/webmaster

# Contenu à insérer :
# webmaster peut redémarrer et vérifier apache sans mot de passe
webmaster ALL=(root) NOPASSWD: /bin/systemctl restart apache2, /bin/systemctl status apache2

# Tester la configuration :
sudo -l -U webmaster

# Se connecter en tant que webmaster et exécuter :
su - webmaster
sudo systemctl status apache2
sudo systemctl restart apache2

4. PAM et NSS — nsswitch.conf, /etc/pam.d/ (15 min)

NSS (Name Service Switch) détermine où le système recherche les identités : /etc/nsswitch.conf gère l'ordre (files, ldap, etc.). PAM (Pluggable Authentication Modules) orchestre l'authentification via /etc/pam.d/ (common-auth, common-account, common-session).

# Vérifier NSS
cat /etc/nsswitch.conf | sed -n '1,12p'
# Extrait typique :
# passwd:         files
# group:          files
# shadow:         files

# Lister les fichiers PAM essentiels
ls -l /etc/pam.d/

# Afficher la configuration d'authentification par défaut
cat /etc/pam.d/common-auth

5. Sécurisation SSH et clés Ed25519 (40 min)

L'OpenSSH de Debian 12 supporte Ed25519 (recommandé). Bonnes pratiques : désactiver l'authentification par mot de passe après avoir ajouté les clés publiques, interdire le login root direct, limiter les utilisateurs autorisés.

Durcissement de sshd_config

# Sauvegarder la configuration avant modification
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# Appliquer les paramètres recommandés :
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config

# Restreindre les utilisateurs autorisés (attention à ne pas se bloquer !)
echo 'AllowUsers admin webmaster' | sudo tee -a /etc/ssh/sshd_config

# Redémarrer SSH (SEULEMENT après avoir validé une session par clé ouverte)
sudo systemctl restart ssh

# Vérifier que SSH écoute
ss -tlnp | grep ssh

Génération de clé Ed25519 et déploiement

# Sur la machine client (poste d'administration)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "admin@innovattech"

# Copier la clé publique sur le serveur debian-srv01
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@debian-srv01

# Vérification côté serveur
sudo ls -ld /home/admin/.ssh
sudo ls -l /home/admin/.ssh/authorized_keys
sudo chmod 700 /home/admin/.ssh
sudo chmod 600 /home/admin/.ssh/authorized_keys
sudo chown -R admin:admin /home/admin/.ssh

# Test de connexion (depuis le client)
ssh -i ~/.ssh/id_ed25519 admin@debian-srv01

6. fail2ban — limiter les tentatives SSH (15 min)

fail2ban surveille les journaux système et ajoute des règles firewall (iptables/nftables) pour bannir automatiquement les adresses IP qui cumulent trop d'échecs d'authentification.

# Installer fail2ban
sudo apt update && sudo apt install -y fail2ban

# Créer /etc/fail2ban/jail.local (ne pas modifier jail.conf directement)
cat <<'EOF' | sudo tee /etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5
bantime  = 3600
findtime = 600
EOF

# Activer et démarrer
sudo systemctl enable --now fail2ban

# Vérifier l'état de la jail SSH
sudo fail2ban-client status sshd
# Sortie attendue : 'Status for the jail: sshd' et le nombre d'IP bannies

Travaux Pratiques (80 min)

Contexte

Vous êtes technicien chez InnovatTech SARL. Le serveur bastion debian-srv01 (192.168.10.10) est accessible depuis Internet via NAT du firewall et doit être verrouillé : plus d'authentification par mot de passe, gestion d'un compte de service pour les opérations Apache, et protection contre les brute-force.

Objectif

Sécuriser SSH sur debian-srv01, créer un compte service webmaster avec droits sudo restreints (redémarrage Apache uniquement), et installer/configurer fail2ban.

Prérequis techniques

• Accès SSH à debian-srv01 (console ou session existante)
• Compte administrateur avec droits sudo sur debian-srv01
• Clé Ed25519 disponible (ou à générer) sur la machine d'administration

Étapes détaillées

Étape 1 — Sauvegarder la config SSH et générer une clé Ed25519

# Sur la machine d'administration
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_innovattech -C "admin@innovattech"

Étape 2 — Copier la clé sur debian-srv01 et valider la connexion

ssh-copy-id -i ~/.ssh/id_ed25519_innovattech.pub admin@debian-srv01
ssh -i ~/.ssh/id_ed25519_innovattech admin@debian-srv01
# La connexion doit s'établir SANS demande de mot de passe

Étape 3 — Créer le compte service 'webmaster'

sudo groupadd --force webops
sudo useradd -m -s /bin/bash -G webops webmaster
sudo passwd webmaster

# Vérifier
getent passwd webmaster
getent group webops

Étape 4 — Restreindre sudo pour 'webmaster'

sudo visudo -f /etc/sudoers.d/webmaster
# Coller le contenu suivant :
# webmaster ALL=(root) NOPASSWD: /bin/systemctl restart apache2, /bin/systemctl status apache2

# Vérifier la configuration sudo
sudo -l -U webmaster

Étape 5 — Installer et configurer fail2ban

sudo apt update && sudo apt install -y fail2ban
# Créer /etc/fail2ban/jail.local comme décrit en section 6
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Étape 6 — Durcir sshd_config (après validation des clés)

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# ⚠️ IMPORTANT : Ne quittez pas votre session ouverte avant d'avoir
# validé la connexion par clé dans une DEUXIÈME fenêtre de terminal.

Livrable attendu

Capture d'écran ou copie terminale montrant :

• Création de webmaster — sortie getent passwd webmaster
• Contenu de /etc/sudoers.d/webmaster
• Sortie de sudo -l -U webmaster
• État de fail2ban — fail2ban-client status sshd
• Extrait de /etc/ssh/sshd_config montrant PasswordAuthentication no et PermitRootLogin no

Critères de réussite

• ☑ L'authentification SSH par mot de passe est désactivée et la connexion par clé Ed25519 fonctionne pour admin.
• ☑ Le compte webmaster existe et peut exécuter sudo systemctl restart apache2 sans mot de passe, mais n'a pas de sudo global.
• ☑ fail2ban est actif et la jail sshd est activée (fail2ban-client status sshd).

Synthèse (10 min)

Cette séance a montré que la sécurité d'un serveur commence par une gestion fine des comptes et des permissions : limiter l'usage des bits spéciaux, appliquer la règle du moindre privilège via sudoers restreint, et durcir l'accès distant avec des clés Ed25519 et fail2ban. Une mauvaise configuration PAM ou SSH peut isoler les administrateurs — toujours tester les accès avant de fermer les méthodes alternatives.