Modbus über alles? Warum das 50 Jahre alte Protokoll immer noch die Fabrik beherrscht

von DerSchneider

Einleitung: Der Veteran unter den Feldbussen

Modbus wird 50 Jahre alt – ein Alter, in dem in der Technikwelt normalerweise längst der Ruhestand begonnen hat. Andere Protokolle aus den 1970ern (IEEE 488, HDLC, Bitbus) sind Museumsstücke oder Nischenlösungen. Modbus hingegen ist allgegenwärtig. Jeder zweite Frequenzumrichter, jeder dritte Sensor, fast jede speicherprogrammierbare Steuerung (SPS) beherrscht Modbus – sei es als Modbus RTU über RS485 oder als Modbus TCP über Ethernet.

Wie konnte ein so simples, ja primitives Protokoll fünf Dekaden überleben? Und welche Kosten zahlt die Industrie dafür in puncto Sicherheit, Performance und Interoperabilität? Dieser Artikel beleuchtet Modbus aus systemischer Perspektive: seine historischen Wurzeln, seine technischen Eigenheiten, die heutigen Sicherheitsrisiken – und die Frage, ob es an der Zeit ist, sich von diesem Veteran zu verabschieden.

Die Geburt eines Standards: Modicon und die Einfachheit

Das Jahr ist 1979. Die Firma Modicon (Modular Digital Controller) – Erfinder der speicherprogrammierbaren Steuerung – steht vor einem Problem: Ihre SPSen sollen mit anderen Geräten kommunizieren können, aber es gibt kein standardisiertes Protokoll. Also entwickelt Modicon ein eigenes, das sie schlicht Modbus nennen (kurz für „Modicon Bus“).

Die Designziele sind radikal pragmatisch:

• Minimalistisch: Ein einfaches Master-Slave-Protokoll mit wenigen Funktionen.
• Robust: Soll auch auf verrauschten Leitungen mit einfachen UARTs funktionieren.
• Lizenzfrei: Modicon gibt die Spezifikation frei – jeder kann es implementieren.
• Plattformneutral: Funktioniert auf RS232, RS485, später auch auf TCP/IP.

Die ursprüngliche Modbus‑Spezifikation (Modbus Application Protocol Specification V1.1) umfasst gerade einmal ein Dutzend Funktionen: Lesen und Schreiben von einzelnen oder mehreren Coils (digitalen Ausgängen), Diskreten Eingängen, Halteregistern (16‑Bit‑Daten) und Eingangsregistern. Das war’s. Keine aufwendigen Objektverzeichnisse, keine dynamische Konfiguration, keine Sicherheit – nur nackte Lese- und Schreibbefehle.

Diese Einfachheit war der Schlüssel zum Erfolg. Jeder Hersteller, der einen Frequenzumrichter, ein Panel oder einen Sensor baute, konnte Modbus mit wenigen Personentagen implementieren. Die Lizenzkosten waren null. Und weil Modbus so verbreitet war, implementierten es alle Hersteller, um mit den anderen zu kommunizieren – ein sich selbst verstärkender Netzwerkeffekt.

Technische Anatomie: Wie Modbus funktioniert

Modbus RTU (Remote Terminal Unit)

Die klassische Variante läuft über asynchrone serielle Schnittstellen (RS232, RS485). Ein Datenframe besteht aus:

• Start (mindestens 3,5 Zeichen Stille)
• Adresse (1 Byte, 1–247 für Slaves, 0 für Broadcast)
• Funktionscode (1 Byte, z. B. 0x03 = Read Holding Registers)
• Daten (variable Länge, abhängig von Funktion)
• CRC16 (2 Bytes, zyklische Redundanzprüfung)

Die Einfachheit hat einen Preis: Es gibt keine Unterscheidung zwischen Daten und Steuerbefehlen im Frame – das Protokoll ist nicht „escaping“-fähig. Das bedeutet, dass bestimmte Bytewerte (insbesondere 0x11 und 0x16) nicht im Datenfeld auftreten dürfen, ohne speziell behandelt zu werden. In der Praxis umgeht man das durch Byte‑Stuffing oder verschobene Adressbereiche – ein notdürftiger Flickenteppich.

