Dans le monde numérique actuel, la sécurité réseau est une préoccupation majeure, même à l’échelle d’un domicile. Curieux d’explorer les mécanismes de surveillance réseau, j’ai entrepris de construire mon propre système de détection d’intrusion (IDS) à l’aide d’un mini PC Zotac Nano équipé de deux ports Ethernet. L’objectif était simple : placer ce petit gardien entre mon ordinateur portable et le reste de mon réseau, afin qu’il puisse scruter chaque paquet qui transiterait. Ce projet, riche en apprentissages, a révélé les forces et les faiblesses d’une telle approche DIY (Do It Yourself).
Le Cœur du Système : Un Mini PC Zotac Nano avec Double Ethernet
Le choix de l’équipement était stratégique. J’ai opté pour un mini PC d’entrée de gamme, un Zotac Nano doté d’un processeur Celeron N3160 et de 8 Go de RAM. Ses spécifications de calcul sont modestes, mais il possédait l’atout crucial qui a guidé ma décision : deux ports Gigabit Ethernet à l’arrière. Ce détail était essentiel pour créer un pont réseau transparent, permettant au mini-IDS de s’interposer sans perturber le fonctionnement normal de la connexion.
Mon précédent essai de modification du réseau avait causé quelques plaintes familiales suite à une coupure inattendue. Cette fois, je voulais une configuration isolée et indépendante que je pourrais redémarrer à ma guise sans impacter l’ensemble du réseau domestique. C’est pourquoi le mini-PC a été dédié à cette tâche spécifique, offrant un environnement de test sécurisé et contrôlé.
Mise en Place du Pont Réseau avec Debian 13
Pour la base logicielle, j’ai installé Debian 13, une distribution Linux réputée pour sa stabilité et sa légèreté. La première étape consistait à configurer le mini-PC pour qu’il agisse comme un pont réseau. Concrètement, cela signifie que le trafic entrant par un port Ethernet serait transparentement redirigé vers l’autre, comme si le mini-PC n’existait pas physiquement sur le chemin du trafic, tout en lui permettant d’inspecter ce même trafic.
J’ai connecté l’un des adaptateurs, assigné à enp3s0, au commutateur réseau de ma maison (vers le routeur Starlink). Le second port, ens1, a été relié directement à mon ordinateur portable Windows. Pour s’assurer que tout le trafic de l’ordinateur portable passait par le mini-IDS, j’ai désactivé le Wi-Fi sur le laptop.
La configuration du pont a été réalisée en modifiant le fichier /etc/network/interfaces avec les lignes suivantes :
auto br0
iface br0 inet dhcp
bridge_ports enp3s0 ens1Ces trois lignes indiquent à Debian de créer un pont nommé br0, d’y joindre les deux interfaces Ethernet (enp3s0 et ens1) et d’obtenir son adresse IP de gestion via DHCP. Après quelques tests initiaux, j’ai confirmé que Debian transférait correctement le trafic vers le routeur Starlink, assurant ainsi la connectivité de mon ordinateur portable. Le pont était en place, mais ce n’était que la première étape. Il fallait maintenant un mécanisme pour analyser ce trafic et identifier les activités suspectes.
Suricata : Le Moteur de Détection d’Intrusion Open Source
Pour la partie détection, j’ai choisi Suricata, un moteur de détection d’intrusion réseau open source très performant. Suricata est capable d’inspecter le trafic réseau en temps réel, de rechercher des motifs spécifiques (appelés règles) et de générer des alertes lorsqu’une correspondance est trouvée. Il peut fonctionner à la fois comme un système de détection d’intrusion (IDS) et comme un système de prévention d’intrusion (IPS) s’il est configuré pour bloquer le trafic.
J’ai configuré Suricata pour qu’il écoute sur le port faisant face à l’ordinateur portable (ens1). Après l’installation, une étape cruciale consiste à télécharger les règles de détection. J’ai utilisé sudo suricata-update pour récupérer l’ensemble de règles Emerging Threats Open. Ces règles sont une collection constamment mise à jour de signatures de menaces connues, allant des scans de ports aux tentatives d’exploitation de vulnérabilités.
Sans interface graphique native pour Suricata et peu enclin à éplucher des fichiers de journaux bruts, j’avais besoin d’un outil pour visualiser les alertes de manière conviviale. C’est là qu’EveBox entre en jeu.
EveBox : L’Interface Visuelle pour Gérer les Alertes
EveBox est un tableau de bord web qui transforme les journaux d’événements de Suricata en une interface de recherche et d’analyse. Il permet de parcourir les alertes, d’inspecter les connexions individuelles et de voir quelle règle de détection a déclenché l’alerte. C’est l’outil indispensable pour rendre les informations de Suricata exploitables et compréhensibles.
Pour vérifier le bon fonctionnement de l’ensemble, j’ai effectué un test simple : une requête DNS depuis mon ordinateur portable. Dans PowerShell, j’ai tapé :
nslookup -type=A example.org 192.168.1.9Quelques instants plus tard, à 23h35m58s, EveBox affichait bien la requête pour example.org et sa réponse correspondante. J’avais les fenêtres du terminal et d’EveBox côte à côte, ce qui m’a confirmé que la configuration était correcte et que Suricata voyait bien le trafic. Cette étape était cruciale pour valider l’interception et l’analyse du trafic par le mini-IDS, malgré les résultats inattendus du prochain test de scan de ports.
Mon Premier Scan de Ports n’a Généré Aucune Alerte : Pourquoi ?
Avant d’exécuter un scan de ports, je voulais m’assurer que l’IDS pouvait réellement détecter quelque chose d’un peu plus élaboré qu’une simple requête DNS. Depuis une machine virtuelle Linux située de l’autre côté du commutateur, j’ai créé un fichier texte contenant uid=0(root) gid=0(root) groups=0(root) et l’ai servi via un serveur HTTP Python temporaire. Sur mon ordinateur portable, j’ai ensuite téléchargé ce fichier à travers le pont :
curl.exe http://192.168.1.249:8080/id.txtImmédiatement, deux alertes sont apparues dans EveBox. Suricata avait d’abord identifié la bannière du serveur HTTP de Python, puis avait renvoyé l’entrée que j’attendais : « GPL ATTACK_RESPONSE id check returned root ». Une règle préexistante avait détecté la chaîne de caractères dans la réponse HTTP. Bien que mes « compétences » de hacker se soient limitées à taper le mot « root » dans un fichier, le détecteur avait fait son travail, prouvant qu’il était capable de repérer des motifs spécifiques.
C’est pourquoi le silence complet de l’IDS lors de mon test suivant fut d’autant plus déroutant. Depuis la même machine Linux, j’ai lancé Nmap, un outil de scan de ports réputé, vers mon ordinateur portable Windows, lui demandant de sonder 100 des ports TCP les plus courants :
sudo nmap -sS -n -Pn --top-ports 100 --reason 192.168.1.208En moins de deux secondes, Nmap a identifié quatre ports ouverts (principalement des ports de systèmes de gestion à distance) et 96 ports filtrés. Cependant, en rafraîchissant les journaux d’EveBox, je n’ai trouvé aucune nouvelle alerte. L’IDS était resté muet. Pourquoi Suricata n’avait-il rien signalé ?
Comprendre le Silence de Suricata : La Nuance entre Détection et Alerte
En approfondissant, j’ai vérifié les journaux de flux (flow logs) de Suricata directement sur le mini-IDS. Et là, la surprise : Suricata avait bien détecté 196 flux TCP avec le flag SYN (le premier paquet d’une connexion TCP) entre les deux machines, couvrant l’intégralité des 100 ports cibles. Néanmoins, pour chaque événement, la balise « alerted » était réglée sur false. Le mini-IDS avait vu le trafic, mais Suricata avait décidé qu’il n’était pas assez important pour déclencher une alerte formelle.
Ceci met en lumière une distinction cruciale : Suricata est conçu pour gérer d’énormes volumes de trafic réseau et ne peut pas alerter sur chaque événement. Son moteur de règles évalue la « gravité » ou la « pertinence » d’un événement avant de générer une alerte. Dans ce cas, un scan de 100 ports TCP n’était pas jugé suffisamment menaçant par les règles par défaut pour mériter une notification. Pour un IDS, c’est une fonctionnalité importante pour éviter la surcharge de « faux positifs » qui ne sont pas de réelles menaces.
La Création d’une Règle Locale : Apprendre à Éduquer l’IDS
Pour que Suricata signale un scan de ports, il fallait lui donner des instructions plus spécifiques. J’ai donc décidé d’ajouter une règle locale personnalisée. Cette règle devait détecter un « burst » de 20 paquets SYN TCP provenant d’une seule source vers mon ordinateur portable dans un intervalle de dix secondes. J’ai nommé cette règle « LAB TCP SYN burst to test laptop » pour bien la distinguer et éviter qu’elle ne se déclenche pour des tentatives répétées vers un seul et même port, ce qui n’était pas l’objectif ici.
Après avoir chargé cette nouvelle règle dans Suricata, j’ai répété le scan Nmap. Cette fois, l’alerte est apparue dans EveBox, accompagnée de l’adresse IP du scanner. La satisfaction était palpable : j’avais réussi à « éduquer » mon IDS pour qu’il reconnaisse et signale précisément le type d’activité que je considérais comme suspecte. Cela démontre la puissance et la flexibilité de Suricata, qui peut être adapté à des besoins de surveillance très spécifiques au-delà de ses règles par défaut.
Le Test de Débit : Une Vitesse Prometteuse, mais une Énorme Mise en Garde
Détecter un scan rapide et un transfert de fichier était encourageant, mais la question cruciale était de savoir si le mini-IDS allait ralentir ma connexion réseau et s’il pourrait gérer un volume de paquets élevé. J’ai donc procédé à des tests de débit avec l’outil réseau iperf3.
J’ai effectué trois tests de 15 secondes dans chaque direction, d’abord à travers le mini-IDS, puis en branchant mon ordinateur portable directement sur le commutateur pour avoir une base de comparaison. Les deux machines étaient sur mon LAN domestique, donc la vitesse de ma connexion Internet externe n’avait aucune incidence sur les résultats.
Les vitesses médianes rapportées par la VM Linux étaient impressionnantes :
| Direction de Transfert | Direct vers le commutateur | Via le mini-IDS |
|---|---|---|
| Laptop vers mini-IDS (mesuré au récepteur) | 949 Mbps | 946 Mbps |
| Mini-IDS vers laptop (mesuré à l’émetteur) | 950 Mbps | 950 Mbps |
Une différence de seulement 3 Mbps était tout à fait acceptable si cela signifiait que je bénéficiais d’alertes de sécurité réseau. Le débit était presque celui du gigabit. Cependant, cette apparente réussite cachait une problématique majeure.
Le Fléau des Paquets Perdus : La Vraie Limite du Mini-IDS
En vérifiant les compteurs de capture de Suricata, j’ai découvert la vérité : Debian était capable de transférer chaque paquet tout en offrant une copie à Suricata pour inspection. Mais sous une charge soutenue et importante, ces copies arrivaient beaucoup plus vite que le moteur de détection ne pouvait les traiter. Une fois le tampon de capture plein, Debian a commencé à jeter les copies entrantes, se contentant de laisser le transfert se poursuivre sans inspection.
Sur les 7,80 millions de paquets offerts à la capture pendant les tests de pontage, 5,73 millions ont été purement et simplement abandonnés. Cela représente environ 73,5 % de paquets perdus !
Évidemment, ce n’est pas idéal. Une règle ne peut correspondre qu’aux preuves que Suricata peut réellement voir. Si le paquet contenant ma fausse réponse uid=0(root) avait fait partie de ces copies abandonnées, j’aurais pu récupérer le fichier sans qu’aucune alerte ne soit générée. Cette perte massive de paquets sous charge est une limitation critique qui rend le système peu fiable pour une surveillance continue et exhaustive.
L’Utilisation Quotidienne : Discord et les Faux Positifs Potentiels
Après avoir soumis le Celeron à l’épreuve d’iperf3, je suis retourné à l’ordinateur portable pour une session d’utilisation normale chronométrée. En 16 minutes et 43 secondes, le mini-IDS avait enregistré 12 672 événements, sans compter ses propres statistiques internes. Parmi ceux-ci, seulement 12 étaient de véritables alertes. Cela semblait gérable et intéressant, jusqu’à ce que je réalise que ces 12 alertes ne faisaient que mentionner… Discord.
Six de ces alertes provenaient de requêtes DNS pour des domaines Discord. Les six autres provenaient de noms d’hôtes visibles lorsque l’ordinateur portable établissait des connexions chiffrées. Il ne serait pas juste de qualifier ces alertes de « faux positifs », car Discord était effectivement en cours d’exécution et les règles avaient correctement identifié son trafic. La question était plutôt de savoir si ces informations étaient réellement utiles.
Après avoir examiné de plus près la liste des alertes, la seule chose dont j’étais certain, c’était que l’ordinateur portable utilisait Discord. En d’autres termes, ce n’était guère une information que je qualifierais de précieuse pour la sécurité. Cela souligne un autre défi des IDS : la nécessité d’affiner les règles pour distinguer le trafic pertinent des « bruits » de fond inoffensifs, afin de ne pas être submergé par des alertes non actionnables.
Conclusion : Un Outil de Laboratoire Prometteur, mais Pas Encore Prêt pour la Maison
Le mini-IDS m’a impressionné lors des premiers scans. Ses enregistrements de flux m’ont montré précisément où mes sondes allaient, et une fois que j’ai écrit une règle, j’ai pu répéter le même test et voir l’alerte se déclencher. C’est une plateforme d’apprentissage fantastique et un outil précieux pour le développement de règles personnalisées ou la compréhension des mécanismes de détection d’intrusion.
Le problème flagrant, bien sûr, a été la perte massive de paquets pendant les tests iperf3. Il est très probable que le modeste processeur Celeron n’ait tout simplement pas pu suivre le rythme. Pour un foyer où l’on joue à des jeux AAA, où l’on diffuse du contenu multimédia en streaming et où l’on télécharge des fichiers volumineux, un taux de perte de paquets de 73,5 % est tout simplement inacceptable pour un système de sécurité fiable.
Dans l’état actuel des choses, je suis heureux d’utiliser ce mini-IDS comme banc d’essai dans mon homelab. C’est un excellent outil pour des tests ponctuels, pour comprendre le fonctionnement de Suricata et pour expérimenter des règles de détection spécifiques. Mais il n’a pas encore gagné sa place sur le réseau domestique principal, où la performance et la fiabilité sont primordiales.
Néanmoins, je reste confiant que Suricata aurait fonctionné bien mieux si seulement je lui avais fourni suffisamment de puissance de calcul pour fonctionner correctement. La prochaine fois qu’un de mes serveurs, machines virtuelles ou même ordinateurs de bureau commencera à communiquer avec quelque chose que je ne reconnais pas, je sais que ce mini-IDS sera mon premier recours pour diagnostiquer et identifier la menace potentielle. C’est un pas significatif vers une meilleure compréhension et une plus grande maîtrise de la sécurité de mon propre réseau, même si le chemin est encore long pour un IDS domestique pleinement opérationnel et fiable.