Rendezvous in der DMZ Fernwartung und Firewalls: Bestandsaufnahme und Empfehlung

Ordnungsmerkmale

erschienen in: <kes> 2005^#4, Seite 42

Rubrik: Management und Wissen

Schlagwort: Fernwartungszugänge

Zusammenfassung: Für Fernwartungslösungen gibt es verschiedene Möglichkeiten von "ziemlich offen" bis hochsicher. Um nicht nur externe Angreifer abzuwehren, sondern auch den Zugang des "Fernwarters" auf das notwendige Maß zu beschränken, empfiehlt sich eine zusätzliche Netztrennung und gegebenenfalls auch ein spezieller Übergang in der DMZ.

Autor: Von Bernhard Schneck, Kirchheim

Fernwartungszugänge zu internen Objekten sind heutzutage oft eine zentrale Anforderung: Die Anwender komplexer Systeme von beispielsweise Branchen-Softwarelösungen bis hin zu Computertomographen oder auch Druckmaschinen und Turbinen erwarten, dass die Anbieter den reibungslosen und nahezu unterbrechungsfreien Betrieb der teuren Installationen garantieren. Dazu benötigen die Hersteller einen Remote-Zugriff auf die beim Kunden installierten Systeme: Jederzeit müssen Daten abgerufen und kontrolliert, erforderliche Wartungsarbeiten durchgeführt und Störungen umgehend behoben werden können. Eventuell bestehen auch Hersteller selbst zur Softwarepflege auf einem Remote Access.

Fernwartungszugänge vom Hersteller-Support via Datenleitung zur betreuten Installation sind immer eine Herausforderung für die IT-Sicherheit, denn in der Regel befindet sich das angesteuerte System ja innerhalb eines Kundennetzes, das mit Firewalls nach außen abgeschottet wird. Eine partielle Öffnung dieser Netzwerkgrenze für den Remote-Zugriff ist unvermeidlich, sollte aber so gering wie möglich gehalten werden. In der Praxis übliche Verfahrensweisen gewähren jedoch oft erheblich mehr Zugriffsmöglichkeiten für Externe als eigentlich notwendig wäre. Auch in puncto Authentifizierung des zugreifenden Dienstleisters zeigt sich nicht selten eine ungenügende Sicherheit.

Nach der Diskussion zweier gängiger Fernwartungslösungen mit typischen Sicherheitsmerkmalen und -mängeln sollen an dieser Stelle daher anschließend zwei Wege gezeigt werden, wie man Lösungen mit höherem Sicherheitsniveau erreichen kann.

Einwahl und Durchgriff

Eine noch immer häufig genutzte Lösung ist die Einwahl über einen Dial-up-Router per Modem- oder ISDN-Verbindung in das Anwendernetz. Weitgehend analog dazu ist die Freischaltung der IP-Adresse des Hersteller-Supports (Absender) zur betreuten Maschine (Ziel) auf der Haupt-Firewall. Der Hersteller-Support kann also wie gewünscht via Modem/ISDN oder per Internet auf die Installation oder – je nach Implementierung – auch unnötigerweise auf weitere Teile im Anwendernetz zugreifen (vgl. Abb. 1). Diese Lösung beachtet kaum die Anforderungen der IT-Sicherheit und führt zu folgenden Risiken, die das gesamte Kundennetz bedrohen:

Der Hersteller-Support wird beim Zugriff meist nur anhand der Telefonnummer (Calling Line Identification Presentation, CLIP) oder IP-Adresse authentifiziert. Diese Daten lassen sich jedoch von unbefugten Dritten problemlos fälschen (Spoofing), um – zumindest teilweisen – Zugang zum Anwendernetz zu erhalten.
Die meist unverschlüsselte Fernwartungsverbindung kann abgehört und durch Angreifer "übernommen" werden (Session Hijacking).
Eingedrungene Angreifer oder illoyale Mitarbeiter des fernwartenden Anbieters können in der Regel vom betreuten Rechner aus auf weitere Systeme im Anwendernetz zugreifen.
Bei Fehlern im Dial-up-Router beziehungsweise der Firewall können Angreifer sogar ohne Umweg über den Wartungsrechner direkt auf andere Systeme im Anwendernetz zugreifen.

Abbildung 1: Standardlösung für Fernwartungszugriffe ist ein – meist unverschlüsselter – Zugang via Dial-in oder durch die Firewall hindurch.

IPsec-VPN-Zugriff

