Modbus TCP sur un rétrofit : protéger ce qu’on ne peut pas remplacer

Il y a quelques semaines, sous le post qui accompagnait mon premier article, un lecteur a raconté qu’il refusait d’installer du Modbus TCP sur des installations récentes. Puis, en formation, il a découvert qu’un pare-feu industriel pouvait lire Modbus TCP en profondeur, jusqu’à n’autoriser que certaines valeurs écrites sur un registre, et seulement par un client donné.

Son témoignage pose la bonne question. Sur une installation neuve, on choisit son protocole. Sur un rétrofit, on hérite d’un parc : des automates, des variateurs, des centrales de mesure qui ne parlent que Modbus et qui doivent continuer de tourner.

Modbus TCP n’a ni authentification ni chiffrement. L’ANSSI le cite d’ailleurs parmi les protocoles vulnérables dans la version 2.0 de son guide « Mesures détaillées » pour les systèmes industriels, publiée fin 2025. Ce n’est pas une raison pour tout arracher. C’est une raison pour l’entourer correctement.

Pourquoi on ne bannit pas Modbus

Remplacer un automate, ce n’est pas changer une carte. C’est reprendre le programme, les schémas, la supervision, refaire les essais et prévoir un arrêt. Multipliez par le nombre d’équipements d’une station, et le rétrofit devient un projet à part entière.

Il y a aussi la continuité de service. Une station d’eau potable ne s’arrête pas pour changer de protocole. Chaque intervention se cale sur un créneau de faible consommation, avec un retour arrière prêt.

En électricité, on ne recâble pas toute une installation parce qu’un vieux tableau n’a pas de protection différentielle. On ajoute la protection en tête du départ, on la teste, on la documente. Avec Modbus, c’est la même logique.

Le filtrage en profondeur

Un pare-feu classique raisonne en adresses et en ports : telle machine peut joindre tel automate sur le port 502. C’est du tout ou rien. Une fois la connexion autorisée, le client peut lire et écrire n’importe quel registre.

Un pare-feu capable d’inspecter Modbus lit le contenu de chaque trame. Il peut alors décider sur quatre critères.

Critère	Exemple de règle	Ce que ça empêche
Client	seule la supervision peut écrire	un poste quelconque qui envoie des commandes
Code fonction	lecture (03, 04) pour tous, écriture (06, 16) pour la supervision	une écriture depuis un client prévu pour lire
Registres	écriture limitée aux registres de consigne	la modification d’un réglage ou d’un seuil
Valeurs	consigne de niveau entre 1,0 et 4,5 m	une consigne aberrante

On peut aussi refuser les fonctions dont l’exploitation n’a pas besoin : diagnostic, identification, et les codes propres aux logiciels de programmation de certains constructeurs. Le programme de l’automate ne se modifie pas depuis le réseau de supervision.

Voici à quoi ressemble l’esprit d’une politique, pour un automate de pompage fictif. La syntaxe réelle dépend de chaque constructeur.

# Automate de pompage (fictif) - 10.10.20.11, port 502
autoriser supervision 10.10.10.5 FC 03, 04 registres 0 à 199
autoriser supervision 10.10.10.5 FC 06 registre 120 (consigne niveau), valeurs 100 à 450
autoriser historien 10.10.10.8 FC 03 registres 0 à 199
refuser tout le reste, journaliser

Trois lignes d’autorisation, une ligne de refus. C’est lisible, c’est vérifiable, et chaque ligne se justifie par un besoin d’exploitation.

Ce que le filtrage ne fait pas

Modbus ne transporte aucune identité. Le pare-feu reconnaît un client à son adresse réseau, rien de plus. Quelqu’un qui se branche sur le même segment et prend l’adresse de la supervision verra ses écritures passer, tant qu’elles respectent les règles.

Le filtrage contrôle ce qui est écrit, pas qui l’écrit.

C’est déjà beaucoup : une consigne hors plage ou une écriture sur un registre de sécurité sera bloquée, quel que soit l’émetteur. Mais cela ne suffit pas. D’où trois habitudes.

Le pare-feu au plus près des automates. En coupure devant la cellule, pas seulement en tête de réseau. Moins il reste de câble entre le filtre et l’automate, moins il y a d’endroits où usurper une adresse.
Une liste blanche de clients courte. La supervision, l’historien, le poste de maintenance quand il est branché. Pas « le réseau de l’usine ».
La lecture seule par défaut. Tout le monde peut lire, l’écriture est une exception justifiée et documentée.

Le filtrage complète la segmentation, il ne la remplace pas. C’est un disjoncteur de plus sur le départ, pas une raison de supprimer celui de tête. J’en parlais dans Sécurisé, documenté, maintenable : la protection se pense par couches.

Gardez aussi un œil sur le journal. Une écriture refusée, c’est une information : soit une règle oubliée, soit quelqu’un qui tente ce qu’il ne devrait pas. Dans les deux cas, on veut le savoir. C’est l’intégrité, au sens de mon article sur la disponibilité, l’intégrité et la confidentialité, qui se surveille au quotidien.

