Inventorier les objets IoT oubliés sur le réseau

Un objet connecté oublié n’est pas un actif à faible valeur, c’est une identité réseau non gouvernée avec un microprogramme rarement corrigé. Le compromis est brutal : découvrir et bloquer vite peut interrompre un équipement métier, tolérer l’inconnu laisse un point d’entrée durable à un attaquant.

→ Lire l’explication complète de la marmotte

Inventaire IoT : partir du réseau, pas de la base d’actifs

Une base de gestion de configuration, ou CMDB (Configuration Management Database), décrit ce que l’organisation pense posséder. Le réseau décrit ce qui est effectivement présent. Pour les objets connectés, la seconde source doit arbitrer la première. Une caméra achetée hors processus, une sonde ajoutée par un prestataire ou une passerelle laissée après un pilote ne demandent pas l’autorisation à la CMDB pour émettre du trafic.

L’inventaire doit corréler au minimum cinq observations : adresse MAC (Media Access Control), port de commutateur, attribution DHCP (Dynamic Host Configuration Protocol), requêtes DNS (Domain Name System) et empreinte de trafic. Une adresse MAC seule ne suffit pas. Elle se falsifie, change avec certains adaptateurs et identifie un fabricant, pas un modèle ni un propriétaire. L’association d’un fabricant, d’un bail DHCP, d’une option DHCP, d’un profil de destinations et d’un port physique donne une attribution exploitable.

Commencer par les journaux DHCP, les tables d’adresses MAC des commutateurs, les baux Wi-Fi, les journaux RADIUS (Remote Authentication Dial-In User Service) et les requêtes DNS. Les flux NetFlow ou IPFIX (IP Flow Information Export) complètent le tableau : un thermostat qui contacte périodiquement une même plate-forme n’a pas le même profil qu’un écran de salle qui établit des sessions vers plusieurs réseaux de diffusion. Ce n’est pas de la magie comportementale vendue sous blister, juste de la collecte correctement recoupée.

La découverte active, par balayage de ports ou interrogation SNMP (Simple Network Management Protocol), reste secondaire. Elle peut réveiller un équipement fragile, déclencher une alarme industrielle ou produire une réponse trompeuse. Une imprimante qui expose HTTPS n’est pas nécessairement administrable, et un port 443 ouvert ne transforme pas une boîte en appliance de sécurité. Vingt ans d’exploitation apprennent que le matériel le plus discret est souvent celui dont le redémarrage est le plus coûteux.

Un actif n’entre dans l’inventaire qu’avec un propriétaire métier, un propriétaire technique, une localisation, une fonction, une méthode d’administration, une version de micrologiciel, un statut de support et des dépendances réseau. Sans ces champs, on possède une liste de numéros, pas un inventaire. L’objet reste alors classé « inconnu à contenir », pas « probablement inoffensif ». Le probablement est un protocole réseau très mal documenté.

Pour les fondations de segmentation et de filtrage, la page Réseaux complète les mécanismes décrits ici. Le sujet IoT ne se limite pas à une catégorie de terminaux : c’est un problème de contrôle d’accès et de preuves d’administration.

Confinement réseau des objets non inventoriés

La décision recommandée est de placer tout objet non attribué dans un segment de quarantaine à accès sortant refusé par défaut. Seuls DHCP, DNS vers des résolveurs désignés, NTP (Network Time Protocol) vers des serveurs de temps désignés et le service d’enrôlement explicitement nécessaire peuvent être autorisés. Cette règle évite qu’une découverte prenne la forme d’une compromission documentée après coup.

Le compromis central oppose disponibilité immédiate et réduction de surface d’attaque. Une quarantaine peut casser un écran de visioconférence, un lecteur de badge ou une sonde environnementale. L’exception doit donc être temporaire, liée à un propriétaire identifié et assortie d’une date d’expiration. Une exception sans expiration devient une politique de sécurité, mais sans le nom et sans la revue. Le secteur adore appeler cela de l’agilité.

La segmentation par VLAN (Virtual Local Area Network) est insuffisante si le pare-feu autorise « IoT vers Internet » dans son ensemble. Une règle utile décrit un émetteur, une destination, un protocole, un port et une justification. Pour une caméra, autoriser le flux vers son enregistreur, DNS et NTP peut suffire. Autoriser TCP (Transmission Control Protocol) 443 vers tout Internet au motif que l’éditeur utilise le nuage revient à déléguer le filtrage à des destinations inconnues et changeantes.

