Information des connexions sans-agent pour les équipements réseau
Cyberwatch scanne les équipements réseau (routeurs, commutateurs, pare-feu, appliances…) en connexion sans-agent, par SNMP sur le port UDP 161. Le scan interroge l’agent SNMP de l’équipement, sans rien y installer ni modifier, et remonte :
- le système et sa version (firmware), d’où sont déduites les vulnérabilités ;
- le nom d’hôte et les adresses IP ;
- des métadonnées : emplacement, numéro de série, modèle, rôle de haute disponibilité, échéances de licence… ;
- les ports en écoute ;
- des défauts de sécurité de la configuration SNMP.
La matrice des flux figure dans les prérequis des connexions sans-agent, et les équipements pris en charge dans la liste des systèmes supportés.
Versions et identifiants SNMP
Cyberwatch prend en charge SNMP v1, v2c et v3 :
- en v1 et v2c, l’identifiant est une communauté ;
- en v3, l’utilisateur doit avoir une authentification et un chiffrement (niveau de sécurité
authPriv). Les niveauxnoAuthNoPrivetauthNoPrivne sont pas pris en charge.
Les protocoles d’authentification proposés sont SHA, SHA-256, SHA-512 et MD5, et les protocoles de chiffrement AES, AES-256 et DES.
Nous recommandons SNMPv3 avec SHA-256 ou SHA-512 et AES. Un scan en v1 ou v2c, ou avec un utilisateur SNMPv3 en MD5 ou en DES, produit un défaut de sécurité sur l’actif.
Vues MIB à autoriser
Cyberwatch n’a besoin que d’un accès en lecture. La vue SNMP de l’utilisateur ou de la communauté utilisée doit inclure les branches suivantes :
| MIB | Racine d’OID | Données lues | Si la vue l’exclut |
|---|---|---|---|
| SNMPv2-MIB, groupe system | 1.3.6.1.2.1.1 | Description, identifiant d’objet (sysObjectID), durée de fonctionnement, nom, emplacement et contact | Le scan échoue. |
| Branche du constructeur | 1.3.6.1.4.1.<numéro> | Système, version et caractéristiques propres au constructeur | La détection échoue, voir En cas d’échec de la détection. |
| HOST-RESOURCES-MIB | 1.3.6.1.2.1.25 | Durée de fonctionnement de l’équipement ; logiciels installés, qui donnent la version de certains équipements | La durée de fonctionnement est celle de l’agent SNMP. La version de ces équipements n’est pas détectée, et la détection échoue pour Cisco ISE, Ucopia, et Juniper quand la description ne donne pas la version. |
| IP-MIB, OSPF-MIB | 1.3.6.1.2.1.4, 1.3.6.1.2.1.14 | Adresses IP | Les adresses IP manquent. |
| ENTITY-MIB | 1.3.6.1.2.1.47 | Fabricant, modèle, numéro de série et révision matérielle du châssis | Le modèle et le numéro de série sont lus dans la branche du constructeur, quand elle les donne. La détection d’Arista, qui y lit sa version, échoue. |
| TCP-MIB, UDP-MIB | 1.3.6.1.2.1.6, 1.3.6.1.2.1.7 | Ports en écoute | Les ports manquent. |
| SNMP-USER-BASED-SM-MIB, SNMP-VIEW-BASED-ACM-MIB, SNMP-COMMUNITY-MIB | 1.3.6.1.6.3.15, 1.3.6.1.6.3.16, 1.3.6.1.6.3.18 | Utilisateurs SNMPv3, accès v1/v2c et communautés configurés sur l’équipement | Seuls les défauts de sécurité de l’identifiant utilisé sont signalés. |
<numéro> est le numéro d’entreprise IANA du constructeur, par lequel commence l’identifiant d’objet de l’équipement : 1.3.6.1.4.1.9.1.… pour un équipement Cisco, par exemple. Un équipement bâti sur l’agent net-snmp lit aussi les branches de net-snmp (1.3.6.1.4.1.8072 et 1.3.6.1.4.1.2021), et celle de son éditeur. Une vue qui inclut 1.3.6.1.2.1 et 1.3.6.1.4.1 couvre donc toutes les branches nécessaires.
Les trois tables de 1.3.6.1.6.3 décrivent la configuration SNMP de l’équipement. Les ouvrir à Cyberwatch est facultatif. Cyberwatch n’en remonte que des défauts de sécurité : il ne remonte jamais une communauté hors de la liste des communautés faibles, ni le nom d’un utilisateur sans authentification.
Hors groupe system et branche du constructeur, une table absente, exclue de la vue ou qui ne répond pas ne fait pas échouer le scan : l’information correspondante manque simplement.
Métadonnées
Le scan remonte des métadonnées, affichées dans l’onglet « Métadonnées » de l’actif. Elles sont mises à jour à chaque scan réussi : une métadonnée que le scan ne lit plus disparaît. Les valeurs vides et les valeurs par défaut des agents SNMP (Unknown, root@localhost…) sont ignorées, et une valeur est tronquée à 255 caractères.
Métadonnées communes
Ces métadonnées sont lues dans les MIB standard, quel que soit le constructeur :
| Clé | Source | Description |
|---|---|---|
snmp-location | sysLocation (SNMPv2-MIB) | Emplacement déclaré dans la configuration SNMP |
snmp-contact | sysContact (SNMPv2-MIB) | Contact déclaré dans la configuration SNMP |
system-manufacturer | entPhysicalMfgName (ENTITY-MIB) | Fabricant du châssis |
system-product-name | entPhysicalModelName (ENTITY-MIB), sinon branche du constructeur | Modèle du châssis |
system-serial-number | entPhysicalSerialNum (ENTITY-MIB), sinon branche du constructeur | Numéro de série du châssis |
system-version | entPhysicalHardwareRev (ENTITY-MIB) | Révision matérielle du châssis, et non version du firmware |
snmp-agent-version | versionTag (UCD-SNMP-MIB) | Version de l’agent net-snmp |
Les colonnes d’ENTITY-MIB sont lues sur la première entité de classe châssis. Quand ENTITY-MIB ne donne ni modèle ni numéro de série, ils sont lus dans la branche du constructeur, pour la plupart des constructeurs pris en charge.
Les clés system-* sont celles que remonte le scan des actifs Linux. Un même filtre, par exemple meta:system-serial-number:FCW2140, trouve donc aussi bien un serveur qu’un équipement réseau.
Métadonnées propres à certains équipements
| Clé | Équipements | Valeur |
|---|---|---|
ha-state | Check Point, Cisco ASA, F5 BIG-IP, FortiGate, Juniper | État de haute disponibilité, standalone hors cluster pour Cisco ASA, Check Point, F5 BIG-IP et FortiGate. En cluster, Cisco ASA, Check Point et F5 BIG-IP donnent le rôle de l’équipement (active, standby, offline pour F5, active-attention pour Check Point…). FortiGate donne le mode du cluster (active-active, active-passive), le même sur chaque membre. Juniper : virtual-chassis pour un Virtual Chassis, aucune valeur pour un équipement seul. |
virtual-chassis-member | Juniper | Un membre du Virtual Chassis par valeur : identifiant, rôle, numéro de série, modèle et version, par exemple 9 master LX0213388389 ex4550-32f 15.1R7-S10 |
config-unsaved | Cisco (IOS, IOS XE, IOS XR, NX-OS, ASA…) | true si la configuration en cours a été modifiée depuis sa dernière sauvegarde, sinon false |
boot-image | Extreme Networks EXOS | Image démarrée : primary ou secondary |
firmware-pending-version | Extreme Networks EXOS | Version de l’image choisie pour le prochain démarrage, quand elle diffère de la version en cours |
routerboot-pending-version | MikroTik | Version de RouterBOOT fournie par RouterOS, quand elle diffère de celle installée : la mise à niveau de RouterBOOT reste à faire |
firmware-update-available | Synology | true si DSM signale une mise à jour disponible, false s’il n’en signale aucune. Aucune valeur quand DSM n’a pas pu vérifier. |
av-signature-version, av-signature-date | FortiGate | Version et date de la base de signatures antivirus |
ips-signature-version, ips-signature-date | FortiGate, Sophos (version seule) | Version et date de la base de signatures IPS |
license-expiration | Cisco AsyncOS, Sophos, WALLIX Bastion | Échéance de licence la plus proche |
support-expiration | Check Point, Sophos | Échéance de support la plus proche |
Les dates sont au format AAAA-MM-JJ.
Exploiter les métadonnées
- Dans l’inventaire, filtrer les actifs avec le filtre Métadonnée, ou en saisissant
meta:clé[:valeur]dans la barre de recherche. La clé et la valeur sont recherchées par préfixe (voir l’ancrage des recherches). Par exemple :meta:ha-state:standby: équipements en attente dans un cluster ;meta:config-unsaved:true: équipements Cisco dont la configuration n’est pas sauvegardée ;meta:license-expiration:2026: équipements dont une licence expire en 2026.
- Afficher une métadonnée en colonne de l’inventaire, comme décrit dans Ajouter une colonne de métadonnée. Une clé à plusieurs valeurs, comme
virtual-chassis-member, affiche ses valeurs séparées par des virgules. - Ces filtres servent aussi aux règles d’actifs, aux alertes et aux exports. L’API v3 renvoie les métadonnées dans le détail d’un actif, et filtre la liste des actifs par
metadata_keyetmetadata_value.
Ports en écoute
Le scan remonte les ports en écoute de l’équipement dans l’onglet « Ports » de l’actif. Il lit :
- pour TCP, la table
tcpListenerTable, ou à défaut les connexions en écoute detcpConnTable(TCP-MIB) ; - pour UDP, la table
udpEndpointTable, ou à défautudpTable(UDP-MIB).
Les ports des adresses de bouclage sont ignorés, comme les sockets UDP connectées. Un port qui écoute sur toutes les adresses est remonté sans adresse. SNMP ne donne ni le service ni le produit d’un port : ces colonnes restent vides.
La lecture est limitée à 500 lignes par table et à 60 secondes pour l’ensemble des tables. Au-delà, ou si l’équipement cesse de répondre, Cyberwatch garde les ports déjà lus et le signale dans le résultat brut du scan par une ligne # Listening ports from <table>: <raison>.
Comme pour les autres actifs, un port TCP 21, 23 ou 873 en écoute produit les défauts de sécurité FTP-port, Telnet-port ou rsync-port.
Défauts de sécurité SNMP
Le scan signale les défauts de sécurité suivants dans l’onglet « Défauts de sécurité » de l’actif :
| Identifiant | Sévérité | Titre | Signalé quand | Détail |
|---|---|---|---|---|
SNMP_weak_community_string | Élevée | SNMP weak community string | Une communauté de la liste des communautés faibles est acceptée par l’équipement, ou figure dans sa table des communautés (snmpCommunityTable) | Community string: <communauté> |
SNMP_v1_v2c_enabled | Moyenne | SNMP v1/v2c enabled or configured | Le scan se fait en v1 ou v2c, ou la configuration d’accès de l’équipement (vacmSecurityToGroupTable) contient une entrée v1 ou v2c | SNMPv1 ou SNMPv2c |
SNMP_no_authentication | Moyenne | SNMPv3 user without authentication | Un utilisateur SNMPv3 de l’équipement (usmUserTable) n’a pas d’authentification | User: initial, sinon User without authentication |
SNMP_weak_authentication_protocol | Faible | SNMPv3 MD5 authentication | L’utilisateur du scan, ou un utilisateur de l’équipement, s’authentifie en MD5 | User: <utilisateur> (MD5) |
SNMP_weak_privacy_protocol | Moyenne | SNMPv3 weak or no encryption | L’utilisateur du scan, ou un utilisateur de l’équipement, chiffre en DES ou ne chiffre pas | User: <utilisateur> (DES) ou User: <utilisateur> (no encryption) |
Ces défauts sont déduits de l’identifiant utilisé et des tables que la vue rend lisibles. Le scan reste non intrusif : il ne tente jamais de s’authentifier autrement qu’avec l’identifiant de la connexion, sauf pour le test des communautés faibles. Ce test n’a lieu que pour un scan en v1 ou v2c. Il essaie, en lecture seule, les communautés de la liste du script Nmap snmp-brute : public, private, snmpd, mngt, cisco, admin, PUBLIC, PRIVATE, rmonmgmtuicommunity, secret, cascade, ANYCOM, ILMI, volition, TENmanUFactOryPOWER, MiniAP et snmp-Trap.
Le nom d’un utilisateur sans authentification suffit à interroger l’équipement : il n’est pas affiché, sauf s’il est public, comme initial.
Chaque utilisateur, version ou communauté donne une occurrence distincte du défaut de sécurité. Une occurrence qui n’est plus détectée lors d’un scan réussi est corrigée, et une occurrence ignorée le reste. Le cycle de vie des défauts de sécurité est décrit dans Utiliser les défauts de sécurité.
En cas d’échec de la détection
Si le scan échoue, l’actif garde son dernier état connu : firmware, vulnérabilités, métadonnées, ports et défauts de sécurité ne sont pas effacés. L’échec est signalé :
- sur le script d’analyse de l’actif, qui passe en « Échec de communication » avec le message d’erreur ;
- sur la connexion sans-agent, dans la colonne « Dernière erreur de connexion » du menu Connexions sans-agent.
Si les échecs se répètent, l’actif finit par passer en perte de communication.
Chaque requête SNMP attend sa réponse 3 secondes et est retentée 2 fois. Un scan dure au plus 5 minutes. Le message d’erreur est préfixé par le numéro d’entreprise du constructeur, quand il est connu (PEN 9: …). Les messages les plus courants sont :
| Message | Cause probable | Résolution |
|---|---|---|
Timeout after 3 seconds | L’équipement ne répond pas : flux UDP 161 bloqué, agent SNMP arrêté, ou communauté inconnue de l’équipement (v1, v2c) | Vérifier la matrice des flux, la configuration SNMP de l’équipement et l’identifiant. |
Unknown user name | L’utilisateur SNMPv3 de l’identifiant n’existe pas sur l’équipement | Vérifier le nom d’utilisateur de l’identifiant et la configuration SNMP de l’équipement. |
Authentication failure (…) | Mot de passe ou protocole d’authentification SNMPv3 erroné | Vérifier le mot de passe et le protocole d’authentification de l’identifiant. |
Decryption error | Mot de passe ou protocole de chiffrement SNMPv3 erroné | Vérifier le mot de passe et le protocole de chiffrement de l’identifiant. |
Unsupported security level | L’utilisateur SNMPv3 de l’équipement n’a pas à la fois une authentification et un chiffrement | Le configurer au niveau authPriv, voir Versions et identifiants SNMP. |
Could not retrieve the version of <produit> | L’équipement ne donne pas sa version là où Cyberwatch la lit | Vérifier que la vue inclut la branche du constructeur, puis contacter le support. |
No Such Instance currently exists at this OID (<OID>), No such name (…) | Un OID nécessaire à la détection est absent ou exclu de la vue | Vérifier que la vue inclut l’OID cité, puis contacter le support. |
Time limit of 300 s exceeded | L’équipement répond trop lentement pour terminer le scan en 5 minutes | Vérifier la charge de l’équipement et la latence du réseau. |
Si l’équipement n’est pas reconnu, ou si sa détection reste en échec, écrire à support@cyberwatch.com avec le message d’erreur et un SNMPWalk complet de l’équipement (snmpwalk -On <équipement> 1.3.6.1).