Présentation du projet

Contexte de l'entreprise

NexaGroup est une ESN (Entreprise de Services du Numérique) fondée en 2015, spécialisée dans le développement web, l'intégration de solutions métier et le conseil en transformation digitale. L’entreprise compte 75 collaborateurs répartis sur deux sites :

• Site principal — Paris : siège social, 55 salariés, hébergeant l’infrastructure principale.
• Site secondaire — Lyon : antenne régionale, 20 salariés, reliée au siège via VPN site-à-site.

Enjeux et objectifs du projet

Dans un contexte de croissance et de montée en criticité des services numériques, NexaGroup a engagé un projet de modernisation de son infrastructure. Les principaux objectifs sont :

• Assurer la haute disponibilité des services cœur (authentification, données, supervision) via des mécanismes de redondance.
• Renforcer la sécurité par une segmentation fine en VLAN et un contrôle centralisé des flux réseau.
• Améliorer la visibilité et la supervision de l’infrastructure (alertes, tableaux de bord, corrélation d’événements).
• Fournir des services collaboratifs modernes (partage de fichiers, visioconférence, helpdesk) aux équipes internes.

Périmètre de la solution mise en œuvre

Le projet couvre l’infrastructure réseau et serveurs des deux sites (Paris et Lyon), incluant le routage, la sécurité périmétrique, les services Active Directory, la supervision et les outils collaboratifs internes.

Environnement technique

Architecture réseau

L’architecture réseau de NexaGroup est conçue autour d’un cœur redondé basé sur un cluster de pare-feux pfSense HA. Elle s’appuie sur une segmentation par VLAN afin d’isoler les usages (serveurs, postes clients, DMZ, administration et site distant) et de maîtriser les flux inter‑zones.

Vue logique des zones

Plan d'adressage IP

Principes de routage et de flux

• Tout le trafic inter‑VLAN transite par le cluster pfSense (routage + filtrage L3/L4).
• Les flux entre VLAN 20 / 60 (postes) et VLAN 10 (serveurs) sont limités aux ports applicatifs nécessaires.
• La DMZ (VLAN 30) est isolée : aucun accès direct depuis les postes clients ; seuls des flux contrôlés vers les serveurs internes sont autorisés.
• Le site distant (VLAN 50/60) est joint via un tunnel VPN WireGuard chiffré, terminé sur les pare‑feux pfSense.

Segmentation VLAN

La segmentation par VLAN permet de cloisonner les usages (postes, serveurs, DMZ, administration, site distant) et de limiter l’impact d’un incident de sécurité à une zone donnée. Chaque VLAN est associé à une politique de filtrage spécifique au niveau du cluster pfSense.

Rôle des principaux VLAN

Schéma de l'infrastructure

Le schéma ci‑dessous représente les principales zones (LAN, DMZ, site distant, Internet), la répartition des VLAN et le rôle du cluster pfSense dans le routage et la sécurisation des flux.

Cluster Pare-feu HA (pfSense) En production

# 1. VPN > WireGuard > Status
#    Latest Handshake < 2 min + Transfer RX/TX en augmentation

# 2. Ping tunnel point-à-point (depuis Lyon)
ping 10.100.0.1

# 3. Ping SRV-AD01 Paris depuis client VLAN 60
ping 192.168.10.5

# 4. Résolution DNS
nslookup srv-glpi.barrault.pb 192.168.10.5

# 5. Test failover HA : suspendre PFSENSE-01
#    Résultat attendu : perte max 1-2 paquets, reprise auto < 5 s
#    Vérifier PFSENSE-02 : Status > CARP = MASTER
#    Vérifier : VPN > WireGuard > Status > Latest Handshake récent

# Sur pfSense Paris — VPN > WireGuard > Status
# Ou depuis le shell :
wg show

# Observer le champ "transfer" du peer Lyon :
#   transfer: 1.23 MiB received, 4.56 MiB sent
# Lancer un ping depuis un client VLAN 60 (Lyon) vers 192.168.10.5
# Les valeurs TX/RX doivent augmenter → trafic dans le tunnel ✓

# Sur pfSense Paris — Diagnostics > Packet Capture > Interface WAN
# Ou depuis le shell :
tcpdump -ni em0 host 203.0.113.4

# Résultat attendu : uniquement des paquets UDP port 51820
# (trafic WireGuard chiffré)
# Si on voit du ICMP, TCP 389, TCP 445 en clair → le trafic ne passe PAS
# par le tunnel → vérifier les routes statiques et la gateway WG

