Sichere Produktionssysteme

Dienste aus der Cloud haben "Rolling Updates" und der Begriff "Evergreen IT" bedeutet einfach im Grund kontinuierliche Aktualisierungen. Also keine 3-Jahres-Rhytmen mehr für neue Office oder Windows Versionen. Allerdings funktioniert dieses Prinzip nicht mit Produktionsanlagen und diese Seite zeit an einem anonymisierten Beispiel einen möglichen Lösungsweg.

Umfeld

Es war wieder einmal ein Anruf eines Kunden, der das Ende des Erweiterten Supports von Windows 2012 R2 im Oktober 2023 erfahren hat. Dass Windows 2012 damals schon über 10 Jahre alt war und seit 5 Jahren keine Bugfixes mehr erschienen sind, hat nicht gestört, denn es war auch nur ein Dateiserver mit einer Software, die z.B. ein Hochregallager steuert oder auswertet. Es kann aber jegliche andere Einrichtung in der Produktion sein. Ich bin sicher, dass viele Leser nun im Gedanken durchgehen, welche Systeme sie schon jahrelang so "vergessen" haben.

In Industrieanlagen werden Förderbänder, Pressen, Drehbänke und vieles mehr über spezielle Steuerungskomponenten individuell zusammengebaut. Da gibt es dann Druckluft, Hydraulik, Magnete, Lichtschranken, die an Schaltkästen angeschlossen werden, in denen dann Steuerungscomputer von Siemens, Beckhoff, Wago, Phoenix-Contact, Moeller/Eaton, Mitsubishi u.a. ihre Arbeit tun. Einige dieser Systeme können mittlerweile zwar direkt TCP/IP über Ethernet und HTTPS angesteuert werden. Viele nutzen aber noch Feldbusse und Protokolle wie MODBUS/TCP, um dann mit einer Steuerungssoftware auf Windows diese Daten abzufragen, zu visualisieren oder auch für eine Weiterverarbeitung in einen ERP-System o.ä. bereitzustellen.

In meiner Ausbildung 1988-91 habe ich bei Nixdorf noch Computer betreut, die über eine ISA-Steckkarte einen IEEE488-Bus einen Bestückungsautomaten für SMD-Bauteile gesteuert haben. Auch wenn dieses Gerät vermutlich nicht mehr in Betrieb ist, so wissen wir alle, welche Schätzchen bei Firmen seit Jahren oder gar Jahrzehnten ihren Dienst tun. Wenn solche Anbindungen wirklich noch über Hardware-Schnittstellen geht, dann können Sie solche Server auch nicht mal schnell virtualisieren. Aber wer kennt noch ISA, EISA, VESA Local Bus, RS-232, Centronics, PS/2 und andere Schnittstellen, schon viele Jahre nur noch PCI und USB bekannt sind?

Den Sprung zu 32bit oder gar 64Bit haben viele Hersteller zwar schon vollzogen aber das bedeutet nicht, dass dies auch für ältere Systeme angeboten wird. Dann müssen Sie im Extremfall immer noch eine 32bit-Windows Server 2008R-Installation betreiben, damit dort das 16bit Subsystem noch die Software von damals starten kann. Windows 2012 hatte kein 16bit Subsystem mehr. Wenn aber ein Upgrade der Software auf halbwegs aktuelle Versionen auch eine Nachrüstung und ggfls. Umprogrammierung der Steuerungstechnik erforderlich macht, dann wird es schnell sehr teuer.

Also stellt sich die Frage, wie Sie solche Systeme weiter betreiben können.

Ausgangssituation

