Durcir sudo : moins de risques, zéro friction

Il y a deux types de machines Linux.

Celles où « sudo » est un outil pratique, presque invisible. Et celles où « sudo » devient une bombe à retardement. Pas parce que sudo est mauvais. Mais parce qu’on l’a laissé vivre sa vie. Avec des droits trop larges, des habitudes un peu sales, des exceptions empilées au fil des mois.

Et ça, en 2026, c’est encore plus vrai parce que les environnements bougent vite : VPS jetables, CI/CD, containers, équipes distribuées, freelances qui se connectent deux semaines puis disparaissent. Bref. Du mouvement. Et sudo déteste le mouvement quand il n’est pas cadré.

Dans cet article, on va durcir sudo sans casser le quotidien. Moins de risques, zéro friction. Enfin… zéro friction réaliste. On ne va pas transformer votre serveur en coffre-fort inutilisable.

Petit clin d’œil au passage : si vous aimez ce genre de contenu SysAdmin pratique, il y en a pas mal sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com), surtout quand ça touche Linux et la productivité. Fin de l’interruption.

---

Pourquoi sudo est souvent le point faible (même quand tout le reste est « ok »)

Le problème classique, c’est le réflexe : « je mets l’utilisateur dans sudoers et c’est réglé ». Oui. Sauf que « c’est réglé » veut souvent dire :

• pas de traçabilité propre (ou logs incomplets)
• des commandes autorisées trop larges, parfois avec des jokers
• des environnements sudo qui gardent des variables dangereuses
• des timeouts longs, donc une session sudo ouverte pendant que vous partez prendre un café
• et parfois, le pire… NOPASSWD: ALL pour « gagner du temps »

Durcir sudo, ce n’est pas ajouter des obstacles. C’est enlever les angles morts.

---

Avant de toucher à quoi que ce soit : un rappel des fichiers qui comptent

Sur la majorité des distributions :

• /etc/sudoers : fichier principal (à ne JAMAIS éditer avec un éditeur normal)
• /etc/sudoers.d/ : snippets modulaires, beaucoup plus propres à maintenir
• logs : selon votre configuration, ça part dans journald, syslog, ou un fichier dédié

Règle d’or : utilisez visudo. Toujours.

bash sudo visudo

Et pour un fichier dans sudoers.d :

bash sudo visudo -f /etc/sudoers.d/90-mon-equipe

visudo vous évite le classique « oups j’ai cassé sudo et je suis dehors ».

---

Étape 1 : activer une vraie journalisation (et la rendre exploitable)

Loguer ce qui est tapé, pas juste le fait qu’une commande a été lancée

Sudo peut enregistrer l’entrée et la sortie des sessions. C’est très utile quand vous avez besoin de comprendre ce qui a été fait, surtout si la commande appelle un shell ou déclenche d’autres actions.

Ajoutez dans un fichier dédié :

bash sudo visudo -f /etc/sudoers.d/10-logging

Puis :

sudoers Defaults log_output Defaults iolog_dir="/var/log/sudo-io" Defaults iolog_file="%{seq}" Defaults logfile="/var/log/sudo.log"

Créez le dossier et verrouillez les droits :

bash sudo mkdir -p /var/log/sudo-io sudo chown root:root /var/log/sudo-io sudo chmod 700 /var/log/sudo-io sudo touch /var/log/sudo.log sudo chown root:root /var/log/sudo.log sudo chmod 600 /var/log/sudo.log

Si vous utilisez systemd, vous pouvez aussi centraliser via journald, mais avoir un fichier dédié rend l’audit plus rapide. Surtout quand vous devez extraire une période précise.

Image : où regarder quand on audite sudo

---

Étape 2 : couper ce qui fuit souvent… l’environnement

C’est un point sous-estimé. Certaines variables d’environnement peuvent changer le comportement de commandes privilégiées. Et parfois, ça devient un vecteur d’escalade ou de contournement.

Dans un fichier :

bash sudo visudo -f /etc/sudoers.d/20-env

Ajoutez :

sudoers Defaults env_reset Defaults use_pty Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Defaults env_keep -= "LD_PRELOAD LD_LIBRARY_PATH PYTHONPATH PERL5LIB RUBYLIB"

Deux notes rapides :

• use_pty aide côté traçabilité et limite certains abus (et c’est franchement une bonne pratique moderne).
• secure_path évite le « je lance la mauvaise commande parce que mon PATH est bizarre ». Ça arrive plus souvent qu’on veut l’admettre.

---

Étape 3 : réduire la fenêtre de tir (timeout et re-auth)

Le ticket sudo qui reste valide trop longtemps, c’est pratique. Mais c’est aussi le scénario « laptop déverrouillé, session ouverte, quelqu’un passe ».

