Année 1 — Réalisations en centre

Service rendu et besoin

Active Directory Domain Services (AD DS) centralise les identités d’un parc Windows : un même compte de domaine permet de se connecter aux postes autorisés, sans recréer un compte local partout. Cette réalisation porte sur l’annuaire et sa délégation ; R02 traite l’usage des partages et des stratégies de groupe.

Fonctionnement

Le contrôleur de domaine conserve les objets utilisateurs, ordinateurs et groupes et assure l’authentification, notamment avec Kerberos. Le DNS permet aux clients de retrouver ce contrôleur. Les unités d’organisation (OU) classent les objets et délimitent l’administration déléguée ; les groupes de sécurité servent à attribuer les droits. Déléguer une OU évite de donner des privilèges sur tout le domaine. Un domaine à contrôleur unique ne constitue pas une solution redondante.

Prérequis techniques et organisationnels

Prérequis généraux : un serveur Windows Server correctement nommé, un adressage stable, un DNS adapté au domaine et des droits d’administration pour créer celui-ci. Le client doit utiliser un DNS capable de retrouver le domaine et avoir une édition Windows compatible avec la jonction. Il faut aussi définir les OU, les groupes et les responsabilités d’administration avant de créer les objets.

Mise en œuvre

1. Installation du rôle AD DS sur Windows Server 2022
2. Promotion en contrôleur de domaine et création du domaine dorian.lan
3. Création des unités d’organisation : Admins, Utilisateurs, Ordinateurs, Service Pro
4. Création des comptes et des groupes de sécurité
5. Délégation de droits d’administration par unité d’organisation
6. Jonction d’un poste Windows 10 au domaine et test d’ouverture de session

Résultat et contrôles

La jonction d’un poste Windows 10 et l’ouverture d’une session de domaine ont été testées après la création de l’annuaire. Ce contrôle porte sur l’intégration du client ; il n’établit pas la tolérance aux pannes du domaine.

Compétences validées

• Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : unités d’organisation, groupes de sécurité et délégation de l’administration selon le moindre privilège.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service et réaliser les tests d’intégration : promotion du contrôleur de domaine, puis jonction d’un poste et test d’ouverture de session.

Service rendu et besoin

Le service fournit aux utilisateurs un dossier commun, accessible depuis un lecteur réseau, et applique des paramètres homogènes aux postes. Il évite de configurer chaque session manuellement. Contrairement à la création de l’annuaire (R01) ou à la procédure GPO ciblée (R25), l’objectif est ici l’environnement de travail obtenu.

Fonctionnement

Le serveur publie le dossier par SMB, le protocole de partage de fichiers Windows. L’accès dépend à la fois des permissions du partage et des droits NTFS sur les fichiers : l’autorisation effective reste limitée par les deux. La stratégie de groupe (GPO), liée à une unité d’organisation (OU), applique les paramètres aux objets concernés selon son filtrage. Sa préférence de mappage associe un chemin réseau UNC, qui désigne un dossier partagé, à une lettre de lecteur. Elle facilite l’accès, mais n’accorde aucun droit supplémentaire sur le dossier. Sans accès au domaine, le poste ne peut pas actualiser ses stratégies.

Prérequis techniques et organisationnels

Prérequis généraux : un domaine fonctionnel, un poste joint au domaine, la console de gestion des stratégies de groupe (GPMC), une OU contenant les utilisateurs visés et un groupe de sécurité pour les autorisations. Il faut disposer d’un dossier partagé joignable et décider qui peut lire ou modifier son contenu.

Mise en œuvre

1. Création d’un dossier partagé sur le serveur
2. Réglage des permissions de partage et NTFS au plus juste
3. Création d’une GPO liée à une unité d’organisation
4. Mappage automatique d’un lecteur réseau par préférence de GPO
5. Application de paramètres système (fond d’écran, restrictions)
6. Vérification sur le poste avec gpupdate /force puis gpresult /r

Résultat et contrôles

Le contrôle sur le poste s’appuie sur gpupdate /force pour demander l’actualisation, puis gpresult /r pour vérifier les GPO appliquées. Ces outils renseignent l’application de la stratégie ; les permissions du partage restent une couche distincte.

Compétences validées

• Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation : permissions de partage et NTFS réglées au plus juste ; vérifier le respect des règles d’utilisation des ressources numériques : restrictions appliquées aux postes par GPO.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service et réaliser les tests d’intégration : lecteur réseau mappé automatiquement, application contrôlée avec gpupdate et gpresult.

Service rendu et besoin

