Modbus überträgt seit 1979 Prozessdaten, und seine TCP-Variante tut dies seit den späten 1990er-Jahren über Ethernet. Es findet sich in Produktionsanlagen, Umspannwerken, Wasserwerken, Technikzentralen und unzähligen Skid-Systemen, die seit einem Jahrzehnt niemand mehr geöffnet hat. Das Protokoll wurde für eine Welt konzipiert, in der das physische Kabel die Sicherheitsgrenze darstellte. Es gibt kein Login, keine Verschlüsselung und kein Konzept von Benutzerkonten. Ein Gerät akzeptiert einen Befehl zum Schreiben eines Sollwerts genauso bereitwillig wie einen Befehl zum Lesen einer Temperatur – von jedem Host aus, der eine TCP-Verbindung zu Port 502 aufbauen kann.

Aus diesem Grund ist Modbus TCP-Sicherheit in der Praxis primär eine Frage der Firewall-Architektur. Das Protokoll selbst lässt sich selten anpassen, und die Feldgeräte dürfen oft nicht modifiziert werden. Folglich müssen Sie den Kommunikationspfad zu ihnen kontrollieren. Dieser Leitfaden erläutert die präzise Umsetzung: welche Regeln in welcher Reihenfolge zu definieren sind, wie weit die Funktionscode-Inspektion reicht, welche Rolle TLS-gesichertes Modbus auf Port 802 spielt, wie Missbrauch detektiert wird und wie all dies ohne Unterbrechung eines seit 15 Jahren unverändert laufenden Prozesses implementiert werden kann. Er richtet sich an Sicherheitsverantwortliche und OT-Ingenieure, die die Risiken von Modbus kennen und ein belastbares Regelwerk etablieren müssen.

Warum Modbus TCP-Sicherheit an der Firewall beginnt

Was das Protokoll nicht leistet

In der Spezifikation des Modbus-Anwendungsprotokolls existiert kein Sicherheitsabschnitt, da das ursprüngliche Bereitstellungsmodell von einem geschlossenen Netzwerk ausging. Fünf Schwachstellen sind für das Firewall-Design maßgeblich:

• Keine Authentifizierung. Der Server validiert die Identität des Clients nicht. Die Quell-IP ist das einzige Merkmal – und sie kann gefälscht oder kompromittiert werden.

• Keine Autorisierung. Jeder Client kann jeden Funktionscode auf jedem freigegebenen Register des Geräts ausführen. Ein reiner Lesezugriff (Read-Only) kann von einem Modbus-Server nicht eigenständig erzwungen werden.

• Keine Verschlüsselung oder Integrität. Alle Daten werden im Klartext übertragen, sodass Befehle mitgelesen und manipuliert (Replay-Angriffe) werden können. Die CISA-Meldung ICSA-17-101-01 zum Modicon-Modbus-Protokoll beschreibt exakt dies: Klartextübertragungen ermöglichen Angreifern das erneute Abspielen von Start-, Stopp-, Upload- und Download-Befehlen.

• Kein Sitzungskontext. Die Unit-ID im Header dient als Routing-Feld für Gateways, nicht der Identifikation von Benutzern oder Rollen.

• Fragiles Parsing. Eingebettete Protokoll-Stacks reagieren oft empfindlich auf fehlerhafte Eingaben. Die CISA-Meldung ICSA-25-114-01 von April 2025 dokumentiert mehrere über Modbus erreichbare Schwachstellen in Schneider Electric Modicon-Steuerungen, die zu einem Denial of Service (DoS) führen können.

Diese Schwachstellen treten auch bei Neuentwicklungen auf. Im Juni 2026 wurde eine Schwachstelle aufgrund fehlender Authentifizierung für den Modbus TCP-Dienst auf der Delta DVP-12SE PLC (CVE-2026-12819) veröffentlicht, die es nicht authentifizierten Angreifern ermöglicht, sicherheitskritische Steuerungsfunktionen auszuführen. Eine Analyse der CISA-Daten durch Forescout zählte zwischen März 2010 und Januar 2026 insgesamt 3.637 ICS-Sicherheitsmeldungen mit 12.174 Schwachstellen über 689 Hersteller hinweg. Hersteller beheben diese Risiken nicht immer zeitnah, und Patch-Zyklen in der OT betragen oft Jahre. Die Netzwerkinfrastruktur muss diesen Schutz zwingend kompensieren.