# Depuis un poste Windows VLAN 60 (Lyon)
tracert 192.168.10.5

# Résultat attendu :
#   1    <1 ms   192.168.60.254   (pfSense Lyon — gateway VLAN 60)
#   2    <5 ms   192.168.10.5     (SRV-AD01 Paris)
#
# Si un saut 203.0.113.x apparaît → trafic en clair sur VMnet5
# → vérifier : System > Routing > Static Routes
#              gateway = GW_WG_PARIS (10.100.0.1) et non WAN

1. Depuis un client, lancer : ping 8.8.8.8 -t
2. Suspendre SRV-PFSENSE-01
3. Résultat attendu : perte de 1 à 2 paquets maximum, puis reprise via SRV-PFSENSE-02 qui passe en statut MASTER.

Contrôleurs de domaine (AD DS / DNS / DHCP) En production

OU=Entreprise
  ├── OU=Utilisateurs
  ├── OU=Ordinateurs
  ├── OU=Groupes
  └── OU=Services (ex: SVC_Nextcloud)

Serveur de données (SRV-BDD) En production

# Port 22 : ALLOW depuis VLAN 40 (Administration)
# Port 3306 : ALLOW depuis 192.168.10.0/24 uniquement
# Politique par défaut : DENY INCOMING

Nextcloud & Talk (SRV-NEXTCLOUD) En production

1. Identification & Rôle

2. Intégration réseau

3. Paramétrage & Configuration

• Serveur Web : Apache2 + module SSL.
• PHP : apcu, gd, imagick, ldap, mysql, zip, intl
• Certificat SSL : Auto-signé (CN: nextcloud.barrault.pb) — requis pour Talk.
• Service TURN (Coturn) : Coïmplanté sur SRV-NEXTCLOUD, Port 3478, auth: static-auth-secret.

Base de données (sur SRV-BDD)

• Nom : nextclouddb | Utilisateur : nc_user

Domaines de confiance (config.php)

'trusted_domains' => array (
  0 => '192.168.10.35',
  1 => 'nextcloud.barrault.pb',
),
'overwriteprotocol' => 'https',

4. Sécurité & Règles pare-feu

Intégration Active Directory (LDAP)

• Serveur LDAP : 192.168.10.5 (Port 389)
• Bind DN : CN=SVC_Nextcloud,OU=NEXTCLOUD,OU=Groupe SERVICES,DC=barrault,DC=pb
• Filtre utilisateurs : Groupe "Nextcloud Users"

5. Tests & Validation

Authentification via compte AD fonctionnelle. Appels audio/vidéo Talk opérationnels via le serveur TURN.

SIEM Wazuh (SRV-WAZUH) En production

1. Identification & Rôle

2. Intégration réseau

3. Paramétrage & Configuration

• Stockage dédié : Second disque de 50 Go monté sur /var/lib/wazuh-indexer. Point persistant via /etc/fstab.
• Accès Dashboard : https://wazuh.barrault.pb (Login: admin). Certificat auto-signé.
• Données analysées : Journaux Windows (Sécurité/Système), Intégrité FIM, Vulnérabilités.

Déploiement agent (exemple SRV-AD01)

- OS Agent : Windows
- Server address : 192.168.10.40
- Groupe : Default
- Démarrage du service : NET START WazuhSvc

4. Sécurité & Règles pare-feu

Ports ouverts (UFW) :

• 443/tcp : Interface Web (Dashboard)
• 1514/tcp : Remontée des logs agents
• 1515/tcp : Enrôlement des agents
• 55000/tcp : API Wazuh
• 514/udp : Réception Syslog (pfSense)

5. Composants Wazuh (Version 4.9)

Schéma d'architecture SIEM

6. Intégration pfSense → Wazuh (Syslog)

Types de logs collectés depuis pfSense

7. Couverture par VLAN

8. Matrice de risque

9. Procédure d'installation (Annexe)

Préparation stockage (disque dédié Indexer)

# Exemple (Debian/Ubuntu) : disque /dev/sdb (50 Go) monté pour l'Indexer
sudo mkdir -p /var/lib/wazuh-indexer
sudo mkfs.ext4 /dev/sdb1
# Ajouter dans /etc/fstab (UUID) puis :
sudo mount -a
df -h | grep wazuh