FOG sert à remettre des postes dans un état logiciel commun sans réinstaller manuellement Windows et les applications. Un poste de référence fournit l’image maître, ensuite réutilisée pour le déploiement. Le gain recherché est la reproductibilité.

Fonctionnement

Au démarrage PXE, le poste reçoit son adressage par DHCP. Dans le montage documenté, les options 66 et 67 désignent le serveur FOG et le fichier de démarrage, chargé initialement par TFTP. L’environnement FOG prend ensuite en charge la capture ou la réécriture du disque selon la tâche définie dans l’interface web. Le fichier de démarrage doit correspondre au mode BIOS ou UEFI. Une image de déploiement ne remplace pas la sauvegarde des données utilisateur : son application peut écraser le disque cible.

Prérequis techniques et organisationnels

Prérequis généraux : Debian 13 à jour, adresse fixe, accès administrateur, stockage suffisant pour les images, poste de référence préparé et cible compatible PXE. La procédure utilise un DHCP existant, distinct de FOG, dont il faut pouvoir modifier les options. Avant un déploiement, il faut identifier le bon poste, vérifier la compatibilité matérielle et autoriser l’effacement des données. L’image de référence doit ensuite être maintenue à jour.

Mise en œuvre

1. Installation de FOG sur une Debian 13 disposant d’une pile LAMP
2. Configuration du DHCP (options 66 et 67) pour le démarrage PXE
3. Capture d’une image maître depuis un poste Windows 10 de référence
4. Déploiement de l’image sur un poste cible par démarrage réseau
5. Suivi des tâches depuis l’interface web et changement des identifiants par défaut
6. Rédaction de la procédure de capture et de déploiement

Résultat et contrôles

L’image du poste Windows 10 de référence a été capturée puis déployée sur un poste cible. C’est le test d’intégration documenté, distinct de la simple ouverture du tableau de bord FOG. Les identifiants par défaut ont été changés.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : serveur FOG et chaîne de démarrage réseau (DHCP options 66 et 67, TFTP) ; réaliser les tests d’intégration : déploiement de l’image maître sur un poste cible.

Service rendu et besoin

Cette réalisation apprend à récupérer un environnement Windows après perte de son disque et à préparer un gabarit réutilisable pour les exercices. La sauvegarde conserve un état du système ; la restauration vérifie qu’il peut être réutilisé. Le clonage produit une nouvelle VM à partir de l’existante.

Fonctionnement

VirtualBox présente à Windows des composants virtuels, dont ses disques. L’outil « Sauvegarder et restaurer » crée une image des volumes nécessaires au système sur un second disque. L’environnement de récupération, lancé depuis l’ISO Windows, permet ensuite de réappliquer cette image sur un disque de remplacement. La partition réservée au système a été agrandie avec MiniTool Partition Wizard dans ce travail ; cette opération dépend du partitionnement et n’est pas une exigence universelle. Un second disque situé sur le même hôte ne protège pas de la perte de cet hôte.

Prérequis techniques et organisationnels

Prérequis généraux : VirtualBox, une image ISO Windows, des ressources disponibles sur l’hôte et assez de stockage pour le système, sa sauvegarde et sa restauration. La procédure prévoit environ 120 Go libres. Avant d’utiliser un clone comme poste distinct, il faut prévoir sa généralisation avec Sysprep (retrait des informations propres au poste) et de nouvelles identités réseau ; cette préparation est une recommandation, pas une action supplémentaire attestée ici.

Mise en œuvre

1. Création de la VM (8 Go de RAM, 4 vCPU, disque SSD virtuel) et installation de Windows 10
2. Extension de la partition réservée au système avec MiniTool Partition Wizard
3. Création d’une image système depuis « Sauvegarder et restaurer »
4. Restauration de l’image sur un nouveau disque via l’environnement de récupération
5. Clonage de la VM pour obtenir un modèle de déploiement

Résultat et contrôles

Une image système a été créée puis restaurée sur un nouveau disque via l’environnement de récupération. Le clonage a fourni un modèle réutilisable. Ce contrôle concerne une VM de laboratoire, sans mesure de délai ni validation d’un plan de reprise complet.

Compétences validées

• Gérer le patrimoine informatique — Gérer des sauvegardes : création d’une image système, puis restauration testée sur un nouveau disque via l’environnement de récupération.

Service rendu et besoin

pfSense place un point de contrôle entre le réseau interne (LAN) et le réseau amont (WAN). Il donne aux postes un accès réseau tout en décidant quels flux peuvent passer. La centralisation des règles évite de dépendre uniquement des protections propres à chaque poste.

Fonctionnement