Keine Theorie: Der Vorfall FrostyGoop

Am 22. und 23. Januar 2024 attackierten Angreifer ein kommunales Fernwärmeunternehmen in Lemberg (Ukraine). Bei Minustemperaturen fiel die Heizungsversorgung für über 600 Mehrfamilienhäuser rund zwei Tage lang aus. Dragos identifizierte später die Schadsoftware FrostyGoop – die neunte ICS-spezifische Malware weltweit und die erste, die Modbus TCP über Port 502 direkt gegen speicherprogrammierbare Steuerungen einsetzte.

Die Funktionsweise verdeutlicht die Bedrohung: In Go geschrieben, liest FrostyGoop eine JSON-Konfigurationsdatei mit Ziel-IPs und zu manipulierenden Holding-Registern aus und sendet reguläre Modbus TCP-Befehle. Es wird kein Exploit benötigt. Laut Dragos erkannten Antiviren-Lösungen die Malware bei Entdeckung nicht. Da viele Zielsysteme direkt aus dem Internet erreichbar waren, war keine vorherige Kompromittierung des internen Netzwerks erforderlich. Das ukrainische CSSC und Dragos brachten den Vorfall mit ENCO-Steuerungen in Verbindung – die Methode funktioniert jedoch gegen jede antwortende Modbus-Komponente.

Die Debatte über die Komplexität und eine staatliche Urheberschaft ist für Verteidiger zweitrangig. Entscheidend sind die gemeinsamen Schwachpunkte: erreichbare Systeme, flache Netzwerkstrukturen und ein unauthentifiziertes Protokoll. Eine präzise Firewall-Policy eliminiert alle drei Angriffsvektoren.

Zunehmende Exposition von OT-Systemen

• Zum Zeitpunkt der FrostyGoop-Analyse identifizierte Dragos Zehntausende Modbus-Geräte, die direkt über das Internet erreichbar waren (rund 46.000 gemäß Cybersecurity Dive).

• Ein Scan von Bitsight aus dem Jahr 2025 erfasste rund 180.000 im Internet exponierte ICS/OT-Geräte – ein Anstieg von 12 Prozent gegenüber dem Vorjahr, wobei Modbus zu den am häufigsten exponierten Protokollen zählte.

• Ein im April 2026 veröffentlichter Scan von Comparitech identifizierte 179 industrielle Systeme auf Port 502, darunter Komponenten aus der Energie- und Infrastrukturbranche. Die Verfasser betonten, dass selbst Angreifer mit geringen Fähigkeiten Daten auslesen und manipulieren konnten.

Sollte in Ihrer Organisation die Annahme herrschen, „unsere PLCs sind nicht mit dem Internet verbunden“, ist der Nachweis dieser Trennung durch ein Audit die dringendste Maßnahme (siehe die Prüfschritte im weiteren Verlauf dieses Dokuments).

Verkehrsanalyse vor der Regelerstellung: Modbus TCP-Anatomie für Firewall-Administratoren

Eine Standardregel für Port 502 lässt sich schnell definieren. Für eine wirksame Funktionscode- oder Registerfilterung ist jedoch ein tiefes Verständnis der Paketstruktur erforderlich. Jede Modbus TCP-Nachricht besteht aus einem MBAP-Header und einer nachfolgenden Protocol Data Unit (PDU):

Der Header umfasst 7 Bytes und die PDU maximal 253 Bytes; somit überschreitet ein vollständiger Frame nicht die Grenze von 260 Bytes. Dank dieser kompakten, konsistenten Struktur lässt sich Modbus exzellent per Deep Packet Inspection (DPI) prüfen. Reine Paketfilter auf L3/L4 schöpfen das Sicherheitsniveau bei Weitem nicht aus.

Klassifizierung und Behandlung von Funktionscodes

Funktionscode 43 veranschaulicht diese Notwendigkeit: Autorisierte Asset-Management-Tools nutzen ihn zum Auslesen von Hersteller- und Modellkennungen; Angreifer nutzen ihn für die Aufklärung (Reconnaissance). Dasselbe Paket, grundlegend andere Absicht. Die Differenzierung gelingt allein über das Quellsystem mittels rollenbasierter Firewall-Regeln.

