Segmentation réseau des téléviseurs de supervision

Quand une bonne idée devient une leçon d’humilité

Disclaimer

Ce projet est issu d’une situation professionnelle réelle chez Novalink, présentée ici sous une forme anonymisée. Les noms des équipements, adresses IP et éléments d’infrastructure ont été modifiés pour respecter les obligations de confidentialité.

Une observation qui devient une proposition

Pendant mon stage chez Novalink, j’ai remarqué quelque chose qui m’a interpellé lors d’une discussion avec mon maître de stage Mario Alves. Dans les openspaces du client, plusieurs téléviseurs professionnels affichaient en permanence l’interface de PRTG Network Monitor, un outil de supervision réseau hébergé dans un datacenter distant qui supervise plusieurs clients. Ces écrans étaient visibles par tous les employés et permettaient de surveiller en temps réel l’état de l’infrastructure.

Ce qui m’a frappé, c’est que ces téléviseurs étaient connectés directement au réseau de production, dans le même VLAN que d’autres ressources bien plus sensibles de l’entreprise. Dans la conversation, je me suis surpris à demander à Mario dans quel VLAN étaient exactement ces TV. Quand il m’a répondu qu’elles étaient dans le VLAN XX avec d’autres équipements, j’ai spontanément réagi en lui disant que ce n’était pas idéal et qu’il faudrait mieux segmenter le réseau pour isoler ces équipements.

Ma réflexion était assez simple : ces téléviseurs sont des équipements largement délaissés en termes de maintenance. Les mises à jour du système d’exploitation embarqué sont rares, voire inexistantes, et ces appareils peuvent potentiellement exposer des services inutiles ou avoir des vulnérabilités non corrigées. Même si le risque était plutôt théorique à ce stade, Mario a confirmé ma préoccupation. Ces équipements, de par leur nature, pouvaient constituer un point d’entrée potentiel pour un attaquant qui aurait ensuite pu rebondir vers d’autres ressources beaucoup plus sensibles du réseau.

Mario a validé ma proposition et m’a autorisé à établir un plan d’action pour intervenir sur l’infrastructure. C’était la première fois qu’un projet naissait vraiment de ma propre initiative, d’une observation personnelle que j’avais faite et transformée en proposition concrète. Cette responsabilité me motivait particulièrement.

La préparation : établir un plan avant d’intervenir

Avant de toucher à quoi que ce soit sur l’infrastructure de production, j’ai dû préparer un plan d’action détaillé. Ce n’était pas juste une formalité administrative, c’était vraiment nécessaire pour réfléchir à toutes les étapes, anticiper les problèmes potentiels, et surtout pour que Mario puisse valider mon approche avant que je ne commence à intervenir sur les équipements.

Mon plan était relativement simple sur le papier :

Créer un nouveau VLAN dédié aux téléviseurs (Mario m’a indiqué d’utiliser le VLAN ID 80)
Définir une plage d’adressage IP spécifique pour ce VLAN (172.31.80.0/28, un petit réseau avec seulement 14 adresses utilisables pour nos 5 téléviseurs)
Propager ce VLAN sur tous les switchs concernés (le switch de cœur de réseau et les switchs de distribution dans les openspaces)
Configurer les ports connectés aux téléviseurs en mode accès dans ce VLAN
Créer les règles de filtrage sur le pare-feu FortiGate pour autoriser uniquement l’accès au serveur PRTG distant

Sur le papier, ça semblait vraiment straightforward. J’avais déjà travaillé avec les VLAN pendant ma formation et lors de mes précédents projets chez Novalink. Je pensais vraiment maîtriser le concept et la configuration. J’étais confiant que ce serait un projet assez rapide à réaliser.

J’ai présenté mon brouillon de plan d’action à Mario, il l’a validé avec quelques ajustements mineurs, et nous avons fixé un moment pour intervenir ensemble sur l’infrastructure.

La configuration : quand la théorie rencontre la réalité

Le jour de l’intervention, je me suis connecté en SSH aux switchs Aruba. J’avais déjà l’habitude de travailler avec ces équipements, donc l’interface et la syntaxe de configuration ne me posaient pas de problème particulier. Mario était à côté de moi, pas pour faire le travail à ma place, mais pour valider chaque commande importante avant que je ne l’exécute. Sa méthode pédagogique était claire : je devais lui montrer la commande que je m’apprêtais à entrer, il me posait parfois des questions pour vérifier que je comprenais vraiment ce que j’allais faire, et si je commettais une erreur, il me l’indiquait avant que je ne l’envoie pour que je puisse la corriger moi-même.