Le routage choisit où envoyer les paquets ; le NAT sortant traduit les adresses privées vers l’adresse de sortie. Ce NAT ne remplace pas le filtrage. Le pare-feu à états mémorise les connexions autorisées pour reconnaître les paquets de retour. Sur une interface, les règles ordinaires sont parcourues de haut en bas : la première correspondance décide du traitement. Le DHCP distribue l’adressage aux clients du LAN. Seul le trafic traversant pfSense est contrôlé : les échanges directs entre postes d’un même réseau ne passent pas nécessairement par lui.

Prérequis techniques et organisationnels

Prérequis généraux : une VM compatible avec pfSense CE, deux cartes réseau séparant WAN et LAN, un plan d’adressage cohérent, un accès au réseau amont et un poste client de test. Il faut définir les flux utiles et les accès d’administration autorisés avant d’écrire les règles. Un accès console doit rester disponible si une règle coupe l’administration web.

Mise en œuvre

1. Installation de pfSense sur une machine virtuelle à deux interfaces
2. Affectation des interfaces WAN et LAN et adressage
3. Assistant de configuration initiale et changement du mot de passe administrateur
4. Configuration du serveur DHCP côté LAN
5. Création des règles de pare-feu et vérification du NAT sortant
6. Tests de connectivité et de blocage depuis un poste client

Résultat et contrôles

Des tests de connectivité et de blocage ont été effectués depuis un poste client après la configuration des interfaces, du DHCP, du filtrage et du NAT sortant. Leur portée reste celle de cette intégration : ni audit exhaustif des règles ni déploiement de VLAN n’est attesté par ces étapes.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : pare-feu pfSense assurant routage, NAT sortant et DHCP côté LAN ; réaliser les tests d’intégration : tests de connectivité et de blocage depuis un poste client.

Service rendu et besoin

Le service cherche à empêcher un poste de joindre un domaine déjà identifié comme malveillant. Le filtrage intervient lors de la résolution DNS, avant la connexion qui dépend de cette réponse. Il complète le pare-feu, sans garantir le blocage de toutes les communications malveillantes.

Fonctionnement

BIND9 répond aux requêtes DNS. Ses zones de politique de réponse (RPZ) remplacent certaines réponses normales par une décision locale. Ici, les domaines listés sont redirigés vers un sinkhole, une adresse de substitution, et les réécritures sont journalisées. Des tâches planifiées mettent à jour les données issues d’URLhaus et de ThreatFox. Ces sources contiennent des indicateurs différents : seuls les domaines exploitables doivent alimenter la politique DNS. La qualité du filtrage dépend donc des données importées et de leur actualisation.

Prérequis techniques et organisationnels

Prérequis généraux : un serveur Debian administrable, BIND9, des clients utilisant ce résolveur et un accès aux sources de renseignement. Il faut prévoir le traitement des listes, leur mise à jour, la conservation des journaux et la gestion des faux positifs. Les API actuelles d’abuse.ch demandent une clé d’accès ; cela ne prouve pas son mode de gestion dans ce déploiement. Un accès direct par IP ou un résolveur externe, notamment DNS chiffré, peut contourner ce filtrage.

Mise en œuvre

1. Installation et configuration de BIND9 sur Debian
2. Création des zones internes
3. Configuration des Response Policy Zones
4. Téléchargement automatique des flux URLhaus et ThreatFox par tâche planifiée
5. Redirection des domaines listés vers un sinkhole
6. Journalisation des réécritures pour l’audit

Résultat et contrôles

Le contrôle d’intégration déclaré est la réécriture d’un domaine listé vers le sinkhole, avec journalisation. Il ne démontre ni l’interception de toutes les connexions ni le blocage d’une infection réelle ; les sorties de console illustratives n’ajoutent pas de validation.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : serveur BIND9 avec zones RPZ alimentées automatiquement par URLhaus et ThreatFox ; réaliser les tests d’intégration : résolution d’un domaine listé réécrite vers le sinkhole et journalisée.

Service rendu et besoin

WordPress fournit un site dont les contenus sont administrables depuis un navigateur. L’hébergement sur Debian permet de gérer soi-même le système, le serveur web et la base, au lieu de dépendre d’une plateforme hébergée. Il implique aussi d’en assurer l’entretien.

Fonctionnement

La pile LAMP associe Linux, Apache, MariaDB et PHP. Apache reçoit les requêtes et sélectionne le site avec son hôte virtuel ; PHP exécute WordPress, qui lit ou enregistre les contenus dans MariaDB. Un compte applicatif limité à la base du site évite d’utiliser le compte administrateur du serveur SQL. Cette restriction réduit les droits disponibles en cas de compromission de l’application, mais ne garantit pas la protection de toutes les données. Les permissions des fichiers et la maintenance des extensions restent importantes.

