Conscience Réseau - Réflexions et Journal d'Apprentissage

Aperçu du Projet

Date de début : 29 octobre 2025 Objectif : Documenter le parcours de construction d'une architecture réseau homelab sécurisée avec des VLANs et des stratégies de segmentation avancées. Statut : En Cours

Session 1 : Conception de l'Architecture Initiale et Philosophie des VLANs

Idées Clés

  1. Les VLANs ne sont pas magiques - Ce sont un outil, pas une solution complète. Ils fonctionnent mieux lorsqu'ils sont combinés avec :
    • Des règles de pare-feu appropriées (refuser par défaut)
    • Des audits de sécurité réguliers
    • Surveillance et alertes
    • Éducation des employés/utilisateurs (en entreprise) ou discipline personnelle (en homelab)
  2. Le Principe du « Refus par Défaut » - Au lieu d'ouvrir tout et de bloquer le mauvais trafic, nous :
    • Refusons tout par défaut
    • Ajoutons à la liste blanche le trafic spécifique autorisé
    • Ceci inverse la posture de sécurité de « ouvert sauf s'il est bloqué » à « fermé sauf s'il est autorisé »
  3. Problème Réel : Le réseau initial plat entraînait :
    • Aucune visibilité sur les schémas de communication des appareils
    • Les appareils compromis pouvaient atteindre des données sensibles
    • Aucune frontière naturelle entre les domaines de sécurité
    • Difficulté à dépanner ce qui devrait/ne devrait pas fonctionner

Décisions Architecturales Prises

  • 5 VLANs contre 20+ : Commencer simplement plutôt que de sur-ingénieriser
  • Choix de pfSense : Besoin d'un pare-feu open-source et transparent avec support VLAN
  • Exigence de Commutateur Géré : Les commutateurs non gérés ne peuvent pas comprendre le marquage VLAN
  • Intégration Sans Fil : SSIDs séparés par domaine de sécurité, et non un seul réseau

Préoccupations et Notes

  • ⚠️ Risque de Sauts de VLAN (VLAN Hopping) : Attaques de double marquage possibles si non défendues
  • ⚠️ Complexité de la Configuration : Une faute de frappe dans une règle de pare-feu peut casser tout un segment
  • ⚠️ Surcharge de Performance : Minimale en homelab, mais le routage entre les VLANs ajoute de la latence
  • ⚠️ Compatibilité des Appareils Anciens : Les anciens appareils IoT pourraient ne pas prendre en charge correctement le marquage VLAN

Session 2 : Plongée en Profondeur - Philosophie des Règles de Pare-feu

Analyse des Règles

VLAN IoT (Le plus Restrictif) : - Seulement DNS/NTP sortant - Pourquoi ? - Les appareils IoT effectuent souvent des mises à jour cloud automatiques - En limitant à DNS/NTP uniquement, nous empêchons l'exfiltration - Contrôler leur comportement de « prise de contact »

  • Accès spécifique au serveur - Pourquoi ?
    • Si l'IoT a besoin d'accéder à des services, rendez cela explicite
    • Ceci empêche une ampoule compromise d'accéder à votre base de données

VLAN Serveur (Restriction Modérée) : - Communication interne de serveur à serveur - Pourquoi ? - Les pods Kubernetes peuvent avoir besoin de communiquer entre eux - Les bases de données nécessitent un accès client - Mais les clients externes sont restreints

  • Accès Internet Contrôlé - Pourquoi ?
    • Mises à jour du serveur (apt, docker pull, etc.)
    • Appels API vers des services externes
    • Mais journalisation/surveillance des connexions sortantes

VLAN de Confiance (Le plus Permissif) : - Les appareils personnels bénéficient d'un accès large - Pourquoi ? - Les utilisateurs ne devraient pas être constamment bloqués par le pare-feu - Mais toujours isolés des réseaux non fiables - Peuvent accéder à Internet directement sans restrictions

Réalisation Critique

Les règles de pare-feu ne servent pas seulement à bloquer le mauvais trafic — elles servent à faire respecter les limites de confiance. Chaque VLAN représente un niveau de confiance, et les règles déterminent ce à quoi ce niveau de confiance peut accéder.

Session 3 : Pièges de l'Implémentation et Solutions

Problème n°1 : Configuration Native du VLAN 1 du Commutateur

Problème : Le VLAN 1 est spécial — c'est le VLAN de gestion par défaut Pourquoi c'est important : Une mauvaise configuration peut vous empêcher d'accéder à la gestion des appareils Solution : Gardez le VLAN 1 inutilisé ou dédié uniquement à l'accès de gestion des appareils

Problème n°2 : Intégration du Point d'Accès WiFi (AP)