Stellen Sie sich vor, ein Kunde oder ihre eigene Firma hat folgendes System.

  • Sie haben eine Produktionsumgebung
    Das kann ein Förderanlage, Sortierstation, Fräsmaschinen, Schweißroboter, Hochregallager, Drehbänke o.ä. sein
  • Die Systeme werden mit industriellen Steuerungen (SPS) kontrolliert, die irgendwie mit einem Leitrechner auf Windows-Basis verbunden sind
    Dazu kommt meist ein Feldbus (RS485, Modbus, IEE-488, 1-Wire o.ä.) zum Einsatz.
  • Auf dem Leitrechner unter Windows läuft die Software des Herstellers
    Diese ist die Brücke zwischen der proprietären Schnittstelle zur SPS und einem nachfolgenden System, z.B. Buchhaltung, Überwachung, Auftragssteuerung u.a.
  • Die Schnittstelle zwischen dieser Brückensoftware und ihrer regulären IT ist z.B. FTP, SMB, SMTP.
    Tatsächlich funktionieren viele Systeme einfach per Dateiaustausch und IN/OUT-Ordner. Dateien sind der logische Nachfolger von Lochkarten und das Format MT940 (https://de.wikipedia.org/wiki/MT940) für Bankenkommunikation gab es schon, ehe ich 1992 in der Siemens Finanzabteilung die Banksysteme betreut habe und wird wohl 2025 erst endgültig abgeschafft.

So ein System kann jahrelang oder sogar Jahrzehnte laufen. Es soll z.B.: immer noch Stanzmaschinen geben, die mit Windows 95 gesteuert werden und die Werkzeugdaten als auch Ergebnisse der Pressung als Datenträgerbegleitzettel übermitteln müssen.

Wir haben also immer wieder Systeme, die so alt sind, dass es vom Hersteller keinen Support mehr gibt aber im Grund funktionieren und vielleicht noch nicht einmal komplett abgeschrieben sind. Wir reden hier nicht von von Mobiltelefonen und Notebooks mit 2-5 Jahren oder geringwertige Wirtschaftsgüter. Eine Presse kann schon mal auf 14 Jahre abgeschrieben werden.

Natürlich kann ich als Firma ein Gerät auch früher als "defekt" aussortieren und den Restwert nach Abzug des Schrottpreis sofort ansetzen aber dann muss ich in einen Nachfolger investieren. Aber nur weil eine Maschine laut AFA einen Restwert von 1€ hat, muss sie ja nicht ersetzt werden. Solange Sie ihre Leistung erbringt und nicht ausfällt, verdient sie ja nun erst recht. Lang nutzen ist nicht nur betriebswirtschaftlich, sondern auch ökologisch und energetisch oft die günstigere Wahl. Ich schreibe diese Webseite 2003 auch auf einem Lenovo T480s aus dem Jahre 2018, also 5 Jahre alt, obwohl Computer eine AFA von 3 Jahren haben.

Also müssen wir uns Gedanken machen, wie wir so ein System nun "sicher" solange weiter betreiben, bis es abgelöst wird.

Die Frage stellt sich aber nicht nur bei Systemen, die noch lange laufen, sondern der sichere Betrieb ist natürlich auch für aktuelle Systeme nicht nur von installierten Updates und aktuellen Virenscannern abhängig.

Überlegung

Ein komplett isoliertes System ist nicht angreifbar und kann sich eigentlich nur selbst durch Softwarefehler oder Hardwaredefekte stören. Der ein oder andere wird sicher noch die Sorgen vor der Jahr 2000 Umstellung mitbekommen haben und selbst bei Exchange passieren Fehler einfach aufgrund einer Zeit. (Siehe Exchange Y2K22 Bug). Aber die größere Gefahr besteht natürlich, sobald ein System mit anderen Systemen kommuniziert und die Schnittstellen ein Einfallstor bieten. Selbst eine Beschränkung auf authentifizierte Kommunikationspartner ist keine 100%-Sicherheit. (Siehe auch Storm-0558 und Storm 0588 Nachbereitung).

Haben wir früher nur zwischen Intranet, DMZ und Internet unterschieden und das Verfahren später auf Tier 0/1/2 Security mit eigenen Priviledged Admin Workstations erweitert, so ist heute "ZeroTrust" das neue Mantra. Genau genommen stimmt es aber und Windows hat daher schon lange seine Firewall per Default eingehend "zu" und Software muss entsprechende "Allow-Regeln" einrichten. Ein Windows Server ohne Funktionen ist nicht einmal per PING erreichbar. Erst z.B. die File-System-Server-Rolle aktiviert auch ICMP.

So sollten wir auf allen Systemen verfahren und nur Verbindungen annehmen, die erforderlich sind. Das beschränkt sich nicht nur auf die Ports sondern könnte auch die Remote-IP mit einbeziehen. Im klassischen Domain-Netzwerk wäre so eine Liste aber aufwändig zu pflegen und ausgehende Verbindungen sind eh kaum reglementiert. Es stellt sich dann auch die Frage, wie "gut" denn die Firewall eines alten Systems ist und wie zuverlässig die genutzten Protokolle abgesichert werden können. Wie ich auf Alte Clients Windows 2008 und Alte Clients Windows XP exemplarisch beschrieben habe, gibt es ja auch Systeme, die nur SMB1 und nicht SMB2/3 unterstützen und damit bei einer SMB1 Abschaltung auf ein Problem laufen. Auch der Zwang zur TLS 1-2-Verschlüsselung (TLS 1.2 Enforcement) die die Kerberos RC4 Abschaltung ist nicht möglich, wenn Sie so alte Systeme integrieren müssen. Da natürlich auch Dritthersteller, insbesondere Antiviren-Produkte so alte Systeme nicht mehr unterstützen, würden sie eine aktive Malware nur indirekt an den negativen Auswirkungen erkennen.

Es gibt also nicht nur dem Aspekt einer Absicherung des Altsystems gute Gründe dies zu segmentieren, sondern wenn die Anbindung dieser System geregelt ist, können Sie in ihrem regulären IT-Netzwerk die Sicherheitsbasis erst deutlich anheben. Es gewinnen daher beide Welten: Die alten Server, die ohne weitere Updates und mit alten Protokolle weiter betrieben werden sollen und die regulären Systeme, die endlich keine Kompatibilität zu alten Gegenstellen bewahren müssen. Alte und neue Systeme müssen gegeneinander geschützt werden, denn auch aktuell gepatchte Systeme sind nicht fehlerfrei.

Umbauplanung

Wie Sie ihr System nun umbauen, bedarf einer individuellen Betrachtung und Entwicklung einer Lösung. Dies hier ist nur ein exemplarischer Vorschlag einer Vorgehensweise zu dem oben aufgeführten Muster. Der Ansatz basiert darauf, die Systeme in abgeschottete Netzwerke (VLANs) zu verschieben bei denen Firewalls die Verbindungsmöglichkeiten auf das absolute Minimum zu beschränken und die genutzten Protokolle und Schnittstellen ggfls. auf sicherere Wege geändert werden. Dazu gehört natürlich auch, dass der Server nicht mehr Mitglied im regulären Active Directory ist. Eine Domainmitgliedschaft erfordert sehr viele offene Ports zwischen Client und Server und widerspricht einer minimierten applikationsbezogenen Kommunikation.

Ermitteln der Kommunikationsbeziehungen und Anforderungen

Zuerst schauen wir uns den Server und seine Verbindungen an:

Thema

Beschreibung

Erledigt

Wie kommuniziert die Software?

Dazu gehören nicht nur die bekannten Schnittstellen zum zu Produktion und der Weiterverarbeitung sondern auch alle anderen Protokolle. Gibt es LDAP-Server, die von der Software gefragt werden oder liegen Daten auf anderen SQL-Servern? Wichtig ist hier auch, wie die Software die Gegenstellen findet. Nutzt sie schon DNS oder sind in Konfigurationsdateien vielleicht IP-Adressen statisch hinterlegt?

Active Directory und Anmeldungen

Mit welchen Anmeldekonten erfolgen die Zugriffe und ist ein Betrieb ohne Active Directory möglich? Als "Workgroup"-Computer fallen viele Protokolle (DNS, NETLOGON, Kerberos, SMB) weg aber auch einige nützliche Dinge wie z.B. Gruppenrichtlinien. Auch wird das LAN-Interface nicht mehr als "Domain" sondern als "Internet" klassifiziert.

Aber auch die Software selbst ist zu prüfen, d.h. Dienst läuft schon mit "LocalSystem", "NetworkService" oder einem lokalen Konto oder kann darauf umgestellt werden.

Hardware

Läuft der Server noch auf Physik, weil z.B. spezielle Schnittstellenkarten verbaut sind? Dann sollten Sie über Hardware-Reserven nachdenken. Ohne Spezialhardware könnte in dem Zuge auch eine Migration zu einer Virtualisierung erfolgen. Prüfen Sie aber, ob das Gast-Betriebssystem auch unterstützt wird.

API-Schnittstelle zum regulären Netzwerk

Die gängigste Schnittstelle für alte Systeme ist nun mal "Dateifreigaben über SMB". Dann ist die Richtung des Zugriffs erforderlich. Wenn die Altsoftware die Daten lokal bereitstellt, dann muss die nächste Station die Daten regelmäßig abrufen oder hochladen und muss sich dazu mit einem lokalen Konto anmelden. Umgekehrt müsste die Altsoftware weiterhin auf das reguläre Netzwerk zugreifen. Beides ist möglich, wenn sich die Server auflösen, über Firewall Regeln erreichen und sich erfolgreich anmelden können. Unschön ist dabei natürlich, dass bei älteren Systemen weiter SMB1 genutzt wird.
Sie können natürlich prüfen, ob sie den "Dateitransfer" auf modernere Schnittstellen umstellen, die auch weniger Ports benutzt. Das kann durchaus SFTP/FTPS oder WebDav sein.

Die Liste ist nicht zwingend vollständig. Wenn Sie unsicher sind, dann fragen Sie den Hersteller oder Consultants mit Erfahrung bei Altsystemen.

Umbau

Sie sollten nach der IST-Aufnahme einen Plan haben, wie sie das System zukünftig sicher betreiben wollen und dann an die Umsetzung gehen. Die Zielumgebung könnte wie folgt aussehen:

Für den Umbau müssen wir natürlich etwas Zeit aufwenden. Hier ein exemplarischer Ablauf:

Thema

Beschreibung

Erledigt

VLAN einrichten

Wir wollen diese System ja aus dem Hausnetzwerk raus haben und in eine eigenen IP-Subnetz durch eine Firewall segmentieren.

  • VLAN-Nummer festlegen
  • VLAN auf den Switchen (Trunks, Ports) konfigurieren
    d.h. auf den Uplinks muss das neue VLAN als "tagged" addiert werden.
    Bei virtuellen Servern müssen Sie meist das VLAN noch als virtuellen Switch einrichten und auf due physikalischen Karten binden.
  • IP-Adressbereich für das VLAN festlegen
  • Ggfls. DHCP/BootP Funktionen zur Adressvergabe im VLAN

Nun haben wir ein virtuelles Netzwerk aber noch keine Außenverbindung aber auch noch keine Clients im Netzwerk

Firewall

Der Nächste Schritt ist die Konfiguration der Firewall, die zugleich Router für den Verkehr zu diesem Netzwerk ist.

  • VLAN in der Firewall als Interface einrichten
  • Subnetz im IP-Routing bekannt geben
  • Regeln für Kommunikation „ERP -> Server“ für das erforderliche Protokoll einrichten
  • Ggfls. Regeln für die Administration einrichten, z.B. RDP aus dem Admin-Netz auf den Server oder Verwaltung über Hyper-V-Konsolen

Sie können ja Testweise einen Test-Server schon mal in das VLAN mit der zukünftigen IP-Adresse konfigurieren und die API-Zugriffe prüfen.

Server umziehen

Nun kommt der vielleicht heikelste Moment des Serverumbaus

  • Lokales Administrator-Konto anlegen bzw. Kennwort für das Konto verifizieren
    Wenn der Server aus der AD-Domain entfernt wurde, ist das ihr späterer Zugang
  • Lokales ERP-Dienstkonto für den ERP-Zugriff anlegen
    Wenn das ERP-System per SMB auf den Server zugreift, muss es sich ja auch anmelden
  • ERP-Dienstkonto auf dem Dateishare und NTFS berechtigen
  • DNS
    Wenn der Server aus dem AD entfernt wird,, kann er sich selbst nicht mehr im DNS des Active Directory dynamisch eintragen. Bei Bedarf addieren sie einfach einen statischen Eintrag. Eine Namensauflösung anderer Systeme per DNS ist oft nicht erforderlich oder kann für die wenigen Ziele per HOSTS-Datei vergeben werden.
  • Schnappschuss oder Backup machen
  • Applikationsdienste beenden und Server aus der Domain entfernen
    Nun ist er einer "Workgroup". Es gibt Firmen, die betreiben extra einen Forest für "Altsysteme", um sich die Administration zu erleichtern. Das müssen Sie selbst abwägen.
  • Server ins VLAN umstellen
    Bei physikalischen Server müssen sie den Switch-Port auf das neue VLAN als "Untag" einrichten.
    Bei virtuellen Servern ist es meist eine Konfiguration der virtuellen Netzwerkkarte auf dem Host
  • IP-Adresse (Statisch / DHCP) und Namensauflösung
    Der Server braucht im neuen VLAN natürlich seine neue IP-Adresse. Meist wird sie statisch vergeben.
  • Computer booten, damit AD-Leave aktiv wird. Lokale Anmeldung als Admin
  • Dienste starten und kontrollieren, ob auf dem Server soweit wieder alles läuft

Verbundene Systeme

Der Server ist nur ein Teil des Systemverbunds.

  • ERP zu Server/Server zu ERP
    Sie müssen z.B. ihre ERP-Software nun natürlich so einrichten, das Sie den Server wieder nutzt., d.h. ggfls. neue IP-Adresse und veränderte Zugangsdaten oder Protokolle
  • Server zu SPS/SPS zu Server
    Auf auf der internen Seite sind vermutlich Anpassungen erforderlich. Das kann sogar sehr umfangreich sein, wenn Sie die SPS-Systeme in dem Zuge auch in das neue VLAN umziehen wollen.
  • Sonderfall SMB
    Wenn die Dateien per SMB übertragen werden und der Leitrechner kein SMB2 kann aber sie im regulären LAN SMB1 verbieten wollen, dann könnte eine "SMB-Bridge" helfen. Sie können z.B. mit Linux einen SMB2-Server aufsetzen, der per SMB1 die Freigabe Daten vom Leitrechner mounted und sebst freigibt.

Nacharbeiten

Server und die SPS-Systeme sind nun in ihrem eigenen VLAN und gegen Zugriffe aus dem regulären Netzwerk und natürlich dem Internet durch die Firewall abgeschottet. Das gilt auch für die Gegenrichtung. Aber der Server ist immer noch wichtig und daher sind weitere Dinge anzupassen, wie z.B.:

  • Monitoring
    Der „alte“ Server mag zwar keine Windows Updates oder AV-Updates mehr bekommen, aber im Monitoring sollte er dennoch weiter überwacht werden. Auch bei einem alten abgeschotteten Server können Festplatten volllaufen und bei Hardware ist erst recht ein Blick auf das System erforderlich.
  • Backup
    Auch eine “Datensicherung” ist weiter erforderlich. Erfolgt diese über den Hyper-V-Host, dann ändert sich erst einmal nichts. Wird der Server über Agenten gesichert, müssen auch hier Konfiguration des Server, der Software und Firewall ggfls. angepasst werden.
  • Härtung des regulären Netzwerks
    Wenn Sie all die alten unsicheren Systeme in eigene Zellen verbannt haben , könnten sie ja nun im regulären Netzwerk ja mal TLS1. erzwingen, SMB1 und RC4 abschalten, RPC und LDAP-Signing einschalten und unverschlüsselte Verbindungen per LDAP u.a. unterbinden.

Nach all den Schritten sollte der Server in seinem eigenen Subnetz weitestgehend isoliert stehen und nur die absolut notwendigen Zugriffe durch die Firewall erlaubt sein. Natürlich muss man zusätzlich sicherstellen, dass die zugreifenden Systeme nicht kompromittiert werden und damit als Sprunghost dienen können. Zudem muss es unmöglich oder zumindest sehr erschwert werden, dass jemand ein fremdes System in dieses VLAN mit den unsicheren Systemen bringt. So eine Konfiguration macht es natürlich auch nicht einfacher, wenn externe Dienstleister das System supporten müssen o.ä. Stellen Sie auch sicher, das bei Probleme z.B.: die Installationsdatenträger und Quellen weiterhin vorhanden sind. Wir dürfen nicht davon ausgehen, dass Treiber etc. nach 10+ Jahren noch im Internet zu finden sind oder sie finden nur Kopien mit zweifelhaftem Inhalt.

Und dann wünsche ich ihrem Server noch einige schöne Jahre in seiner "Zelle mit Durchreiche".

Weitere Links