Prérequis techniques et organisationnels

Prérequis généraux : une Debian à jour, des droits d’administration, un adressage stable, un nom DNS pointant vers le serveur et des versions compatibles de PHP, MariaDB et des extensions requises. Il faut prévoir un responsable des mises à jour, des sauvegardes des fichiers et de la base, ainsi qu’un certificat pour HTTPS. Ces dispositions d’exploitation ne sont pas toutes attestées par les actions ci-dessous.

Mise en œuvre

1. Installation d’Apache, PHP 8.4 et MariaDB
2. Sécurisation de MariaDB avec mysql_secure_installation
3. Création d’une base dédiée et d’un compte applicatif aux droits limités
4. Déploiement de WordPress et réglage des droits de fichiers
5. Configuration du virtual host et assistant d’installation
6. Vérification du service et documentation

Résultat et contrôles

Le service a été vérifié après l’assistant d’installation. La réalisation documente la pile, la base dédiée, les droits et l’hôte virtuel ; elle ne permet pas d’affirmer que HTTPS ou une restauration de sauvegarde ont été validés. La procédure les présente comme des éléments d’exploitation à prévoir.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : pile LAMP, base dédiée et compte applicatif aux droits limités, virtual host ; réaliser les tests d’intégration : vérification du service après l’assistant d’installation.

Service rendu et besoin

Le projet GSB nécessite trois bases accessibles à l’équipe. La même méthode de configuration est appliquée aux trois serveurs, avec une base propre à chacun. L’objectif est d’éviter des comptes et des droits incohérents d’un serveur à l’autre, pas de mettre en place une réplication ou un cluster.

Fonctionnement

MariaDB stocke les données et contrôle les requêtes selon le compte connecté. Le rôle admin_role rassemble les privilèges attribués aux administrateurs nominatifs ; le rôle par défaut les active dès la connexion. Le compte étudiant dispose de droits de lecture et de modification des données, sans changement de structure. Les rôles regroupent les droits dans chaque instance : ils ne synchronisent pas automatiquement les trois serveurs. L’accès distant exige aussi une écoute réseau et une autorisation correspondant à l’origine du client.

Prérequis techniques et organisationnels

Prérequis généraux : MariaDB installé et démarré, une version compatible avec les rôles, un accès d’administration SQL, les identités des utilisateurs et une politique de droits commune. Il faut définir les postes autorisés à se connecter. L’écoute sur toutes les interfaces et les comptes autorisés depuis tout hôte, décrits dans la procédure de laboratoire, ne constituent pas un filtrage réseau restrictif.

Mise en œuvre

1. Vérification du service et exécution de mysql_secure_installation
2. Création du rôle admin_role et des droits associés
3. Création des comptes administrateurs nominatifs et du compte étudiant
4. Attribution du rôle et activation par défaut
5. Ouverture de l’écoute réseau et tests de connexion depuis les postes

Résultat et contrôles

Les connexions distantes depuis les postes ont été testées. La procédure mentionne un mot de passe commun pour le travail en équipe : il s’agit d’une limite du montage pédagogique, pas d’une pratique de production. Les exemples SQL affichés ne sont pas des journaux d’exécution.

Compétences validées

• Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : rôle admin_role, comptes nominatifs et droits centralisés plutôt qu’attribués compte par compte.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service : trois serveurs configurés à l’identique ; réaliser les tests d’intégration : tests de connexion à distance depuis les postes.

Service rendu et besoin

GLPI réunit la connaissance du parc et le suivi de l’assistance. Les fiches de matériel et de logiciels aident à identifier les ressources concernées ; les tickets gardent une trace des demandes, de leur affectation et de leur traitement. Cela évite de dépendre d’un inventaire saisi uniquement à la main et de messages dispersés.

Fonctionnement

Le serveur GLPI est une application web sur une pile LAMP (Linux, Apache, MariaDB, PHP). L’agent installé par paquet MSI sous Windows collecte les caractéristiques matérielles et logicielles du poste puis les transmet au serveur, qui met à jour l’inventaire. Les entités organisent le périmètre des données ; les profils définissent les actions autorisées. Les catégories classent les tickets et les accords de niveau de service (SLA) fixent des délais cibles. Configurer un SLA ne prouve pas que ces délais ont été respectés.

Prérequis techniques et organisationnels

