Le problème Modbus dont personne ne veut parler
Modbus TCP est omniprésent en OT. PLCs, RTUs, passerelles SCADA, systèmes de gestion de bâtiments. Si vous travaillez en environnement industriel depuis plus d'un an, vous l'avez forcément utilisé.
Le protocole a été conçu en 1979. Il repose sur l'hypothèse d'un réseau de confiance, isolé physiquement, où toute personne ayant un accès physique est autorisée. Cette hypothèse a cessé d'être vraie il y a une vingtaine d'années, mais la plupart des usines font encore tourner Modbus en clair sur des réseaux plats, sans authentification, sans chiffrement et sans contrôle d'accès.
Ce n'est pas un risque théorique. N'importe qui disposant de Wireshark et d'un accès réseau peut lire chaque valeur de registre en clair. N'importe qui avec un script Python peut écrire dans des bobines et des registres de maintien. Pas de handshake, pas de jeton de session, rien.
Ce qui rend Modbus TCP difficile à sécuriser
Modbus TCP reprend le protocole série d'origine et l'encapsule dans TCP/IP sur le port 502. C'est tout. Pas de TLS, pas d'en-tête d'authentification, aucune notion d'identité utilisateur.
Pas d'authentification. Un serveur Modbus TCP accepte sans broncher les commandes de n'importe quelle adresse IP qui peut l'atteindre. Pas de nom d'utilisateur, pas de mot de passe, pas d'échange de certificat. Si vous pouvez ouvrir une connexion TCP vers le port 502, vous êtes dedans.
Pas de chiffrement. Chaque code fonction, adresse de registre et valeur transite en clair. Un attaquant sur le réseau voit exactement ce que votre HMI lit et écrit. Il peut aussi modifier les paquets en transit s'il est positionné pour une attaque de type man-in-the-middle.
La rejouabilité est triviale. Les paquets Modbus TCP sont suffisamment sans état pour que le trafic capturé puisse être rejoué ultérieurement. Enregistrez une commande « write single coil » et vous pouvez la renvoyer quand vous voulez. Le PLC ne fera pas la différence.
Segmentation réseau : commencez par là
Si vous ne faites qu'une seule chose, isolez votre trafic Modbus du reste de votre réseau. Cette seule mesure élimine la plus grande catégorie d'attaques : quelqu'un sur le LAN d'entreprise (ou un poste IT compromis) qui accède directement à votre réseau de contrôle.
Les VLANs sont le minimum. Placez vos équipements Modbus sur leur propre VLAN. Ne vous contentez pas de tagger le trafic. Verrouillez le routage inter-VLAN pour que seuls des hôtes spécifiques puissent franchir la frontière.
Les pare-feux entre zones sont indispensables. Un VLAN sans pare-feu entre lui et le reste du réseau n'est qu'une décoration organisationnelle. Il vous faut une inspection dynamique des paquets à la frontière, avec des règles qui n'autorisent explicitement que les paires source/destination et les ports attendus.
Si vous suivez IEC-62443, cela correspond au modèle zones et conduits. En pratique, cela signifie tracer une ligne claire entre votre niveau 2 (contrôle) et votre niveau 3 (opérations site), avec un conduit défini pour tout trafic devant franchir cette frontière.
Chiffrement du trafic Modbus
Modbus TCP ne disposant d'aucun chiffrement natif, vous devez l'encapsuler dans autre chose.
Les tunnels VPN entre sites ou entre un poste de travail d'ingénierie et le réseau de contrôle sont l'approche la plus courante. IPsec ou WireGuard fonctionnent tous les deux. L'essentiel est que le tunnel se termine au plus près de l'équipement Modbus, et non en bordure d'un réseau plat où le trafic circule en clair sur le dernier tronçon.
Les wrappers TLS comme stunnel peuvent chiffrer Modbus TCP entre deux points d'extrémité. C'est efficace pour les liaisons point à point, par exemple un HMI qui communique avec un PLC spécifique. La gestion à grande échelle est plus lourde, mais cela offre un chiffrement par connexion.
Les pare-feux protocolaires ajoutent une couche supplémentaire. Un pare-feu qui comprend les codes fonction Modbus peut bloquer les commandes d'écriture provenant d'hôtes qui ne devraient faire que de la lecture, ou restreindre les plages de registres accessibles à une source donnée. Un proxy inline qui comprend les codes fonction Modbus peut appliquer des politiques par équipement et par code fonction, sans modifier le PLC ni le HMI.
Contrôle d'accès sans support natif
Modbus ne sait pas ce qu'est un « utilisateur ». Le contrôle d'accès doit donc être appliqué au niveau réseau et applicatif.
Autorisez les IP sources au niveau du pare-feu. Seuls le HMI, l'historien et le poste d'ingénierie doivent pouvoir atteindre le port 502 de vos PLCs. Tout le reste est bloqué. C'est rudimentaire, mais cela supprime les accès opportunistes depuis des machines quelconques sur le réseau.
Utilisez une passerelle ou un proxy pour le contrôle basé sur les rôles. Si vous avez besoin d'une granularité plus fine (lecture seule pour les opérateurs, lecture-écriture pour les ingénieurs), il vous faut quelque chose devant l'équipement Modbus qui associe des utilisateurs authentifiés à des ensembles de permissions. Une passerelle d'accès Modbus-aware fait cela en terminant la connexion Modbus, en authentifiant l'utilisateur, puis en ne proxifiant vers l'équipement aval que les codes fonction autorisés.
MFA pour l'accès distant, sans exception. Si quelqu'un se connecte à votre réseau de contrôle à distance — via un VPN, un jump host ou une passerelle cloud — il doit utiliser l'authentification multi-facteurs. C'est non négociable. Un mot de passe volé ne doit pas suffire pour atteindre un PLC.
Supervision : on ne protège pas ce qu'on ne voit pas
Le trafic Modbus en clair est en réalité facile à superviser, car il est en texte clair et bien structuré. Profitez-en.
Déployez un IDS qui comprend Modbus. Snort et Suricata disposent tous deux de préprocesseurs Modbus. Ils peuvent alerter sur des codes fonction inattendus, des écritures dans des plages de registres qui ne devraient pas être modifiées, ou du trafic provenant d'adresses IP absentes de votre liste d'autorisation.
Établissez d'abord une ligne de base du trafic normal. Avant de rédiger des règles d'alerte, capturez une semaine de trafic Modbus normal et caractérisez-le. À quelle fréquence le HMI interroge-t-il ? Quels registres lit-il ? Y a-t-il des écritures dans des bobines en fonctionnement normal ? Une fois que vous savez à quoi ressemble le « normal », les anomalies deviennent évidentes.
Journalisez tout au niveau de la passerelle. Si vous exploitez un proxy ou une passerelle Modbus, enregistrez chaque connexion et chaque code fonction. Quand quelque chose tourne mal, disposer d'une piste d'audit complète — qui a écrit quoi dans quel registre, et quand — fait la différence entre une investigation de 30 minutes et un exercice forensique de trois jours.
La gestion des correctifs en OT, c'est différent
Appliquer des correctifs en OT ne ressemble pas à la gestion de patches IT. On ne peut pas pousser des mises à jour un mardi soir et redémarrer. Les arrêts coûtent de l'argent réel, et une mauvaise mise à jour firmware sur un PLC peut arrêter une ligne de production.
Sachez ce que vous faites tourner. Tenez un inventaire de chaque équipement Modbus, de sa version firmware et du statut des correctifs de son fabricant. La plupart des usines ne peuvent pas répondre à cette question, ce qui signifie qu'elles ne peuvent pas patcher même si elles le souhaitent.
Testez les correctifs dans un environnement de préproduction. Si vous disposez d'un PLC de test ou d'un environnement de simulation, validez les correctifs là-bas avant de les déployer en production. Si vous n'avez pas d'environnement de test, il vous en faut un. Le coût est négligeable comparé à une mise à jour ratée sur un système en production.
Planifiez des fenêtres de maintenance réalistes. Travaillez avec les opérations pour identifier des fenêtres où le patching est possible. Un rythme trimestriel est une cible raisonnable pour la plupart des environnements. Annuel, c'est trop lent. Mensuel est ambitieux en OT, mais visez-le si vous le pouvez.
Les normes à suivre
IEC-62443 est la référence en matière de cybersécurité industrielle. Elle fournit un cadre pour les zones, les conduits et les niveaux de sécurité qui se traduit directement en décisions d'architecture réseau concrètes. Commencez par les parties 3-2 (évaluation des risques de sécurité) et 3-3 (exigences de sécurité système).
NIST SP 800-82 est le guide du gouvernement américain pour la sécurité des ICS. Il est pratique et bien rédigé. Si vous évoluez dans un environnement CMMC ou NIST 800-171, il s'aligne sur ces exigences et apporte des conseils spécifiques OT que le seul 800-171 ne couvre pas.
NIS2 s'applique si vous opérez dans l'UE ou si vous fournissez des secteurs d'infrastructure critique européens. Il impose des obligations de notification d'incidents et des exigences de sécurité qui couvrent spécifiquement les environnements OT. Si vous ne suivez pas encore la conformité NIS2, vérifiez si votre organisation entre dans son périmètre.
Par où commencer demain
Choisissez l'action à fort impact que vous n'avez pas encore réalisée. Pour la plupart des usines qui font tourner Modbus TCP sur un réseau plat, c'est la segmentation. Placez vos équipements de contrôle derrière un pare-feu, restreignez les hôtes pouvant atteindre le port 502, et journalisez les connexions. Cela seul comblera la majorité des lacunes. Tout le reste se construit sur cette base.