C’est lors de la configuration des liaisons entre switchs que j’ai rencontré un obstacle auquel je ne m’attendais absolument pas. L’infrastructure utilisait des agrégats de liens (link aggregation ou LACP) entre les switchs pour assurer de la redondance et de la bande passante. En gros, au lieu d’avoir un seul câble entre deux switchs, il y en avait deux qui étaient agrégés logiquement pour former un seul lien logique plus robuste et plus rapide.

Le problème, c’est que je ne maîtrisais pas vraiment ce concept. Je comprenais vaguement le principe théorique de l’agrégation, mais je ne comprenais pas comment ça interagissait concrètement avec la configuration des VLAN en mode trunk. Résultat : j’ai configuré le trunk pour mon nouveau VLAN sur un seul des deux ports physiques de l’agrégat, pas sur les deux.

Techniquement, ma configuration fonctionnait. Le trafic du VLAN passait bien à travers le lien. Mais en réalité, je venais de complètement annuler l’intérêt de l’agrégation. Si le port que j’avais configuré tombait en panne, le trafic ne basculerait pas automatiquement sur le second port de l’agrégat puisque je ne l’avais pas configuré pour porter le VLAN. J’avais créé un point de défaillance unique alors que toute l’architecture était justement conçue pour éviter ça.

Mario a identifié l’erreur et me l’a expliquée. Il m’a montré comment configurer correctement le trunk sur l’agrégat lui-même plutôt que sur les ports physiques individuels. Sur le moment, j’ai appliqué la correction, j’ai compris mécaniquement ce qu’il fallait faire, mais je n’avais pas vraiment saisi en profondeur pourquoi c’était nécessaire. Je me suis dit « ok, c’est comme ça qu’il faut faire avec les agrégats » sans vraiment comprendre la logique sous-jacente.

Nous avons continué la configuration. J’ai progressivement propagé le VLAN sur tous les switchs concernés, configuré les ports d’accès pour les téléviseurs, puis nous sommes passés à la configuration du FortiGate. Là, j’étais sur un terrain beaucoup plus familier. Ce projet arrivait après mes expériences avec le déploiement IDS/IPS et la configuration de VPN, donc j’avais déjà des bases solides sur les FortiGate.

J’ai créé les politiques de sécurité inter-VLAN assez facilement :

Source : le réseau des téléviseurs (172.31.80.0/28)
Destination : l’adresse IP du serveur PRTG dans le datacenter distant
Services autorisés : HTTP et HTTPS uniquement
Tout autre trafic : explicitement bloqué

J’ai également activé la journalisation des flux pour garder une traçabilité de ce qui transitait depuis ce VLAN.

Les tests de validation

Une fois toute la configuration en place, il fallait valider que tout fonctionnait comme prévu. J’ai testé la connectivité depuis différents angles pour m’assurer de l’étanchéité du VLAN.

D’abord, j’ai vérifié que les téléviseurs pouvaient toujours accéder au serveur PRTG et afficher correctement l’interface de supervision. Ensuite, j’ai testé depuis d’autres VLAN pour confirmer qu’il était impossible de joindre directement les téléviseurs, ce qui était exactement le comportement souhaité. Enfin, j’ai vérifié dans les journaux du FortiGate que les règles s’appliquaient correctement et que seul le trafic autorisé passait.

Tout fonctionnait parfaitement. Les téléviseurs étaient maintenant isolés dans leur VLAN dédié, ne pouvaient communiquer qu’avec le serveur PRTG, et le reste du réseau était protégé d’une éventuelle compromission de ces équipements.

Mario a validé que le projet était terminé et que tout était opérationnel. J’étais satisfait du résultat, même si je restais avec cette sensation désagréable de ne pas avoir vraiment compris en profondeur cette histoire d’agrégats.

Le déclic qui vient après coup

Quelques jours plus tard, alors que le projet était déjà bouclé et que j’étais passé à autre chose, je me suis surpris à repenser à cette configuration. Je ne sais pas exactement ce qui a déclenché cette réflexion, peut-être que mon cerveau continuait à travailler en arrière-plan sur ce concept que je n’avais pas totalement assimilé.