Prérequis généraux : un serveur avec un environnement web, PHP et MariaDB compatibles, une URL stable, l’inventaire activé dans GLPI et des postes capables de joindre cette URL. L’installation du MSI demande des droits locaux suffisants. Il faut aussi désigner les responsables du support, définir les catégories et délais attendus, protéger les données d’inventaire et attribuer des profils adaptés. Ce sont des conditions d’exploitation, pas de nouveaux contrôles réalisés.

Mise en œuvre

1. Installation de GLPI sur une pile LAMP
2. Création des entités, profils et utilisateurs
3. Déploiement de l’agent GLPI sur les postes (paquet MSI)
4. Remontée automatique de l’inventaire matériel et logiciel
5. Configuration des catégories de tickets et des SLA

Résultat et contrôles

Les remontées automatiques d’inventaire, les entités, profils, utilisateurs, catégories de tickets et SLA sont documentés. La fiche n’atteste pas la résolution d’un incident réel ni le respect mesuré d’un délai. La visibilité du parc reste liée aux postes équipés et aux inventaires effectivement reçus.

Compétences validées

• Gérer le patrimoine informatique — Recenser et identifier les ressources numériques : inventaire matériel et logiciel remonté automatiquement par l’agent GLPI.
• Répondre aux incidents et aux demandes d’assistance et d’évolution — Collecter, suivre et orienter des demandes : module de tickets, catégories et délais de traitement (SLA).
• Mettre à disposition des utilisateurs un service informatique — Déployer un service : installation de GLPI, entités, profils et utilisateurs.

Service rendu et besoin

Un filtrage réseau limité aux adresses, aux ports et aux protocoles ne suffit pas à examiner le contenu applicatif des échanges. Suricata ajoute cette lecture du contenu : il compare le trafic à des signatures (ici le jeu de règles Emerging Threats) pour repérer des scans, des exploits ou des flux suspects. L’intérêt de la mise en place est de ne pas se limiter à une alerte lue après coup, mais de pouvoir stopper un flux malveillant au moment où il passe.

Fonctionnement

Il faut distinguer deux usages. En mode détection (IDS), Suricata observe le trafic, génère des alertes et ne bloque rien. En mode prévention (IPS) inline, le trafic passe par lui : nftables redirige les paquets vers une file NFQUEUE du noyau, Suricata les lit, applique ses règles, puis rend un verdict. Une règle d’action « drop » écarte le paquet ; une règle « alert » signale sans bloquer. La présence de signatures ne signifie donc pas qu’elles bloquent toutes. Les événements sont journalisés, ici au format EVE JSON, ce qui permet de les exploiter ensuite avec d’autres outils.

Prérequis techniques et organisationnels

Prérequis généraux : un hôte Linux placé sur le chemin du trafic à filtrer, un noyau avec Netfilter/nftables et le support NFQUEUE, des règles à jour, et de quoi réduire les faux positifs. En inline, une panne ou une surcharge de Suricata peut couper le trafic qu’il traite, et un faux positif bloque du trafic légitime : l’ajustement des règles fait partie du service.

Périmètre de cette réalisation : Suricata sur Debian, mode inline par NFQUEUE et nftables, règles Emerging Threats, journalisation EVE JSON, ajustement des règles contre les faux positifs.

Mise en œuvre

1. Installation de Suricata sur Debian
2. Passage en mode IPS inline via NFQUEUE et nftables
3. Intégration des règles Emerging Threats
4. Test de détection : un scan Nmap doit être bloqué
5. Journalisation au format EVE JSON
6. Ajustement des règles pour réduire les faux positifs

Résultat et contrôles

Le test documenté est un scan Nmap, qui doit être bloqué et journalisé. La fiche ne détaille ni le nombre de signatures chargées ni les mesures de performance, et le bloc de commande affiché dans la vignette est une illustration, pas une preuve supplémentaire.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : Suricata en mode IPS inline (NFQUEUE, nftables) avec les règles Emerging Threats ; réaliser les tests d’intégration : un scan Nmap est bloqué et journalisé.

Service rendu et besoin

Les attaques par force brute ou les scans se repèrent dans les journaux : tentatives SSH échouées à répétition, requêtes web anormales. CrowdSec lit ces journaux pour détecter ces comportements et décider quelles adresses IP sont hostiles. La mise en place évite d’avoir à surveiller les fichiers de log à la main et de bloquer les adresses une par une.

Fonctionnement

