"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).

Element complémentaire : vérifiez les politiques globales de mots de passe

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.

Pour avoir plus de choix disponible nous allons instaler le paquet rsyslog et redémarrer via les commandes

apt install rsyslog -y
reboot

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.

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é).

Element complémentaire : traçabilité des actions sudo
Toutes les commandes exécutées via sudo sont journalisées. Mais comment ?

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 ?

Element complémentaire : audit des binaires SUID sur le système

En tant qu'administrateur sécurité, il est essentiel de savoir quels binaires possèdent le bit SUID sur le système. Un binaire SUID compromis est une porte d'entrée directe vers les droits root.

PARTIE 4 : 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

Element complémentaire : différence entre verrouillage et désactivation du shell

Cette distinction est fondamentale en infogérance : un client qui demande une coupure d'accès immédiate attend que toutes les voies d'accès soient fermées, pas uniquement le mot de passe

Prérequis

Machine virtuelle Linux.

Accès root initial.

Éditeur nano ou vim.