Et soudainement, tout s’est éclairci dans ma tête. J’ai compris pourquoi il fallait configurer le trunk sur l’agrégat logique plutôt que sur les ports physiques individuels. L’agrégat, c’est comme un seul « super-port » virtuel qui se comporte comme une entité unique. Si on configure les VLAN sur les ports physiques séparément, on casse cette abstraction et on perd tous les bénéfices de l’agrégation : la redondance, le load balancing, la failover automatique.

Ce déclic qui vient après coup, plusieurs jours après avoir terminé le projet, m’a fait réaliser quelque chose d’important sur la façon dont j’apprends. Parfois, comprendre mécaniquement comment faire quelque chose ne suffit pas. La vraie compréhension profonde, celle qui permet d’appliquer le concept dans d’autres contextes et de l’expliquer à quelqu’un d’autre, elle vient parfois avec un décalage temporel, quand le cerveau a eu le temps de digérer l’information et de la connecter à d’autres connaissances.

Ce que j’en retiens : amélioration vs nécessité

Avec le recul, ce projet m’a appris plusieurs choses qui vont bien au-delà de la simple technique de configuration des VLAN et des agrégats.

D’abord, il m’a enseigné l’humilité intellectuelle. Je pensais maîtriser les VLAN, et je me suis rendu compte qu’il y avait des aspects connexes comme les agrégats que je ne maîtrisais pas du tout. Cette découverte de mes propres lacunes, même si elle était un peu frustrante sur le moment, était en réalité très précieuse. Elle m’a rappelé qu’en informatique, on n’a jamais vraiment fini d’apprendre, et que chaque nouveau projet est une opportunité de découvrir quelque chose qu’on ne savait pas.

Ensuite, ce projet m’a permis de comprendre la différence entre une tâche de maintenance ou de dépannage et une amélioration proactive. Cette segmentation des téléviseurs n’était pas une réelle nécessité au sens strict. Il n’y avait pas de panne à réparer, pas d’incident de sécurité à traiter en urgence. C’était une amélioration, une couche de sécurité supplémentaire ajoutée à l’infrastructure de manière anticipée. Le risque que ces téléviseurs soient compromis et servent de point d’entrée était réel et légitime, mais il était plutôt théorique à ce stade.

Cette distinction est importante parce qu’elle reflète deux approches différentes de l’administration système. On peut se contenter de réagir aux problèmes quand ils surviennent, ou on peut adopter une posture proactive en identifiant et en corrigeant les faiblesses potentielles avant qu’elles ne deviennent des problèmes réels. Ce projet était clairement dans la seconde catégorie, et c’est d’ailleurs pour ça qu’il est né de ma propre observation plutôt que d’une demande externe.

Le fait de travailler sur une infrastructure de production, où « on n’a pas le droit à l’erreur » comme je le dis souvent, m’a également appris la rigueur. Ce n’est pas un laboratoire où on peut tout casser et réinitialiser les équipements si quelque chose ne fonctionne pas. Chaque commande compte, chaque modification doit être réfléchie et validée. Cette pression, loin de me stresser grâce à la présence rassurante de Mario, m’a au contraire rendu plus méthodique et plus attentif aux détails.

Enfin, ce projet m’a fait découvrir les agrégats de liens, une fonctionnalité que je ne maîtrisais pas avant et que j’ai apprise sur le tas. Cette découverte m’a donné une meilleure compréhension globale de la segmentation réseau et de la façon dont les différentes technologies (VLAN, agrégation, pare-feu) s’articulent pour créer une infrastructure à la fois performante et sécurisée.

Ce projet illustre parfaitement une réalité du métier d’administrateur système que les formations théoriques ne transmettent pas toujours bien : on apprend vraiment en faisant, en se confrontant à des situations réelles où nos connaissances théoriques sont mises à l’épreuve de la complexité du terrain. Et parfois, les apprentissages les plus profonds viennent non pas pendant l’action elle-même, mais dans ces moments de réflexion après coup où tout se met en place dans notre tête.

Ce projet a été réalisé lors de mon stage chez Novalink en 2023/2024, sous la supervision de Mario Alves, dans le cadre de l’amélioration continue de la sécurité des infrastructures clients.