Le fonctionnement se fait en deux parties distinctes. L’agent (moteur CrowdSec) analyse : il applique des scénarios sur les journaux et produit des décisions (par exemple « bannir cette IP »). Le bouncer exécute : c’est un composant séparé qui interroge ces décisions et les applique, ici dans nftables. Sans bouncer, CrowdSec détecte et enregistre, mais ne bloque rien. La liste de blocage communautaire ajoute des adresses signalées par d’autres utilisateurs de CrowdSec, en plus de ce que l’agent détecte localement.

Prérequis techniques et organisationnels

Prérequis généraux : accès en lecture aux journaux à analyser, collections adaptées aux services présents, un composant de filtrage (ici nftables) que le bouncer peut piloter, et les accès nécessaires aux services communautaires utilisés. Un compte de console est nécessaire si l’on utilise cette interface de gestion. Un bannissement mal paramétré peut couper un administrateur légitime : il faut connaître les adresses à ne jamais bloquer.

Périmètre de cette réalisation : CrowdSec avec les collections linux, http et sshd, scénarios de détection activés, bouncer nftables, inscription à la liste communautaire, suivi avec cscli et la console web.

Mise en œuvre

1. Installation de CrowdSec et des collections linux, http et sshd
2. Activation des scénarios de détection
3. Mise en place du bouncer nftables
4. Inscription à la liste de blocage communautaire
5. Test : une force brute SSH entraîne le bannissement de l’IP
6. Suivi avec cscli et la console web

Résultat et contrôles

Le test documenté est une force brute SSH qui entraîne le bannissement de l’adresse.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : CrowdSec, scénarios de détection et bouncer nftables ; réaliser les tests d’intégration : une force brute SSH entraîne le bannissement de l’adresse.

Service rendu et besoin

Sur plusieurs machines, chaque journal reste sur son hôte : un incident se perd dans la masse ou n’est vu qu’une fois les dégâts faits. Wazuh rassemble les événements en un point unique, les analyse avec des règles et signale ce qui sort de l’ordinaire. C’est une brique de collecte et d’analyse des événements de sécurité (SIEM), associée à la détection sur les hôtes (HIDS), qui sert à voir et à comprendre les événements, pas seulement à constater qu’un service répond.

Fonctionnement

Quatre éléments se partagent le travail. L’agent, installé sur chaque hôte, collecte les journaux et surveille l’intégrité de fichiers (FIM). Le manager reçoit ces données, les passe dans son moteur de règles et génère des alertes. L’indexer (OpenSearch) stocke et indexe ces alertes. Le dashboard est l’interface web de consultation. L’Active Response est une fonction du manager qui peut lancer un script sur un agent quand une règle se déclenche ; elle n’agit que si on la configure sur des règles précises.

Prérequis techniques et organisationnels

Prérequis généraux : un système pris en charge, des ressources dimensionnées pour l’indexation et la durée de conservation des événements, des agents autorisés à lire les journaux, et des communications limitées aux composants concernés. Il faut définir les machines à suivre, les journaux utiles et la personne chargée de traiter les alertes. L’installation centrale et le déploiement des agents sont deux opérations distinctes ; le guide lié décrit surtout l’installation centrale.

Périmètre de cette réalisation : manager, indexer OpenSearch et dashboard déployés, agents sur les hôtes surveillés, règles de détection et FIM activés, règles adaptées au lab, Active Response configurée sur des règles critiques.

Mise en œuvre

1. Déploiement du manager, de l’indexer OpenSearch et du dashboard
2. Installation d’agents sur les machines surveillées
3. Activation des règles de détection et du contrôle d’intégrité (FIM)
4. Création de règles adaptées au contexte du lab
5. Configuration de l’Active Response sur les règles critiques

Résultat et contrôles

La réalisation présente le déploiement des composants centraux, l’installation des agents, le contrôle d’intégrité et la configuration de règles. La procédure associée conserve des contrôles finaux à compléter ; aucun déclenchement d’alerte ou d’Active Response n’y est attesté. Il faut distinguer les fonctions configurées de leur validation par un événement de test.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : manager, indexer et tableau de bord Wazuh, agents installés sur les hôtes surveillés, règles de détection et contrôle d’intégrité activés.

Service rendu et besoin

Un utilisateur ne devrait pas être le premier à découvrir qu’un disque est plein ou qu’un serveur est surchargé. Zabbix mesure en continu la disponibilité et l’état des machines, conserve l’historique et prévient quand une valeur dépasse un seuil. Il aide à agir avant une interruption, sans garantir qu’une panne sera toujours prévisible.

Fonctionnement