Segmentierung: Platzierung von Modbus-Conduits nach dem Zonenmodell

IEC 62443 und NIST SP 800-82 Rev. 3 verfolgen denselben Ansatz: Die Leitumgebung wird in Zonen gleicher Vertrauenswürdigkeit unterteilt, und Datenflüsse zwischen ihnen sind ausschließlich über definierte Verbindungswege (Conduits) zulässig. Das Firewall-Regelwerk setzt diese Conduits durch. Für Modbus ist zu prüfen, wo Kommunikationsflüsse verlaufen und welche Verbindungen legitim sind.

Inline-Firewall, TAP oder redundanter Einsatz

Regeldurchsetzung (Enforcement) erfordert ein Inline-System. Sichtbarkeit kann passiv über TAPs oder SPAN-Ports generiert werden, die Netzwerk-Monitoring-Sensoren speisen. Best Practice in KRITIS-Umgebungen ist die Kombination beider Ansätze: Die Firewall an der Zonengrenze erzwingt die Richtlinie, während ein paralleler Sensor den Datenverkehr unabhängig bewertet und Anomalien erkennt. Platzieren Sie Kontrollpunkte so nah wie möglich an den Endgeräten – typischerweise an Zellgrenzen –, damit ein kompromittiertes Leitsystem nicht unkontrolliert alle Steuerungen der Anlage erreichen kann.

Strategische Festlegung: Fail-Open versus Fail-Closed

Hardware-Komponenten können ausfallen. Ein Hardware-Bypass (Fail-Open) sichert die Kontinuität des Prozesses, hebt jedoch die Regeldurchsetzung auf. Fail-Closed schützt die Integrität der Sicherheitsrichtlinie, unterbricht jedoch den Steuerungsverkehr. Es gibt hier keine Universallösung. Stimmen Sie dieses Verhalten für jede Zone gemeinsam mit Betriebsführung und Anlagensicherheit (Safety) ab, dokumentieren und testen Sie das Szenario. Sicherheitsgerichtete Steuerungen (SIS) gehören zwingend in eigene Segmente mit separatem Regelwerk; Firewall-Änderungen dürfen deren Kommunikation unter keinen Umständen beeinträchtigen.

Modbus TCP Firewall-Regeln: Ein praxiserprobtes Regelwerk

Das folgende Modell definiert ein strukturiertes Regelwerk für ein Conduit zwischen einer Leitebene (Supervisory-Zone) und einer Steuerungsebene (Control-Zone). Passen Sie Bezeichner und IP-Bereiche an, behalten Sie die Logik bei.

Basisregeln (Layer 3 und Layer 4)

Drei Prinzipien gewährleisten die Wartbarkeit: Verwenden Sie benannte Gruppen statt einzelner IP-Adressen, damit der Tausch eines HMI lediglich eine Objektänderung erfordert. Versehen Sie jede Regel mit Verantwortlichen (Owner) und Prüffristen. Protokollieren Sie abschließende Deny-Regeln, um undokumentierte Kommunikationsversuche verlässlich aufzudecken.

Minimalbeispiel unter Linux nftables

Das folgende Beispiel zeigt die L3/L4-Logik auf einer Linux-Bridge oder einem Router. Es führt keine Funktionscode-Inspektion durch und dient ausschließlich als Basisschutz. Testen Sie die Syntax vor dem Produktiveinsatz in einer Laborumgebung.

Dieses Konzept hat sich bewährt: Das quelloffene Projekt Modbusfw erweiterte Netfilter bereits frühzeitig, um Filterentscheidungen anhand von Modbus-Header-Werten wie Funktionscode, Unit-ID und Registern zu treffen. Die Erkenntnis bleibt bis heute gültig: Das bloße Öffnen von Port 502 lässt jeden beliebigen Steuerbefehl ungefiltert passieren.

Rollenbasierte Funktionscode-Allowlists

Diese Maßnahme entscheidet darüber, ob ein System lediglich erreichbar ist oder dabei auch sicher betrieben werden kann. Definieren Sie Richtlinien rollenbasiert:

