# Année 1 — Réalisations en centre - Link: https://dpioch.aristeecampus.org/realisations-en-centre/annee-1-realisations-en-centre/ - Published: 2026-11-13T17:53:56+01:00 - Author: Admin CFA Aristée · La Valette-du-Var · Année 1 · 2025–2026 Les réalisations menées au CFA Aristée pendant la première année du BTS SIO option SISR : administration Windows et Linux, réseau, virtualisation, déploiement, sécurité et supervision. [Voir les réalisations en centre](https://dpioch.aristeecampus.org/realisations-en-centre/) [Le contexte GSB](https://dpioch.aristeecampus.org/realisations-en-centre/contexte-gsb/) ## 1re année · 2025-2026 Bases de l’administration Windows et Linux, réseau, virtualisation et déploiement, puis le laboratoire de sécurité du projet GSB. R01⌊Console Utilisateurs et ordinateurs Active Directory⌉ Windows & AD ### Active Directory — domaine et annuaire Annuaire Active Directory centralisant les comptes et l’authentification : un contrôleur de domaine Windows Server 2022 avec ses unités d’organisation, ses groupes et une administration déléguée. * Windows Server 2022 * AD DS * DNS * PowerShell Voir le détail #### 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. **Service rendu** · Authentification centralisée pour tout le parc et gestion unifiée des identités. #### 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. [Procédure GPO associée](https://dpioch.aristeecampus.org/procedure/creation-dun-gpo/) R02⌊Éditeur de gestion des stratégies de groupe⌉ Windows & AD ### Stratégies de groupe et partage réseau Poste utilisateur configuré par stratégie de groupe : un partage réseau protégé par des droits de partage et NTFS, et une GPO qui mappe le lecteur et applique des paramètres système. * GPO * NTFS * SMB * gpresult Voir le détail #### 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. **Service rendu** · Configuration homogène et reproductible de l’ensemble du parc. #### 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. [Procédure : GPO de mappage](https://dpioch.aristeecampus.org/procedure/creation-dun-gpo/) R03⌊Interface web du serveur FOG⌉ Virtualisation & déploiement ### Masterisation et déploiement de postes avec FOG Serveur FOG sur Debian 13 qui capture l’image d’un poste de référence et la redéploie sur d’autres postes grâce au démarrage réseau PXE. * FOG Project * Debian 13 * PXE * TFTP * DHCP Voir le détail #### 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. **Service rendu** · Masterisation et redéploiement rapides et reproductibles des postes. #### 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. [Procédure : installation de FOG](https://dpioch.aristeecampus.org/procedure/installation-de-fog-sur-debian-13/) R04⌊Machine virtuelle Windows 10 dans VirtualBox⌉ Virtualisation & déploiement ### VM Windows 10 : installation, sauvegarde et restauration Pouvoir récupérer une VM Windows 10 après la perte de son disque et réutiliser un environnement de travail : installation sous VirtualBox, image système, restauration sur un nouveau disque et clonage. * VirtualBox * Windows 10 * Image système * MiniTool Partition Voir le détail #### 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. **Service rendu** · Capacité de restauration éprouvée et gabarit de poste réutilisable. #### 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. [Procédure : sauvegarde et clonage](https://dpioch.aristeecampus.org/procedure/installation-sauvegarde-et-clonage/) R06 ``` *** Welcome to pfSense *** WAN (wan) -> em0 -> v4/DHCP4 LAN (lan) -> em1 -> v4: /24 0) Logout 1) Assign Interfaces 2) Set interface(s) IP address ``` Réseau & pare-feu ### Pare-feu pfSense : filtrage et routage Pare-feu pfSense en machine virtuelle à deux interfaces : routage entre LAN et WAN, NAT sortant, DHCP côté LAN et règles de filtrage vérifiées depuis un poste client. * pfSense * NAT * Firewall * DHCP * VLAN Voir le détail #### 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. **Service rendu** · Point de filtrage et de routage centralisé entre le réseau interne et Internet. #### 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. [Procédure : pfSense](https://dpioch.aristeecampus.org/procedure/installation-de-pfsense/) R09 ``` $ dig @127.0.0.1 malware-c2.example +short 127.0.0.1 ; réécrit par la zone RPZ (sinkhole) $ grep rpz /var/log/named.log rpz QNAME rewrite malware-c2.example via rpz.urlhaus ``` Sécurité & supervision ### Filtrage DNS des domaines malveillants — BIND9 et RPZ Empêcher l’accès à des domaines connus comme malveillants lors de leur résolution DNS, avec BIND9 et des politiques RPZ mises à jour à partir d’URLhaus et de ThreatFox. * BIND9 * RPZ * URLhaus * ThreatFox * cron Voir le détail #### 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. **Service rendu** · Blocage préventif des domaines malveillants dès la résolution de noms. #### 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. R10⌊Tableau de bord WordPress⌉ Systèmes & services ### Serveur web WordPress sur pile LAMP Publier et administrer un site WordPress hébergé sur Debian, en maîtrisant le serveur web Apache, l’exécution PHP et les données stockées dans MariaDB. * Debian * Apache2 * PHP 8.4 * MariaDB * WordPress Voir le détail #### 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. **Service rendu** · Site web hébergé en interne, administrable et maîtrisé de bout en bout. #### 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. [Procédure : WordPress](https://dpioch.aristeecampus.org/procedure/installation-de-wordpress/) R11 ``` MariaDB [(none)]> CREATE ROLE 'admin_role'; Query OK, 0 rows affected MariaDB [(none)]> GRANT admin_role -> TO 'utilisateur1'@'%'; Query OK, 0 rows affected ``` Systèmes & services ### Bases MariaDB pour le projet GSB Trois serveurs MariaDB configurés à l’identique pour le projet GSB : une base par serveur, un rôle d’administration, des comptes nominatifs et un accès distant testé. * MariaDB * SQL * Rôles * Debian Voir le détail #### 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. **Service rendu** · Bases de données opérationnelles, homogènes et administrables par toute l’équipe projet. #### 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. [Procédure : MariaDB GSB](https://dpioch.aristeecampus.org/procedure/mariadb-environnement-gsb/) R12⌊Interface de GLPI⌉ Support & parc ### Inventaire et centre de services avec GLPI GLPI déployé sur une pile LAMP pour tenir l’inventaire du parc, remonté automatiquement par l’agent GLPI sur les postes, et suivre les demandes du support par tickets. * GLPI * GLPI Agent * LAMP * MSI Voir le détail #### 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. **Service rendu** · Inventaire à jour et support utilisateur outillé. #### 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. [Procédure : gestionnaire de parc](https://dpioch.aristeecampus.org/procedure/gestionnaire-de-parc-informatique/) R13 ``` $ sudo tail -f /var/log/suricata/fast.log [Drop] [1:2013028] ET SCAN Nmap Scripting Engine 203.0.113.10:443 -> 192.168.1.45 [Drop] [1:2024897] ET POLICY flux sortant suspect ``` Sécurité & supervision ### Détection et prévention d’intrusion avec Suricata Suricata inspecte le trafic réseau avec les règles Emerging Threats et, configuré en mode inline (NFQUEUE, nftables), peut écarter les paquets qui correspondent à une signature. J’ai installé et réglé l’ensemble sur Debian. * Suricata * NFQUEUE * nftables * EVE JSON Voir le détail #### 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** · Filtrage actif des intrusions au niveau du réseau. R14⌊Console CrowdSec⌉ Sécurité & supervision ### Blocage comportemental des IP avec CrowdSec CrowdSec analyse les journaux (SSH, web, système) pour repérer des comportements hostiles ; un bouncer nftables applique ensuite le bannissement des IP. J’ai mis en place l’analyse et le blocage. * CrowdSec * nftables * cscli Voir le détail #### 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** · Réponse automatique et continue aux attaques répétées. R15 ``` $ /var/ossec/bin/agent_control -l Wazuh agent_control. Available agents: ID:001 bind9 Active ID:002 zabbix Active ID:003 guacamole Active ID:004 ansible Active ``` Sécurité & supervision ### Centralisation des journaux et SIEM Wazuh Centraliser les journaux des machines pour analyser les événements de sécurité avec Wazuh. J’ai déployé les composants centraux, les agents et les fonctions de surveillance décrites dans cette réalisation. * Wazuh * OpenSearch * HIDS * FIM * Active Response Voir le détail #### 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** · Surveillance et réponse de sécurité centralisées. [Procédure : Wazuh](https://dpioch.aristeecampus.org/procedure/deploiement-de-wazuh/) R16 ``` $ systemctl status zabbix-agent2 Active: active (running) $ zabbix_agent2 -t system.cpu.util system.cpu.util [u|3.84] $ zabbix_agent2 -t vfs.fs.size[/,pused] vfs.fs.size[/,pused] [u|41.2] ``` Sécurité & supervision ### Supervision de l’infrastructure avec Zabbix Suivre la disponibilité, le processeur, la mémoire, les disques et les services avec Zabbix afin de repérer les dérives. J’ai configuré le serveur, les agents et les seuils d’alerte. * Zabbix Server * Zabbix Agent 2 * MariaDB * Grafana Voir le détail #### 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** · Supervision proactive : les dérives sont détectées avant l’incident. R22 ``` $ glpi-agent --server https://glpi/front/inventory.php [info] target server0: inventory [info] sending inventory... OK Parc > Ordinateurs Windows inventorié ``` Support & parc ### Gestion de parc avec GLPI et son agent GLPI centralise l’inventaire du parc sur un serveur Debian 13 (Apache, MariaDB) et l’agent GLPI y envoie l’inventaire des postes. J’ai installé le serveur, déployé l’agent et contrôlé les équipements remontés. * GLPI * GLPI Agent * Debian 13 * Apache * MariaDB Voir le détail #### 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** · Inventaire centralisé et meilleure traçabilité des équipements. [Procédure : gestionnaire de parc](https://dpioch.aristeecampus.org/procedure/gestionnaire-de-parc-informatique/) [Procédure : agent GLPI](https://dpioch.aristeecampus.org/procedure/deploiement-de-glpi-agent/) R25 ``` C:\> gpupdate /force Mise à jour de la stratégie... La mise à jour de la stratégie utilisateur s'est terminée. C:\> gpresult /r | find "GPO" ``` Windows & AD ### Création et déploiement d'une stratégie de groupe Une stratégie de groupe configure les postes et utilisateurs d’un domaine depuis le serveur. J’ai créé une GPO, l’ai liée à l’unité d’organisation concernée et ai contrôlé son application sur un poste client. * Windows Server * Active Directory * GPO Voir le détail #### 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** · Administration centralisée et reproductible des postes du domaine. [Procédure : GPO](https://dpioch.aristeecampus.org/procedure/creation-dun-gpo/) R47 ``` VM Windows Server 2019 (VirtualBox) AD DS · OU ADMIN / ORDINATEUR / UTILISATEURS 2 machines jointes · GPO d’essai ``` Windows & AD ### Contrôleur de domaine Windows Server 2019 : OU, comptes et GPO d’essai Installer dans VirtualBox un Windows Server 2019 avec le rôle Active Directory, créer des unités d’organisation et des comptes, joindre deux machines au domaine et tester une GPO d’arrière-plan. * Windows Server 2019 * Active Directory * VirtualBox Voir le détail #### 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. **Service rendu** · Domaine de test opérationnel, avec deux machines jointes et une GPO appliquée. [Procédure : GPO](https://dpioch.aristeecampus.org/procedure/creation-dun-gpo/)