Le serveur Zabbix stocke ses données dans une base (ici MariaDB). Sur chaque hôte, l’agent 2 répond aux requêtes du serveur ou lui envoie des valeurs : processeur, mémoire, espace disque, état de services. Des modèles regroupent les éléments à surveiller par type de machine. Un déclencheur transforme une valeur en problème : si la mesure franchit un seuil, une alerte est créée. Les tableaux de bord affichent ces données ; une intégration avec Grafana est également possible. Zabbix répond à « la machine fonctionne-t-elle, et avec quelle marge ? » ; ce n’est pas un SIEM, qui analyse des événements de sécurité issus des journaux (voir Wazuh, R15).

Prérequis techniques et organisationnels

Prérequis généraux : un serveur avec sa base de données, une connectivité entre serveur et agents, un agent installé et déclaré sur chaque hôte, et des seuils réfléchis pour éviter à la fois le silence et le bruit d’alertes. Il faut aussi définir qui reçoit les alertes.

Périmètre de cette réalisation : serveur Zabbix avec MariaDB, agent 2 sur chaque hôte, modèles CPU, mémoire, disque et services, déclencheurs à plus de 80 % de CPU et plus de 90 % de disque, alertes et tableaux de bord.

Mise en œuvre

1. Installation du serveur Zabbix et de sa base
2. Déploiement de l’agent 2 sur chaque hôte
3. Application des modèles (CPU, mémoire, disque, services)
4. Définition des déclencheurs (CPU > 80 %, disque > 90 %)
5. Configuration des alertes et tableaux de bord

Résultat et contrôles

Le serveur, les modèles de supervision, les seuils et les tableaux de bord sont configurés dans cette réalisation. Les valeurs affichées dans la vignette sont illustratives. Pour valider une chaîne d’alerte complète, il faut vérifier le passage en problème puis le retour à la normale et la réception de la notification par son destinataire.

Compétences validées

• Gérer le patrimoine informatique — Vérifier les conditions de la continuité d’un service informatique : supervision de la disponibilité et déclencheurs sur le processeur et le disque pour agir avant la panne.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service : serveur Zabbix, agents sur chaque hôte, modèles, alertes et tableaux de bord.

Service rendu et besoin

Sans inventaire fiable, on ignore quels postes existent, avec quel matériel et quels logiciels, et le suivi des interventions s’appuie sur des tableaux à la main. GLPI sert de référentiel unique du parc et de centre de services (tickets, utilisateurs, profils). L’agent évite de saisir chaque poste manuellement.

Fonctionnement

Il y a deux composants. Le serveur GLPI est une application web (Apache, PHP) adossée à une base MariaDB : il stocke les équipements et reçoit les inventaires. L’agent GLPI tourne sur chaque poste, collecte le matériel, le système et les logiciels, puis envoie le résultat au serveur à l’URL configurée. L’inventaire natif doit être activé côté serveur, sinon les envois sont ignorés. Si le poste ne joint pas le serveur ou refuse son certificat HTTPS, son inventaire ne peut pas être actualisé.

Prérequis techniques et organisationnels

Prérequis généraux : côté serveur, une machine Debian avec IP fixe et nom DNS, Apache, PHP et MariaDB, l’inventaire activé dans GLPI. Côté poste, des droits administrateur locaux pour installer l’agent et une connexion HTTP(S) vers le serveur. La procédure du portfolio indique 2 vCPU, 2 Go de RAM et 20 Go de disque au minimum ; ce sont ses prérequis, pas une mesure sur la machine réalisée.

Périmètre de cette réalisation : GLPI sur Debian 13 avec Apache, PHP et MariaDB ; agent installé sur les postes avec le serveur cible paramétré ; inventaire lancé.

Mise en œuvre

1. Préparation d’un serveur Debian 13 avec Apache, PHP et MariaDB
2. Déploiement et configuration de GLPI
3. Installation de l’agent sur les postes et paramétrage du serveur cible
4. Lancement de l’inventaire et contrôle des équipements remontés
5. Validation du fonctionnement et documentation

Technologies

• GLPI
• GLPI Agent
• Debian 13
• Apache
• MariaDB

Résultat et contrôles

Les équipements remontés après le premier inventaire ont été contrôlés dans GLPI. Ce contrôle relie l’installation de l’agent à un résultat côté serveur : une fiche matériel et logiciel effectivement reçue. L’extrait de la vignette reste une illustration, pas un inventaire exhaustif du parc.

Compétences validées

• Gérer le patrimoine informatique — Recenser et identifier les ressources numériques : inventaire remonté par l’agent et contrôle des équipements dans GLPI.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service : GLPI sur Debian 13 et agent sur les postes ; réaliser les tests d’intégration : validation du fonctionnement après le premier inventaire.

