Laboratoire personnel · DozyLab
Mon homelab, conçu et exploité seul en dehors de la formation et de l’alternance. Il me sert à bâtir une infrastructure complète, documentée au standard professionnel, et à expérimenter librement la virtualisation, le réseau, l’annuaire et la sécurité. Les réalisations présentées ici sont personnelles : elles ne relèvent ni du centre de formation ni de l’entreprise.
Présentation du laboratoire
Le laboratoire DozyLab
En parallèle de la formation et de l’alternance, je conçois et j’exploite seul DozyLab, un homelab auto-hébergé. L’objectif : bâtir une infrastructure complète et cohérente, documentée comme en production, pour expérimenter librement la virtualisation, le réseau segmenté, les services d’annuaire et la sécurité.
Chaque service suit les mêmes règles : conteneurs LXC non privilégiés par défaut, conventions de nommage et d’adressage formalisées, un coffre de référence (Vaultwarden) pour les identifiants et des procédures techniques pour les déploiements documentés (références HL-PRC). Disposer d’un coffre ne dispense pas de vérifier les secrets présents dans les fichiers de configuration.
Les fiches issues du laboratoire portent la mention Homelab : ce sont des réalisations personnelles, distinctes de mes travaux en centre et en entreprise.
En bref
- Nature
- Laboratoire personnel
- Matériel
- Cluster Proxmox VE à 3 nœuds (40 Go de mémoire au total), pare-feu Juniper SRX300 (arrivée du lien Internet), commutateur Cisco SF302-08PP
- Réseau
- 9 VLAN 802.1Q, matrice de flux inter-VLAN
- Invités Proxmox
- Le relevé en lecture seule du 12 novembre 2026 a renvoyé 16 VM ou conteneurs LXC en état « running ». Cela décrit l’état des invités, pas la santé de chaque application.
- À valider
- Fonctionnement des applications, réception du trafic recopié pour Suricata, tests de restauration PBS et copie hors site.
- Envisagé
- step-ca, Keycloak, Loki et Grafana Alloy, FOG Project
- Documentation
- Procédures HL-PRC publiées sur ce portfolio ; versionnement dans Gitea à compléter
Une infrastructure, une carte
Parcourez le réseau par couches. Appuyez sur un équipement ou une liaison pour lire les faits documentés. Les adresses privées et identifiants des invités sont masqués.
Relevé en lecture seule
État ponctuel, pas de télémétrie
3 hôtes et 12 invités observés dans Proxmox
Les équipements réseau sont documentaires : leur état actuel n’est pas vérifié. Tous les invités renvoyés par le connecteur Proxmox existant sont représentés ; ce relevé n’est pas un scan exhaustif des postes du réseau.
- Internet (WAN) — Réseau externe ; arrivée du lien Internet sur le port fournisseur du Juniper SRX300 (client DHCP, zone non fiable), derrière un routeur d’accès fournisseur ; opérateur et routeur d’accès : non documentés ; IP : non publiée ; Documenté · opérateur non documenté
- Juniper SRX300 — Matériel · pare-feu ; Équipement autonome ; CPU et RAM non documentés ; IP : Non documentée ; Documenté · état non vérifié
- Cisco SF302-08PP — Matériel · commutateur ; Équipement autonome ; CPU et RAM non documentés ; IP : [adresse masquée] (inventaire) ; Documenté · état non vérifié
- Netgear R6020 — Matériel · point d’accès ; Équipement autonome ; CPU et RAM non documentés ; IP : Non documentée ; Documenté · état non vérifié
- PVE1 — Matériel · hyperviseur ; Hôte physique PVE1 ; 12th Gen Intel(R) Core(TM) i5-12400T · 6 cœurs / 12 threads · RAM reconnue 14,86 Gio ; IP : [adresse masquée] · [adresse masquée] ; En ligne · relevé du 11 octobre
- PVE2 — Matériel · hyperviseur ; Hôte physique PVE2 ; Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz · 4 cœurs / 8 threads · RAM reconnue 15,37 Gio ; IP : [adresse masquée] · [adresse masquée] ; En ligne · relevé du 11 octobre
- PVE3 — Matériel · hyperviseur ; Hôte physique PVE3 ; Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz · 2 cœurs / 4 threads · RAM reconnue 7,60 Gio ; IP : [adresse masquée] · [adresse masquée] ; En ligne · relevé du 11 octobre
- TP-Link TG3468 — Matériel · carte réseau ; PVE3 ; Ressources propres non documentées ; IP : Non documentée ; Documenté · état non vérifié
- Technitium DNS — LXC ; PVE1 ; 1 cœur alloué · RAM configurée 1024 Mio · disque 8G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- AD DS + AD CS — VM ; PVE2 ; 2 vCPU · RAM configurée 4096 Mio · disque 60G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- Nginx Proxy Manager — VM · Docker ; PVE1 ; 2 vCPU · RAM configurée 4096 Mio · disque 20G (capacité configurée) · mémoire exposée 2048 Mio (écart non résolu) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- Vaultwarden — LXC ; PVE2 ; 2 cœurs alloués · RAM configurée 768 Mio · disque 12G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- Gitea — LXC ; PVE1 ; 1 cœur alloué · RAM configurée 1024 Mio · disque 16G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- WatchTower — LXC ; PVE1 ; 2 cœurs alloués · RAM configurée 2048 Mio · disque 24G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- n8n — VM ; PVE2 ; 2 vCPU · RAM configurée 4096 Mio · disque 25G (capacité configurée) ; IP : [adresse masquée] · [adresse masquée] ; Implémenté · invité démarré, service non testé
- Hermes Agent — LXC ; PVE3 ; 2 cœurs alloués · RAM configurée 8192 Mio · disque 35G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, intégration en cours
- Wazuh — VM ; PVE1 ; 2 vCPU · RAM configurée 4096 Mio · disque 100G (capacité configurée) ; IP : Non vérifiée · agent invité indisponible ; Implémenté · invité démarré, intégration en cours
- Suricata — Type non documenté ; PVE3 ; CPU et RAM non documentés ; IP : Non documentée ; Prévu · non déployé
- Apache Guacamole — LXC ; PVE1 ; 2 cœurs alloués · RAM configurée 1024 Mio · disque 10G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, intégration en cours
- Zabbix — LXC ; PVE2 ; 2 cœurs alloués · RAM configurée 2048 Mio · disque 20G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- CrowdSec — LXC ; PVE1 ; 1 cœur alloué · RAM configurée 512 Mio · disque 8G (capacité configurée) ; IP : [adresse masquée] ; Implémenté · invité démarré, service non testé
- Proxmox Backup Server — Service installé directement sur l’hôte PVE3 (pas de VM ni de conteneur) ; datastore, rétention et test de restauration à valider ; Implémenté · sur l’hôte
PBS est installé directement sur PVE3, sans VM ni conteneur. Au dernier audit d’infrastructure du 4 novembre 2026, la copie hors site via le hook Google Drive échouait et les sauvegardes PBS/NFS restaient sur le même stockage local ; aucune restauration n’était attestée. Les procédures décrivent la configuration, pas une preuve de sauvegarde réussie.
Segmentation et limites
VLAN 10 ADM ; 20 SRV ; 30 DMZ ; 40 CLI ; 50 VOIP ; 60 DEPLOY ; 70 WIFI ; 80 LAB ; 99 CLUSTER. Corosync : 99 prioritaire, 10 en secours selon la documentation ; 99 non routé. Aucune dépendance DNS entre applications n’est déduite.
RAM et disques des invités : capacités configurées, pas consommation. NPM : RAM configurée 4096 Mio, capacité de statut 2048 Mio — écart conservé explicitement. IP Wazuh non vérifiée : l’agent invité ne répond pas ; l’adresse du reverse proxy ne remplace pas celle de la VM.
Suricata : non déployé ; implantation passive prévue sur PVE3. Ports du Cisco, état des équipements et postes clients non vérifiés. Zabbix et CrowdSec sont des invités démarrés, pas des services validés de bout en bout.
Sources : relevé API Proxmox du 11 octobre 2026, connecteur existant via WatchTower avec certificat interne vérifié ; état documentaire Homelab du 7 octobre, inventaire WatchTower sans date, flux SRX documentés le 5 octobre.
État Proxmox mis à jour le 12 novembre 2026 à 00:11 CET. La lecture seule de l’API du cluster a renvoyé 3 nœuds et 16 invités, tous à l’état « running » : ProxPanel, Guacamole, DC01, Technitium DNS, Nginx Proxy Manager, WatchTower, n8n, Gitea, Zabbix, Monitoring, Wazuh, Vaultwarden, CrowdSec, Suricata, passerelle Tailscale et Hermes. Ce relevé confirme uniquement l’état des invités dans Proxmox, pas la santé des applications. Le schéma qui précède reste un relevé historique du 11 octobre 2026 ; l’état d’un invité ne prouve pas le fonctionnement de son service.
Services
État des invités Proxmox relu le 12 novembre 2026 ; les observations applicatives et les captures gardent leur propre date. « Running » signifie que l’invité est démarré dans Proxmox, pas que le service qu’il héberge a passé une recette de bout en bout. « À valider » signale un contrôle applicatif ou une intégration non démontrés par ce relevé.
Implémentés
- Technitium DNS — DNS interne avec DNSSEC, en conteneur LXC Implémenté
- Active Directory — annuaire, DHCP et autorité de certification racine (AD CS) sous Windows Server 2022 Implémenté
- Nginx Proxy Manager — reverse proxy et terminaison TLS (machine virtuelle, exception Docker documentée) Implémenté
- Vaultwarden — coffre de référence pour les secrets Implémenté
- Gitea — interface accessible ; dépôts et versionnement des procédures à compléter Implémenté
- WatchTower — registre d’infrastructure développé sur mesure, en conteneur LXC Implémenté
- n8n — VM démarrée dans Proxmox ; le dernier inventaire de workflows du 11 novembre 2026 recensait 35 sources configurées et des étapes de publication/média distinctes Implémenté
- Wazuh — SIEM (manager, indexer, tableau de bord) : le tableau de bord répond, raccordement des sources en cours Implémenté
- Proxmox Backup Server — installé directement sur l’hôte PVE3 (pas de VM ni de conteneur). L’audit du 4 novembre n’a pas confirmé de copie hors site ni de restauration testée ; l’installation seule ne prouve pas la récupérabilité des sauvegardes Installé · contrôles à valider
- Apache Guacamole — portail d’accès distant accessible ; aucune session récente configurée n’apparaît dans la capture Implémenté
- Hermes — agent dans le VLAN LAB ; la veille passe par un relais sortant vérifié, la file d’approbation humaine dans WatchTower reste à raccorder Implémenté
- Zabbix — supervision des métriques ; conteneur LXC sur PVE2, démarré lors du relevé du 11 octobre Implémenté
- CrowdSec — protection périmétrique ; conteneur LXC sur PVE1, démarré lors du relevé du 11 octobre Implémenté
Prévus et envisagés
- step-ca — autorité subordonnée et renouvellement automatique des certificats (ACME) Envisagé
- Keycloak — authentification unique OIDC fédérée à l’annuaire Envisagé
- Loki et Grafana Alloy — centralisation et collecte des journaux des services critiques Envisagé
- FOG Project — déploiement de postes par PXE (VLAN 60, DEPLOY) Envisagé
- Suricata — VM présente et démarrée sur PVE3 ; la réception effective du trafic recopié et la validation applicative ne sont pas établies par le relevé Proxmox Invité démarré
- Ansible — automatisation du déploiement des agents et des configurations Prévu
Principes d’architecture
Les règles appliquées à chaque service, pour garder un ensemble cohérent et maintenable.
Conception
- Les services sont répartis entre conteneurs LXC et machines virtuelles. Docker est utilisé dans des VM pour Nginx Proxy Manager et n8n ; ce dernier usage ne correspond pas à l’ancienne règle « Docker uniquement pour NPM » et reste une exception d’architecture à suivre.
- Ansible est prévu pour l’automatisation ; Kubernetes n’est pas mis en place.
- Nommage structuré par service et par zone, identifiants de machines dérivés du VLAN et de l’adresse.
- Objectif : une procédure versionnée pour chaque déploiement. Les procédures déjà rédigées sont accessibles sur ce portfolio ; le versionnement dans Gitea reste à compléter.
Sécurité
- Vaultwarden est le coffre de référence pour les identifiants ; la présence de secrets dans les fichiers de configuration doit être vérifiée séparément.
- PKI interne : autorité racine AD CS en RSA 4096, subordination par step-ca prévue.
- Segmentation stricte avec matrice de flux inter-VLAN.
- Durcissement systemd et accès d’administration : leur niveau varie selon les hôtes et les services ; ce portfolio ne prétend pas qu’un accès SSH par clé soit la seule méthode utilisée partout.
- Capture réseau passive par recopie de port dédiée.
Projets et automatisation
Ce que j’ai développé ou intégré pour piloter le laboratoire.
WatchTower Implémenté
Registre d’infrastructure développé sur mesure : vue d’ensemble, topologie, hôtes, capacité Proxmox, PKI, écarts de configuration, accès, registre et journal des changements. Chaque valeur affichée indique son origine (inventaire, décision ou mesure) ; une source injoignable s’affiche comme telle et aucune mesure n’est inventée.
- FastAPI
- React
- Vite
- TypeScript
- Tailwind CSS
- PWA
Veille SOC automatisée Chaîne multi-étapes · état daté
Dernier inventaire n8n consulté le 11 novembre 2026 : 13 workflows recensés, dont 7 actifs ; le collecteur principal était configuré sur 35 sources et sa dernière exécution observée ce jour-là avait réussi. La publication et le traitement des médias passent par des workflows séparés, avec des échecs récents dans l’inventaire : ces mesures ne démontrent donc pas une chaîne complète et fiable à chaque passage.
Le flux est sortant depuis Hermes : aucune ouverture entrante supplémentaire du pare-feu n’a été nécessaire. Une première fiche réelle a été publiée puis relue le 7 octobre : OpenSSH : plusieurs vulnérabilités signalées par le CERT-FR.
- n8n
- Hermes
- Relais d’inférence
- API REST WordPress
- CERT-FR
- IT-Connect
- ZATAZ
Hermes Implémenté
Hermes Agent est auto-hébergé dans le VLAN LAB et relié à WatchTower. Les actions disponibles dépendent des outils et connecteurs configurés ; aucune file d’approbation globale n’est affirmée ici. Les identifiants et jetons ne sont pas reproduits dans le portfolio, et la supervision de sécurité reste un chantier distinct.
En savoir plus sur Hermes · Ouverture d’un flux sur le SRX · Accès SSH par clé
Les interfaces du laboratoire en images
Six interfaces du laboratoire en images : DNS, versionnement, accès distant, automatisation, coffre et assistant IA. Les autres vues proviennent du lot de captures du 5 octobre 2026 ; la nouvelle interface Web du coffre a été fournie le 8 octobre 2026. Les noms internes, comptes et identifiants ont été retirés. Chaque légende distingue l’interface visible d’un fonctionnement réellement démontré.
Technitium DNS · tableau de bord
Gitea · accueil du service
Apache Guacamole · portail d’accès distant
n8n · workflow de veille, capture d’archive
Voir l’état vérifié et les limites de la chaîne de veille.
Vaultwarden · interface Web du coffre
Hermes · accueil de l’agent, capture d’archive
Voir le déploiement Hermes, ses connecteurs et ses procédures de veille.
Les erreurs OAuth, pages blanches, formulaires d’authentification, conversations privées et anciennes vues du portfolio ne sont pas présentés comme des preuves du laboratoire. Une interface accessible ne garantit ni sa sécurité ni le fonctionnement de bout en bout.
Réalisations du laboratoire
Les fiches conservent leur numéro d’origine. Filtrez par domaine ou par compétence, puis ouvrez une fiche pour le détail.
COMMANDES DE CONTRÔLE pvecm status pvesm status Illustration — aucun résultat exécuté n’est reproduit dans cet encart.
Cluster de virtualisation Proxmox VE à trois nœuds
Trois hyperviseurs Proxmox VE réunis en cluster pour les administrer depuis un point unique, avec un lien de cohérence séparé et un contrôle du quorum.
- Proxmox VE
- Corosync
- 802.1Q
- LVM-thin
- Debian
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Service rendu et besoin
Le cluster Proxmox VE réunit trois serveurs physiques sous une administration commune pour héberger les machines virtuelles et les conteneurs du laboratoire. On peut consulter leurs ressources et gérer les invités depuis la même interface. La mise en grappe ne crée ni sauvegarde ni redémarrage automatique des services sur un autre nœud : ces fonctions demandent une conception et des réglages supplémentaires.
Fonctionnement
Corosync fait circuler l’état de la grappe entre les nœuds. Avec trois nœuds, chacun détient une voix et il faut la majorité pour garder le quorum. La procédure déclare deux liens : le lien prioritaire passe par un segment non routé, le second par le segment d’administration. Comme les deux partagent la même interface physique, la redondance est logique, pas matérielle.
Prérequis techniques et organisationnels
Pour cette architecture : trois machines compatibles avec Proxmox VE, des versions cohérentes, des noms et adresses stables, une synchronisation horaire, un réseau à faible latence entre les nœuds et un stockage planifié pour chaque hôte. Le commutateur doit transporter les VLAN prévus et un accès console doit rester disponible pendant les changements d’administration. Le nom de grappe et les noms d’hôtes sont à arrêter avant l’adhésion des nœuds.
Mise en œuvre
- Installation homogène des trois nœuds (même version, même stockage).
- Configuration des ponts réseau en mode VLAN aware et des interfaces étiquetées.
- Bascule progressive de l’adressage d’administration avec console de secours.
- Remplacement du dépôt d’entreprise par le dépôt communautaire.
- Création de la grappe avec deux liens Corosync, puis adhésion des nœuds.
- Déclaration des stockages restreints à leur nœud et création d’un groupe d’administration.
Résultat et contrôles
Les trois hôtes sont réunis dans le cluster ; le relevé Proxmox du 11 octobre 2026 présenté sur cette page les montre en ligne. Les commandes pvecm status, corosync-cfgtool -s et pvesm status servent à contrôler le quorum, les liens et les stockages. La fiche ne démontre pas de bascule automatique ni de restauration ; la liste de vérifications de la procédure reste à compléter.
Compétences et liens
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation : groupe d’administration de la grappe et droits associés ; vérifier les conditions de la continuité d’un service : deux liens de cohérence Corosync et contrôle du quorum.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : installation homogène des trois nœuds et création de la grappe ; réaliser les tests d’intégration : vérification du quorum, des liens et des stockages.
Commutateur Cisco SF302-08PP : VLAN et administration
Séparer les usages du laboratoire en réseaux virtuels (VLAN) avec le Cisco SF302-08PP, tout en gardant un accès d’administration et une liaison vers le pare-feu.
- Cisco
- VLAN
- 802.1Q
- SSH
- PuTTY
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Service rendu et besoin
Le commutateur sépare le réseau en VLAN au niveau 2 : il isole les segments mais ne route pas entre eux. Le routage et le filtrage inter-VLAN sont assurés par le pare-feu SRX, relié au commutateur par un trunk. Le point à préserver pendant la configuration est l’administration : en mode couche 2, le montage utilise une adresse de gestion sur un VLAN dédié. La modifier sans accès de secours peut couper l’administration.
Fonctionnement
Les VLAN sont créés et nommés, les ports d’accès affectés, et le port de liaison, ou uplink, transporte les huit VLAN routés sur un trunk, un lien qui conserve leur identification par étiquette 802.1Q. Le VLAN de cluster reste présent uniquement sur les ports des hyperviseurs et n’est pas sur le trunk d’uplink. Le plan de gestion migre vers le VLAN 10 en passant par un chemin de secours câblé à part.
Prérequis techniques et organisationnels
Exigences de la procédure : pare-feu déjà opérationnel, avec le VLAN d’administration routé et servi en DHCP ; deux chemins vers le commutateur pendant la bascule ; un port libre et un câble ; un câble console ; un client SSH acceptant les algorithmes anciens de ce modèle. Limites documentées : firmware en fin de support, compte d’administration unique, console série encore à valider, ports de réserve sans contrôle d’accès.
Mise en œuvre
- Réinitialisation et prise en main du commutateur ; console série de secours restant à valider.
- Création et nommage des VLAN, affectation des ports d’accès.
- Configuration du trunk d’uplink vers le pare-feu.
- Mise en place d’un chemin de secours avant la bascule.
- Migration de l’adresse de gestion vers le VLAN 10 et reprise en SSH.
- Sauvegarde de la configuration après chaque étape validée.
Résultat et contrôles
La procédure demande de valider le VLAN cible (poste obtenant une adresse, passerelle qui répond) avant de déplacer l’adresse de gestion, puis de vérifier la session SSH sur la nouvelle adresse et d’enregistrer la configuration. Elle est en version 0.1 et sa liste de vérifications n’est pas cochée. L’encart de la fiche est un repère matériel, pas une capture de configuration.
Compétences et liens
- Gérer le patrimoine informatique — Vérifier les conditions de la continuité d’un service : chemin de secours établi avant la bascule et configuration enregistrée après chaque étape ; niveaux d’habilitation : administration limitée au VLAN d’administration, en SSH.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : segmentation en VLAN et trunk vers le pare-feu ; réaliser les tests d’intégration : validation du VLAN cible avant la migration du plan de gestion.
CONTRÔLES DNS Résolution directe et inverse Récursion et mise en cache Voir le tableau de bord anonymisé dans la galerie des interfaces.
Serveur DNS interne Technitium
Retrouver les services du laboratoire par leur nom et résoudre les noms Internet avec Technitium DNS, installé en conteneur LXC et utilisé par les clients via leur configuration DHCP.
- Technitium DNS
- LXC
- DNS
- Proxmox VE
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Service rendu et besoin
Le DNS associe les noms des services à leurs adresses IP : il évite aux utilisateurs et aux applications de mémoriser chaque adresse. Technitium fournit au laboratoire les réponses pour ses zones internes et la résolution des noms publics. Le contrôle local de ces réponses facilite l’administration et permet de limiter les clients autorisés à utiliser le résolveur.
Fonctionnement
Une zone directe associe un nom à une adresse ; une zone inverse permet de rechercher le nom correspondant à une adresse. Pour les noms publics, la résolution récursive recherche la réponse et la met en cache. Le DHCP distribue l’adresse du serveur DNS aux clients des segments concernés. Les enregistrements d’un domaine Active Directory doivent rester cohérents avec son propre DNS ; déployer Technitium ne réalise pas automatiquement cette intégration.
Prérequis techniques et organisationnels
Pour le déploiement décrit : un hôte Proxmox VE disponible, un modèle de conteneur LXC, une adresse stable hors du pool DHCP, le VLAN serveur transporté jusqu’au conteneur et des flux DNS autorisés en UDP et TCP. Il faut choisir les zones et les enregistrements internes, restreindre la récursion aux réseaux autorisés, pouvoir modifier les paramètres DHCP et conserver un accès de gestion indépendant de la résolution que l’on modifie. Le cluster est le contexte d’hébergement, pas une obligation intrinsèque de Technitium.
Mise en œuvre
- Création d’un conteneur LXC non privilégié sur le VLAN serveurs.
- Installation de Technitium après relecture du script d’installation.
- Changement immédiat des identifiants par défaut de la console.
- Création de la zone directe et des zones inverses.
- Restriction de la récursion aux réseaux internes.
- Bascule des pools DHCP segment par segment puis vérification avec
dig.
Résultat et contrôles
Les contrôles prévus sont des interrogations dig sur un nom public, un nom interne et une adresse en inverse, puis la vérification qu’un client renouvelé reçoit la bonne adresse DNS. Un renouvellement de bail est nécessaire pour appliquer la bascule. Un instantané du conteneur est pris avant la configuration. L’encart de la fiche est une liste de contrôles, pas un résultat.
Compétences et liens
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : récursion restreinte aux réseaux internes, identifiants par défaut changés dès l’installation.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : DNS interne en conteneur, bascule des clients DHCP segment par segment ; réaliser les tests d’intégration : résolutions directes et inverses vérifiées avec dig.
COMMANDES DE CONTRÔLE systemctl is-active wazuh-manager systemctl is-active wazuh-indexer systemctl is-active wazuh-dashboard Illustration — pas une sortie d’exécution vérifiée.
Supervision de sécurité avec Wazuh
Regrouper les événements de sécurité du laboratoire pour les analyser avec Wazuh. La plateforme centrale et son tableau de bord sont installés ; le raccordement des sources est en cours.
- Wazuh 4.14
- Ubuntu 24.04
- OpenSearch
- systemd
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Service rendu et besoin
Pour repérer des événements de sécurité sur plusieurs machines, il faut les réunir à un seul endroit. Wazuh collecte les événements envoyés par des agents, les analyse avec ses règles et les affiche dans un tableau de bord. Ici, le tableau de bord est accessible ; la collecte depuis les sources du laboratoire est en cours d’intégration. Il ne faut donc pas lire cette fiche comme un SIEM déjà alimenté de bout en bout.
Fonctionnement
Le manager analyse et expose l’API, l’indexer OpenSearch stocke les alertes, et le tableau de bord les présente en HTTPS. L’installeur officiel pose les trois composants sur la même machine, sans grappe.
Prérequis techniques et organisationnels
Pour ce montage tout-en-un : Ubuntu 24.04, un compte autorisé à installer les services et des ressources suffisantes pour l’analyse, l’indexation et la rétention des événements. Le dimensionnement dépend du nombre d’agents et du volume de journaux, pas seulement de l’ouverture du tableau de bord. Il faut limiter les flux aux usages utiles : HTTPS vers le tableau de bord, événements des agents vers le manager et enregistrement des agents quand il est utilisé. Les DNS, certificats, droits de consultation et horodatages doivent être cohérents. Le déploiement et l’enregistrement des agents restent distincts de l’installation centrale.
Mise en œuvre
- Préparation du serveur (paramètres noyau, limites de ressources).
- Installation tout-en-un de Wazuh.
- Durcissement des services systemd et pare-feu local.
- Intégration réseau : nom DNS interne, pare-feu local et accès HTTPS au tableau de bord.
- Vérification des services et des ports en écoute.
Résultat et contrôles
La procédure prévoit de contrôler les trois services avec systemctl, les ports en écoute et l’affichage de la page de connexion. L’encart de la fiche ne reproduit que ces commandes : ce n’est pas une sortie d’exécution. Les règles, alertes et agents ne sont pas démontrés par cette fiche.
Compétences et liens
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : Wazuh en installation tout-en-un, durcissement systemd et pare-feu local ; réaliser les tests d’intégration : vérification des services, des ports en écoute et de l’accès au tableau de bord.
PRINCIPE DE VALIDATION JUNOS commit check commit confirmed 5 Validation et retour arrière Illustration — pas une sortie réelle.
Mise en service d'un pare-feu Juniper SRX300
Pare-feu Juniper SRX300 qui route huit VLAN, filtre les flux entre zones, traduit les adresses vers Internet et fournit DHCP et relais DNS.
- Juniper SRX300
- Junos
- NAT
- DHCP
- 802.1Q
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Service rendu et besoin
Dans ce réseau, le commutateur segmente et le pare-feu décide qui parle à qui. Le SRX300 reçoit Internet sur son port WAN (côté routeur d’accès du fournisseur) et distribue les huit VLAN routés sur son trunk vers le commutateur. Tout flux non autorisé explicitement entre deux zones est bloqué par défaut.
Fonctionnement
Chacun des huit VLAN routés dispose d’une sous-interface et d’une affectation à une zone de sécurité ; les pools DHCP distribuent les paramètres des réseaux concernés. Une matrice de flux fixe les ouvertures : l’administration peut joindre les zones explicitement autorisées par la matrice, le réseau Wi-Fi invité ne joint aucune zone interne, le reste est fermé. Les clients sortent vers Internet en NAT source. Le VLAN de cluster est exclu du trunk vers le pare-feu et n’est pas routé. Le routeur d’accès garde son propre NAT, donc la traduction est double.
Prérequis techniques et organisationnels
Exigences de la procédure : accès console série (9600 8N1), plan d’adressage et matrice de flux arrêtés avant de configurer, deux câbles (WAN et trunk), un gestionnaire de secrets, et une fenêtre d’intervention si le lien Internet est partagé. Le raccordement se fait après validation de la configuration, pour ne pas introduire un second serveur DHCP dans un réseau en production. Hors périmètre : VPN, haute disponibilité, mise à jour du système.
Mise en œuvre
- Remise à zéro et prise en main par la console série.
- Trunk 802.1Q et sous-interfaces de VLAN.
- Zones de sécurité, carnet d’adresses et politiques.
- Serveur DHCP par VLAN et relais DNS.
- NAT source vers Internet et compte d’administration nominatif.
commit confirmed, vérifications finales et raccordement.
Résultat et contrôles
Le pare-feu est mis en service selon le plan de zones et de flux décrit. commit confirmed permet une validation avec retour automatique à l’ancienne configuration si elle n’est pas confirmée. La recette doit vérifier le bail WAN, le DHCP, le NAT, le refus des flux inter-zones interdits et l’accès SSH depuis l’administration. La procédure conserve une liste de contrôles non cochée ; l’encart de commandes n’est pas une sortie d’exécution.
Compétences et liens
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : compte d’administration nominatif, connexion root par mot de passe refusée, SSH limité à la zone d’administration.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : routage inter-VLAN, DHCP, relais DNS et NAT ; réaliser les tests d’intégration : commit confirmed puis vérifications finales avant le raccordement.
Nouvelles procédures intégrées
14 procédures supplémentaires issues du laboratoire DozyLab, anonymisées et documentées.
- Désactivation du message de souscription Proxmox VE
- Zabbix Agent — supervision des nœuds Proxmox VE
- Guacamole — redirection de lecteur RDP
- Netgear R6020 — OpenWrt, SNMP et Zabbix
- PBS — publication via reverse proxy NPM
- Proxmox VE — erreur de stockage de sauvegarde
- Proxmox VE — sauvegarde Google Drive (NFS/Rclone)
- ProxPanel — mise en service LXC et publication NPM
- Bitwarden — isolation par sous-domaines NPM
- WatchTower — raccordement des connecteurs de supervision
- Zabbix Agent 2 — déploiement sur Technitium DNS
- Guacamole — thème sombre
- Proxmox VE — blocage d'interface Intel e1000e
- HL-PRC-034 — WatchTower — résolution du statut inconnu des hôtes Zabbix