SUDO : implémentation et sécurisation des accès sur Debian/Ubuntu

La gestion des privilèges est l’une des pierres angulaires de la sécurité d’un système Linux. sudo (Superuser DO) permet à des utilisateurs ordinaires d’exécuter des commandes avec les privilèges d’un autre utilisateur — généralement root — de manière contrôlée et traçable. Contrairement à un accès root permanent, sudo impose une authentification à la demande et enregistre chaque action dans les journaux système.

Sur Debian et Ubuntu, sudo est le mécanisme privilégié pour l’élévation de droits. Il remplace avantageusement le compte root direct, impossible à auditer finement. La version actuelle dans les dépôts Debian (bookworm) est sudo 1.9.16p2, qui apporte notamment la journalisation centralisée des sessions et des options de sécurité renforcées via les directives Defaults.

Cet article couvre l’installation, la configuration de base et avancée du fichier sudoers, les alias, les options Defaults et les bonnes pratiques pour durcir l’utilisation de sudo en environnement de production.

Architecture de sudo

Fonctionnement général

Lorsqu’un utilisateur exécute une commande précédée de sudo, le processus suivant se déroule :

1. sudo lit le fichier /etc/sudoers et les fichiers présents dans /etc/sudoers.d/
2. Il vérifie si l’utilisateur est autorisé à exécuter la commande demandée
3. Si une authentification est requise, il demande le mot de passe de l’utilisateur (pas celui de root)
4. La commande est exécutée avec les privilèges accordés
5. L’action est enregistrée dans /var/log/auth.log

Les fichiers de configuration

La configuration repose sur deux emplacements :

• /etc/sudoers — fichier principal, ne jamais éditer directement avec un éditeur standard
• /etc/sudoers.d/ — répertoire pour les règles modulaires par rôle ou service

Règle absolue : toujours utiliser visudo pour modifier /etc/sudoers. Cet outil verrouille le fichier pendant l’édition et valide la syntaxe avant de sauvegarder. Une erreur de syntaxe dans sudoers peut bloquer totalement l’accès aux privilèges root.

Installation et configuration de base

Installation de sudo

Sur Debian minimal, sudo n’est pas toujours préinstallé. Installation depuis le compte root :

# Installer sudo depuis le compte root
apt install sudo

# Vérifier la version installée
sudo --version | head -1
# Sudo version 1.9.16p2

Ajouter un utilisateur au groupe sudo

La méthode la plus directe est d’ajouter l’utilisateur au groupe sudo, présent par défaut sur Debian et Ubuntu :

# Ajouter l'utilisateur 'alice' au groupe sudo
usermod -aG sudo alice

# Vérifier l'appartenance au groupe
groups alice
# alice : alice sudo

# L'utilisateur doit se déconnecter/reconnecter pour que le changement prenne effet
# Ou recharger les groupes dans la session courante
su - alice

Cette méthode donne un accès root complet. C’est pratique sur un poste de travail, mais trop permissif pour la production — les sections suivantes couvrent les règles granulaires.

Supprimer les droits sudo

# Retirer 'alice' du groupe sudo
deluser alice sudo

# Ou via gpasswd
gpasswd -d alice sudo

Syntaxe du fichier sudoers

Structure d’une règle

Chaque règle dans /etc/sudoers suit la syntaxe :

WHO  WHERE=(AS_WHOM)  COMMANDS

Exemples concrets :

# alice peut exécuter toutes les commandes en tant que root depuis n'importe quel hôte
alice  ALL=(ALL:ALL)  ALL

# bob peut uniquement redémarrer nginx
bob  ALL=(root)  /usr/bin/systemctl restart nginx

# Le groupe webadmin peut gérer apache2 et nginx
%webadmin  ALL=(root)  /usr/bin/systemctl restart apache2, 
                       /usr/bin/systemctl restart nginx, 
                       /usr/bin/systemctl reload nginx

Explication des champs :

• ALL (WHERE) — s’applique depuis n’importe quel hôte
• (ALL:ALL) — peut exécuter en tant que n’importe quel utilisateur et groupe
• Les chemins de commandes doivent être absolus
• Le préfixe % désigne un groupe Unix

Les alias pour simplifier la gestion