Ein Mindestmaß an Sicherheit gegenüber Bedrohungen durch Dritte bietet eine Fernwartungslösung per Virtual Private Network (VPN), meist über IPsec-Protokoll realisiert: Zum einen schützt eine starke Verschlüsselung die Kommunikation, sodass die Verbindung im Internet nicht abgehört und übernommen werden kann. Zum anderen erfordert IPsec beim Verbindungsaufbau eine Authentifizierung mittels X.509-Zertifikaten oder vorher vereinbarten Schlüsseln, was sicherstellt, dass es sich bei der Gegenstelle tatsächlich um das Gateway des Hersteller-Supports handelt.

Abbildung 2: Fernwartungszugänge per IPsec sind zwar verschlüsselt, bergen aber die Gefahr von Netz-Koppelungen (siehe Text).

Die Lösung mit IPsec behebt also die ersten beiden Mängel der zunächst geschilderten "Standardlösung" und grenzt – eventuell jedoch nur scheinbar – externe Angreifer aus. Das Problem der unbeschränkten Zugriffsmöglichkeiten für den Fernwarter im Anwendernetz wird mit diesem Verfahren aber nicht gelöst.

Auf der anderen Seite eröffnet IPsec jedoch das zusätzliche Risiko ungewollter Netz-Koppelungen: Als Protokoll der Vermittlungsschicht (ISO/OSI-Layer 3) betrachtet IPsec alle angeschlossenen Bereiche zunächst als einheitliches Netzwerk. Ein Hersteller-Support, der Installationen bei mehreren Anwendern über IPsec-Verbindungen betreut, muss mittels sorgfältiger Konfiguration die unterschiedlichen Kundennetze voneinander trennen. Wenn dabei Fehler unterlaufen, können unbeabsichtigte Koppelungen zwischen Anwendernetzen entstehen, sofern nicht dort entsprechende Firewall-/VPN-Gateway-Regeln einen entsprechenden Zugriff verhindern. Da viele Hersteller auf bestimmte Branchen spezialisiert sind, besteht die reelle Gefahr, dass durch nachlässige IPsec-Konfiguration Netze konkurrierender Unternehmen zusammengeschaltet und direkte Zugriffe auf Systeme und Daten eines Wettbewerbers möglich werden.

Isolation und SSH-Tunnel

Für gehobene Sicherheitsansprüche bei der Fernwartung sollte man den unmittelbaren Wartungsbereich mit einer zusätzlichen Firewall vom übrigen Anwendernetz isolieren. Diese Firewall stellt sicher, dass der Hersteller-Support nur zu der betreuten Installation gelangt, von dort aber alle Wege in andere Netzbereiche versperrt bleiben. Zugriffe von anderen Systemen im Anwendernetz auf die separierte Installation sind hingegen (üblicherweise) zulässig und per Firewall-Konfiguration zu steuern.

Abbildung 3: Eine zusätzliche Firewall und die Verbindung per SSH-Tunnel bilden eine sicherheitsbewusste Fernwartungslösung.

Sofern man das zusätzlich eingebrachte Firewall-System im Bridging-Modus auf der Verbindungssicherungsschicht (ISO/OSI-Layer 2, Data Link Layer) einsetzt, sind für diese Lösung keine Veränderungen in der logischen Netzwerkstruktur erforderlich. Beim Betrieb im Routing-Modus auf Layer 3 (Vermittlungsschicht, Network Layer) wäre hingegen eine Restrukturierung in zwei Subnetze erforderlich. Alternativ könnte man auf Layer 3 mit Network Address Translation (NAT) arbeiten, falls die IP-Umsetzung keine Probleme für die Anwendung(en) des Wartungsobjekts mit sich bringt.

Für die Verbindung von Hersteller-Support zur lokalen Firewall bietet sich eine Secure-Shell-Session an (SSH). Gegenüber IPsec hat dieses Protokoll den Vorteil, dass es eine durchgängige Verbindung bis zum Ziel innerhalb des Anwendernetzes – also der Segment-Firewall – ermöglicht. So kann der Wartungszugriff nicht "vom rechten Weg abkommen" und landet direkt auf der Firewall im Wartungssegment.

Durch einen SSH-Tunnel kann der Fernwarter mit beliebigen TCP-basierten Anwendungen auf die betreute Installation zugreifen. Dabei gewährleistet das SSH-Protokoll analog zu IPsec eine starke Verschlüsselung für die Datenübertragung via Internet. Darüber hinaus bietet es im Vergleich zu IPsec zwei weitere Vorzüge: Zum einen ermöglicht es eine einfache individuelle User-Identifizierung, beispielsweise per Passwort oder Token; eine derartige personenbezogene Komponente erhöht zudem deutlich die Hürde für den missbräuchlichen Zugriff durch autorisiertes Personal. Und zweitens lässt SSH bei der Weiterleitung von TCP-Verbindungen durch die Tunnel nur explizit freigeschaltete Verbindungen zu – ungewollte Netz-Koppelungen wie bei IPsec sind hier somit ausgeschlossen.