Granulare Filterung: Adressen, Mengen und Unit-IDs

Funktionscode-Filterung reduziert die Angriffsfläche erheblich. Ein unberechtigter Schreibbefehl auf ein falsches Register bleibt jedoch eine Gefahr. Sofern Ihre Firewall dies unterstützt (die Funktionsumfänge variieren je nach Hersteller), sollten Sie folgende Prüfungen implementieren:

• Registerbereich-Allowlists. Erlauben Sie Schreibzugriffe nur auf operativ benötigte Sollwertblöcke. Blockieren Sie Zugriffe auf Register, die Betriebsmodi, Konfigurationen oder Sicherheits-Bypässe steuern.

• Mengenbegrenzungen (Quantity Limits). Ein Write-Multiple-Registers-Befehl über 100 Register, während das Leitsystem regulär nur zwei beschreibt, indiziert eine Anomalie.

• Unit-ID-Einschränkungen. Hinter einem TCP-zu-Seriell-Gateway bestimmt die Unit-ID das adressierte serielle Endgerät. Gestatten Sie nur in der Kommunikationsmatrix dokumentierte IDs. Unit-ID 0 dient auf seriellen Bussen als Broadcast – unkontrollierte Broadcasts erreichen potenziell viele Komponenten mit einem einzigen Paket.

• Protokollvalidierung (Sanity Checks). Verwerfen Sie Frames mit Protocol-IDs ungleich 0, unpassenden Längenangaben oder PDUs über 253 Bytes. Dies blockiert Fuzzing-Versuche und Scan-Werkzeuge frühzeitig.

Verbindungsmanagement: Timeouts, Limits und Ratenbegrenzung

Häufig wird empfohlen, kurze Firewall-Timeouts von 30 bis 60 Sekunden zu setzen. Dies erfordert Vorsicht: Viele Modbus-Master halten TCP-Verbindungen permanent offen und fragen Daten in festen Zyklen ab. Ist das Idle-Timeout der Firewall kürzer als das Polling-Intervall, trennt sie intakte Verbindungen. Der Master baut diese wieder auf, was zu Datenlücken und erhöhtem Log-Aufkommen führt. Zu lange Timeouts belegen unnötig Zustandstabellen. Empfohlenes Vorgehen:

1. Messen Sie das längste Polling-Intervall pro Master-Geräte-Paar während der Baseline-Phase.

2. Konfigurieren Sie das Idle-Timeout auf ein Mehrfaches dieses Intervalls (Faktor 3 bis 5) und aktivieren Sie TCP-Keepalive auf den Master-Systemen.

3. Ermitteln Sie die maximale Anzahl paralleler TCP-Verbindungen der Endgeräte. Viele kompakte PLCs verarbeiten nur wenige Verbindungen gleichzeitig. Begrenzen Sie parallele Sessions pro Quelle und Ziel deutlich unterhalb dieses Limits, um Denial-of-Service-Zustände durch fehlerhafte Clients oder Scans zu verhindern.

4. Begrenzen Sie die Rate neuer Verbindungsaufbauten pro Quelle, um automatisierte Scans und Connection-Floods abzuwehren.

Effektives und zielgerichtetes Logging

• Protokollieren Sie alle verworfenen Pakete (Denies) auf dem Modbus-Port sowie an der finalen Default-Deny-Regel.

• Protokollieren Sie erlaubte Schreibvorgänge mit Quelle, Ziel, Funktionscode, Registeradresse und Datenmenge. Diese Parameter sind für die forensische Rekonstruktion von Sicherheitsvorfällen unabdingbar.

• Leiten Sie Protokolldaten in Echtzeit an Ihr SIEM oder OT-Monitoring weiter und stellen Sie eine konsistente Zeitsynchronisation (NTP/PTP) sicher. Asynchrone Zeitstempel über verschiedene Systeme hinweg erschweren die Vorfallanalyse massiv.

• Alarmieren Sie bei Verhaltensänderungen: Ein Master, der erstmals Schreibbefehle sendet, oder Schreibzugriffe außerhalb regulärer Betriebszeiten erfordern unmittelbare Überprüfung.

