Déploiement d’une architecture IDS/IPS en environnement ultra-sensible

Quand la théorie rencontre la réalité du terrain

Le contexte : un pentest qui change tout

Pendant mon stage chez Novalink, l’un de nos clients a fait réaliser un test d’intrusion sur son infrastructure réseau. Les résultats ont révélé plusieurs vulnérabilités critiques qui nécessitaient une réponse immédiate. La solution retenue ? Un système de détection et de prévention d’intrusions capable d’analyser l’ensemble du trafic réseau sans interrompre le moindre service. Rien que de très classique en apparence, sauf que le contexte ne l’était absolument pas. Ce client opérait dans un secteur tellement sensible que je ne peux toujours pas révéler la nature exacte de son activité, ayant signé une clause de confidentialité stricte. Tout ce que je peux dire, c’est que les protocoles de sécurité sur place dépassaient largement tout ce que j’avais pu imaginer jusqu’alors.

La découverte en laboratoire : trois tentatives pour comprendre

Avant même de penser au déploiement sur site, mon maître de stage Mario Alves m’a confié une mission apparemment simple : comprendre comment fonctionnent les ports SPAN et le mode sniffer sur les équipements Fortinet. Sa méthode pédagogique était claire : je devais d’abord faire mes propres recherches, puis lui expliquer ce que j’avais compris, et seulement ensuite il me donnerait ses explications.

Je me suis donc plongé dans la documentation technique, les forums spécialisés, et j’ai rapidement découvert le principe général des systèmes de détection d’intrusion. Ce qui m’a frappé lors de mes premières recherches, c’est que j’ai trouvé beaucoup d’informations sur différentes approches de détection, notamment l’analyse comportementale et d’autres méthodes assez sophistiquées. Quand j’ai présenté mes découvertes à Mario, il m’a écouté attentivement puis m’a précisé un détail crucial : chez Fortinet, le système repose principalement sur l’analyse de signatures de paquets. Ce n’était pas exactement ce que mes recherches générales m’avaient laissé entrevoir, et c’est là que j’ai compris qu’il existait une vraie différence entre comprendre un concept de manière théorique et savoir comment il est implémenté concrètement sur un équipement spécifique.

C’est lors de cette conversation que Mario m’a vraiment expliqué le fonctionnement détaillé. Pour détecter une intrusion, le système Fortinet compare chaque paquet qui transite sur le réseau à une base de données contenant des milliers de signatures connues de virus, de malwares et d’attaques. C’est comme si on comparait chaque personne qui entre dans un bâtiment à un fichier de personnes recherchées. Cette explication m’a fait réaliser quelque chose d’immédiatement inquiétant : si une nouvelle menace apparaît, quelque chose qui n’existe pas encore dans la base de signatures, alors le système ne pourra tout simplement pas la détecter. Cette prise de conscience est venue assez tôt dans le projet, mais j’y reviendrai plus tard parce qu’elle a vraiment influencé ma façon de voir la cybersécurité.

En parallèle de cette compréhension conceptuelle, je devais aussi maîtriser la manipulation pratique des équipements. L’interface en ligne de commande était complètement nouvelle pour moi à l’époque, et jongler entre la théorie et ces aspects pratiques n’était pas évident. Il m’a fallu trois essais complets en laboratoire avant de vraiment maîtriser l’ensemble des manipulations. À chaque fois que je bloquais sur quelque chose, je posais des questions à Mario ou je retournais faire des recherches complémentaires sur Internet. Cette alternance entre exploration autonome et demande d’aide ciblée m’a permis de progresser assez rapidement, même si sur le moment, ces trois tentatives m’ont paru longues.

Le laboratoire nous a d’ailleurs réservé une première surprise instructive. L’employé chargé de nous fournir les adresses IP à attribuer aux FortiGate a fait une erreur et nous a donné une adresse déjà utilisée par une autre machine. Résultat : un conflit d’adresses qui a bloqué le système pendant un moment. Ce genre de problème trivial en apparence peut complètement paralyser un déploiement si on ne comprend pas ce qui se passe. Heureusement, nous l’avons rencontré en laboratoire et pas sur site, ce qui m’a permis d’apprendre à diagnostiquer ce type de situation dans un environnement sans pression.

Le principe technique : comprendre le SPAN et le mode sniffer