Le contrôle d’accès réseau par 802.1X associe une identité à un port filaire ou Wi-Fi. Il apporte une décision d’admission, pas une preuve que le micrologiciel est sain. Les équipements incapables de 802.1X finissent souvent dans un contournement MAB (MAC Authentication Bypass). MAB doit déboucher sur un segment extrêmement limité, jamais sur le réseau utilisateur. L’adresse MAC est un indice de raccordement, pas un secret. Elle se copie avec une facilité presque vexante.

Prévoir aussi le cas des objets radio qui communiquent par une passerelle. Le réseau ne voit alors qu’une passerelle et perd l’identité des capteurs derrière elle. L’inventaire doit contenir la relation parent-enfant, le protocole radio, le nombre attendu de capteurs et le comportement de remplacement. Sans cela, un capteur ajouté hors contrôle devient indétectable tant que la passerelle continue à bavarder normalement.

Surface d’attaque : firmware, identités et sorties cloud

Un objet IoT compromis est fréquemment exploité pour trois fonctions : point d’appui interne, relais de trafic ou collecte de données. Les attaques connues incluent les mots de passe par défaut, les interfaces d’administration exposées, les mises à jour non signées, les vulnérabilités de serveur web embarqué, les services Telnet ou SSH (Secure Shell) oubliés et les bibliothèques cryptographiques abandonnées.

Le filtrage entrant ne suffit pas. Une compromission initiée par une connexion sortante chiffrée vers une infrastructure de commande reste possible si toute sortie HTTPS est autorisée. Un proxy explicite, lorsque le matériel le supporte, fournit une identité et des journaux. Quand il ne le supporte pas, limiter les destinations par noms résolus et adresses documentées, avec revue régulière. Les plages de diffusion de contenu et les services partagés compliquent cette approche : c’est précisément une raison de questionner le choix fournisseur, pas une raison d’ouvrir tout le réseau.

Les certificats client offrent une meilleure identité qu’un mot de passe partagé si l’objet prend en charge TLS (Transport Layer Security) avec validation de chaîne et de nom d’hôte. Un certificat installé identiquement sur mille équipements n’est pas une identité par équipement, c’est un mot de passe cher avec une date d’expiration. La clé privée doit être générée dans l’équipement lorsqu’un composant matériel le permet, ou injectée par un canal d’enrôlement protégé. La gestion des clés relève des mêmes principes que la cryptographie appliquée : une clé exportable et réutilisée ne devient pas moins exposée parce qu’elle vit dans une petite boîte blanche.

La révocation d’un certificat ne ferme pas les sessions déjà établies. Elle dépend aussi de la capacité de l’équipement à vérifier l’état de révocation, souvent absente sur les objets contraints. En cas de compromission, couper l’accès réseau de l’objet reste la mesure immédiate. La PKI (Public Key Infrastructure) réduit l’usurpation lors de nouvelles connexions, elle ne désinfecte pas un micrologiciel.

Ce mécanisme ne garantit pas la sûreté physique, l’intégrité des mesures, la qualité d’un fournisseur ni l’absence de porte dérobée matérielle. Ces garanties viennent de l’analyse fournisseur, des exigences contractuelles, de tests de réception, de la redondance métier et, pour les usages à impact, d’une architecture qui reste sûre quand la donnée de l’objet devient indisponible ou fausse.

Exemple reproductible : isoler une adresse MAC inconnue

Sur un pare-feu Linux, un ensemble nftables permet d’isoler une adresse MAC observée sur un segment de découverte. Le filtrage MAC n’empêche pas l’usurpation, mais il fournit une mesure immédiate le temps d’identifier le port et le propriétaire. La règle doit s’ajouter à une politique de segmentation IP, pas la remplacer.

# Créer une table et une chaîne de transit dédiées à la quarantaine.
sudo nft add table inet iot_quarantine
sudo nft 'add chain inet iot_quarantine forward { type filter hook forward priority 0; policy accept; }'

# Journaliser puis bloquer tout transfert émis par l'objet inconnu.
# Remplacer l'adresse par celle relevée dans la table du commutateur.
sudo nft add rule inet iot_quarantine forward ether saddr 00:11:22:33:44:55 \
  log prefix \"IOT_UNKNOWN_DROP \" drop

# Vérifier que la règle est chargée et conserver la sortie dans le dossier d'incident.
sudo nft list table inet iot_quarantine

Cette mesure suppose que le pare-feu voit effectivement le trafic de transit. Un routage inter-VLAN local au commutateur contourne cette règle. La topologie doit donc imposer le passage des flux inter-segments par le point de contrôle. Tester cette hypothèse avec une capture ou une trace de flux, pas avec un diagramme vieux de trois réorganisations.