Implementierung ohne Betriebsunterbrechung: Monitor, Alert, Enforce

Das Vertrauen des Betriebs geht verloren, wenn eine Firewall produktive Abfragen blockiert. Industrielle Sicherheitsgateways bieten hierfür Monitor- bzw. Learning-Modi: Eine temporäre Allow-Regel an oberster Position protokolliert alle auftretenden Funktionscodes. So wird der reale Datenverkehr transparent, bevor Blockaden aktiv geschaltet werden.

1. Passive Bestandsaufnahme. Zeichnen Sie Modbus-Verkehr via TAP oder SPAN über einen repräsentativen Zeitraum auf – einschließlich Schichtwechseln, Chargenläufen, Wartungsintervallen und Berichtszyklen. Zwei bis vier Wochen sind als Minimum anzusetzen.

2. Erstellung der Kommunikationsmatrix. Dokumentieren Sie für jeden Datenfluss: Master, Server, Unit-ID, Funktionscodes, Registerbereiche, Polling-Raten, Verantwortliche und den betrieblichen Zweck. Diese Matrix ist das zentrale Dokument; die Firewall-Regeln stellen lediglich deren technische Umsetzung dar.

3. Alert-Only-Betrieb. Definieren Sie das Zielregelwerk, belassen Sie neue Regeln jedoch auf „Permit and Log“. Analysieren Sie alle Verbindungen, die im Enforcement-Modus blockiert worden wären.

4. Klärung von Abweichungen mit der Betriebsleitung. Jeder nicht erfasste Datenfluss ist entweder legitim und undokumentiert (Aufnahme in die Matrix) oder unautorisiert (Behebung erforderlich).

5. Validierung im Labor oder in Testzellen. Prüfen Sie Fehlerszenarien: Firewall-Neustarts, Bypass-Umschaltungen, Failover-Mechanismen sowie das Rollback von Regeln.

6. Phasenweises Enforcement. Blockieren Sie zuerst externe Zugriffe (Internet und IT-Verkehr zu Port 502), setzen Sie anschließend die L3/L4-Allowlist durch, gefolgt von der Funktionscode-Filterung für Schreibbefehle und abschließend Registerkontrollen. Jede Phase erfordert ein definiertes Wartungsfenster mit Rollback-Plan.

7. Regelbetrieb und Auditierung. Prüfen Sie das Regelwerk quartalsweise, lassen Sie temporäre Freigaben automatisiert auslaufen und behandeln Sie jeden neuen Kommunikationsfluss als genehmigungspflichtigen Change.

Angriffserkennung hinter der Firewall: Kritische Alarmszenarien

Firewalls erzwingen definierte Richtlinien. Ein passives Monitoring (IDS) erkennt Aktivitäten, die außerhalb dieses Regelwerks liegen. Der Modbus-Analyzer von Zeek protokolliert Quelle, Ziel, Funktionen und Exceptions in der modbus.log; Suricata verfügt über native Modbus-Parser und Regelsyntaxen. Die von Dragos im Rahmen der FrostyGoop-Analyse veröffentlichten Signaturen bieten eine solide Basis. Folgende Szenarien bieten den höchsten Sicherheitsgewinn:

Beispielhafte Suricata-Regeln zur Erkennung. Aktivieren Sie den App-Layer-Parser, definieren Sie die Host-Gruppen und validieren Sie die Signaturen anhand einer Baseline:

Prävention und Erkennung ergänzen sich: Häufig auslösende Sensorregeln zeigen Datenflüsse auf, die entweder legitimiert und im Regelwerk ergänzt oder administrativ unterbunden werden müssen.

Modbus/TCP Security auf Port 802: TLS, Rollen und Implikationen für Firewalls

Die Modbus Organization hat die Spezifikation „Modbus/TCP Security“ 2018 veröffentlicht und seither weiterentwickelt. Sie kapselt die Standard-PDU in TLS und nutzt den registrierten Port 802. Damit werden zwei zentrale Sicherheitsfunktionen integriert:

• Gegenseitige Authentifizierung (mTLS). Server und Client weisen ihre Identität über X.509v3-Zertifikate nach. Die Firewall muss Identitäten nicht mehr anhand flüchtiger IP-Adressen ableiten.