Une fois que j’ai vraiment compris le concept, l’architecture déployée m’est apparue particulièrement élégante dans sa simplicité. L’idée centrale repose sur une technologie appelée SPAN, qui permet de dupliquer tout le trafic réseau qui transite par un switch. Concrètement, on configure certains ports du switch comme sources, et ces ports vont recopier l’intégralité du trafic qu’ils voient vers un port de destination spécifique. Ce port de destination est ensuite connecté à un FortiGate configuré en mode « One-Arm Sniffer », ce qui signifie qu’il observe le trafic sans être physiquement dans le chemin de production.

L’avantage énorme de cette approche, c’est qu’on peut analyser l’ensemble du trafic réseau sans créer le moindre point de défaillance. Si le FortiGate tombe en panne ou rencontre un problème, le réseau de production continue à fonctionner normalement puisque le trafic réel ne passe pas à travers lui. C’était d’ailleurs une contrainte absolue du client : aucune interruption de service n’était tolérable, même le temps d’une installation.

Pour ce projet, nous avons déployé quatre FortiGate 60F, chacun connecté à un stack de switches différent pour couvrir l’ensemble de l’infrastructure. Tous ces FortiGate remontaient leurs logs vers un FortiAnalyzer 300G qui centralisait l’ensemble des événements de sécurité, et l’administration globale était gérée par un FortiManager hébergé sur une machine virtuelle dans un VLAN dédié au management.

Le jour J : quand les protocoles de sécurité deviennent réalité

Avant de partir sur site, j’étais plutôt confiant. J’avais réussi mes manipulations en laboratoire, je connaissais maintenant les concepts, et surtout j’avais Mario avec moi, ce qui me rassurait énormément. Je savais déjà que le contexte ne serait pas tranquille, donc mentalement j’étais préparé à un environnement strict.

Mais savoir intellectuellement qu’un site est sécurisé et le vivre concrètement, ce sont deux choses très différentes. Dès notre arrivée, tout le matériel que nous avions apporté, les FortiGate, le FortiAnalyzer, nos outils, tout est passé aux rayons X pour autorisation d’entrée. Mon téléphone et mon ordinateur personnel sont restés à l’accueil. Plus de possibilité de vérifier rapidement une commande que j’aurais oubliée, plus de documentation accessible en un clic, plus aucun de mes repères habituels. Tout devait être dans ma tête ou dans les notes papier que nous avions préparées.

Une fois à l’intérieur, j’ai été systématiquement accompagné par un agent de sécurité qui surveillait mes moindres faits et gestes. Je ne pouvais circuler nulle part seul, et l’agent me suivait partout, y compris aux toilettes, ce qui était franchement gênant mais compréhensible vu le contexte. Paradoxalement, sa présence ne m’a pas vraiment troublé pendant le travail technique lui-même. Il s’est d’ailleurs montré serviable en m’aidant à porter le matériel, ce qui a créé une forme de collaboration inattendue malgré son rôle de surveillance.

Ce qui m’a vraiment occupé l’esprit pendant l’installation, ce n’était pas tant la configuration logicielle des FortiGate, qui reste relativement simple chez Fortinet avec des interfaces assez intuitives et beaucoup de cases à cocher, mais plutôt l’installation physique dans des espaces parfois exigus. Et c’est d’ailleurs là que j’ai connu mon moment de plus grande frayeur du projet.

Lors de l’installation d’un des FortiGate dans une baie de brassage particulièrement étroite, j’ai accidentellement heurté un câble d’alimentation d’un switch qui était mal branché. Le switch s’est éteint immédiatement. Sur le moment, j’ai ressenti une vague de panique absolue. Si la configuration de ce switch n’était pas sauvegardée, nous allions devoir tout reconfigurer, et tout cela aurait été entièrement de ma faute, dans un environnement ultra-sensible où la moindre erreur pouvait avoir des conséquences importantes. Heureusement, après quelques secondes qui m’ont paru durer une éternité, le switch a redémarré et la configuration était bien sauvegardée. Mais cette frayeur m’a marqué et m’a rendu encore plus vigilant pour la suite de l’installation.

Le soulagement : quand les logs commencent à remonter

Une fois tous les équipements physiquement installés et configurés, est venu le moment de vérité : vérifier que les logs remontaient correctement sur le FortiAnalyzer. Je ne connaissais pas cette infrastructure dans laquelle nous intervenions, je n’avais aucun repère visuel familier, et surtout je n’avais plus accès à mes outils habituels pour dépanner rapidement en cas de problème. Quand j’ai vu les premiers événements apparaître sur l’interface du FortiAnalyzer, j’ai ressenti un soulagement énorme. Ce n’était pas juste une satisfaction technique d’avoir réussi la configuration, c’était un vrai relâchement émotionnel après toute cette tension.

