Durcir et journaliser sudo (sudoers)

sudo est la porte d'élévation de privilèges de vos serveurs : c'est à la fois un point de contrôle et une cible. Mal configuré, il accorde trop, journalise trop peu, et laisse passer des contournements. Ce guide montre comment journaliser sudo de façon exploitable (avec enregistrement de session rejouable), durcir les Defaults sans casser l'automatisation, et limiter les privilèges proprement. L'approche suit CIS 5.3 et les recommandations R38 à R44 d'ANSSI-BP-028 v2.0.

Ce que vous allez apprendre

• Journaliser sudo dans un fichier dédié et enregistrer les sessions
• Éditer sudoers en sécurité avec visudo
• Durcir les Defaults (use_pty, !visiblepw, délais) sans footgun
• Limiter les privilèges : groupe dédié, négations bannies, arguments précisés
• Rejouer une session sudo avec sudoreplay pour l'investigation

Pourquoi durcir sudo

Chaque règle sudoers est une délégation de pouvoir. Deux risques :

• Trop de privilèges : un ALL=(ALL) ALL ou des commandes mal cadrées permettent une élévation complète, parfois par contournement (un éditeur autorisé qui lance un shell, une négation ! contournable).
• Pas de traçabilité : par défaut, sudo ne consigne que dans syslog. Sans journal dédié ni enregistrement, vous ne savez pas qui a fait quoi lors d'un incident.

Durcir sudo, c'est donc réduire ce qui est accordé et rendre tout traçable.

Toujours éditer sudoers avec visudo

N'éditez jamais /etc/sudoers ou les fichiers de /etc/sudoers.d/ directement : une erreur de syntaxe peut vous verrouiller hors de sudo. visudo valide la syntaxe avant d'écrire. Pour un fichier de sudoers.d/ :

sudo visudo -cf /etc/sudoers.d/10-hardening

Prérequis

• Un serveur Linux (Debian, Ubuntu, RHEL, AlmaLinux, Rocky)
• Un accès root (ou un sudo fonctionnel) et un second accès de secours
• De préférence une VM de test : une erreur sudoers peut couper l'accès admin

Établir une baseline

Regardez les Defaults déjà en place :