• Rollenbasierte Autorisierung. Die Rolle des Clients wird in einer Zertifikatserweiterung übermittelt (OID 1.3.6.1.4.1.50316.802.1). Dadurch kann die Steuerung festlegen, dass ein Zertifikat mit der Rolle „Operator“ Schreibbefehle ausführen darf, während ein „Viewer“ rein lesenden Zugriff erhält.

Die Spezifikation setzt TLS 1.2 oder neuer voraus und wird von modernen Industrie-Gateways und aktuellen Steuerungen unterstützt. China hat diesen Standard unter GB/T 41868-2022 übernommen. Das Protokoll schließt grundlegende Lücken, verändert jedoch die Kontrollmöglichkeiten auf Netzwerkebene.

Umgang mit dem Sichtbarkeitsverlust bei Verschlüsselung

• Risikobasierte Migration. Migrieren Sie Conduits mit dem höchsten Risiko zuerst (zonenübergreifende Verbindungen, Fernzugriffe). Belassen Sie unkritische Intra-Zellen-Verbindungen vorerst im Klartext.

• Autorisierungsprüfung am Endpunkt. Nutzen Sie Zertifikatsrollen, damit das Endgerät unberechtigte Schreibversuche eigenständig abweist. Diese Endpoint-Härtung wirkt unabhängig von der Prüftiefe der Firewall.

• Inspektion an definierten Übergabepunkten. Wenn Funktionscode-Filterung und TLS parallel zwingend sind, terminieren Sie Sessions auf einem dedizierten Sicherheits-Gateway. Dieses authentifiziert den Client und leitet geprüfte Befehle an das Altsystem weiter. Dieses Muster eignet sich auch für Systeme ohne TLS-Fähigkeit.

• Port 502 nach Migration konsequent deaktivieren. Einige Systeme lauschen standardmäßig auf beiden Ports. Nach der Migration auf Port 802 muss Standard-Modbus auf dem Endgerät abgeschaltet und Port 502 im Conduit gesperrt werden.

• Verhaltensmonitoring beibehalten. Auch verschlüsselte Sessions zeigen Endpunkte, Datenvolumen, Timings und Fehlerbilder. Ergänzen Sie Endpoint-Logs für Operationen, die Netzwerksensoren nicht mehr einsehen können.

• Tunneling für Bestandssysteme (Legacy). IPsec-Tunnel zwischen Zonengrenzen stellen Vertraulichkeit und Integrität her. Nach Terminierung des Tunnels kann die Funktionscode-Inspektion direkt greifen.

Serielles Modbus (RS-485) erfordert getrennte Maßnahmen. Da laut IETF keine standardisierten Sicherheitsmechanismen für serielle Modbus-Verbindungen existieren, sichern die hier beschriebenen Maßnahmen die TCP-Netzwerkpfade und Gateways ab, nicht jedoch die serielle Buslinie selbst.

Fernwartung, Dienstleister und die Netzkante (Perimeter)

• Port 502 unter keinen Umständen direkt im Internet exponieren. Dies betrifft insbesondere Port-Forwardings auf Mobilfunkroutern oder Edge-Gateways. Benötigen externe Systeme Messwerte, müssen diese push-basiert über DMZ-Dienste bereitgestellt werden.

• Dienstleisterzugriffe über Jump-Hosts führen. Erzwingen Sie Multi-Faktor-Authentifizierung (MFA), protokollieren Sie Sitzungen und befristen Sie Zugänge. Der Jump-Host fungiert als einzige autorisierte Quell-IP für nachgelagerte Steuerungen.

• Ausgehenden Datenverkehr von Steuerungen unterbinden. PLCs und RTUs benötigen im Regelfall keinen Internetzugriff. Ein striktes Egress-Deny verhindert Command-and-Control-Verbindungen kompromittierter Geräte.

• Eigene Exposition aktiv prüfen. Prüfen Sie öffentliche IP-Bereiche zyklisch auf Port 502 und 802 über Dienste wie Shodan oder Censys. Externe Sicherheitsanalysten können die Unerreichbarkeit verifizieren. Testen Sie ausschließlich autorisierte Netze und vermeiden Sie unkoordinierte Scans im OT-Betrieb, um Anlagenausfälle durch empfindliche Steuerungen zu verhindern.

