Das Modbus-Problem, über das niemand sprechen will
Modbus TCP ist in der OT allgegenwärtig. PLCs, RTUs, SCADA-Gateways, Gebäudemanagementsysteme. Wer mehr als ein Jahr in industriellen Umgebungen gearbeitet hat, ist damit in Berührung gekommen.
Das Protokoll wurde 1979 entwickelt. Es setzt ein vertrauenswürdiges, air-gapped Netzwerk voraus, in dem jeder mit physischem Zugang autorisiert ist. Diese Annahme ist seit etwa zwei Jahrzehnten überholt, aber die meisten Anlagen betreiben Modbus nach wie vor vollständig offen auf flachen Netzwerken – ohne Authentifizierung, ohne Verschlüsselung, ohne jegliche Zugangskontrolle.
Das ist kein theoretisches Risiko. Jeder mit Wireshark und Netzwerkzugang kann jeden Registerwert im Klartext lesen. Jeder mit einem Python-Skript kann in Coils und Holding-Register schreiben. Kein Handshake, kein Session-Token, nichts.
Warum Modbus TCP schwer abzusichern ist
Modbus TCP nimmt das ursprüngliche serielle Protokoll und verpackt es in TCP/IP auf Port 502. Das war es. Kein TLS, kein Authentifizierungs-Header, kein Konzept einer Benutzeridentität.
Keine Authentifizierung. Ein Modbus TCP-Server akzeptiert bereitwillig Befehle von jeder IP-Adresse, die ihn erreichen kann. Kein Benutzername, kein Passwort, kein Zertifikataustausch. Wer eine TCP-Verbindung zu Port 502 öffnen kann, ist drin.
Keine Verschlüsselung. Jeder Funktionscode, jede Registeradresse und jeder Wert wird im Klartext übertragen. Ein Angreifer im Netzwerk sieht genau, was Ihr HMI liest und schreibt. Bei einer Man-in-the-Middle-Position kann er Pakete auch während der Übertragung verändern.
Replay ist trivial. Modbus TCP-Pakete sind zustandslos genug, dass aufgezeichneter Datenverkehr später erneut abgespielt werden kann. Einen „Write Single Coil"-Befehl aufzeichnen und beliebig oft erneut absenden – die PLC merkt keinen Unterschied.
Netzwerksegmentierung: Hier anfangen
Wenn Sie nur eine Maßnahme umsetzen, segmentieren Sie Ihren Modbus-Datenverkehr vom Rest Ihres Netzwerks. Dieser einzelne Schritt beseitigt die größte Angriffskategorie: dass jemand im Unternehmens-LAN (oder auf einem kompromittierten IT-Arbeitsplatz) direkt in Ihr Steuerungsnetzwerk gelangt.
VLANs sind das Minimum. Platzieren Sie Ihre Modbus-Geräte in einem eigenen VLAN. Taggen Sie den Datenverkehr nicht einfach und betrachten Sie die Sache als erledigt. Stellen Sie sicher, dass das Inter-VLAN-Routing gesperrt ist, sodass nur bestimmte Hosts die Grenze passieren können.
Firewalls zwischen Zonen sind entscheidend. Ein VLAN ohne Firewall zum restlichen Netzwerk ist nur organisatorische Dekoration. Sie benötigen Stateful Packet Inspection an der Grenze, mit Regeln, die ausschließlich die erwarteten Quell-/Zielpaare und Ports explizit erlauben.
Wer IEC 62443 befolgt, findet hier das Zonen- und Konduit-Modell wieder. In der Praxis bedeutet das, eine klare Grenze zwischen Level 2 (Steuerung) und Level 3 (Standortbetrieb) zu ziehen, mit einem definierten Konduit für Datenverkehr, der diese Grenze passieren muss.
Modbus-Datenverkehr verschlüsseln
Da Modbus TCP keinerlei native Verschlüsselung bietet, muss der Datenverkehr in etwas anderes eingebettet werden.
VPN-Tunnel zwischen Standorten oder zwischen einer Engineering-Workstation und dem Steuerungsnetzwerk sind der gängigste Ansatz. IPsec und WireGuard funktionieren beide. Entscheidend ist, dass der Tunnel so nah wie möglich am Modbus-Gerät endet – nicht am Rand eines flachen Netzwerks, wo der Datenverkehr auf dem letzten Abschnitt unverschlüsselt bleibt.
TLS-Wrapper wie stunnel können Modbus TCP zwischen zwei Endpunkten verschlüsseln. Das funktioniert gut für Punkt-zu-Punkt-Verbindungen, etwa wenn ein HMI mit einer bestimmten PLC kommuniziert. Im größeren Maßstab ist der Verwaltungsaufwand höher, aber es bietet verbindungsweise Verschlüsselung.
Protokollbewusste Firewalls fügen eine weitere Schicht hinzu. Eine Firewall, die Modbus-Funktionscodes versteht, kann Schreibbefehle von Hosts blockieren, die nur lesen sollten, oder einschränken, auf welche Registerbereiche eine bestimmte Quelle zugreifen darf. Ein Inline-Proxy mit Modbus-Verständnis kann gerätespezifische, funktionscodespezifische Richtlinien durchsetzen, ohne Änderungen an der PLC oder dem HMI zu erfordern.
Zugangskontrolle ohne native Unterstützung
Modbus kennt keinen „Benutzer". Zugangskontrolle muss daher auf Netzwerk- und Anwendungsebene durchgesetzt werden.
Quell-IPs an der Firewall per Allowlist beschränken. Nur das HMI, der Historian und die Engineering-Workstation sollten Port 502 auf Ihren PLCs erreichen können. Alles andere wird verworfen. Das ist ein grober Ansatz, aber er verhindert den ungezielten Zugriff von beliebigen Maschinen im Netzwerk.
Gateway oder Proxy für rollenbasierte Kontrolle einsetzen. Wenn Sie feinere Granularität benötigen (nur Lesen für Bediener, Lesen und Schreiben für Ingenieure), brauchen Sie eine Komponente vor dem Modbus-Gerät, die authentifizierte Benutzer auf Berechtigungssätze abbildet. Ein Modbus-fähiges Access Gateway übernimmt dies, indem es die Modbus-Verbindung terminiert, den Benutzer authentifiziert und dann nur die erlaubten Funktionscodes an das nachgelagerte Gerät weiterleitet.
MFA für den Fernzugriff, ausnahmslos. Wer sich remote mit dem Steuerungsnetzwerk verbindet – über VPN, einen Jump Host oder ein Cloud-Gateway – benötigt Multi-Faktor-Authentifizierung. Das ist nicht verhandelbar. Ein gestohlenes Passwort darf nicht ausreichen, um eine PLC zu erreichen.
Monitoring: Was Sie nicht sehen, können Sie nicht schützen
Flacher Modbus-Datenverkehr lässt sich gut überwachen, weil er im Klartext vorliegt und gut strukturiert ist. Nutzen Sie das.
IDS mit Modbus-Unterstützung betreiben. Snort und Suricata verfügen beide über Modbus-Präprozessoren. Sie können bei unerwarteten Funktionscodes, Schreibzugriffen auf Registerbereiche, die nicht beschrieben werden sollten, oder Datenverkehr von IP-Adressen außerhalb der Allowlist alarmieren.
Normalen Datenverkehr zuerst als Baseline erfassen. Bevor Sie Alarmregeln schreiben, zeichnen Sie eine Woche normalen Modbus-Datenverkehr auf und analysieren Sie ihn. Wie oft pollt das HMI? Welche Register liest es? Werden im Normalbetrieb überhaupt Coils beschrieben? Wer weiß, wie „normal" aussieht, erkennt Anomalien sofort.
Alles am Gateway protokollieren. Wenn Sie einen Modbus-Proxy oder ein Gateway betreiben, protokollieren Sie jede Verbindung und jeden Funktionscode. Wenn etwas schiefläuft, ist ein vollständiges Audit-Trail – wer was in welches Register geschrieben hat und wann – der Unterschied zwischen einer 30-minütigen Untersuchung und einer dreitägigen forensischen Analyse.
Patch-Management in OT ist anders
Patchen in OT ist nicht wie Patchen in IT. Updates lassen sich nicht einfach dienstagabends einspielen und neu starten. Ausfallzeiten kosten echtes Geld, und ein fehlerhaftes Firmware-Update auf einer PLC kann eine Produktionslinie stilllegen.
Wissen, was läuft. Führen Sie ein Inventar aller Modbus-fähigen Geräte mit Firmware-Version und Patch-Status des Herstellers. Die meisten Anlagen können diese Frage nicht beantworten – und können damit nicht patchen, selbst wenn sie es wollten.
Patches in einer Staging-Umgebung testen. Wenn Sie eine Test-PLC oder eine Simulationsumgebung haben, validieren Sie Patches dort, bevor Sie sie in der Produktion einsetzen. Wenn Sie keine Testumgebung haben, brauchen Sie eine. Die Kosten sind gering im Vergleich zu einem fehlgeschlagenen Update auf einem laufenden System.
Wartungsfenster realistisch planen. Stimmen Sie sich mit dem Betrieb ab, um Fenster zu finden, in denen Patchen möglich ist. Quartalsweise ist für die meisten Umgebungen ein vernünftiges Ziel. Jährlich ist zu langsam. Monatlich ist für OT ambitioniert, aber streben Sie es an, wenn es möglich ist.
Empfehlenswerte Standards
IEC 62443 ist der Goldstandard für industrielle Cybersicherheit. Er bietet einen Rahmen für Zonen, Konduits und Sicherheitsstufen, der sich direkt auf reale Netzwerkarchitekturentscheidungen abbilden lässt. Beginnen Sie mit den Teilen 3-2 (Sicherheitsrisikobewertung) und 3-3 (Systemsicherheitsanforderungen).
NIST SP 800-82 ist der Leitfaden der US-Regierung zur ICS-Sicherheit. Er ist praxisnah und gut geschrieben. Wer sich in einer CMMC- oder NIST 800-171-Umgebung befindet, findet hier Anforderungen, die mit diesen Vorgaben übereinstimmen, und OT-spezifische Hinweise, die 800-171 allein nicht abdeckt.
NIS2 gilt für Unternehmen, die in der EU tätig sind oder in EU-kritische Infrastruktursektoren liefern. Sie schreibt Meldepflichten bei Vorfällen und Sicherheitsanforderungen vor, die OT-Umgebungen ausdrücklich einschließen. Wer die NIS2-Compliance noch nicht verfolgt, sollte prüfen, ob die eigene Organisation in ihren Anwendungsbereich fällt.
Womit Sie morgen anfangen können
Wählen Sie die wirkungsvollste Maßnahme, die Sie noch nicht umgesetzt haben. Für die meisten Anlagen, die Modbus TCP auf einem flachen Netzwerk betreiben, ist das die Segmentierung. Platzieren Sie Ihre Steuerungsgeräte hinter einer Firewall, schränken Sie ein, welche Hosts Port 502 erreichen können, und protokollieren Sie die Verbindungen. Das allein schließt die meisten Lücken. Alles andere baut auf diesem Fundament auf.