Für diese Fernwartungslösung sind als zusätzliche Elemente ein SSH-Gateway und eine Paketfilter-Firewall erforderlich, die (wie bereits beschrieben) möglichst auch als Bridge arbeiten kann – einige Sicherheits-Appliances vereinen auch beide Funktionen in einem kombinierten System (z. B. GeNUBox). Dieses Szenario minimiert bereits weitgehend die Sicherheitsrisiken für das Anwendernetz – als Restrisiko verbleiben vor allem Fehlfunktionen oder -konfigurationen der Haupt-Firewall an der äußeren Netzwerkgrenze.

Rendezvous-Server

Um eine noch höhere Sicherheit zu implementieren, kommt die Fernwartung über einen "Rendezvous-Server" gänzlich ohne direkten Durchgriff des Herstellers in das Anwendernetz aus: Eine Verbindung zum Wartungsobjekt kommt dann nur zustande, wenn sowohl der Hersteller-Support von außen als auch ein Administrator des Anwenders von innen zur gleichen Zeit aktiv einen Tunnel zum Rendezvous-Server aufbauen. Neben diesem Server, der in der so genannten demilitarisierten Zone (DMZ) steht, ist – wie schon in der zuvor beschriebenen Lösung – eine SSH-/Firewall-Appliance zur Abtrennung des eigentlichen Wartungsbereichs erforderlich.

Abbildung 4: Hochsichere Lösung zur Fernwartung über Rendezvous-Server

Unangemeldete Zugriffe durch den Fernwarter sind bei dieser Lösung nicht mehr möglich, da Verbindungsversuche über die DMZ hinaus von der Haupt-Firewall konsequent geblockt werden. Der Aufbau einer Fernwartungsverbindung läuft dann in folgenden Schritten ab:

Der Hersteller-Support baut einen SSH-Tunnel zum Rendezvous-Server in der DMZ des Kunden auf und authentifiziert sich dort. Der SSH-Client leitet alle benötigten TCP-Ports per "local forwarding" zum Rendezvous-Server um.
Der Administrator des Anwendernetzes baut einen Tunnel von der SSH-/Firewall-Appliance im Wartungsbereich zum Rendezvous-Server in der eigenen DMZ auf. Für alle zuzulassenden TCP-Ports existieren hier Remote-Forwarding-Einträge auf das Wartungsobjekt. Bei Bedarf kann vor dem Aufbau dieses SSH-Tunnels ein alternativer Filterregelsatz aktiviert werden, der das Wartungsobjekt während des Fernzugriffs durch den Hersteller – anders als im Regelbetrieb – stärker oder sogar vollständig vom restlichen Anwendernetz trennt.
Der Hersteller-Support greift durch beide Tunnel, die auf dem Rendezvous-Server aufeinanderstoßen und eine durchgängige Verbindung bilden, auf die betreute Installation zu.

Die benötigte Kombination aus Rendezvous-Server und Firewall-Bridge lässt sich auch mit den "Bordmitteln" jeder BSD- oder Linux-Distribution erstellen. Dabei gilt es, sorgsame Sicherheitsvorkehrungen zu treffen, vor allem eine hinreichende Authentifizierung des Dienstleisters sicherzustellen.

Dieses Verfahren bietet zuverlässigen Schutz gegen alle wesentlichen Risiken: Der Datenaustausch ist stark verschlüsselt, die Teilnehmer werden (personenbezogen) sicher authentifiziert und erhalten im Anwendernetz durch die lokale Firewall nur Zugriff auf den Bereich, der für Wartungsarbeiten vorgesehen ist. Darüber hinaus müssen auf der Haupt-Firewall keine durchgängigen Verbindungen von außen in das interne Netz freigeschaltet werden und der (Anwender-)Administrator hat stets alle Wartungszugänge unter Kontrolle, da ohne seine Anforderung kein Rendezvous mit dem externen Support zustande kommt.

Zudem lassen sich alle Fernwartungs-Aktionen auf dem Rendezvous-Server protokollieren – da dieser nicht unter Kontrolle des Fernwartes steht, ergibt sich hier eine zusätzliche, sichere Audit-Möglichkeit. Nicht zuletzt schützt dieses Szenario das Wartungsobjekt – je nach Konfiguration im Regelbetrieb – zudem auch verstärkt vor eingedrungenen Angreifern und Innentätern aus dem Anwendernetz, da die Verbindung zum Rendezvous-Server nur fallweise und ausgehend von der SSH-/Firewall-Appliance aufgebaut werden kann.

Bernhard Schneck ist Geschäftsführer der GeNUA mbH.