Die Timing‑Falle: Modbus RTU erkennt das Frame-Ende an einer Pause von mindestens 3,5 Zeichen. Das ist auf heutigen Hochgeschwindigkeits-Mikrocontrollern problematisch: Bei 115200 Bit/s entsprechen 3,5 Zeichen etwa 300 µs. Ein Interrupt-Latenz von mehr als 300 µs (durch ein Echtzeitbetriebssystem) kann dazu führen, dass das Ende eines Frames falsch erkannt wird. Die Lösung: Entweder Modbus ASCII (das klare Start/End-Zeichen verwendet) oder aufwändige Timer-basierte Framing-Erkennung.

Modbus TCP (Modbus/TCP)

Mit dem Siegeszug von Ethernet wurde Modbus auf TCP/IP portiert. Das Frame ist nahezu identisch, nur ohne CRC (das von TCP/IP übernommen wird) und mit einem 7‑Byte‑Header (Transaction ID, Protocol ID, Length, Unit ID). Port 502 ist offiziell für Modbus TCP reserviert.

Der Vorteil: Modbus TCP kann über existierende Unternehmensnetzwerke laufen, ohne zusätzliche Verkabelung. Der Nachteil: Die Sicherheitsprobleme multiplizieren sich, wie wir später sehen werden.

Die Schattenseiten: Warum Modbus ein Sicherheitsrisiko ist

Modbus wurde zu einer Zeit entwickelt, als das Wort „Cybersicherheit“ noch nicht existierte. Die Folge: Modbus ist von Grund auf unsicher. Die Schwachstellen sind systemisch:

1. Keine Authentifizierung
Jeder Client, der auf das Netzwerk zugreifen kann, kann Modbus‑Befehle senden. Es gibt keine Passwörter, keine Zertifikate, keine Rollen. Ein Angreifer muss lediglich die Modbus‑Adresse des Zielgeräts kennen (oft der Werksstandard 1) und kann dann beliebig Coils setzen oder Register schreiben.

2. Keine Verschlüsselung
Alle Daten – auch sensible Prozesswerte oder Konfigurationsparameter – werden im Klartext übertragen. Ein Angreifer im Netzwerk kann mithören (Sniffing) und die Kommunikation analysieren, um Schwachstellen zu finden.

3. Keine Integritätssicherung (außer CRC)
Das CRC im RTU-Modus schützt nur vor zufälligen Bitfehlern, nicht vor gezielter Manipulation. Ein Angreifer kann ein Frame ändern und das CRC neu berechnen – das Protokoll erkennt keine böswillige Modifikation.

4. Broadcast als Denial‑of‑Service‑Waffe
Der Broadcast‑Befehl (Adresse 0) wird von allen Slaves gleichzeitig ausgeführt. Ein Angreifer kann einen Broadcast‑Write auf ein kritisches Register senden (z. B. „Motorfreigabe aus“) und so die gesamte Produktion lahmlegen.

5. Keine Rate Limiting
Modbus hat keine eingebaute Begrenzung der Befehlshäufigkeit. Ein Angreifer kann tausende Lese‑/Schreibbefehle pro Sekunde senden, was die SPS überlastet und in einen Reset oder eine Fehlerzustand treiben kann („Modbus‑Storm“).

Die Realität: Sicherheitsvorfälle mit Modbus sind keine Theorie. Der Stuxnet‑Wurm (2010) nutzte Modbus‑Befehle, um die Drehzahlen von Uranzentrifugen zu manipulieren. Die CrashOverride‑Malware (2016) schrieb direkt auf Modbus‑Halteregister in ukrainischen Umspannwerken, um Leistungsschalter zu öffnen. In beiden Fällen half die Einfachheit von Modbus den Angreifern mehr als den Verteidigern.

Die unangenehme Wahrheit: Modbus ist auch technisch veraltet

Über die Sicherheitsprobleme hinaus hat Modbus handfeste technische Einschränkungen, die in modernen Automatisierungsarchitekturen schmerzen:

1. Keine Geräteerkennung
Ein Modbus‑Master muss die Adressen und Registerzuordnungen der Slaves im Voraus kennen. Es gibt kein „Plug and Play“. Wer einen Sensor austauscht, muss oft die SPS‑Programmierung anpassen, weil die Registeradressen abweichen. Das widerspricht dem Gedanken der Industrie 4.0 mit dynamischer Konfiguration.