Installation Wazuh (script officiel)

sudo apt update && sudo apt upgrade -y
sudo apt install curl apt-transport-https unzip wget libcap2-bin software-properties-common gnupg2 -y

curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash wazuh-install.sh -a -o

DNS & accès dashboard

• Créer l'enregistrement DNS wazuh → 192.168.10.40 dans la zone barrault.pb (sur SRV-AD01).
• Accès : https://wazuh.barrault.pb (certificat auto-signé).

Enrôlement agent (exemple Windows : SRV-AD01)

# Dans le dashboard : Add agent (OS Windows) / Server address 192.168.10.40 / Group Default
# Puis sur le serveur Windows :
NET START WazuhSvc

Point de vigilance (pipeline d'alertes)

Commandes de diagnostic utiles

# Indices OpenSearch (alertes)
curl -u admin:admin https://192.168.10.40:9200/_cat/indices/wazuh-alerts*

# Logs Wazuh
tail -f /var/ossec/logs/ossec.log
tail -f /var/ossec/logs/alerts/alerts.json

# Agents
/var/ossec/bin/agent_control -l

# Test connectivité agent -> manager (Windows)
Test-NetConnection -ComputerName 192.168.10.40 -Port 1514

10. Tests & Validation

Remontée des alertes de sécurité Windows réussie. Création d'événements de test FIM détectée et indexée.

GLPI — Gestion de parc & Helpdesk (SRV-GLPI) En production

1. Identification & Rôle

2. Intégration réseau

3. Paramétrage & Configuration

Pile applicative

• Serveur Web : Apache2 avec module PHP
• PHP : Extensions requises (curl, gd, intl, ldap, mysql, xml, zip, mbstring)
• Base de données : Externalisée sur SRV-BDD (192.168.10.30)
  • Base : glpidb
  • Utilisateur : glpi_user
  • Accès restreint depuis 192.168.10.25 uniquement

Intégration Active Directory

• Annuaire LDAP configuré vers 192.168.10.5 (port 389)
• Importation automatique des utilisateurs et groupes AD
• Authentification unique via les identifiants du domaine barrault.pb

Fonctionnalités activées

• Inventaire automatique du parc (via agent GLPI / FusionInventory)
• Module Helpdesk : création et suivi de tickets par les utilisateurs
• Gestion des contrats, licences logicielles et fournisseurs

4. Sécurité & Règles pare-feu

Pare-feu local (UFW)

# Port 22  : ALLOW depuis VLAN 40 (Administration SSH)
# Port 80  : ALLOW depuis 192.168.0.0/16 (Accès Web interne)
# Port 443 : ALLOW depuis 192.168.0.0/16 (HTTPS)
# Politique par défaut : DENY INCOMING

5. Tests & Validation

• Accès à l'interface web vérifié depuis les VLAN 20 et 40.
• Authentification LDAP fonctionnelle avec les comptes du domaine.
• Remontée d'inventaire automatique validée sur les postes clients.

6. Architecture distribuée (3-Tiers)

7. Sécurisation HTTPS & HSTS

Le protocole HTTPS est rendu obligatoire pour protéger les authentifications (mots de passe AD) et les données d'inventaire.

• Modules Apache : mod_ssl, mod_rewrite, mod_headers
• Certificat : RSA 2048 bits / SHA-256 — signé par la CA interne pfSense
• Port 80 : Redirection permanente (301) vers HTTPS
• Port 443 : SSLEngine on + HSTS activé (force l'utilisation HTTPS)
• DocumentRoot : /var/www/html/glpi/public (obligatoire depuis GLPI 10)
• Sessions PHP : session.cookie_httponly = On (prévention XSS)

8. Configuration LDAP détaillée

• Serveur primaire : 192.168.10.5 (SRV-AD01) — Port 389
• Serveur secondaire : 192.168.10.10 (SRV-AD02)
• BaseDN : DC=barrault,DC=pb
• Bind DN : CN=glpi_bind,OU=Services,DC=barrault,DC=pb
• Attribut login : samaccountname
• Filtre : Exclusion des comptes désactivés via userAccountControl
• Synchronisation : CRON quotidien à 03h00 via glpi:ldap:synchronize_users

9. Inventaire automatisé (Agent GLPI)

• URL de collecte : https://srv-glpi.barrault.pb/front/inventory.php
• Postes clients (VLAN 20) : Déploiement automatisé via GPO (Startup Script)
• Serveurs (VLAN 10/30) : Déploiement via Ansible
• Périmètre : Matériel, logiciel, antivirus, volumes disques

10. Matrice des flux réseau

Supervision (SRV-ZABBIX) En production

1. Identification & Rôle

2. Intégration réseau

3. Paramétrage & Configuration

Architecture

• Serveur Zabbix : Collecteur de métriques et moteur d'alertes
• Frontend Web : Apache2 + PHP (accès via https://srv-zabbix.barrault.pb)
• Base de données : Externalisée sur SRV-BDD (192.168.10.30)
  • Base : zabbixdb
  • Utilisateur : zabbix_user

Schéma d'architecture monitoring

Éléments supervisés

4. Déploiement des agents Zabbix

Méthode de déploiement réellement utilisée

Exécution du script sur Debian

# Sur chaque machine Debian/Ubuntu cible
sudo bash zabbix_deploy.sh

Ce que fait le script zabbix_deploy.sh

• Installe zabbix-agent2 via le dépôt Zabbix correspondant à l'OS détecté.
• Configure /etc/zabbix/zabbix_agent2.conf (Server, ServerActive, Hostname).
• Active et redémarre le service zabbix-agent2 (systemctl enable/restart).
• Tente l'ajout automatique de l'hôte dans Zabbix via l'API (hostgroup.get, template.get, host.create).

Paramètres clés (zabbix_agentd.conf)

• Server=192.168.10.20 (Autorise Zabbix à interroger l'agent)
• ServerActive=192.168.10.20 (Pour les éléments actifs si configurés)
• Hostname=<FQDN_Machine> (Doit correspondre exactement au nom dans l'UI Zabbix)

5.1 Compte rendu technique

Incidents rencontrés (extraits)

Supervision pfSense via SNMP (HA CARP)

# pfSense : Services > SNMP : Enable, Port 161, Read Community (ex: public)
# Test depuis SRV-ZABBIX :
apt install snmp -y
snmpwalk -v2c -c public 10.0.0.2 .1.3.6.1.2.1.1

Widgets de dashboard recommandés

5. Modèles (Templates) et Déclencheurs (Triggers)

6. Notifications et Alerting

• Média de notification : Email via relais SMTP interne (Postfix)
• Destinataires : Groupe IT (VLAN 40)
• Conditions de déclenchement : Uniquement pour les alertes de sévérité High et Disaster.

7. Plan d'Action & Matrice de Risque

8. Sécurité & Règles pare-feu

• 10050/tcp : Agent Zabbix (passif) — ouvert sur chaque hôte supervisé
• 10051/tcp : Zabbix Server (trapper) — ouvert sur SRV-ZABBIX
• 443/tcp : Frontend Web — depuis VLAN 40 uniquement
• 161/udp : SNMP — interrogation des équipements réseau (pfSense)

9. Tests & Validation

• Remontée des métriques vérifiée pour tous les hôtes enregistrés dans l'interface Web.
• Déclenchement de triggers testé (simulation de charge CPU via stress, espace disque faible).
• Notifications par e-mail fonctionnelles reçues sur la boîte IT.

VLAN 20 — Clients Utilisateurs En production

1. Identification & Rôle

Ce VLAN regroupe les postes de travail (ex: CLT-WIN) des collaborateurs du site principal. Ils accèdent aux ressources internes (VLAN 10) et à internet, tout en étant isolés de la DMZ (VLAN 30) et du domaine d'administration (VLAN 40).

2. Intégration réseau

3. Sécurité

• Le trafic vers les autres VLAN est soumis à des ACL strictes dans pfSense.
• Filtrage internet sortant via proxy/pfSense.

Infrastructure Web & Reverse Proxy (DMZ) En production

1. Identification & Rôle

2. Intégration réseau

3. Paramétrage & Configuration

Configuration Nginx (SRV-RPROXY)

# /etc/nginx/nginx.conf
upstream myapp {
    least_conn;
    server 192.168.30.20;
    server 192.168.30.21;
}

server {
    listen 80;
    location / {
        proxy_pass http://myapp;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

4. Sécurité & Règles pare-feu

Flux inter-VLAN (pfSense)

• VLAN 30 → VLAN 10 (192.168.10.5 + .10) : Port 53 TCP/UDP autorisé (DNS)

Règles pare-feu local

• SRV-RPROXY : Port 80 autorisé depuis réseau client
• SRV-WEB1/WEB2 : Port 80 autorisé UNIQUEMENT depuis 192.168.30.10.

5. Tests & Validation

Load balancing vérifié : requêtes distribuées avec maintien sur nœud disponible via least_conn. Arrêt manuel de WEB1 entraîne la redirection totale vers WEB2 transparente pour le client.

VLAN 40 — Département IT & Administration En production

1. Rôle et Objectif

Ce VLAN est strictement dédié aux administrateurs réseau et système de NexaGroup. Il héberge les postes et outils de gestion, et bénéficie de privilèges d'accès étendus sur l'infrastructure pour la maintenance et la supervision (SSH, RDP, accès Web management).

Les postes IT de ce segment intègrent les outils RSAT (Remote Server Administration Tools), notamment Active Directory Users and Computers (dsa.msc) et Group Policy Management Console (gpmc.msc), afin d'administrer le domaine barrault.pb directement depuis les clients sans connexion RDP sur SRV-AD01.

2. Intégration réseau

3. Règles de sécurité

Il est le seul réseau autorisé à accéder aux interfaces d'administration des pare-feu, des hyperviseurs, et au port 22 des divers serveurs Linux (SRV-BDD, SRV-NEXTCLOUD, etc.).

VLAN 50 — Serveur AD Local (RODC) En production

1. Identification & intégration réseau

2. Procédure d'installation et promotion RODC

2.1 Pré-requis avant promotion

Avant de promouvoir AD-HERO, il faut s'assurer que le tunnel WireGuard est opérationnel et que SRV-AD01 est joignable depuis Lyon :

# Vérifications préalables depuis AD-HERO
ping 192.168.10.5
nslookup barrault.pb 192.168.10.5

# Configuration réseau provisoire (avant promotion)
# IP             : 192.168.50.5/24
# Gateway        : 192.168.50.254 (pfSense Lyon)
# DNS primaire   : 192.168.10.5 (SRV-AD01 Paris, temporaire)

2.2 Installation du rôle AD DS

# PowerShell administrateur sur AD-HERO
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2.3 Promotion en RODC

Install-ADDSDomainController `
  -DomainName "barrault.pb" `
  -SiteName "Default-First-Site-Name" `
  -ReadOnlyReplica:$true `
  -InstallDns:$true `
  -NoGlobalCatalog:$false `
  -Force:$true

2.4 Vérification de la réplication

# Depuis SRV-AD01 Paris — vérifier que le RODC apparaît
Get-ADDomainController -Filter * | Select Name, IsReadOnly, Site, IPv4Address

# Depuis AD-HERO — forcer la réplication initiale
repadmin /syncall /AdeP

# Contrôler le statut de réplication
repadmin /showrepl

3. Password Replication Policy (PRP)

# Depuis SRV-AD01 Paris — autoriser la mise en cache des credentials
Add-ADDomainControllerPasswordReplicationPolicy `
  -Identity "AD-HERO" `
  -AllowedList "Domain Users"

Justification BTS E6 : la PRP limite la mise en cache aux comptes strictement nécessaires. Si AD-HERO est volé, l'attaquant ne peut extraire que les empreintes des utilisateurs lyonnais — pas celles des administrateurs ou des comptes de service du siège Paris.

4. Configuration DNS finale

Après déploiement du RODC et vérification de la réplication de la zone barrault.pb, la configuration DNS doit être mise à jour pour que le RODC serve en priorité :

5. Test de résilience — Simulation de coupure VPN

Ce test est la validation fonctionnelle majeure du RODC : il prouve que le site Lyon reste opérationnel même sans le tunnel WireGuard.

1. Couper le tunnel WireGuard côté pfSense Lyon (désactiver temporairement le peer).
2. Depuis un poste VLAN 60, vérifier la résolution : nslookup barrault.pb → doit répondre via 192.168.50.5.
3. Tenter une ouverture de session avec un compte du domaine → doit fonctionner via le cache RODC.
4. Réactiver le tunnel et valider la reprise normale des services centraux (GLPI, Nextcloud).

VLAN 60 — Postes Clients Distants En production

1. Description générale

Ce VLAN regroupe les postes clients du site Lyon. Il est diffusé via le switch MikroTik SwOS relié au pfSense Lyon, garantissant une étanchéité complète avec le VLAN 50 (infrastructure RODC) et un routage contrôlé vers les services du siège via le tunnel WireGuard.

2. Configuration DHCP sur pfSense Lyon

Chemin pfSense : Services → DHCP Server → VLAN60

3. Configuration du switch MikroTik SwOS (VLAN 802.1Q)

Le switch MikroTik fonctionne en mode VLAN 802.1Q. Il reçoit les trames taguées depuis pfSense Lyon sur le port trunk (Port1) et les distribue sur les ports access en retirant le tag VLAN avant transmission aux équipements terminaux.

3.1 Rôle des ports

3.2 Configuration Ingress (Onglet VLAN)

3.3 RSTP désactivé sur les ports access

Le RSTP (Rapid Spanning Tree Protocol, 802.1w) évite les boucles réseau en bloquant temporairement un port pendant la phase Learning. Ce délai est utile entre switches, mais inutile et pénalisant sur un port connecté à un PC ou un serveur (ceux-ci ne peuvent pas créer de boucles).

Désactiver le RSTP (ou passer en mode Edge Port) sur Port2 et Port3 permet au port de passer immédiatement en état Forwarding dès la détection du lien, sans délai d'attente à chaque redémarrage d'un PC.

4. Flux autorisés via le tunnel WireGuard

5. Diagnostic — Problèmes rencontrés lors du déploiement

Commandes de diagnostic utiles

# Depuis pfSense Lyon (Diagnostics > Command Prompt)
ifconfig ue1                          # État physique de l'interface
ifconfig ue1.60                       # Sous-interface VLAN 60 (doit afficher 192.168.60.254)
tcpdump -ni ue1 -c 20                 # Trames arrivant sur le port physique
arp -a | grep 192.168.60              # Table ARP : IPs des clients VLAN 60

# Depuis un poste client Windows (VLAN 60)
ipconfig /all                         # Vérifier la config IP reçue du DHCP
ping 192.168.60.254                   # Gateway pfSense Lyon
ping 192.168.10.5                     # SRV-AD01 Paris via tunnel WireGuard
nslookup barrault.pb 192.168.50.5     # Résolution via RODC local
nltest /dsgetdc:barrault.pb           # Test découverte DC

Procédure de Migration HTTPS (PKI Interne) Documenté

1. Contexte de la demande

2. Options techniques envisagées

3. Déploiement de la PKI (Autorité de Certification)

La solution retenue repose sur pfSense (SRV-PFSENSE-01 / MASTER). Le processus suivi a été :

• Création de la CA (Certificate Authority) interne : Génération d'une racine de confiance appelée "Infrastructure CA NexaGroup" via System > Cert. Manager > CAs.
• Génération des certificats serveurs : Création d'un certificat pour chaque service nécessitant du HTTPS, en signant avec notre CA interne. L'identifiant Common Name (CN) correspond au FQDN du service (ex: glpi.barrault.pb).
• Distribution : La CA Root a été exportée (format .crt) puis intégrée dans le dépôt Autorités de certification racines de confiance des postes clients via GPO AD, évitant ainsi les alertes de sécurité du navigateur.

4. Mise en œuvre sur les serveurs web (ex: Apache)

1. Transfert des certificats : Les clés .crt et .key ont été placées dans /etc/ssl/certs/ et /etc/ssl/private/ sur le serveur web.

2. Configuration du VirtualHost (Redirection + SSL) :

# Redirection HTTP vers HTTPS
<VirtualHost *:80>
    ServerName glpi.barrault.pb
    Redirect permanent / https://glpi.barrault.pb/
</VirtualHost>

# Configuration HTTPS
<VirtualHost *:443>
    ServerName glpi.barrault.pb
    DocumentRoot /var/www/html/glpi/public

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/glpi-cert.crt
    SSLCertificateKeyFile /etc/ssl/private/glpi-key.key
</VirtualHost>

3. Activation : Activation des modules SSL et redémarrage d'Apache (a2enmod ssl, a2enconf default-ssl, systemctl restart apache2).

5. Durcissement Sécurité (HSTS)

• Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

6. Difficultés rencontrées et remédiation

GPO Pare-feu — Règles VNC & ICMP Documenté

1. Diagnostic initial

Avant toute modification, vérifier que les services écoutent effectivement et que le problème est bien au niveau du pare-feu :

# Sur le poste concerné (PowerShell administrateur)
netstat -an | findstr 5900

# Résultat attendu : VNC en état LISTENING sur 0.0.0.0:5900
# → le service fonctionne, le blocage est bien au niveau du pare-feu

# Vérifier le profil réseau (Public vs Domain)
Get-NetConnectionProfile

2. Création de la GPO

1. Ouvrir gpmc.msc sur SRV-AD01 (192.168.10.5)
2. Clic droit sur barrault.pb → Create a GPO in this domain
3. Nommer la GPO : GPO - Parefeu Regles Entrant
4. Clic droit sur la GPO → Edit

Chemin dans l'éditeur de GPO

Computer Configuration
  └── Policies
      └── Windows Settings
          └── Security Settings
              └── Windows Defender Firewall with Advanced Security
                  └── Inbound Rules

3. Règle 1 — VNC (port 5900 TCP)

Clic droit sur Inbound Rules → New Rule

4. Règle 2 — ICMP Echo Request (ping entrant)

Clic droit sur Inbound Rules → New Rule

5. Liaison de la GPO

6. Application et validation

Forcer l'application sur les postes

# Sur chaque poste client
gpupdate /force

Vérifier que les règles sont bien appliquées

Get-NetFirewallRule | Where-Object {
  $_.DisplayName -like '*VNC*' -or $_.DisplayName -like '*ICMP*'
}

7. Tests de validation

8. Récapitulatif des règles déployées

Tests & Validation

L'ensemble des services a fait l'objet de tests de validation fonctionnelle et de résilience.

Matrice de validation

Bilan & Difficultés rencontrées

Compétences mobilisées

Difficultés rencontrées

Bilan

Mise en place d'une haute disponibilité pfSense avec basculement automatique et politique de filtrage ACL Documenté

Contexte et enjeux

Compétences SISR couvertes

Compétences mobilisées : bloc B3 (administration des réseaux), bloc B4 (cybersécurité — pare-feu, politique de sécurité).

Architecture HA pfSense

Le cluster repose sur trois mécanismes complémentaires : adresse virtuelle partagée, réplication des états de session et synchronisation de la configuration.

Adressage des nœuds (exemple VLAN infrastructure VLAN 10)

Les IP réelles des appliances sont en fin de subnet ; la VIP CARP sert de passerelle pour les clients et serveurs du VLAN.

Politique de filtrage ACL

Règles ACL principales (extrait représentatif)

Tests et validation

Déroulement (jalons)

Résultats des tests

Aliases pfSense — Méthodologie et mise en œuvre

Aliases Hosts — Serveurs individuels

Aliases Networks — Sous-réseaux

Aliases Ports — Services réseau

Règles pare-feu — pfSense Paris (PF01/PF02)

LAN_SRV — VLAN 10 Serveurs

LAN_CLT — VLAN 20 Clients

LAN_DMZ — VLAN 30 DMZ

LAN_IT — VLAN 40 Administration

WG_TUNNEL — Trafic site distant Lyon (VLAN 50 + VLAN 60)

SIM_WAN et WAN

Règles pare-feu — pfSense Lyon (Site distant)

VLAN50 — RODC Lyon

VLAN60 — Clients distants Lyon

Bilan

Déploiement et configuration d'un SIEM Wazuh pour la supervision de la sécurité du SI NexaGroup Documenté

Contexte et enjeux

Compétences SISR couvertes

Compétences mobilisées : bloc B4 (cybersécurité — détection d'intrusion, analyse de logs, politique de sécurité), bloc B2 (administration des systèmes).

Indicateurs clés du déploiement

Architecture Wazuh

Le manager centralise les événements, applique les règles et alimente le dashboard ; les agents collectent les logs et l'état des systèmes sur le périmètre supervisé.

Schéma logique (flux manager ↔ agents)

Flux : SRV-WAZUH VLAN 10 → agents sur SRV-AD01, SRV-AD02, SRV-BDD, SRV-NEXTCLOUD, serveurs DMZ/VLAN 30 et serveurs site distant/VLAN 50 (enrôlement, heartbeats, événements sécurité).

État des agents

Règles d'alertes personnalisées

Les règles ci-dessous complètent le catalogue Wazuh pour refléter le contexte NexaGroup (exposition SSH, AD, serveurs Linux).

Procédure de réponse à un incident

La chaîne ci-dessous formalise le traitement d'une alerte SIEM, de la détection à la remédiation.

Tests et validation

Bilan