Pour les environnements avec de nombreux utilisateurs ou commandes, les alias évitent la répétition et facilitent la maintenance :

# Alias d'utilisateurs
User_Alias ADMINS   = alice, bob, carol
User_Alias WEBTEAM  = dave, eve

# Alias de commandes
Cmnd_Alias SERVICES  = /usr/bin/systemctl start *, /usr/bin/systemctl stop *, 
                       /usr/bin/systemctl restart *, /usr/bin/systemctl reload *
Cmnd_Alias NETWORK   = /sbin/ip, /sbin/ifconfig, /usr/sbin/tcpdump
Cmnd_Alias PACKAGES  = /usr/bin/apt update, /usr/bin/apt upgrade, 
                       /usr/bin/apt install *, /usr/bin/dpkg

# Alias d'hôtes (utile dans les environnements multi-serveurs)
Host_Alias WEBSERVERS = web01, web02, web03
Host_Alias DBSERVERS  = db01, db02

# Application des alias
ADMINS    ALL          = SERVICES, PACKAGES
WEBTEAM   WEBSERVERS   = SERVICES
bob       DBSERVERS    = /usr/bin/pg_dump, /usr/bin/pg_restore

Options Defaults — paramètres globaux et sécurité

La directive Defaults contrôle le comportement global de sudo. Elle se place en tête du fichier sudoers ou dans un fichier dédié sous /etc/sudoers.d/ :

## Éditer avec : visudo -f /etc/sudoers.d/security

# Réduire la durée du cache de credentials (défaut : 15 min)
# Après ce délai, sudo redemande le mot de passe
Defaults  timestamp_timeout=5

# Timeout à 0 : mot de passe requis à chaque invocation sudo
# Defaults  timestamp_timeout=0

# Journaliser les entrées et sorties de toutes les commandes sudo
Defaults  log_input
Defaults  log_output
Defaults  iolog_dir=/var/log/sudo-io

# Envoyer un email en cas de tentative non autorisée
Defaults  mail_badpass
Defaults  mailto="[email protected]"

# Bloquer la modification du PATH par l'utilisateur
Defaults  secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Nombre de tentatives de mot de passe autorisées
Defaults  passwd_tries=3

# Timeout pour saisir le mot de passe (minutes)
Defaults  passwd_timeout=1

Gérer les fichiers dans /etc/sudoers.d/

Créer des fichiers séparés par rôle dans /etc/sudoers.d/ simplifie la gestion et réduit le risque de corrompre le fichier principal :

# Créer un fichier pour les administrateurs web
visudo -f /etc/sudoers.d/webadmin

# Contenu du fichier
%webadmin ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx

# Les fichiers dans sudoers.d doivent avoir les droits corrects
chmod 440 /etc/sudoers.d/webadmin

# Vérifier la syntaxe sans appliquer
visudo -c -f /etc/sudoers.d/webadmin
# /etc/sudoers.d/webadmin: parsed OK

# Vérifier l'ensemble de la configuration sudoers
visudo -c
# /etc/sudoers: parsed OK

Sécurisation avancée

Principe du moindre privilège

La règle fondamentale : n’accorder que les droits strictement nécessaires à chaque compte. Les configurations trop larges sont une surface d’attaque :

# À ÉVITER — accès root total pour un compte de déploiement
deployer  ALL=(ALL)  ALL

# PRÉFÉRER — uniquement les commandes nécessaires au déploiement
deployer  ALL=(root)  /usr/bin/systemctl restart myapp, 
                      /usr/bin/systemctl reload myapp, 
                      /usr/bin/chown -R www-data:www-data /var/www/myapp

NOPASSWD : usage contrôlé

NOPASSWD supprime l’obligation de saisir un mot de passe. À réserver aux cas où c’est impératif (scripts automatisés, pipelines CI/CD) et uniquement pour des commandes précises :

# Acceptable : NOPASSWD limité à une commande spécifique
deployer  ALL=(root)  NOPASSWD: /usr/bin/systemctl restart myapp

# Dangereux : à ne jamais utiliser en production
deployer  ALL=(ALL)  NOPASSWD: ALL

Si un compte avec NOPASSWD: ALL est compromis, l’attaquant obtient un accès root immédiat sans aucune barrière supplémentaire. Le mot de passe est la dernière ligne de défense.