2. Begrenzte Datentypen
Modbus kennt nur 16‑Bit‑Register (Halteregister) und Bits (Coils). 32‑Bit‑Gleitkommazahlen (Float) müssen über zwei aufeinanderfolgende Register abgebildet werden – mit allen Problemen der Byte-Reihenfolge (Little‑ vs. Big‑Endian). Strings werden als aufeinanderfolgende 16‑Bit‑Werte kodiert. Es gibt keine einheitliche Konvention, was zu endlosen Kompatibilitätsproblemen führt.

3. Keine Ereignisbenachrichtigung
Modbus ist ein reines Polling‑Protokoll. Der Master muss zyklisch alle Slaves abfragen, auch wenn sich deren Werte nicht geändert haben. Das erzeugt unnötigen Netzwerkverkehr. Bei 247 Slaves und einer Zykluszeit von 100 ms pro Slave kommt man auf eine Gesamtzykluszeit von fast 25 Sekunden – viel zu langsam für viele Regelungen. Modbus kann keine spontanen Nachrichten („Change of State“) senden.

4. Keine Prioritäten
Alle Befehle sind gleich wichtig. Ein Lese-Befehl für einen Temperatursensor hat dieselbe Priorität wie ein Schreib-Befehl für einen Not‑Aus. Es gibt keine Möglichkeit, zeitkritische Telegramme zu bevorzugen.

Die Modbus‑Rettungsringe: Wie man das Unvermeidbare sicherer macht

Weil Modbus nicht verschwinden wird (dazu ist es zu tief in der installierten Basis verankert), haben Ingenieure und Normungsgremien Wege gefunden, die schlimmsten Schwächen zu mildern:

1. Modbus Security (Modbus/TCP Security – RFC 2025 in Arbeit)
Eine Erweiterung, die TLS‑Verschlüsselung (Transport Layer Security) über Port 802 (statt 502) nutzt. Bietet Authentifizierung (Zertifikate), Verschlüsselung und Integritätsschutz. Nachteil: Erfordert leistungsfähigere Hardware in den Slaves – viele bestehende Geräte können kein TLS.

2. Tunneling über VPN
Ein Klassiker: Modbus TCP läuft nur innerhalb eines abgeschotteten VLANs oder über einen VPN‑Tunnel. Das schützt vor externen Angriffen, aber nicht vor Insider‑Bedrohungen oder kompromittierten Geräten im selben VLAN.

3. Application Level Gateways (ALG)
Spezielle Firewalls, die Modbus‑Telegramme auf Anwendungsebene prüfen (Deep Packet Inspection). Sie können bestimmte Funktionscodes blockieren (z. B. Write Multiple Registers), Adressbereiche einschränken oder Ratenbegrenzungen durchsetzen. Geräte wie der Hirschmann Eagle oder der Phoenix Contact mGuard sind dafür optimiert.

4. Modbus mit Coils als Freigabe
Eine sichere Programmierpraxis: Kritische Schreibbefehle werden nicht direkt ausgeführt, sondern setzen zunächst ein Freigabe‑Coil, das innerhalb eines kurzen Zeitfensters (z. B. 100 ms) zurückgesetzt werden muss. Das erschwert automatisierte Angriffe.

Die Konkurrenz: Warum Modbus nicht längst abgelöst wurde

Es gibt technisch überlegene Feldbusse und Protokolle:

• PROFINET (Siemens) – Echtzeit-Ethernet mit Geräteerkennung, Diagnose, Sicherheit (PROFIsafe)
• EtherCAT (Beckhoff) – extrem schnelles Ethernet (100 µs Zyklen)
• OPC UA – plattformunabhängig, sicher, mit Informationsmodellen
• MQTT – leichtgewichtig, ideal für IIoT und Cloud‑Anbindung

Warum setzt sich keines davon gegen Modbus durch? Die Antwort ist systemisch: Installierte Basis und Kompatibilitätszwang. Eine typische Fabrik hat hunderte von Modbus‑Geräten, die über Jahrzehnte angeschafft wurden. Sie alle zu ersetzen wäre wirtschaftlicher Wahnsinn. Neue Geräte müssen aus Kompatibilitätsgründen weiterhin Modbus unterstützen, auch wenn sie zusätzlich moderne Protokolle beherrschen.

