Maintenir à jour un schéma réseau, c’est un vrai défi pour de nombreux services informatiques. Généralement, ce n’est pas une tâche prioritaire, et pourtant, il joue un rôle important pour avoir une bonne visibilité sur le système d’information dans son ensemble. Il y a un outil open source qui pourrait vous aider à accomplir cette tâche : Scanopy. En scannant votre réseau, il détermine automatiquement un schéma réseau. Voici comment l’installer et l’utiliser.

Un outil qui crée un schéma réseau tout seul, et qui le maintient à jour, je crois qu’on en a tous rêvé. Pour autant, ce n’est pas une tâche évidente, car il faut que cet outil soit capable d’analyser le réseau dans son ensemble, ce qui sous-entend aussi de s’intéresser aux différents VLAN, pour avoir un résultat exhaustif et cohérent.

Dans cet article, nous allons parler de Scanopy (anciennement NetVisor), un outil créé dans cet objectif : “Des diagrammes réseau propres. Configuration unique, aucun entretien.“, c’est le slogan visible sur le site Internet. Au-delà de la promesse de la génération de diagramme réseau (cartographie automatique du réseau), cet outil permet de savoir ce qui est exposé sur les différentes machines connectées à votre réseau : et ça, potentiellement, vous pourriez passer à côté si le travail est effectué manuellement.

Scanopy est une solution open source avec une version communautaire (gratuite pour un usage personnel ; voir cette page) capable de scanner un ou plusieurs réseaux. En effet, l’outil repose sur deux composants clés : le serveur accessible via une interface web et qui centralise les données, et le daemon qui agit comme un agent de découverte réseau. Vous pouvez déployer un agent sur différents réseaux (un par VLAN, par exemple) et centraliser toutes les informations sur un seul serveur. Le fait de positionner un agent directement sur un réseau permet de collecter plus d’informations (y compris les adresses MAC). Son architecture est détaillée sur cette page.

Scanopy est capable de détecter plus de 200 services différents : Docker, Veeam, Proxmox Backup Server, MariaDB, Active Directory, Bitwarden, Keycloak, Nextcloud, SSH, CrowdSec, RDP, OPNsense, Fortinet, Graylog ou encore Grafana. Il détecte donc des services spécifiques qu’il est capable de nommer et des services génériques (SSH, RDP, etc.), voire des types d’équipements (pare-feu, poste de travail, etc.). Il peut aussi analyser un hôte Docker en se connectant directement au moteur Docker en lui-même.

Voici le lien vers le dépôt GitHub de la solution :

• GitHub – Scanopy

Scanopy : un ou plusieurs agents

Quand vous déployez Scanopy en local sur votre infrastructure, vous pouvez déployer uniquement un serveur et un daemon (agent). À partir de là, vous pourrez scanner votre réseau local. Une autre approche consiste à avoir un serveur Scanopy et plusieurs daemons (agents), comme le montre le schéma ci-dessous.

En réalité, ce choix doit s’effectuer en fonction de vos besoins et de votre architecture réseau. Si le daemon Scanopy est connecté en direct au réseau à analyser, il peut faire une découverte plus précise grâce à la détection des hôtes via le protocole ARP. Au contraire, si ce n’est pas le cas (analyse d’un VLAN B depuis un VLAN A, par exemple), la découverte sera partielle, car limitée au scan TCP (donc uniquement les machines avec des ports ouverts). Cela s’explique par le fait que le protocole ARP (couche 2) ne passe pas les routeurs.

Il y a donc 3 stratégies de déploiement envisageables pour Scanopy :

• Un serveur central et un seul daemon, avec du routage permettant l’analyse de tous les VLAN (scan limité)
• Un serveur central et un daemon par VLAN
• Un mix des deux, c’est-à-dire un daemon uniquement sur certains VLAN où il y a besoin d’un scan plus précis

Ce choix aura aussi un impact sur les flux réseau, et donc sur le filtrage au niveau firewall. Mais il faut savoir que Scanopy a deux modes de fonctionnement : Pull (le daemon se connecte au serveur) et Push (le serveur se connecte au daemon). Le mode Pull est préférable, car il implique moins de changement au niveau des règles de pare-feu.

Dans le cadre de cet article, je vais vous expliquer comment installer Scanopy avec un serveur central et un agent. Puis, nous verrons comment ajouter un agent sur un sous-réseau spécifique, ce qui vous donnera toutes les informations nécessaires pour les différents scénarios.