Exploitation : rotation, supervision et reprise

Chaque objet attribué doit disposer d’une fenêtre de maintenance, d’une source de micrologiciel vérifiée, d’un mécanisme de sauvegarde de configuration et d’une procédure de remplacement. Une sauvegarde contenant un mot de passe administrateur partagé ou une clé privée exportée est un duplicateur de compromission. Chiffrer l’archive, contrôler ses accès et tester la restauration sur un équipement de rechange.

La rotation des identifiants doit distinguer les comptes humains, les secrets d’interface de programmation et les certificats d’équipement. Les mots de passe de maintenance ne doivent jamais être communs à une gamme entière. Quand un fournisseur ne permet pas cette séparation, l’objet doit être isolé comme un système non administrable à distance, avec accès local contrôlé. Ce n’est pas élégant, mais l’élégance n’empêche pas les mots de passe gravés dans un firmware.

Superviser les changements de fabricant MAC sur un port, les nouveaux noms DNS, les destinations inédites, les échecs d’authentification et les écarts de volume. Un changement d’adresse MAC peut signaler un remplacement légitime, un adaptateur ajouté ou une usurpation. L’alerte sans processus de qualification produit un cimetière de tickets. L’alerte reliée à un propriétaire, un emplacement et une règle de confinement produit une décision.

La reprise doit prévoir la perte du service distant du fournisseur. Un objet dont l’administration, l’heure ou la fonction métier dépend d’un unique domaine externe devient indisponible lors d’une panne DNS, d’une expiration de certificat ou d’une fermeture de service. Documenter le comportement dégradé, les opérations locales possibles et la durée acceptable d’absence de données. L’architecture cyber ne remplace pas cette décision métier, elle force à la prendre avant le premier incident.

🐝 Ce qui arrive si on s’en passe

Sans inventaire tenu à partir du réseau, une alerte ne se transforme pas en décision : une adresse MAC ou une adresse IP signalée ne renvoie à aucun port, aucun local, aucun propriétaire, et la qualification s’étire pendant que les baux DHCP et les tables de commutateurs ont déjà tourné. Les avis de vulnérabilité deviennent inexploitables, faute de savoir quels modèles et quelles versions de micrologiciel sont réellement raccordés ; une fin de support passe inaperçue et l’équipement continue d’émettre des années après. Un remplacement matériel laisse en place des identifiants et des règles de pare-feu dont plus personne ne connaît la cible. Enfin, un capteur ajouté derrière une passerelle radio n’apparaît nulle part : il n’existe ni preuve de son arrivée, ni point de comparaison pour constater son départ.

🦫 Explication de la marmotte 🍫

Un objet connecté oublié est un appareil relié au réseau mais absent de la liste officielle des équipements. Il peut s’agir d’une caméra, d’un capteur, d’un écran ou d’une passerelle qui relie plusieurs petits appareils. Pour le gérer, il faut d’abord observer le réseau : quelles machines se connectent, sur quelle prise ou quel accès sans fil, quelles adresses elles utilisent et avec quels services elles communiquent.

Ces informations sont comparées à la liste des équipements attendus. Si aucun responsable, aucune fonction ou aucune méthode de mise à jour n’est connue, l’objet est placé dans une zone séparée. Cette zone limite ses échanges au strict nécessaire, par exemple recevoir une adresse réseau, connaître l’heure et joindre un service validé. L’appareil ne peut pas joindre librement les postes de travail ni Internet.

Ensuite, un responsable doit identifier l’objet, décider s’il doit rester, vérifier son logiciel interne et remplacer ses mots de passe ou ses certificats d’accès. Un certificat est un fichier qui permet à un appareil de prouver son identité. S’il est volé, couper le réseau de l’appareil reste nécessaire, car une connexion déjà ouverte peut continuer.

Enfin, il faut surveiller les nouveaux appareils et les changements de comportement. Si l’identification échoue ou si l’appareil ne peut pas être corrigé, il doit rester isolé ou être retiré. L’inventaire n’est donc pas une liste décorative : il permet de décider qui peut communiquer, pourquoi et pendant combien de temps.

Pages voisines

La citent

Inventorier les objets IoT oubliés sur le réseau

Elle cite

: les deux pages se citent l’une l’autre.

Inventorier les objets IoT oubliés sur le réseau

Inventorier les objets IoT oubliés sur le réseau

Inventaire IoT : partir du réseau, pas de la base d’actifs

Confinement réseau des objets non inventoriés

Surface d’attaque : firmware, identités et sorties cloud

Exemple reproductible : isoler une adresse MAC inconnue

Exploitation : rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines