"TechSupport" - Gestion Multi-Niveaux

Vous travaillez pour TechSupport, une entreprise qui gère les serveurs de grands clients bancaires. Pour des raisons de sécurité et de traçabilité, l'accès au compte root est strictement interdit aux équipes de support.

L'équipe est divisée en deux niveaux :

Niveau 1 (N1) : Diagnostic, surveillance, lecture de logs. Ne doit rien modifier.

Niveau 2 (N2) : Intervention, redémarrage de services, gestion du stockage.

Votre mission est de configurer un serveur vierge pour accueillir ces équipes avec des droits parfaitement ajustés.

Ce TP est probablement le plus technique des trois. Il vous amène à manipuler la syntaxe précise du fichier sudoers, à comprendre la différence fondamentale entre l’élévation temporaire via Sudo et l’élévation contextuelle via SUID, ainsi qu’à gérer le cycle de vie des comptes.

Utiliser Sudo avec Alias pour définir des périmètres d'action stricts.

Comprendre et mettre en place le SUID pour des exécutables spécifiques.

Protéger la configuration système avec des Attributs Immuables.

Gérer la sécurité des comptes (expiration, verrouillage).

PARTIE 1 : La Hiérarchie (Groupes & Utilisateurs)

Créez les groupes techniques :

support_n1

support_n2.

Créez les employés :

sdebeauvoir (Support N1) membre du groupe support_n1.

adumas (Support N2) membre du groupe support_n2.

gsand (Manager) membre d'aucun groupe technique.

Simulez un prestataire temporaire : Créez l'utilisateur arimbaud avec une date de fin de validité de compte fixée à dans 30 jours (utilisez useradd avec l'option adéquate ou chage).

PARTIE 2 : Délégation Chirurgicale (Sudoers & Alias)

Nous devons donner des droits précis. L'édition du fichier /etc/sudoers doit se faire via visudo.

Définition des Alias de Commandes (Cmnd_Alias) :

Créez un alias CMD_LECTURE contenant : /bin/cat, /usr/bin/tail, /bin/grep.

Créez un alias CMD_SERVICES contenant : /bin/systemctl.

Règles pour le Niveau 1 (sdebeauvoir) :

Elle doit pouvoir lancer les commandes de CMD_LECTURE sur n'importe quel fichier, mais sans mot de passe (pour l'automatisation).

Elle doit pouvoir vérifier l'état des services (systemctl status) mais pas les redémarrer. Astuce : Sudo permet de spécifier des arguments précis. Essayez d'autoriser /bin/systemctl status *.

Règles pour le Niveau 2 (adumas) :

Il a le droit d'utiliser CMD_SERVICES (restart, stop, start) avec mot de passe.

Il doit pouvoir monter des disques (/bin/mount), mais uniquement s'il est authentifié.

Test de sécurité :

Connectez-vous en sdebeauvoir. Peut-elle lire /var/log/syslog ? (Oui).

Peut-elle lire /etc/shadow avec sudo cat ? (Oui, et c'est un problème de sécurité à noter ! Sudo sur cat est dangereux).

Essaie-t-elle de redémarrer un service ? (Doit être refusé).

PARTIE 3 : L'outil "Hérité" (Le SUID)

Le client utilise un très vieux programme de sauvegarde interne (simulé ici) qui doit tourner avec les droits root, mais qui doit être lancé par l'équipe N2. On ne veut pas passer par Sudo pour des raisons de compatibilité de script.

Simulation du programme :

En tant que root, créez un petit script ou copiez une commande inoffensive. Pour l'exercice, nous allons copier la commande touch (qui sert à créer des fichiers vides) vers /usr/local/bin/super_touch.

cp /bin/touch /usr/local/bin/super_touch

Configuration des droits :

Attribuez le fichier au groupe support_n2.

Restreignez les droits : Seul root et le groupe peuvent l'exécuter (750).

Activez le SUID (Set User ID) sur ce binaire.

L'expérience :

Connectez-vous en adumas (N2). Allez dans un dossier appartenant à root (ex: /etc/).

Essayez

touch test_adumas.txt

Échec (Permission denied).

Essayez

/usr/local/bin/super_touch test_adumas_suid.txt

Succès !

Analyse : Vérifiez à qui appartient le fichier créé. Il appartient à root, même si c'est adumas qui l'a créé. Pourquoi ?

PARTIE 4 : Protection contre l'erreur humaine (Chattr)

Même avec Sudo, une erreur est vite arrivée (ex: rm -rf /etc par accident). Certains fichiers critiques ne doivent jamais être supprimés, même par root, tant qu'on n'a pas explicitement levé la sécurité.

Créez un fichier de configuration critique : /etc/config_client.conf.

Ajoutez l'attribut Immuable (+i) à ce fichier.

Le test du crash :

Restez en root.

Essayez de supprimer le fichier avec rm -f.

Essayez de modifier le fichier avec nano ou echo.

Tout doit échouer.

Retirez la protection pour pouvoir le modifier.

PARTIE 5 : Gestion des départs (Verrouillage)

adumas quitte l'entreprise brutalement. Vous devez couper ses accès immédiatement sans supprimer son compte (pour garder l'historique de ses actions).

Verrouillez le compte de adumas (Lock).

Vérifiez dans le fichier /etc/shadow à quoi ressemble la ligne de adumas (cherchez le !).

Essayez de vous connecter en adumas

su - adumas

Prérequis

Machine virtuelle Linux.

Accès root initial.

Éditeur nano ou vim.