Interdire les commandes permettant un shell escape

Certaines commandes (éditeurs, pagers, interpréteurs) permettent d’obtenir un shell root si elles sont exécutées avec sudo. Les interdire explicitement :

# Interdire les commandes susceptibles d'ouvrir un shell
bob  ALL=(root)  ALL, !/bin/bash, !/bin/sh, !/usr/bin/vim, !/usr/bin/vi, 
                      !/usr/bin/less, !/usr/bin/python3, !/usr/bin/perl

# L'option noexec empêche les sous-processus depuis les commandes autorisées
# (bloque les shell escapes depuis vim :!cmd, less !cmd, etc.)
Cmnd_Alias EDITORS = /usr/bin/vim, /usr/bin/nano, /usr/bin/less, /usr/bin/more
Defaults!EDITORS  noexec

Journalisation et audit

Toutes les actions sudo sont enregistrées dans /var/log/auth.log sur Debian/Ubuntu. Pour surveiller les usages suspects, voir aussi la configuration avancée de Fail2ban pour bloquer les tentatives répétées :

# Voir les dernières commandes sudo exécutées
grep sudo /var/log/auth.log | tail -20

# Filtrer les tentatives refusées
grep "sudo.*command not allowed|NOT in sudoers" /var/log/auth.log

# Afficher toutes les commandes d'un utilisateur spécifique
grep "sudo.*alice" /var/log/auth.log | awk '{print $1,$2,$3,$NF}'

# Si log_output est activé, rejouer une session enregistrée
sudoreplay /var/log/sudo-io/00/00/01

Lister et vérifier les droits sudo

# Lister les commandes autorisées pour l'utilisateur courant
sudo -l

# Lister les droits d'un autre utilisateur (nécessite les droits sudo)
sudo -l -U alice

# Exemple de sortie :
# User alice may run the following commands on srv01:
#     (root) /usr/bin/systemctl restart nginx
#     (root) /usr/bin/systemctl reload nginx

# Tester une commande sans l'exécuter (-n = non-interactif)
sudo -n -l -U bob 2>&1

Cas pratiques en production

Compte de déploiement applicatif

## /etc/sudoers.d/deploy
## Compte de déploiement : redémarre les services et ajuste les droits de fichiers

Cmnd_Alias DEPLOY_CMDS = /usr/bin/systemctl restart myapp, 
                          /usr/bin/systemctl reload nginx, 
                          /usr/bin/chown -R www-data /var/www/myapp, 
                          /usr/bin/chmod -R 755 /var/www/myapp

deploy  ALL=(root)  NOPASSWD: DEPLOY_CMDS

Administrateur réseau

## /etc/sudoers.d/netadmin

Cmnd_Alias NET_CMDS = /sbin/ip, /sbin/ifconfig, /usr/sbin/tcpdump, 
                      /usr/sbin/nft, /usr/bin/ss

%netadmin  ALL=(root)  NET_CMDS

Utilisateur sensible avec re-authentification systématique

## /etc/sudoers.d/strict

# Désactiver le cache de credentials pour les comptes sensibles
# sudo redemande le mot de passe à chaque commande
Defaults:finance_user  timestamp_timeout=0
Defaults:finance_user  log_input, log_output

finance_user  ALL=(root)  /usr/bin/gpg, /usr/bin/openssl

À lire également

• Durcissement SSH — au-delà des clés publiques — renforcer l’authentification SSH en complément d’une politique sudo stricte pour sécuriser l’accès au serveur de bout en bout
• AppArmor sur Debian/Ubuntu : profils, modes et confinement applicatif — confiner les processus lancés avec des privilèges élevés via sudo dans un profil MAC restrictif
• Fail2ban — configuration avancée et filtres personnalisés — bloquer automatiquement les tentatives d’authentification répétées, y compris les abus de sudo
• Authentification par clé publique sur un serveur SSH — sécuriser l’accès SSH avant même d’arriver à la couche de gestion des privilèges

Références

• Documentation officielle sudoers — sudo.ws
• Man page sudoers(5) — Debian Manpages
• Man page sudo(8) — Debian Manpages
• Wiki Debian — sudo
• Documentation Ubuntu Server — sudo