Problème : Comment les APs WiFi grand public gèrent-ils les VLANs ? Solution : Tous ne le font pas aussi bien - APs d'entreprise (UniFi, Omada, Aruba) : Excellent support VLAN - APs grand public : Support VLAN limité ou inexistant - Solution de contournement : Utilisez la fonctionnalité de réseau invité de l'AP pour approcher l'isolation

Problème n°3 : Étendues DHCP par VLAN

Problème : Chaque VLAN a besoin de sa propre étendue DHCP Solution : pfSense peut exécuter DHCP pour plusieurs VLANs - VLAN 30: 10.0.30.100-200 (IoT) - VLAN 50: 10.0.50.100-200 (Confiance) - Prévient les conflits d'IP, permet l'isolation

Problème n°4 : DNS par VLAN ?

Question : Chaque VLAN devrait-il avoir un DNS différent ? Approche actuelle : DNS unique (10.0.0.1 sur le pare-feu), mais on pourrait faire : - DNS de liste de blocage pour le VLAN IoT (prévenir le C&C des logiciels malveillants) - Filtrage de contenu pour le réseau invité - DNS séparé pour le VLAN soucieux de la confidentialité

Session 4 : Menaces de Sécurité et Atténuations

Menace : Sauts de VLAN (VLAN Hopping) (Double Marquage 802.1Q)

Comment cela fonctionne :

Attacker sends packet with two VLAN tags:
[outer: VLAN 30] [inner: VLAN 20]
Switch removes outer tag (still in VLAN 30)
Next device sees inner tag and processes as VLAN 20

Atténuation : 1. Désactiver le switchport trunking sur les ports d'accès 2. Définir les ports d'accès sur un VLAN spécifique (pas en mode trunk) 3. Maintenir le firmware à jour 4. Surveiller les transitions VLAN inhabituelles

Menace : Usurpation ARP (ARP Spoofing) au sein du VLAN

Comment cela fonctionne : L'attaquant envoie de fausses réponses ARP pour rediriger le trafic Atténuation : - Activer le snooping DHCP - Activer l'Inspection ARP Dynamique (DAI) - Entrées ARP statiques pour les appareils critiques

Menace : Serveur DHCP Pirate

Comment cela fonctionne : L'attaquant exécute un serveur DHCP, donne aux clients la mauvaise passerelle Atténuation : - Le snooping DHCP identifie et bloque les DHCP pirates - Ne faire confiance qu'aux ports DHCP autorisés - Surveiller les activités DHCP inattendues

Menace : Compromission d'un Appareil Légitime

Comment cela fonctionne : L'attaquant prend le contrôle d'un appareil IoT, l'utilise pour scanner le réseau Atténuation : C'est ce que les VLANs empêchent réellement - L'appareil compromis est piégé dans son VLAN - Les règles de pare-feu l'empêchent d'atteindre d'autres réseaux - La segmentation limite le rayon d'impact

Session 5 : Surveillance et Visibilité

Que Devrions-nous Surveiller ?

  1. Transitions VLAN
    • Quels appareils envoient/reçoivent sur plusieurs VLANs ?
    • On ne devrait normalement voir que les appareils de pare-feu faire cela
    • Alerter en cas d'activité inter-VLAN inattendue
  2. Déclenchements de Règles de Pare-feu
    • Quelles règles sont déclenchées ?
    • Attendu : IoT essayant d'atteindre des destinations non autorisées
    • Inattendu : Appareils de confiance essayant d'atteindre des serveurs restreints
  3. Requêtes DNS
    • Quels domaines les appareils IoT essaient-ils d'atteindre ?
    • Peut détecter la communication C&C
    • Peut optimiser les règles de pare-feu basées sur l'utilisation réelle
  4. Bande Passante par VLAN
    • Schémas normaux : Augmentation progressive
    • Schémas suspects : Transferts soudains importants
    • Indicateurs d'exfiltration de données

Outils à Utiliser

  • pfSense natif : Logs dans /var/log/filter.log
  • Prometheus : Collecter des métriques de pfSense
  • Grafana : Visualiser les schémas de trafic réseau
  • Tcpdump : Inspection approfondie des paquets (DPI) si nécessaire

Session 6 : Erreurs Courantes à Éviter

Erreur n°1 : Trop de VLANs Trop Tôt

❌ Créer 20 VLANs pour tous les cas d'utilisation possibles ✅ Commencez avec 3-5, ajoutez si nécessaire

Pourquoi : Plus de VLANs = plus de règles = plus d'endroits où faire des erreurs

Erreur n°2 : Oublier l'Accès de Gestion

❌ Créer un VLAN de gestion, puis être incapable d'accéder au pare-feu ✅ Gardez toujours l'accès de gestion clair et documenté

Pourquoi : Vous SEREZ bloqué si vous ne faites pas attention. La réinitialisation physique est pénible.

