"WebAgency" - Collaboration et Sécurisation

Vous venez d'être embauché comme Administrateur Système Junior chez WebAgency, une agence web.

L'entreprise possède un serveur de développement (local pour ce TP) utilisé par plusieurs employés.
Actuellement, c'est le chaos : tout le monde demande le mot de passe root pour travailler, les fichiers sont supprimés par erreur, et les développeurs ne peuvent pas modifier les fichiers de leurs collègues.

Votre mission est de remettre de l'ordre en appliquant le principe du moindre privilège tout en facilitant la collaboration.

(Bonus) Diagnostiquer une restriction AppArmor.

"La Web Agency en pleine croissance"

Vous êtes l'admin d'une agence web dynamique ("WebAgency") qui héberge plusieurs projets sur un serveur de développement mutualisé.

La problématique : Les développeurs doivent pouvoir travailler ensemble sur les mêmes fichiers sans se bloquer mutuellement (problèmes de droits), tout en empêchant les stagiaires de casser la configuration du serveur.

Le TP met l'accent sur :

SGID (Set Group ID): Pour que tous les fichiers créés dans /var/www/projet_X appartiennent automatiquement au groupe devs (collaboration forcée).

Sticky Bit : Sur un dossier /public/echange pour que les utilisateurs puissent déposer des fichiers mais ne puissent supprimer que les leurs.

Sudo restreint: Permettre aux développeurs de relancer le service web (Apache/Nginx) mais sans avoir les droits root complets.

ACL: Donner un accès en lecture seule aux logs (/var/log/syslog) à un utilisateur "auditeur" sans l'ajouter au groupe adm.

Créer une structure utilisateurs/groupes cohérente.

Mettre en œuvre la collaboration via SGID.

Sécuriser un dossier d'échange via le Sticky Bit.

Donner des droits précis via ACL sans modifier les propriétaires.

Déléguer des commandes spécifiques via Sudo.

PARTIE 1 : La nouvelle équipe (Utilisateurs & Groupes)

Le DRH vous envoie la liste des employés à configurer.

Créez les groupes suivants :

• devs (pour les développeurs)
• stagiaires (pour les stagiaires)

Créez les utilisateurs suivants (avec création de leur dossier personnel) :

• colette (Développeuse Senior) :membre principal de devs.
• acamus (Développeur) : membre principal de devs.
• ploti (Stagiaire) : membre principal de stagiaires.
• ezola (Auditeur Externe) : aucun groupe spécifique pour l'instant.

Attribuez un mot de passe simple (ex: azerty) à chacun pour tester les connexions.

Vérification La commande id colette doit montrer qu'elle appartient au groupe devs.

PARTIE 2 : L'espace de collaboration (SGID & Sticky Bit)

Mission A : Le dossier Projet Web (SGID)

colette et acamus travaillent sur le même site web situé dans /srv/projet_web.
Problème : Quand colette crée un fichier, acamus ne peut pas le modifier car le fichier appartient au groupe primaire de colette (colette:colette).

Votre tâche :

1. Créez le dossier /srv/projet_web.
2. Changez le groupe propriétaire du dossier pour devs.
3. Assurez-vous que les membres du groupe devs aient les droits de lecture/écriture/exécution sur le dossier.
4. Interdisez l'accès aux "Autres" (ploti ne doit rien voir).
5. Activez le SGID sur ce dossier.
6. Testez : Connectez-vous en tant que colette, créez un fichier test_Colette.txt dans ce dossier. Vérifiez avec ls -l que le fichier appartient bien au groupe devs automatiquement.

Mission B : Le dossier d'échange (Sticky Bit)

Il existe un dossier /srv/echange où tout le monde (Devs et Stagiaires) peut déposer des fichiers (maquettes, images, idées).
Problème : ploti (le stagiaire) a supprimé par erreur un fichier important déposé par colette.

Votre tâche :

1. Créez le dossier /srv/echange.
2. Donnez les droits complets (rwx) à tout le monde (User, Group, Others) sur ce dossier (attention, c'est risqué, mais nécessaire ici).
3. Activez le Sticky Bit pour empêcher la suppression des fichiers par un tiers.
4. Testez : colette crée un fichier. Connectez-vous en ploti et essayez de le supprimer. Cela doit être refusé.

PARTIE 3 : L'Audit (ACL - Access Control Lists)

ezola, l'auditeur, doit vérifier les logs de connexion pour un audit de sécurité.
Ces fichiers sont à créer dans /var/log/tp_acl/

mkdir -p /var/log/tp_acl
touch /var/log/tp_acl/aclexample.log
chown root:root /var/log/tp_acl/aclexample.log
chmod 640 /var/log/tp_acl/aclexample.log
echo "Access List" > /var/log/tp_acl/aclexample.log

Problème : Ces fichiers appartiennent à root ou syslog. On ne veut pas mettre ezola dans le groupe root, ni changer le propriétaire du fichier.

Votre tâche :

1. Vérifiez les droits actuels du fichier de log.
2. Utilisez les ACL pour donner à l'utilisateur ezola uniquement le droit de lecture (r) sur ce fichier spécifique.
3. Testez : Connectez-vous en ezola et essayez de lire le fichier avec cat. Connectez-vous en ploti et vérifiez qu'il ne peut pas le lire.

PARTIE 4 : Délégation contrôlée (Sudoers)

colette doit pouvoir redémarrer le service web pour appliquer ses changements.
Problème : On ne veut pas lui donner le mot de passe root.

Installation apache2

apt install apache2 -y

Votre tâche :

1. Installez (si besoin) et configurez Sudo.
2. Éditez la configuration (visudo) pour permettre au groupe devs de redémarrer le service Web (systemctl restart apache2) sans entrer de mot de passe.
3. Interdisez toute autre commande root.
4. Testez : En tant que colette, tapez sudo systemctl restart ssh. Ça doit marcher. Tapez sudo apt update (ou autre), ça doit être refusé.

PARTIE 5 : Bonus / Diagnostic (AppArmor)

Le serveur possède un outil de diagnostic. Le stagiaire ploti essaie d'utiliser la commande ping pour tester la connexion vers Google, mais imaginons qu'une politique de sécurité étrange semble bloquer ou logger spécifiquement cet outil (simulation).

Question Quelle commande vous permettrait de vérifier l'état actuel des profils AppArmor chargés sur le système pour voir si des restrictions sont actives ?

Action Exécutez cette commande et notez combien de profils sont en mode "Enforce" (Bloquant) et "Complain" (Apprentissage).

Une machine virtuelle ou un conteneur Linux (Debian/Ubuntu/CentOS).
La correction se fera sur Debian 13
Accès initial au compte root.