sudo grep -hE '^Defaults' /etc/sudoers /etc/sudoers.d/* 2>/dev/null

Sur une Debian 12, vous trouverez en général :

Defaults  env_reset
Defaults  mail_badpass
Defaults  secure_path="..."
Defaults  use_pty

Bonne nouvelle : use_pty est déjà activé par défaut sur les versions récentes. Mauvaise nouvelle : aucun journal dédié n'est configuré, sudo ne consigne que dans syslog.

Journaliser sudo et enregistrer les sessions

C'est le cœur du durcissement : rendre chaque usage de sudo exploitable. Créez /etc/sudoers.d/10-hardening :

1. Définir un journal dédié et l'enregistrement de session

   Defaults  logfile="/var/log/sudo.log"
   Defaults  log_input, log_output
   Defaults  iolog_dir="/var/log/sudo-io"

2. Valider puis poser les bons droits

   sudo visudo -cf /etc/sudoers.d/10-hardening
   sudo chmod 0440 /etc/sudoers.d/10-hardening

3. Vérifier que tout est capturé

   Après une commande sudo id lancée par un utilisateur, le journal dédié contient l'essentiel :

   Jun 25 07:34:44 : alice : PWD=/home/alice ; USER=root ; TSID=01 ;
       COMMAND=/usr/bin/id

   Et la session complète est enregistrée :

   sudo ls /var/log/sudo-io/
   sudo sudoreplay -l          # lister les sessions
   sudo sudoreplay 01          # rejouer la session TSID 01

sudoreplay rejoue la session à l'identique (frappes et sortie), un atout majeur pour l'investigation après incident.

log_input capture aussi les secrets

log_input enregistre tout ce qui est tapé, y compris des mots de passe saisis dans une commande interactive. Protégez /var/log/sudo-io (droits 0700 root:root) et intégrez ces journaux à votre politique de rétention et de confidentialité.

Renforcer les Defaults

Ajoutez au même fichier les options qui réduisent les abus :

Defaults  use_pty
Defaults  !visiblepw
Defaults  passwd_timeout=1
Defaults  timestamp_timeout=5

Option	Effet
use_pty	Exécute la commande dans un pseudo-terminal : empêche une tâche lancée via sudo de détourner le terminal réel
!visiblepw	Refuse sudo si la saisie du mot de passe serait visible (terminal sans masquage)
passwd_timeout	Délai (minutes) pour saisir le mot de passe
timestamp_timeout	Durée (minutes) avant de redemander le mot de passe

Glissez pour voir

N'utilisez pas requiretty

On voit souvent Defaults requiretty présenté comme un durcissement. C'est un piège : il casse tout sudo non interactif (cron, scripts de déploiement, runuser -u app -- sudo ...). L'équivalent moderne et sûr est use_pty, qui est déjà la valeur par défaut sur les distributions récentes. Ne posez pas requiretty.

Limiter les privilèges

Au-delà des Defaults, ce sont les règles qui comptent.

• Un groupe dédié (ANSSI R38) : accordez sudo via un groupe (%sudo sur Debian, %wheel sur RHEL), jamais à des utilisateurs en direct.

  %sudo   ALL=(ALL:ALL) ALL

• Bannir les négations (R42) : une règle du type ALL, !/bin/su est contournable (chemins alternatifs, copies du binaire). Listez ce qui est autorisé, pas ce qui est interdit.

• Préciser les arguments (R43) : alice ALL=(root) /usr/bin/systemctl restart nginx est bien plus sûr que /usr/bin/systemctl tout court, qui permettrait systemctl edit et donc un shell root.

• Éviter les commandes qui ouvrent un shell : vi, less, find, awk autorisés sans restriction permettent de sortir vers un shell root. Cadrez ou utilisez NOEXEC.

Vérifier

Quelques contrôles rapides :

# La configuration globale est-elle valide ?
sudo visudo -c

# Quelles règles s'appliquent à un utilisateur ?
sudo -lU alice

# Le journal dédié grossit-il à chaque sudo ?
sudo tail -f /var/log/sudo.log

Sécurité et points de vigilance

• Garder un accès de secours : avant de durcir, gardez une session root ou une console ouverte. Une erreur sudoers se corrige depuis cet accès.
• Protéger les journaux : /var/log/sudo.log et /var/log/sudo-io doivent être en accès root uniquement, et idéalement déportés vers un collecteur (un attaquant qui obtient root effacerait les logs locaux).
• Tracer les changements de sudoers : couplez avec auditd, qui surveille /etc/sudoers et /etc/sudoers.d/ (clé scope).
• Revoir régulièrement : sudo -lU <user> pour auditer les droits réels, pas seulement la théorie des fichiers.

Dépannage

Symptôme	Cause probable	Solution
Plus aucun sudo ne fonctionne	Erreur de syntaxe écrite sans visudo	Corriger depuis l'accès root de secours, valider avec visudo -c
Le cron ou un script sudo échoue	requiretty posé	Retirer requiretty, garder use_pty
Rien dans /var/log/sudo.log	logfile absent ou fichier non rechargé	Vérifier /etc/sudoers.d/, droits 0440, relancer une commande
sudoreplay ne trouve rien	log_output non activé	Ajouter log_input, log_output et iolog_dir
Une règle « tout sauf X » est contournée	Usage de négations !	Lister les commandes autorisées explicitement

Glissez pour voir

À retenir

• Toujours visudo : jamais d'édition directe de sudoers
• Journal dédié (logfile) + enregistrement de session (log_input/log_output) rejouable avec sudoreplay
• use_pty (souvent déjà par défaut) et !visiblepw ; jamais requiretty (casse le non-interactif)
• Groupe dédié (R38), pas de négations (R42), arguments précisés (R43)
• Protéger les journaux sudo (root only, déportés) car ils contiennent des traces sensibles
• Référentiels : CIS 5.3 et ANSSI-BP-028 R38 à R44

Prochaines étapes

Tracer avec auditd Journaliser les modifications de /etc/sudoers et corréler avec les actions privilégiées.

Configurer PAM Renforcer l'authentification en amont de sudo : politiques de mot de passe et verrouillage.

CIS Benchmarks Le référentiel d'où viennent ces réglages sudo (section 5.3).

Durcir les points de montage Compléter la réduction de surface au niveau du système de fichiers.

×

📖 Voir la documentation →