Erreur n°3 : Supposer que les Règles de Pare-feu « Fonctionnent Juste »

❌ Écrire des règles complexes sans tester ✅ Commencez par « autoriser tout », surveillez, puis restreignez progressivement

Pourquoi : Les règles interagissent de manière complexe. Testez d'abord dans un environnement à faible impact.

Erreur n°4 : Ne pas Documenter l'Allocation des VLANs

❌ Créer des VLANs verbalement, sans trace écrite ✅ Gardez une feuille de calcul : ID VLAN, Nom, Plage IP, Objectif, Règles

Pourquoi : Vous oublierez le mois prochain. Votre futur vous en aura besoin.

Erreur n°5 : Ignorer la Sécurité Physique

❌ Supposer que les VLANs empêchent les attaques physiques ✅ Sécuriser l'accès physique au commutateur, gestion des câbles

Pourquoi : Toute personne ayant un accès physique peut contourner les VLANs en utilisant la mise en miroir de ports ou des outils d'usurpation ARP

Session 7 : Analyse Coûts-Avantages

Investissement Requis

Composant Coût Nécessité
Commutateur Géré $200-600 CRITIQUE
Matériel pfSense $150-400 CRITIQUE
AP WiFi d'Entreprise $100-300 RECOMMANDÉ
Outils de Surveillance Free-$500 OPTIONNEL
Total $450-1800 Grande valeur

Avantage : Temps Économisé

  • Installation initiale : 6-8 heures
  • Maintenance mensuelle : 30 minutes
  • Dépannage : Plus rapide grâce à des limites réseau claires

Avantage : Amélioration de la Sécurité

  • Avant : Un appareil compromis = accès complet au réseau
  • Après : Un appareil compromis = isolé dans son VLAN, bloqué des ressources sensibles

Avantage : Apprentissage

  • Compréhension approfondie des protocoles réseau
  • Connaissances pratiques en sécurité
  • Confiance dans votre infrastructure

Session 8 : Améliorations Futures à Explorer

À court terme (3 prochains mois)

À moyen terme (3-6 mois)

À long terme (6-12 mois)

Session 9 : Angle Portfolio - Pourquoi C'est Important

Pour les Responsables du Recrutement

Ce projet VLAN démontre : 1. Pensée de Sécurité - Non seulement construire, mais sécuriser 2. Pensée Systémique - Comprendre comment les composants interagissent 3. Attention aux Détails - Les règles de pare-feu exigent de la précision 4. Résolution de Problèmes - Dépannage des problèmes réseau 5. Documentation - Essentiel pour les systèmes de production

Pour les Ingénieurs Examinant le Code

« Ils comprennent l'isolation réseau et peuvent probablement aussi apprécier la défense en profondeur dans l'architecture logicielle »

Pour la Perspective SRE/DevOps

  • Cette personne comprend l'isolation de l'infrastructure
  • Peut probablement bien architecturer les politiques réseau Kubernetes
  • Réfléchit aux limites de sécurité dès le début, et non après coup

Session 10 : Leçons et Observations

Ce Qui a Bien Fonctionné

✅ Choisir pfSense tôt a permis d'éviter de changer plus tard ✅ Commencer par le principe « refuser par défaut » a très bien fonctionné ✅ La documentation (ce fichier !) est inestimable ✅ Tester les règles individuellement avant le déploiement final

Ce Qui a Été Plus Difficile que Prévu

❌ Comprendre l'étendue DHCP à travers les VLANs ❌ Comprendre les concepts de commutation VLAN vs. routage ❌ Intégration WiFi (la plupart des APs ont un support VLAN limité) ❌ Configuration de la surveillance et de la visibilité

Principaux Points à Retenir

  1. La segmentation est une question de confiance, pas seulement de blocage
  2. La documentation est aussi importante que la configuration
  3. La sécurité réseau est une pratique, pas une configuration unique
  4. La surveillance est PLUS importante que les règles de pare-feu (vous ne pouvez pas sécuriser ce que vous ne voyez pas)
  5. Restez simple, puis ajoutez de la complexité avec précaution

Notes pour Mon Futur Moi

Lorsque vous êtes frustré parce qu'une règle de pare-feu ne fonctionne pas : 1. Vérifiez d'abord les logs du pare-feu 2. Vérifiez le marquage VLAN sur le commutateur 3. Confirmez l'étendue DHCP pour ce VLAN 4. Utilisez tcpdump pour voir le trafic réel 5. Dormez dessus, les solutions arrivent lorsque vous ne fixez pas le problème

Vous y arriverez. Le fait que vous documentiez ce parcours signifie que vous développez une expertise réelle, et non pas seulement que vous cliquez sur des boutons.

Dernière mise à jour : 29 octobre 2025 Prochaine révision : 12 novembre 2025 (2 semaines pour implémenter les retours)