• Härtung autorisierter Systeme. IP-Filter sind nur so verlässlich wie die freigegebenen Quellsysteme. Da SCADA-Server bevorzugte Angriffsziele für Pivot-Angriffe darstellen, müssen diese durch Layer-2-Sicherheit (Port Security, ARP Inspection), Application Whitelisting und strenge Kontenrichtlinien gehärtet werden.

Mapping der Kontrollen auf IEC 62443 und NIST SP 800-82

Strukturierte Sicherheitsrichtlinien orientieren sich an etablierten Standards. Ein dokumentiertes Modbus-Regelwerk deckt Kernanforderungen von NIST SP 800-82 Rev. 3 und IEC 62443-3-3 systematisch ab:

Für Betreiber in der EU unterstützt dieses Vorgehen zugleich die Nachweisführung gemäß NIS-2 (Artikel 21), insbesondere in den Bereichen Segmentierung, Protokollierung und Kommunikationssicherheit. In Bezug auf IEC 62443 setzt das Regelwerk die im Rahmen der Zonen- und Conduit-Risikoanalyse (62443-3-2) definierten Vorgaben technisch durch. Eine derartige Dokumentation reduziert den Auditaufwand signifikant.

Zehn typische Fehlkonfigurationen in Modbus-Firewall-Umgebungen

1. „Im Leitsystem gilt: Port 502 Any-to-Any.“ Flache Netze sind die Grundvoraussetzung für Angriffe nach dem Muster von FrostyGoop.

2. Regeln nach Planungsdiagrammen statt nach realem Datenverkehr erstellen. Diagramme spiegeln den Soll-Zustand wider. Paketanalysen zeigen die reale Kommunikation.

3. SCADA-Server per se als vertrauenswürdig einstufen. Sie sind autorisierte Quellen und stellen somit das primäre Ziel für Angreifer dar, um Schadcode weiterzuleiten.

4. Übernahme ungeprüfter Timeout-Werte. Führt zu Verbindungsabbrüchen, fehlschlagenden Abfragen und schwindender Akzeptanz für Sicherheitsmaßnahmen im Betrieb.

5. Diagnosecodes dauerhaft sperren oder dauerhaft erlauben. Die Freigabe sollte zeitlich begrenzt auf Wartungs- und Inbetriebnahmefenster beschränkt sein.

6. Verkehrsinspektion ausschließlich am Perimeter. Kompromittierte Systeme breiten sich lateral (East-West) aus; hier findet auch die Kommunikation zwischen Steuerungen statt.

7. Fehlende Redundanz- und Ausfallkonzepte für Firewalls. Das Verhalten bei Systemfehlern (Fail-Open vs. Fail-Closed) muss pro Zone vorab definiert sein.

8. Temporäre Freigaben ohne Ablaufdatum. Veraltete Regeln für Dienstleister bleiben als offene Einfallstore bestehen. Jede Ausnahme benötigt ein Enddatum und einen Verantwortlichen.

9. Annahme, TLS mache Firewalls überflüssig. mTLS validiert die Identität, steuert jedoch nicht zwingend, welche Register dieser Endpunkt im Detail beschreiben darf.

10. Ausschließliches Logging von Sperrungen (Denies). Erst das Protokollieren autorisierter Schreibbefehle dokumentiert, welche Parameter im Vorfallsfall verändert wurden.

Reifegradmodell für Modbus TCP-Sicherheit

Implementierungsplan (30 - 60 - 90 Tage)

Häufig gestellte Fragen (FAQ) zur Modbus TCP-Sicherheit

1. Welcher Port wird für Modbus TCP verwendet?

Modbus TCP verwendet standardmäßig den bei der IANA registrierten TCP-Port 502. Die TLS-verschlüsselte Variante Modbus/TCP Security nutzt TCP-Port 802.

2. Ist das Modbus TCP-Protokoll sicher?

Nein. Das Standardprotokoll verfügt über keinerlei Mechanismen zur Authentifizierung, Autorisierung oder Verschlüsselung. Die Sicherheit muss vollständig durch nachgelagerte Netzwerkmaßnahmen gewährleistet werden: Segmentierung, Firewall-Richtlinien, Funktionscode-Filterung und Monitoring. Modbus/TCP Security auf Port 802 integriert TLS und rollenbasierte Zertifikate, setzt jedoch voraus, dass Endgeräte und Clients diese Funktion unterstützen.

