🎯 Ma Mission

GSB est un laboratoire pharmaceutique fictif, fil rouge du BTS SIO. Le projet consiste à bâtir, de zéro et en environnement virtualisé, une infrastructure d'entreprise complète et sécurisée. Le socle suit le guide « Définition d'une architecture de passerelle d'interconnexion sécurisée » de l'ANSSI : découpage en zones de confiance décroissante, séparées par des pare-feux successifs.

• Segmenter l'infrastructure en zones (WAN, DMZ entrante / interne, LAN clients, Admin, Supervision).
• Exposer un site web pro.gsb.fr avec rupture protocolaire et défense en profondeur.
• Haute disponibilité des services cœurs : AD, DNS, DFS et DHCP.
• Centraliser la gestion de parc avec GLPI v11 raccordé à l'annuaire en LDAPS.
• Supervision (Zabbix) et SIEM (Wazuh) sans ouvrir de nouvelle faille.

Cascade de 4 pare-feux — chaque saut correspond à une zone de transit. Plus on s'approche du cœur, plus la zone est protégée.

Principe ANSSI appliqué : zone d'accès externe → zone de services relais (rupture protocolaire) → zone de services exposés (DMZ entrante) → zone de services internes (DMZ) → zone d'accès interne.

Conventions : e0 = LAN, e1 = WAN, e2 = OPT1, e3 = OPT2 — Passerelle extérieure = .254, intérieure = .1 — Réseau admin dédié : 172.20.1.0/24.

Toute l'infrastructure tourne sous Proxmox VE. La segmentation réseau s'appuie sur des bridges Linux (vmbr), un par zone, non rattachés à une interface physique.

• Import d'un template OPNsense, clonage pour chaque pare-feu avec réinitialisation des adresses MAC.
• Assignation des rôles d'interface : WAN sur vmbr0, LAN sur vmbr1, puis OPT…
• Poste de paramétrage (Ubuntu) en zone LAN pour piloter l'OPNsense initialement.
• Connectivité Internet initiale via NAT outbound sur le pare-feu de tête, puis désactivé.

Administrer les pare-feux depuis le LAN utilisateur exposerait les interfaces de gestion. La réponse ANSSI : un réseau d'administration dédié (172.20.1.0/24) piloté par PF-Admin. L'administration se fait exclusivement sur OPT1 de chaque pare-feu, depuis l'interface WAN du PF-Admin.

• Autorisation HTTPS de gestion uniquement depuis le réseau d'administration.
• Désactivation de l'anti-lockout rule côté LAN une fois l'accès maîtrisé.
• Suppression des règles métier trop larges et réduction de surface d'exposition.
• Routes statiques pour les flux descendants — les routes par défaut ne gèrent que le trafic sortant.

Deux VM placées dans deux DMZ distinctes pour isoler la base de données du front web.

Installation des paquets :

apt install apache2 php libapache2-mod-php php-mysql php-pdo-mysql
apt install mariadb-server

Création de la base (sur bdd-lab) :

CREATE DATABASE pro;
CREATE USER 'utilisateur_pro'@'IP-WEB-EXT' IDENTIFIED BY '********';
GRANT ALL PRIVILEGES ON pro.* TO 'utilisateur_pro'@'IP-WEB-EXT';
FLUSH PRIVILEGES;

Flux autorisés (ACL clés) :

<VirtualHost *:443>
    ServerName pro.gsbX.local
    DocumentRoot /var/www/html
    SSLEngine on
    SSLCertificateFile     /etc/ssl/.../pro.gsbX.local.crt
    SSLCertificateKeyFile  /etc/ssl/.../pro.gsbX.local.key
    SSLCertificateChainFile /etc/ssl/.../ca.crt
</VirtualHost>

• AD / DNS / DFS — LABANU (.30) & LABANU-02 (.31). Zones DNS intégrées à l'AD (réplication multi-maître) et espace de noms \\gsb.local\dfs répliqué par DFSR.
• DHCP Failover — REZOLAB & REZOLAB-02 en équilibrage de charge 50/50. Le secondaire reprend l'intégralité de la distribution si le primaire tombe.
• Messagerie Postfix — relais SMTP Send-Only en boucle locale, alias support: root pour router les alertes GLPI.

• OS — Debian 13 (Trixie), pile Apache2 / MariaDB, PHP 8.4 + module php-bcmath.
• Durcissement — répertoires config et files sortis du dossier public d'Apache.
• LDAPS (636) — bind sécurisé sur l'AD, TLS_REQCERT never, BaseDN DC=gsb,DC=local.
• Agent d'inventaire — installation silencieuse via partage caché Deploy$ sur LABANU, déclenchée au démarrage (GPO).
• Lecteurs mappés — GPO montant l'espace DFS (S: / T: / U: / V:) par ciblage sur groupes de sécurité.

IF EXIST "C:\Program Files\GLPI-Agent\glpi-agent.bat" GOTO END
msiexec.exe /i "\\172.17.0.30\Deploy$\GLPI-Agent.msi" /quiet ^
    SERVER="http://glpi.gsb.local/front/inventory.php" ^
    RUNNOW=1 ADD_FIREWALL_EXCEPTION=1
:END

Zabbix est placé en zone d'administration. La supervision emprunte PF-Admin puis les interfaces OPT1 d'administration — sans jamais traverser un pare-feu dans le sens entrant.

• Pare-feux — OPNsense en SNMP.
• Serveurs internes — LabAnnu, Rezolab (agent Zabbix).
• Infra — switchs HPE / Linux en SNMP.
• Services — reverse-proxy HAProxy, web Apache, BDD MariaDB, proxy Squid.
• Deux vecteurs : agent Zabbix (riche, sécurisé) et SNMP (léger, universel).

• VM Ubuntu 22.04 : disque ≥ 80 Go, 8 Go de RAM, < 25 agents — installation all-in-one via wazuh-install.sh.
• Wazuh étant en zone protégée, port-forwards créés depuis OPT2 et WAN (ports relevés via netstat).
• Agents actifs : OPNsense (plugin), Linux (APT), Windows.
• Nommage correct des hôtes indispensable : identifie la source des logs dans le dashboard.

• B1 — Gestion de parc et support : ticketing GLPI, inventaire automatisé, déploiement par GPO.
• B2.1 — Systèmes — Virtualisation Proxmox, haute disponibilité Windows Server (AD, DNS, DFS, DHCP failover 50/50).
• B2.2 — Réseau — Architecture à 4 pare-feux, routage pur sans NAT, segmentation en zones, routes statiques et port-forward.
• B2.3 — Services — Service web entrant (Apache/PHP/MariaDB), rupture protocolaire HAProxy, HTTPS avec CA interne.
• B3 — Cybersécurité — Défense en profondeur ANSSI, réseau d'administration hors bande, ACL, supervision Zabbix et SIEM Wazuh.