Et Modbus/TCP Security ?

La Modbus Organization a publié une version sécurisée du protocole, annoncée en octobre 2018 ; la spécification en vigueur au moment où j’écris ces lignes (novembre 2026) est la version 3.6 de juillet 2021. Elle encapsule les trames Modbus habituelles dans TLS, en version 1.2 au minimum, sur le port 802.

Elle répond justement à la question « qui l’écrit ». Le client et le serveur s’authentifient mutuellement avec des certificats X.509. Le certificat du client peut porter un rôle, par exemple « Operator », et l’équipement vérifie à chaque requête si ce rôle a le droit d’exécuter la fonction demandée. En cas de refus, il renvoie une exception Modbus.

Sur le terrain, elle reste pourtant rare, et le rétrofit explique pourquoi.

Il faut que les deux bouts la supportent. Le parc qu’on cherche à protéger est précisément celui qui ne la connaît pas.
Il faut gérer des certificats. Les émettre, les installer, les renouveler, les révoquer. Sur une station sans équipe informatique, c’est un vrai sujet d’exploitation.
Les règles d’autorisation dépendent du constructeur. La spécification laisse au fabricant le soin de définir son algorithme et ses rôles. Sur un parc hétérogène, il faut s’y retrouver.

Pour une installation neuve, c’est une option à exiger dans le cahier des charges, au même titre qu’OPC UA correctement configuré. J’y reviendrai bientôt : OPC UA est sécurisé, à condition de ne pas laisser sa politique de sécurité sur « None ».

Par où commencer

Sur un rétrofit, la démarche tient en cinq étapes.

Recenser qui lit et qui écrit quoi. Pour chaque automate : quels clients, quels codes fonction, quels registres.
Passer en lecture seule tout ce qui n’a pas besoin d’écrire. C’est souvent la majorité des flux.
Placer le filtrage devant les automates les plus critiques d’abord, puis étendre.
Journaliser les refus et les relire, surtout les premières semaines.
Conserver le mode local. Si le réseau tombe ou si une règle bloque à tort, l’exploitant doit pouvoir reprendre la main sur place.

Avant : supervision, historien, bureautique et automates sur un seul réseau. Après : un pare-feu Modbus en coupure protège la cellule automates ; la supervision

L’étape 1 ressemble beaucoup à un document que tout le monde devrait déjà avoir. La table d’échange liste les équipements, les adresses, les variables, le sens des échanges, qui lit et qui écrit.

La table d’échange contient déjà presque toutes vos règles de filtrage.

Bien tenue, elle peut même servir à générer la configuration du pare-feu, au lieu de la ressaisir à la main. J’y consacrerai un article : c’est le document le plus sous-estimé d’une installation.

Sur vos installations, savez-vous précisément qui a le droit d’écrire dans vos automates ?

6. SOURCES

Modbus Organization, MODBUS/TCP Security – Protocol Specification v3.6 (30/07/2021) : https://www.google.com/url?q=https://www.modbus.org/docs/MB-TCP-Security-v36_2021-07-30.pdf&source=gmail&ust=1793945089804000&sa=E
Modbus Organization, Modbus Security: New Protocol to Improve Control System Security (29/10/2018) : https://www.google.com/url?q=https://www.modbus.org/news/modbus-security-new-protocol-to-improve-control-system-security&source=gmail&ust=1793945089804000&sa=E
ANSSI, La cybersécurité des systèmes industriels – Mesures détaillées, v2.0 (27/11/2025) : https://www.google.com/url?q=https://messervices.cyber.gouv.fr/documents-guides/Guide_Systemes_industriels__Mesures_detaillees_v2.pdf&source=gmail&ust=1793945089804000&sa=E
Veille NIS2 – Sénat, dossier législatif : https://www.google.com/url?q=https://www.senat.fr/dossier-legislatif/pjl24-033.html&source=gmail&ust=1793945089804000&sa=E
Veille NIS2 – Leto, report d'octobre 2026 : https://www.google.com/url?q=https://www.leto.legal/news/assemblee-nationale-report-projet-loi-resilience-nis2-octobre-2026&source=gmail&ust=1793945089804000&sa=E
Veille NIS2 – Cabinet Persée (13/10/2026) : https://www.google.com/url?q=https://cabinetpersee.com/blog/posts/nis2-loi-resilience-report/&source=gmail&ust=1793945089804000&sa=E
Veille NIS2 – NosParlementaires (07/10/2026) : https://www.google.com/url?q=https://nosparlementaires.fr/actualites/nis2-loi-cybersecurite-bloquee-assemblee-piratage-dgfip&source=gmail&ust=1793945089804000&sa=E
Assemblée nationale, dossier à suivre : https://www.google.com/url?q=https://www.assemblee-nationale.fr/dyn/17/dossiers/DLR5L17N50731&source=gmail&ust=1793945089804000&sa=E