Nous avons ensuite effectué des tests de validation en générant du trafic entre différents équipements pour vérifier que tout était bien détecté et que les journaux se centralisaient correctement. Chaque test confirmait que le système était opérationnel et que notre travail de préparation en laboratoire avait porté ses fruits.

La passation de connaissances : transmettre pour autonomiser

Une fois le système déployé et validé, il restait une étape cruciale que beaucoup de techniciens négligent : la passation de connaissances aux équipes qui allaient vivre au quotidien avec ce système. Cette partie a été principalement animée par Mario, mais j’ai été associé à la préparation du contenu et j’étais présent lors d’une partie de la présentation. Observer comment Mario adaptait son discours à un public non technique m’a beaucoup appris.

Les questions posées par les équipes sur place étaient très révélatrices de leurs préoccupations opérationnelles concrètes. Elles ne voulaient pas des explications théoriques sur le fonctionnement de l’analyse de signatures, elles voulaient savoir comment faire remonter les erreurs en pratique, comment configurer l’envoi de notifications quand quelque chose d’anormal se produit, et surtout que faire concrètement en cas de détection d’un paquet suspect. Ces questions m’ont fait réaliser qu’un système technique, aussi sophistiqué soit-il, n’a de valeur que s’il s’intègre naturellement dans le workflow quotidien des personnes qui l’utilisent. Nous avons également donné un accès aux logs à l’équipe de sécurité interne pour qu’ils puissent superviser l’ensemble de l’infrastructure de manière autonome.

Les réflexions qui viennent après : les limites de la détection par signature

C’est plus tard, lors de la rédaction de mon rapport de stage, que ma question initiale sur les nouvelles menaces est revenue me hanter avec encore plus de force. En écrivant et en prenant du recul sur ce que nous avions déployé, je me suis dit que dans un établissement aussi sensible, une attaque zero-day, c’est-à-dire une attaque complètement nouvelle qui n’existe dans aucune base de signatures, pourrait passer complètement inaperçue. Le système que nous avions mis en place était excellent pour détecter les menaces connues, mais par définition aveugle face à l’inconnu.

Cette réflexion critique ne diminue en rien la valeur du projet ou la pertinence de la solution déployée. Au contraire, comprendre les limites d’un système de sécurité est tout aussi important que comprendre ses forces. Un bon professionnel de la cybersécurité ne peut pas se contenter de déployer des outils en faisant confiance aveuglément à leur efficacité. Il doit constamment garder à l’esprit ce que le système peut manquer et réfléchir à des approches complémentaires.

Ce que j’en retiens : bien au-delà de la technique

Quand Mario m’a félicité après cette intervention en me disant que j’avais eu une attitude exemplaire pour un gamin de terminale, j’ai compris qu’il ne parlait pas seulement de mes compétences techniques. Ce qui comptait, c’était aussi ma capacité à garder mon calme dans un environnement stressant, à accepter les contraintes de sécurité sans me plaindre, et surtout à avoir conscience que je représentais Novalink auprès du client.

Cette prise de conscience déontologique a été l’un des apports les plus importants de ce projet. En tant que prestataire, chaque erreur que je pourrais commettre ne me pénaliserait pas seulement moi personnellement, mais pourrait potentiellement coûter un contrat à l’entreprise qui m’emploie. Cette responsabilité change complètement la nature du travail et impose une rigueur qui va bien au-delà de la simple maîtrise technique.

Sur le plan technique pur, ce projet m’a permis de découvrir simultanément plusieurs concepts nouveaux : les ports SPAN, le mode sniffer, l’interface CLI des équipements Fortinet, la centralisation des logs avec FortiAnalyzer, et l’administration centralisée avec FortiManager. Mais surtout, il m’a confronté à la réalité du terrain avec ses imprévus, ses contraintes physiques, et ses moments de tension.

Malgré toutes les difficultés, les protocoles contraignants, le stress de l’environnement ultra-sécurisé, et même l’incident avec le câble du switch, je suis sorti de cette expérience avec une certitude : c’est vraiment ce type de travail technique qui me correspond. Il y a quelque chose de profondément satisfaisant dans cette combinaison entre réflexion intellectuelle, manipulation concrète d’équipements, résolution de problèmes sur le terrain, et cette responsabilité de sécuriser des infrastructures critiques.

Ce projet reste pour moi un exemple parfait de ce qu’est vraiment le métier de technicien en systèmes et réseaux : un mélange constant entre préparation rigoureuse et adaptation à l’imprévu, entre maîtrise technique et relations humaines, entre confiance en ses compétences et conscience de ses limites.