Toujours dans un snippet :

bash sudo visudo -f /etc/sudoers.d/30-timeout

Exemple :

sudoers Defaults timestamp_timeout=5 Defaults passwd_timeout=1

• timestamp_timeout=5 : 5 minutes, c’est un bon compromis pour éviter de retaper le mot de passe toutes les 30 secondes.
• Vous pouvez mettre 0 pour demander le mot de passe à chaque fois. Sécurisé, mais friction réelle.
• -1 : à éviter sauf cas très particulier (ticket permanent).

Pour une compréhension plus approfondie sur la sécurité en matière d'IA et les erreurs fatales à éviter, je vous recommande cet article qui aborde ces 7 erreurs fatales de la sécurité IA.

Étape 4 : dire non à NOPASSWD: ALL (mais garder un workflow fluide)

Si vous avez NOPASSWD: ALL, vous avez déjà perdu une partie du contrôle. Même si tout le monde est « de confiance ». Parce que la confiance ne protège pas d’un poste compromis, d’un token volé, d’un script malicieux, d’un copier coller foireux.

La bonne approche, c’est de rendre certaines commandes non interactives. Pas tout.

Exemple concret : déployer un service sans donner la clé du royaume

Supposons un utilisateur deploy qui doit :

• relancer un service systemd
• lire des logs
• faire un git pull dans un répertoire

On peut autoriser uniquement :

bash sudo visudo -f /etc/sudoers.d/50-deploy

sudoers User_Alias DEPLOY = deploy

Cmnd_Alias SVC = /bin/systemctl restart monapp, /bin/systemctl status monapp Cmnd_Alias LOGS = /usr/bin/journalctl -u monapp * Cmnd_Alias APP = /usr/bin/test, /usr/bin/git, /usr/bin/find, /usr/bin/grep

DEPLOY ALL=(root) NOPASSWD: SVC, LOGS DEPLOY ALL=(root) PASSWD: APP

Vous voyez l’idée : ce qui doit tourner en automation peut être NOPASSWD, le reste reste protégé.

Image : penser sudo comme une matrice de commandes

---

Étape 5 : bannir les jokers dangereux (ou les encadrer strictement)

Le joker * est parfois nécessaire. Mais il est aussi la porte ouverte au contournement.

Exemples qui sentent mauvais :

• autoriser /usr/bin/vim * en root
• autoriser /bin/bash *
• autoriser /usr/bin/python3 *
• autoriser des outils qui peuvent exécuter des commandes shell (less, man, tar selon options, etc.)

Le point clé : si vous autorisez un éditeur ou un interpréteur en root, vous autorisez souvent une escalade totale. Même sans le vouloir.

À la place :

• autorisez une commande précise avec des arguments précis
• ou créez un wrapper root, minimal, audité
• ou utilisez un service systemd dédié avec des permissions limitées

C’est moins « sexy », mais c’est propre.

Pour éviter de telles erreurs de sécurité, il est essentiel d'adopter des pratiques robustes. Vous pouvez consulter cet article sur les erreurs fatales de la sécurité IA pour plus d'informations sur ce sujet crucial.

Étape 6 : passer par des groupes et des règles lisibles (sinon ça finit en jungle)

Si vous êtes seul, vous pouvez bricoler. Si vous êtes deux ou plus, vous devez structurer.

Exemple :

sudoers %ops ALL=(root) /bin/systemctl restart nginx, /bin/systemctl status nginx %dev ALL=(www-data) /usr/bin/php /var/www/app/artisan cache:clear

Et vous mettez les gens dans les groupes. Point.

En plus, quand quelqu’un part, vous retirez du groupe. Vous ne cherchez pas dans 14 fichiers ce que vous lui aviez donné.

---

Étape 7 : exiger un mot de passe fort… ou mieux, du MFA via SSH (et sudo reste sobre)

Sudo ne fait pas MFA « tout seul » de façon universelle. Le vrai gain, il est en amont :

• clés SSH
• sshd_config durci
• MFA côté IdP si vous passez par un bastion, ou via PAM selon contexte
• désactivation du password login quand possible

Ensuite sudo devient le deuxième verrou, pas le premier.

Je le dis parce que je vois encore des setups où SSH est faible, et sudo est la seule barrière. Mauvaise idée. Sudo n’est pas là pour compenser une porte d’entrée ouverte.

---

Étape 8 : tester sans se tirer une balle dans le pied

Quand vous changez sudoers :

1. gardez une session root ouverte (console ou autre) le temps de valider
2. validez avec visudo (il check la syntaxe)
3. testez avec un utilisateur ciblé :

bash sudo -l

Vous voyez exactement ce que l’utilisateur a le droit de faire.