Installation de Scanopy avec Docker

Scanopy s’installe à l’aide de Docker grâce aux images prêtes à l’emploi et distribuées par les mainteneurs de la solution. Il y a plusieurs conteneurs à déployer :

• : le daemon (agent) de découverte réseau.
• : la base de données PostgreSQL du serveur.
• : le serveur Scanopy, accessible via un navigateur web.

Persistance des données

Nous allons créer une arborescence de dossiers pour héberger ce projet, à commencer par la racine.

Puis, à l’intérieur, créez ces trois sous-dossiers :

Soit la commande suivante :

Le premier répertoire sert à stocker la configuration de l’agent, le second la base de données et la configuration de PostgreSQL, et le troisième les données du serveur.

Le fichier Docker Compose de Scanopy

À la racine de , créez le fichier avec le code spécifié ci-dessous. J’ai pris comme base le fichier Docker Compose disponible sur GitHub au sein duquel j’ai apporté quelques modifications.

Ce que vous devez savoir :

• Des variables d’environnement sont directement définies dans les premières lignes du fichier (à la suite de ) et réutilisées tout au long de la configuration.
• : dans la définition du daemon, conservez cette ligne pour la découverte des conteneurs Docker. Pour plus de sécurité, préférez l’interrogation via Docker Socket Proxy, car c’est pris en charge (voir cette page de la documentation et mon tutoriel Docker Socket Proxy).
• Le sera accessible sur le port , ce qui veut dire que l’interface web sera accessible sur .

Cette configuration permet à l’application Scanopy de se lancer avec un serveur et un daemon, le tout hébergé sur le même hôte. La configuration est déterminée de façon à permettre au daemon de se connecter au serveur via l’adresse locale (localhost / 127.0.0.1).

Si vous comparez mon fichier Docker Compose à celui du dépôt GitHub de Scanopy, vous remarquerez que je n’ai pas utilisé le même sous-réseau. En effet, lorsque j’ai tenté de build le projet, j’ai eu l’erreur ci-dessous : le sous-réseau défini de façon statique était déjà pris par un autre projet exécuté sur mon hôte Docker). J’ai donc modifié le fichier Docker Compose pour utiliser un autre sous-réseau.

Lancez la construction du projet et patientez un instant.

Vous pouvez aussi afficher les journaux pour voir ce qu’il se passe :

Première connexion à Scanopy

Ouvrez votre navigateur Web et accédez à l’interface d’administration de Scanopy. Un assistant avec 3 étapes doit être complété pour commencer. Vous devez commencer par préciser le contexte d’utilisation.

Puis, nommez l’installation ainsi que votre réseau, tout en sachant que ce daemon y sera rattaché et que vous pouvez créer plusieurs réseaux.

Enfin, créez un compte administrateur.

Voilà, vous disposez d’un accès à l’interface web de Scanopy !

Prise en main de Scanopy

Scanopy commence déjà à travailler : le daemon scanne le réseau sur lequel il est connecté à la recherche d’hôtes et de services. Si vous rafraichissez la page de temps en temps, vous devriez voir apparaître des informations. Le scan complet peut nécessiter plusieurs dizaines de minutes, selon le nombre de sous-réseaux.

Si vous cliquez sur “Sessions” à gauche, vous verrez qu’il y a une tâche en cours : elle montre bien que le daemon Scanopy scanne actuellement le réseau.

La section “Scheduled” permet de voir l’ensemble des tâches planifiées et de les personnaliser. Par défaut, le scan est effectué une fois par jour. L’historique des scans quant à lui est visible dans la section “History“.

Je vous invite à parcourir les sections sous “Assets“, car c’est là que sont visibles tous les éléments détectés :

• Networks : vos différents réseaux, du point de vue de Scanopy.
• Subnets : vos différents sous-réseaux détectés par le daemon. Chaque subnet peut être associé à un réseau Scanopy.
• Groups : créer des groupes logiques de services, ce qui va dessiner un lien entre eux sur le diagramme (purement visuel).
• Hosts : tous les hôtes détectés, avec leur nom, les services, les adresses IP, etc.
• Services : tous les services identifiés sur votre réseau et sur quel(s) hôte(s).