Hinzu kommt die Einfachheit für kleine Geräte. Ein 8‑Bit‑Mikrocontroller mit 2 KB RAM kann problemlos einen Modbus‑Stack laufen lassen, aber keinen OPC‑UA‑Stack (der oft 1 MB RAM benötigt). Für Sensoren und Aktoren im unteren Preissegment bleibt Modbus die einzige realistische Option.

Zukunftsszenarien: Koexistenz statt Ablösung

Die nächsten zehn Jahre werden keinen Sieg eines einzigen Protokolls bringen, sondern eine geschichtete Architektur:

• Feldebene (Sensoren/Aktoren): Modbus RTU über RS485 bleibt dominant, weil es billig und gut genug ist.
• Steuerungsebene (SPS‑zu‑SPS): Ethernet‑basierte Protokolle wie PROFINET oder EtherCAT gewinnen, weil sie Echtzeit und große Datenmengen bieten.
• Leitebene (SCADA, MES, Cloud): OPC UA und MQTT setzen sich durch, weil sie Sicherheit, Informationsmodelle und Cloud‑Anbindung mitbringen.
• Gateway: Zwischen diesen Welten stehen Gateways, die Modbus RTU in Modbus TCP, OPC UA oder MQTT übersetzen. Das ist der pragmatische Weg.

Hersteller wie HMS Networks, Moxa oder Anybus bieten solche Gateway‑Lösungen in Hülle und Fülle. Sie sind der Klebstoff, der die alte Modbus‑Welt mit der neuen IIoT‑Welt verbindet.

Fazit: Der Veteran bleibt – aber mit Orden und Krücken

Modbus ist 50 Jahre alt, unsicher, technisch rückständig und dennoch unverzichtbar. Das ist kein Widerspruch, sondern eine Lehre über die Trägheit industrieller Systeme. Die Fabrik von heute ist eine archäologische Ausgrabung in Betrieb: Schichten von Technologien aus verschiedenen Jahrzehnten, die irgendwie zusammengehalten werden müssen.

Modbus ist das Fundament dieser Schichten. Es wird noch lange nicht verschwinden, aber es wird zunehmend hinter Sicherheits‑Gateways versteckt, durch Firewalls abgeschottet und durch moderne Protokolle ergänzt. Der Erfinder von Modbus, Modicon (heute Teil von Schneider Electric), hätte sich vor 50 Jahren wohl nicht träumen lassen, dass sein schmales Protokoll einmal die halbe Industrie zusammenhält – und zum Sicherheitsalbtraum einer vernetzten Welt wird. Modbus über alles? Ja, aber bitte mit Sicherheitsnetz.

Quellen

• Modicon Inc. (1979): Modbus Protocol Reference Guide. PI–MBUS–300 Rev. J.
• Modbus Organization (2021): Modbus Application Protocol Specification V1.1b3.
• IEC 61158-5-15:2019 – Industrial communication networks – Fieldbus specifications – Part 5-15: Application layer service definition – Type 15 (Modbus) elements.
• Langill, J. (2020): Defending Modbus‑Based Industrial Control Systems. In: SANS Institute Reading Room, GSEC Practical Assignment.
• Dragos, Inc. (2017): CRASHOVERRIDE – Analyzing the Malware that Attacks Power Grids. Dragos Threat Intelligence Report.
• Falliere, N., Murchu, L. O., Chien, E. (2011): W32.Stuxnet Dossier. Symantec Security Response.
• BSI (Bundesamt für Sicherheit in der Informationstechnik) (2024): Sicherheit industrieller Kommunikationsprotokolle – Modbus und OPC UA im Vergleich. BSI‑CS 102/2024.
• Knapp, E. D., Langill, J. T. (2014): Industrial Network Security – Securing Critical Infrastructure Networks for Smart Grid, SCADA, and Other Industrial Control Systems. Syngress, ISBN 978-0-12-420114-9.
• HMS Networks (2025): Industrial Network Market Share Study 2025 (jährliche Studie zu Feldbus- und Industrial-Ethernet-Marktanteilen).