Astuce anti panique

Si vous êtes sur un VPS et que vous risquez de vous verrouiller dehors, assurez-vous d’avoir l’accès console du provider (KVM, console web). Ça sauve des nuits.

---

Petit kit de durcissement « prêt à coller » (base saine)

Si vous voulez un socle simple :

bash sudo visudo -f /etc/sudoers.d/00-baseline

sudoers Defaults env_reset Defaults use_pty Defaults log_output Defaults iolog_dir="/var/log/sudo-io" Defaults logfile="/var/log/sudo.log" Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Defaults timestamp_timeout=5

Puis vous ajoutez des fichiers par équipe, par rôle, par machine.

C’est lisible. C’est maintenable. Et surtout, ça évite le « gros fichier sudoers modifié 40 fois ».

---

Le vrai objectif : moins de risques, sans ralentir les gens

Durcir sudo, ça échoue quand on le fait comme une punition. Ça marche quand on le fait comme une ergonomie de sécurité.

Quelques principes simples :

• donnez les droits minimums, mais donnez les bons
• évitez les outils qui ouvrent un shell
• loguez correctement
• évitez les jokers à l’aveugle
• organisez vos règles dans sudoers.d/
• gardez une fenêtre de ticket raisonnable

Et si vous voulez, je peux aussi publier une checklist téléchargeable et une version orientée « équipe remote + freelances » sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com). Typiquement le genre de situation où sudo se transforme vite en patchwork.

Pour éviter des erreurs de sécurité courantes qui peuvent transformer votre système en un véritable casse-tête, il est essentiel d'adopter des pratiques de sécurité robustes. Une erreur de sécurité unique peut avoir des conséquences désastreuses.

Ressources rapides (à garder sous la main)

• man sudoers
• visudo
• sudo -l
• journalctl -t sudo (selon config)
• audit : /var/log/sudo.log et /var/log/sudo-io/

---

Si vous ne faites qu’une seule chose aujourd’hui : supprimez NOPASSWD: ALL, activez use_pty, et mettez une vraie journalisation. Rien que ça, c’est déjà un gros saut en avant.

Questions fréquemment posées

Pourquoi sudo est-il souvent considéré comme un point faible dans la gestion des machines Linux ?

Sudo devient un point faible lorsqu'il est mal configuré : droits trop larges, absence de traçabilité, commandes autorisées avec des jokers, variables d'environnement dangereuses conservées, timeouts longs et usage excessif de 'NOPASSWD: ALL'. Ces mauvaises pratiques augmentent les risques de sécurité malgré une apparente simplicité.

Quels fichiers sont essentiels pour configurer sudo correctement sur la plupart des distributions Linux ?

Les fichiers clés sont '/etc/sudoers', qui est le fichier principal à ne jamais éditer directement avec un éditeur classique, et le répertoire '/etc/sudoers.d/' contenant des snippets modulaires plus faciles à maintenir. Toujours utiliser 'visudo' pour éditer ces fichiers afin d'éviter de bloquer l'accès sudo.

Comment activer une journalisation efficace des commandes sudo pour améliorer la traçabilité ?

Il faut configurer sudo pour enregistrer non seulement les commandes lancées mais aussi leurs entrées et sorties en ajoutant des directives dans un fichier dédié sous '/etc/sudoers.d/'. Créez ensuite un dossier sécurisé '/var/log/sudo-io' pour stocker ces logs détaillés, ce qui facilite grandement l'audit et la compréhension des actions réalisées.

Pourquoi est-il important de contrôler l'environnement lors de l'utilisation de sudo ?

Certaines variables d'environnement peuvent modifier le comportement des commandes exécutées avec privilèges, créant ainsi des vecteurs d'escalade ou de contournement. En activant 'env_reset', 'use_pty' et en définissant un 'secure_path', on limite ces risques en nettoyant l'environnement et en renforçant la sécurité.

Quelles bonnes pratiques recommande-t-on pour durcir sudo sans perturber le quotidien des utilisateurs ?

Il s'agit d'enlever les angles morts en limitant les droits excessifs, améliorant la journalisation, contrôlant l'environnement, évitant les exceptions inutiles comme 'NOPASSWD: ALL', tout en gardant une expérience utilisateur fluide. L'objectif est moins de friction mais plus de sécurité réaliste adaptée aux environnements dynamiques.

Quels outils ou ressources peut-on consulter pour approfondir la gestion sécurisée de sudo et Linux ?

Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com) propose du contenu pratique sur SysAdmin, Linux et productivité. Ce type de ressource aide à comprendre les bonnes pratiques actuelles pour gérer efficacement sudo dans des environnements modernes comme VPS jetables, containers ou équipes distribuées.