Die bereits seit 1996 von der OPC Foundation herausgegebenen und stetig weiter entwickelten OPC-Spezifikationen stellen heute unverzichtbare offene Anwendungsschnittstellen für einen standardisierten, herstellerübergreifenden Datenaustausch in der Prozessautomatisierung bereit. Besonders die Spezifikationen zur Übertragung von Echtzeitwerten (OPC DA, Data Access), Alarmen und Ereignissen (OPC A/E, Alarms & Events) und historischen Werten (OPC HDA, Historical Data Access) werden intensiv genutzt. Steuerungen, Mensch-Maschine-Schnittstellen zum Bedienen und Beobachten sowie Archivierungs-Server (Data Historians) werden dabei nicht nur untereinander im Prozess-Netzwerk, sondern auch mit Datenbanken, ERP- und anderen Business-Systemen im Unternehmens-Netzwerk verbunden.
Vielerorts ist OPC dadurch inzwischen zu einer kritischen Komponente der Produktionssysteme geworden. Ausfälle oder Manipulationen der OPC-Kommunikation hätten dort gravierende Folgen: vom temporären oder dauerhaften Verlust historischer Daten über falsche oder fehlende Visualisierung für das Anlagenpersonal bis zum Verlust der aktuellen Produktion und der weiteren Produktionsfähigkeit.
Das klassische OPC der ersten Generation basiert auf der Microsoft-Schnittstelle DCOM (Distributed Component Object Model) zum Dienst RPC (Remote Procedure Call) von Windows-Systemen. Dieser Abstammung verdankt OPC im Hinblick auf seine Sicherheit und kontrollierte Verwendung im Netzwerk leider einige problematische Eigenschaften, die bis heute – wenn überhaupt – nur schwer zu beherrschen sind. Mit der OPC Unified Architecture (OPC UA) steht eine aktuellere Generation von OPC auf neuen Grundlagen zur Verfügung, die diese Defizite vermeidet. Dafür wurde DCOM zugunsten einer Service-orientierten Architektur mit wahlweisem Datentransport über ein binäres TCP-Protokoll oder das Web Services-Protokoll SOAP abgelöst.
Die Durchdringung der installierten Basis mit dieser neuen Technologie schreitet aber nur langsam voran. Insbesondere in Bestandsanlagen wird klassisches OPC noch viele Jahre weiter genutzt werden. Die Netzwerksicherheit dieser OPC-Anwendungen ist schwach und ihre Absicherung durch Firewalls bislang wenig wirksam. Beides lässt sich nun deutlich verbessern.
Erblast DCOM/RPC bietet Angriffsflächen
Das Distributed Component Object Model (DCOM) ist eine Software-Architektur von Microsoft zur Entwicklung netzwerkfähiger komponentenbasierter Anwendungen. DCOM nutzt Remote Procedure Calls (RPCs), um Aufrufparameter und Ergebnisse zwischen Client- und Server-Komponenten im gleichen Netzwerk auszutauschen. RPC-Implementierungen standen über die Jahre immer wieder wegen Sicherheitslücken in der Kritik und bleiben ein Angriffspunkt mit potenziellen Schwächen. Vor allem problematisch ist aber weiterhin, dass RPC in seiner gängigen Standard-Konfiguration dynamische Ports verwendet. Ein Client/Server-Dialog in OPC besteht damit nach seiner Eröffnung über den DCOM Port TCP 135 aus mehreren Verbindungen in wechselnder Richtung mit vorher nicht statisch bekannten Ports. Das macht es bei herkömmlichen Stateful Inspection Firewalls unmöglich, wirksame Firewall-Regeln zur Filterung der OPC-Kommunikation zu definieren.
Manche OPC-Server lassen sich auf einen statischen TCP-Port als Endpunkt beschränken, aber nicht alle OPC-Produkte respektieren solche statischen Ports. Alternativ lässt sich über die Windows Registry das Transport-Protokoll für DCOM/RPC auf TCP und einen bestimmten Port Range beschränken. Das ist allerdings – wie die möglichst sichere Konfiguration von OPC und DCOM generell – einigermaßen komplex und macht das Problem der dynamischen Ports nur etwas kleiner, ohne es wirklich zu lösen. Entsprechend ist die installierte Basis geprägt von zu freizügigen DCOM-Zugriffsrechten und für OPC notgedrungen weit geöffneten Firewalls, die bestenfalls nach den IP-Adressen der bekannten Clients und Server filtern.
Stateful Firewall und NAT Routing für OPC
Heute gebräuchliche Stateful Inspection Firewalls untersuchen nur die Header von TCP/IP Netzwerk-Paketen für die Filterung und das so genannte Connection Tracking von Verbindungen, das heißt für die Prüfungen, ob eine neu zu eröffnende Verbindung zulässig oder ein Paket Bestandteil einer bereits als zulässig erkannten Verbindung ist. Bei OPC scheitern sie an genau diesem Connection Tracking, da Client und Server nach Absprachen, die sie über die Nutzdaten (Payload) der zwischen ihnen ausgetauschten Pakete treffen, dynamisch Ports und Verbindungsrichtung wechseln. Aus dem gleichen Grund scheitern auch herkömmliche Verfahren der Adressumschreibung (NAT, Network Address Translation): Diese wirken wiederum nur auf die Adressen in den Headern der Pakete, die OPC-Teilnehmer orientieren sich aber an den in den Nutzdaten übermittelten Adressen, die von den NAT-Verfahren nicht mit umgeschrieben werden.
Versetzt man die Firewall aber in die Lage, auch die Nutzdaten der durchfließenden Pakete zu prüfen und auszuwerten, wird ein Connection Tracking auch für Protokolle wie OPC möglich. Die Absprachen zwischen Client und Server nach einer zulässig eröffneten Verbindung werden von der Firewall verfolgt und zu deren Abwicklung dann dynamisch entsprechende weitere Ports geöffnet und wieder geschlossen. Treibt man diese Deep Packet Inspection (DPI) genannte Technik noch einen Schritt weiter, kann sie die Nutzdaten der Pakete nicht nur prüfen, sondern bei Bedarf auch verändern. Ganz trivial ist das allerdings nicht, da die Konsistenz von OPC-Paketen durch darin enthaltene Prüfsummen gesichert wird.
Mit dem mGuard OPC Inspector hat Innominate für die Firewall seiner industriellen mGuard Security Appliances ein solches Deep Packet Inspection-Modul für OPC realisiert und mit verschiedenen Kombinationen marktgängiger OPC-Clients und -Server erfolgreich getestet. Es analysiert Pakete an den Zielport TCP 135 und erkennt OPC-Classic-Kommunikation. Um eine solche durch die Firewall hindurch zu ermöglichen, muss statisch nur noch die initiale Verbindung vom Client zum TCP Port 135 des Servers erlaubt werden. Der OPC Inspector übernimmt dann das Connection Tracking und die weitere dynamische Konfiguration der Firewall. Dabei ist die Lebensdauer dieser dynamischen Regeln, das heißt das Zeitfenster für die Antwort der jeweiligen Gegenseite, durch den Anwender konfigurierbar. Eine Konsistenzprüfung stellt sicher, dass über TCP Port 135 und alle weiteren dynamisch geöffneten Ports nur OPC-Classic-Verkehr zugelassen wird. Mehrere OPC-Server und -Clients können sich zu beiden Seiten der mGuard Firewall mit dem OPC Inspector befinden und zeitgleich über diese kommunizieren.
Das OPC-Inspector-Modul ist sowohl im Stealth-Modus (Bridging) als auch im Router-Modus (Routing) der mGuard Firewalls einsetzbar. Eine Besonderheit gerade auch für erfahrene OPC-Anwender: Beim Routing kann das Modul auch NAT-Verfahren wie Maskierung oder 1:1 NAT auf den OPC-Traffic anwenden. Die Adressen werden dafür samt zugehörigen Prüfsummen auch in der Payload der Pakete passend umgeschrieben.
Aufgrund seiner weiten Verbreitung in langlebigen Bestandsanlagen besteht also noch für viele Jahre Bedarf, den Einsatz von OPC-Classic netzwerktechnisch sicherer und flexibler zu gestalten. Industrielle Firewall-Router mit Deep Packet Inspection (DPI) für OPC erreichen dies, bei gleichzeitig vereinfachtem Regelwerk. Die DPI-Technik hat weitere interessante Potenziale, etwa die Filterung anderer Industrial Ethernet-Protokolle, auch mit Payload-basierten Regeln zur gezielten Kontrolle von Lese- und Schreibzugriffen auf bestimmte Datenpunkte oder Übermittlung bestimmter Befehle.
.jpg "Flanschen: Dichtheitsprüfung für Wasserstoff")