Scanopy va découvrir vos hôtes, mais ce sera sûrement partiel. Par exemple, les noms d’hôtes ne vont pas forcément remonter, tout dépend du comportement des systèmes interrogés. En fonction de leur configuration, ils ne seront pas tous aussi bavards… L’intérêt étant de laisser Scanopy travailler, puis de repasser derrière lui pour personnaliser la fiche des hôtes détectés (mettre le nom, par exemple).

Sur l’environnement où il a été exécuté et où quelques machines sont exécutées, Scanopy a pu identifier plusieurs machines. On voit notamment deux contrôleurs de domaine Active Directory, un serveur Graylog, un pare-feu OPNsense, un serveur avec des partages (nommé Samba) et un autre accessible via le Bureau à distance.

On peut aussi constater que plusieurs conteneurs Docker ont été détectés, et à chaque fois, il indique sur quel port écoute le conteneur, ce qui est plutôt appréciable.

Scanopy permet d’exporter le schéma réseau sous la forme d’une image. Pour le moment, il n’y a pas d’autres formats disponibles pour l’export, ce qui rend difficile l’édition en dehors de cet outil. Voici un exemple du schéma obtenu sans aucune intervention de ma part, soit un résultat brut.

Je trouve qu’il manque la possibilité d’ajouter un intitulé avec un icône, pour identifier plus facilement chaque hôte avec sa vignette. Un mode compact, qui ne ferait apparaître que le nom et l’adresse IP serait aussi le bienvenu à mon sens.

Déployer un daemon Scanopy

Pour déployer un nouveau daemon Scanopy afin de scanner un autre sous-réseau de façon approfondie, vous devez déclarer un nouveau daemon sur l’interface web. Dans le menu latéral, cliquez sur “Daemons“, puis, une fois sur la nouvelle page, cliquez sur “Create Daemon” en haut à droite.

Vous devez alors le lier à un réseau, lui donner un nom et choisir un mode. Le mode “Pull” est plus avantageux au niveau de la gestion des flux réseau. Vous devez aussi générer une nouvelle clé d’API.

La clé d’API sera utilisée par le nouveau daemon Scanopy pour s’authentifier auprès du serveur.

Vous avez deux options pour installer ce daemon : lancer un script Bash ou l’exécuter avec Docker Compose. Dans les deux cas, des instructions détaillées sont fournies. En fonction des informations saisies dans le formulaire, les commandes sont ajustées automatiquement.

Validez.

Dans la section “Api Keys” située sous “Daemons“, la nouvelle clé d’API destinée au nouveau daemon est visible.

Ce second daemon Scanopy a été déployé sur un NAS Synology via Container Manager (Docker).

Le code ci-dessous a été utilisé pour le déploiement de ce conteneur. J’ai repris le code proposé par Scanopy lors de la création du daemon sur l’interface web, en ajustant seulement 2 informations : l’URL vers le serveur Scanopy () et le chemin vers le volume persistant ().

Ainsi, l’agent Scanopy est en cours d’exécution sur le NAS Synology. Il va pouvoir scanner le réseau sous-jacent auquel est connecté le NAS et il peut même détecter les conteneurs Docker exécutés sur le NAS (facultatif, vous n’avez qu’à commenter la ligne faisant référence à ).

Côté serveur, la mise à jour du champ “Last Seen” dans la liste des daemons montre que la connexion a bien été établie.

Ce nouvel agent va détecter les hôtes et les services, ce qui va alimenter encore un peu plus le diagramme réseau généré par Scanopy.

Conclusion

Scanopy est un outil qui essaie d’apporter une réponse à une problématique loin d’être évidente à adresser : la création dynamique d’un diagramme réseau. Il permet de générer des résultats pertinents, qu’il faut ensuite affiner manuellement via l’édition des assets. De plus, vous devez garder à l’esprit que, d’un réseau à un autre, les résultats pourront être différents : le pare-feu et d’autres systèmes de sécurité peuvent venir perturber l’analyse de Scanopy, et donc influencer la pertinence des résultats.

Pour le moment, certains services sont inconnus aux yeux de Scanopy : il détecte plus de 200 services, ce qui est beaucoup et peu à la fois compte tenu de la diversité des solutions qu’il peut trouver sur son chemin. Enfin, sachez que la feuille de route de Scanopy est bien fournie, et personnellement, j’ai hâte de voir comment va évoluer cette solution dans les prochains mois.