Service rendu et besoin

Dans un domaine, régler chaque poste à la main est long et produit des écarts. Une stratégie de groupe (GPO) enregistre des paramètres une fois sur le serveur et les applique aux comptes ou ordinateurs ciblés. La procédure du portfolio prend l’exemple d’un lecteur réseau connecté automatiquement.

Fonctionnement

Une GPO est un objet Active Directory contenant des paramètres. Elle n’agit que si elle est liée à un site, un domaine ou une unité d’organisation (OU). Les postes la récupèrent à l’ouverture de session ou au démarrage, puis périodiquement ; gpupdate force l’actualisation. Le résultat dépend de la portée : OU liée, filtrage de sécurité, et ordre de traitement si plusieurs GPO se cumulent. gpresult affiche les GPO réellement appliquées à l’utilisateur ou au poste. Une GPO configure l’application d’un réglage, elle ne remplace pas les droits d’accès : pour un partage, les droits de partage et NTFS restent nécessaires.

Prérequis techniques et organisationnels

Prérequis généraux : un domaine Active Directory fonctionnel, un poste joint au domaine, les utilisateurs ou ordinateurs placés dans l’OU visée, la console GPMC et un poste capable de joindre un contrôleur de domaine. Pour l’exemple du lecteur réseau : un partage et un groupe de sécurité.

Périmètre de cette réalisation : Windows Server et Active Directory, GPO créée dans la console de gestion, paramètres configurés, GPO liée à l’OU concernée, actualisation sur un poste client et contrôle avec gpresult.

Mise en œuvre

1. Création de la GPO dans la console de gestion
2. Configuration des paramètres
3. Liaison à l’unité d’organisation concernée
4. Actualisation des stratégies sur un poste client
5. Contrôle avec gpresult

Technologies

• Windows Server
• Active Directory
• GPO

Résultat et contrôles

L’application de la stratégie est contrôlée sur un poste client avec gpresult. Pour un lecteur réseau, ce résultat doit être rapproché de son apparition dans la session et d’un accès au partage conforme aux droits de l’utilisateur. Le nom d’une GPO dans la console serveur ne suffit pas à prouver son application.

Compétences validées

• Mettre à disposition des utilisateurs un service informatique — Déployer un service : stratégie de groupe créée et liée à l’unité d’organisation ; réaliser les tests d’intégration : application contrôlée sur un poste client avec gpresult.

Service rendu et besoin

Un annuaire centralise comptes et postes. L’exercice, mené sur une journée au CFA avec mon formateur, consistait à le monter dans un environnement de test, à vérifier qu’une machine peut rejoindre le domaine et qu’une stratégie de groupe s’applique.

Fonctionnement

Le rôle AD DS transforme le serveur en contrôleur de domaine. Les unités d’organisation (ici ADMIN, ORDINATEUR et UTILISATEURS) rangent les objets et servent de cibles aux stratégies. Une GPO de test modifie l’arrière-plan des utilisateurs concernés : l’image est copiée sur les postes par la GPO, à partir du dossier SYSVOL, un répertoire partagé par chaque contrôleur de domaine, avec un élément de préférence « Fichiers » dont on renseigne la source.

Prérequis techniques et organisationnels

Exigences générales : un hôte capable de faire tourner la machine virtuelle, l’image d’installation de Windows Server, un nom de domaine de test et des clients à joindre. Dans ce cas : VirtualBox sur un PC fixe hôte, machine virtuelle dotée de 8 Go de mémoire, 150 Go de stockage et deux cœurs du processeur, plus un ordinateur portable.

Mise en œuvre

1. Création d’une machine virtuelle VirtualBox sous Windows Server 2019.
2. Ajout du rôle Active Directory depuis « Ajouter des rôles et fonctionnalités » et création d’un domaine de test.
3. Création des unités d’organisation ADMIN, ORDINATEUR et UTILISATEURS.
4. Création d’un compte administrateur puis d’un compte utilisateur de test.
5. Jonction au domaine de deux machines, une virtuelle et une physique, avec test d’ouverture de session.
6. Création d’une GPO de test pour l’arrière-plan : image copiée via SYSVOL, GPO appliquée à des objets AD, puis essai.

Résultat et contrôles

Les deux jonctions au domaine et l’application de la GPO d’essai ont été testées et ont fonctionné.

Compétences validées

• Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : unités d’organisation et comptes de l’annuaire.
• Mettre à disposition des utilisateurs un service informatique — Déployer un service et réaliser les tests d’intégration : contrôleur de domaine, jonction de deux machines et GPO testée.