3. Können Firewalls Modbus-Funktionscodes filtern?

Ja, sofern die Firewall über Applikationserkennung (Deep Packet Inspection) für Modbus verfügt. Industrielle Firewalls und Next-Generation Firewalls ermöglichen die Definition von Allowlists für Funktionscodes sowie teilweise die Prüfung von Registerbereichen und Unit-IDs. Reine Paketfilter können lediglich den gesamten Port freigeben oder sperren.

4. Sollte Port 502 grundsätzlich gesperrt werden?

Port 502 sollte an allen Schnittstellen gesperrt werden, an denen er nicht zwingend erforderlich ist – insbesondere am Internet-Perimeter und an der IT/OT-Grenze. Innerhalb von OT-Zonen ist die Kommunikation meist notwendig; hier ist eine restriktive Allowlist mit Funktionscode-Prüfung einer pauschalen Sperre vorzuziehen.

5. Ersetzt TLS auf Port 802 den Einsatz einer Firewall?

Nein. TLS sichert die Authentizität und Verschlüsselung der Verbindung, und Zertifikatsrollen beschränken Zugriffsrechte. Netzwerksegmentierung, Default-Deny-Regelwerke und Monitoring bleiben unverzichtbar – zumal die Verschlüsselung die Funktionscodes für Standard-Firewalls unsichtbar macht.

6. Wie werden Angriffe auf Modbus TCP zuverlässig detektiert?

Über passives Netzwerk-Monitoring und signaturbasierte Erkennung: Alarmieren Sie bei Schreibzugriffen unberechtigter Quellen, Identifikationsabfragen, Broadcast- und Unit-ID-Sweeps, neuen Master-Systemen, Abfragen außerhalb von Betriebsfenstern, fehlerhaften Paketformaten sowie signifikanten Schwankungen in den Polling-Intervallen. Werkzeuge wie Zeek und Suricata bieten hierfür dezidierte Modbus-Parser.

7. Welche Standards regeln das Firewall-Design in Modbus-Netzen?

Die Normenreihe IEC 62443 (insbesondere Teil 62443-3-3 mit den Anforderungen SR 5.1, SR 5.2, SR 3.1 und SR 6.2) sowie NIST SP 800-82 Rev. 3 definieren die Leitplanken für Zonen, Conduits, Perimeterschutz und Überwachung. Die Spezifikationen der Modbus Organization definieren den Standard des Protokolls und seiner Sicherheitserweiterung.

Ganzheitlicher Schutz für Modbus und Industrieprotokolle mit Shieldworkz

Die Transformation von einem ungesicherten Modbus-Netzwerk zu einer segmentierten, überwachten Infrastruktur erfordert eine strukturierte Methodik: Identifikation der tatsächlichen Kommunikation, Design robuster Zonen und Conduits, präzises Enforcement und die Etablierung kontinuierlicher Detektionsmechanismen. Shieldworkz unterstützt Sie mit spezialisierten Dienstleistungen und Plattformlösungen für SCADA-, OT- und IoT-Umgebungen – von der Sicherheitsanalyse über die Regelimplementierung bis hin zu Monitoring und Incident Response.

• Passive Analyse von Modbus-Datenflüssen, Mastern, Endgeräten und Funktionscode-Nutzungen

• Segmentierungskonzepte und Firewall-Regelwerke gemäß IEC 62443 und NIST SP 800-82

• OT-spezifische Anomalieerkennung, abgestimmt auf Ihre betriebliche Kommunikations-Baseline

• Konzepte für sichere Fernwartung und kontrollierte Dienstleisterzugänge

• Reifegradbeurteilung anhand definierter Security Levels mit priorisierter Roadmap

Möchten Sie Ihre Modbus-Architektur und Firewall-Regelwerke durch Spezialisten prüfen lassen? Vereinbaren Sie ein Fachgespräch mit dem OT-Sicherheitsteam von Shieldworkz für ein technisches OT-Security-Assessment.