Aktive Inhalte (Teil 3) Remote-Controlled Browsers System Sichere und bequeme Nutzung von aktiven Inhalten

Ordnungsmerkmale

erschienen in: <kes> 2006#1, Seite 60

Rubrik: BSI Forum

Schlagwort: Aktive Inhalte

Zusammenfassung: Unter einem Remote-Controlled Browsers System (ReCoBS) versteht das BSI den Web-Zugang mithilfe speziell gesicherter Terminalserver-Systeme. Die Sicherheit beruht auf der Trennung zwischen Ausführung und Darstellung aktiver Inhalte, sodass diese nicht ins interne Netz gelangen. Der für ReCoBS erforderliche Realisierungsaufwand ermöglicht ein Maß an Sicherheit, Web-Funktionalität und Bedienungskomfort, wie es von keiner der verbreiteten Web-Zugangsmethoden geboten wird.

Autor: Von Jörn-Uwe Heyder, BSI

Viele Webseiten setzen aktive Inhalte (z. B. Javascript, Java-Applets, ActiveX-Controls) ein, sodass sich Nutzer einer Freischaltung von aktiven Inhalten im Browser kaum entziehen können. Dies kann auf Anwenderseite zu erheblichem Schaden führen [1]. Daher empfiehlt das BSI der Anbieterseite, auf aktive Inhalte zu verzichten oder zumindest die Web-Inhalte so zu gestalten, dass sie auch ohne Freischaltung im Wesentlichen nutzbar sind (s. [2,3]). Da sich diese Anforderung nur sehr langsam auf Seiten der Anbieter durchsetzt, benötigt die Anwenderseite Lösungen zum sicheren Surfen. Es gibt eine Vielzahl von Web-Zugangsmethoden, die sich allerdings deutlich hinsichtlich der Kriterien Sicherheit, Web-Funktionalität, Bedienungskomfort und Realisierungsaufwand unterscheiden [4]. Im Folgenden wird ein Remote-Controlled Browsers System (ReCoBS) als eine dieser Methoden vorgestellt.

Funktionsweise

Bei ReCoBS werden die Ausführung und die Darstellung aktiver Inhalte durch Realisierung auf verschiedenen Rechnern voneinander getrennt. Hierzu wird der Web-Browser auf einem Terminalserver betrieben, der sich außerhalb der internen gesicherten Umgebung befindet (z. B. in einer demilitarisierten Zone – DMZ – des Sicherheitsgateways). Die in den HTML-Quellcode eingebetteten und mithilfe von HTTP übertragenen aktiven Inhalte werden im Browser auf dem Terminalserver ausgeführt, das heißt die ursprünglich im Code enthaltenen Informationen werden in grafische und akustische Informationen umgewandelt. Vom Terminalserver zu den Arbeitsplatzrechnern werden dann ausschließlich diese Informationen mithilfe eines speziellen Terminalserver-Protokolls übertragen und am Arbeitsplatz-PC des Anwenders von einem entsprechenden Client dargestellt. Das Terminalserver-Protokoll gewährleistet außerdem die Übertragung von Tastatureingaben und Mausbewegungen in umgekehrter Richtung, sodass die Browser von den Arbeitsplätzen aus ferngesteuert werden können.

Topologie

ReCoBS setzt sich im Wesentlichen aus ReCoBS-Server und den ReCoBS-Clients zusammen. An die Stelle eines einzelnen ReCoBS-Servers kann natürlich auch ein Verbund von Servern treten, gegebenenfalls ergänzt um weitere Systeme, wie Load-Balancer, Verzeichnis-Server oder Log-Host. Der ReCoBS-Verbund ist modularer Bestandteil des Sicherheitsgateways. Abbildung 1 zeigt einen Topologie-Vorschlag zur Integration von ReCoBS: Dargestellt ist ein Sicherheitsgateway im empfehlenswerten P-A-P-Aufbau [5]. Das Sicherheitsgateway verbindet das vollständig "geswitchte" LAN mit dem Internet. Der ReCoBS-Verbund befindet sich in einer DMZ, wobei der Load-Balancer an einem eigenen Interface des Application Level Gateway (ALG) angeschlossen ist. Im Folgenden wird zur Vereinfachung nur ein einzelner ReCoBS-Server betrachtet.

[Illustration]
Abbildung 1: Topologie-Vorschlag für ReCoBS

Sicherheitskonzeption

Das Grundprinzip bei ReCoBS besteht in dem Bruch der Informationsverarbeitung, bei dem die im HTML-Code (inkl. aktiven Inhalten) enthaltenen Informationen in grafische Informationen umgewandelt werden. Der Sicherheitsgewinn für das LAN beruht im Wesentlichen auf diesem Bruch: Aufgrund der Trennung zwischen Ausführung und Darstellung aktiver Inhalte erreichen nur die grafischen Informationen des Terminalservers die Arbeitsplatz-PCs und nicht die wesentlich gefährlicheren aktiven Inhalte.

Charakteristisch für ReCoBS ist die gesamte Sicherheitskonzeption, bestehend aus diesem Grundprinzip und den flankierenden Maßnahmen zur Absicherung des Grundprinzips. Hierfür gibt es zwei "Linien der Verteidigung": zum einen den Schutz des ReCoBS-Servers gegenüber dem Internet und zum anderen den Schutz des Hausnetzes gegenüber einem eventuell kompromittierten ReCoBS-Server.

Um den ReCoBS-Server vor Angriffen aus dem Internet zu schützen, werden folgende Maßnahmen ergriffen:

Da auf dem ReCoBS-Server aktive Inhalte ausgeführt werden, können prinzipbedingt erfolgreiche Angriffe auf ihn nicht ausgeschlossen werden. Deshalb wird der Server durch die genannten Maßnahmen besonders geschützt. Falls sie überwunden werden, soll durch

zumindest gewährleistet sein, dass eine Kompromittierung allenfalls kurzzeitig in Kauf genommen werden muss. Eine solche vorübergehende "Opferung" darf keine gravierenden Auswirkungen haben.

Um das Hausnetz vor einem kompromittierten ReCoBS-Server zu schützen, müssen zwei wesentliche Voraussetzungen erfüllt sein:

Das wird im einzelnen durch folgende Maßnahmen realisiert:

Darüber hinaus sollen Standardsicherheitsmaßnahmen entsprechend dem IT-Grundschutz [6] eingehalten werden, etwa die Aktualität der Patches auf allen beteiligten Systemen.

Kennzeichnend für ReCoBS sind die Sicherheitsanforderungen und -maßnahmen. Für die Akzeptanz des Systems sind aber auch die Anforderungen an Betrieb und Anwendung wichtig. Tabelle 1 gibt einen Überblick über die Anforderungen, die das BSI zurzeit an ReCoBS stellt. Eine ausführliche Erläuterung aller Anforderungen ist unter [7] verfügbar.

Nr. betriebstechnische Anforderungen
B 1 ReCoBS-Grundfunktionalität (vgl. Abschnitt Funktionsweise)
B 2 hinreichende Performance, unterstützt durch
B 2.1 Load-Balancing
B 2.2 zusätzliche Bandbreite und Bandbreitenoptimierung
B 2.3 automatisches Ausloggen bei Nicht-Nutzung
B 2.4 lastabhängige Ressourcenbereitstellung für die einzelnen Anwender
B 3 Variabilität, insbesondere durch
B 3.1 Skalierbarkeit
B 3.2 Plattformunabhängigkeit
B 3.3 Einsatzmöglichkeit für unterschiedliche Browser
B 3.4 flexible Konfigurierbarkeit der Anwenderaktivitäten auf dem Server
B 3.5 konzeptionelle Offenheit auch für andere Anwendungen
B 4 einheitliche, zentrale, umfassende und einfache Administration, ergänzt durch
B 4.1 Server-Fernadministration
B 4.2 zentrales Client-Management
B 4.3 Backup-Möglichkeit
Nr. anwendungstechnische Anforderungen
(A 0) Anwender-Grundanforderung (Verhalten wie lokale Anwendung erwünscht)
A 1 Drucken
A 2 Download
A 3 Webseiten-Speicherung
A 4 Copy and Paste
A 5 individuelle Benutzereinstellungen (z. B. Bookmarks, Oberflächengestaltung)
A 6 komfortable Bedienung
A 7 Sound-Unterstützung
Nr. sicherheitstechnische Anforderungen
S 1 Serversicherheit, insbesondere
S 1.1 regelmäßiger System-Integritätscheck
S 1.2 regelmäßiger Reboot von einem schreibgeschützten Medium
S 1.3 Vertraulichkeit auf dem Server (u. a. durch Kapselung der Anwenderumgebungen)
S 1.4 sichere Fernadministration
S 1.5 keine kritischen Systemvorgänge auf dem Server (z. B. darf die Systemfunktionalität keine Verbindungsaufbauten von außen nach innen voraussetzen)
S 1.6 restriktiver Umgang mit ausführbaren Programmen
S 1.7 System-Härtung
S 1.8 Einschränkung der Anwender-Funktionen je nach konkretem Bedarf der Institution
S 1.9 Logging
S 2 Clientsicherheit, dazu gehört
S 2.1 Vertraulichkeit auf dem Client durch Deaktivierung typischer Funktionen von Terminalserver-Clients
S 2.2 Minimalität der Client-Software
S 3 Verbindungssicherheit zwischen Client und Server, insbesondere
S 3.1 Integrität (Authentizität)
S 3.2 Vertraulichkeit
S 3.3 minimales Terminalserver-Protokoll
S 4 sichere Implementierung aller Anforderungen unter Berücksichtigung ihres Zusammenwirkens
S 5 Absicherung durch das Sicherheitsgateway, insbesondere durch
S 5.1 Sicherheitsproxy für das Terminalserver-Protokoll, zumindest generischer Proxy
S 5.2 Web-Sicherheitsproxy
S 5.3 Paketfilter; innerer und äußerer Paketfilter des P-A-P-Aufbaus (ggf. ergänzt durch dedizierten Paketfilter zur Abgrenzung des Servers vom Sicherheitsgateway)

Tabelle 1: betriebs- (B), anwendungs- (A) und sicherheitstechnische (S) ReCoBS-Anforderungen

ReCoBS versus Terminalserver

Das grundlegende technische Prinzip von ReCoBS ist der indirekte Web-Zugang mithilfe von Terminalservern. Die Terminalserver-Technik wird seit Jahrzehnten gut beherrscht und es gibt eine Fülle von kommerziellen und frei verfügbaren Produkten in diesem Bereich. ReCoBS unterscheidet sich in drei wesentlichen Punkten von einem Terminalserver-System, wie es üblicherweise verwendet wird:

Dementsprechend sollte kein Terminalserver-System "von der Stange" gewählt werden, um es unverändert als ReCoBS zu betreiben. Das ist vor allem auf Sicherheitsdefizite solcher Systeme zurückzuführen. Die ReCoBS-Sicherheitsanforderungen und -maßnahmen sind erforderlich, um eine hinreichende Absicherung typischer Einsatz-Szenarien zu gewährleisten. Die umfassende Sicherheitskonzeption ist charakteristisch für ReCoBS und unterscheidet es von einem normalen Terminalserver-System.

Vor- und Nachteile

ReCoBS erfüllt drei wesentliche Anforderungen an den Web-Zugang gleichzeitig: Nutzung von Webseiten mit aktiven Inhalten

Der "gewünschte technische Funktionsumfang" entspricht im Wesentlichen dem technisch möglichen. Ausgenommen sind jedoch einige besonders sicherheitskritische Funktionen, die mithilfe von ReCoBS auch technisch nicht nutzbar sein sollen. Dazu gehört etwa die automatische Softwareinstallation an den Arbeitsplätzen mithilfe aktiver Inhalte.

Keine der verbreiteten Web-Zugangsmethoden erreicht in jedem der drei Kriterien Web-Funktionalität, Bedienungskomfort und Sicherheit ein so hohes Niveau wie ReCoBS (s. [4]). Die genannten Vorteile von ReCoBS erfordern einen gewissen Realisierungsaufwand. Web-Zugangsmethoden mit vergleichbaren Vorteilen dürften einen entsprechenden Aufwand voraussetzen. Bei den unter [4] vorgestellten Methoden mit geringerem Realisierungsaufwand ist mindestens eines der Kriterien Web-Funktionalität, Bedienungskomfort oder Sicherheit wesentlich schwächer ausgeprägt als bei ReCoBS.

Aus betriebstechnischer Sicht kann es zu Performance-Engpässen kommen, vor allem wenn das System viele bewegte Bilder verarbeiten soll. Ursache dafür ist die Informationsverarbeitung auf grafischer Ebene, die in der Regel mehr Ressourcen erfordert. Daher werden zahlreiche Anforderungen an die Ressourcenoptimierung gestellt (vgl. Tab. 1). Herausragendes Beispiel ist die Bandbreite; im ReCoBS-Backbone (s. Abb. 1) kann je nach Einsatzbedingung eine Bandbreite im GBit/s-Bereich erforderlich sein. Zumindest beim ALG würden dadurch die Grenzen des zurzeit technisch Möglichen erreicht. Durch Optimierungsmaßnahmen reicht gegebenenfalls auch eine wesentlich geringere Bandbreite aus. Grundsätzlich gilt jedoch, dass sich mit hinreichend vielen bewegten Bildern (z. B. zahlreichen Videoströmen) und einer entsprechenden Anwenderzahl jedes ReCoBS "in die Knie zwingen" lässt.

Grenzen von ReCoBS

Durch ReCoBS wird die Problematik der aktiven Inhalte auf einen zentralen Server außerhalb des LAN verlagert. Dadurch schützt ReCoBS die Daten im LAN. Nicht geschützt werden jedoch die beim Surfen mittels ReCoBS übertragenen Daten – vor allem weil kurzzeitige erfolgreiche Angriffe auf den ReCoBS-Server nicht auszuschließen sind (vgl. Sicherheitskonzeption). Daher ist ReCoBS vor allem für die uneingeschränkte Recherche im WWW, nicht aber für die Nutzung sensitiver Web-Anwendungen gedacht (z. B. kein Zahlungsverkehr). Hierfür könnte gegebenenfalls ein dedizierter ReCoBS-Server eingesetzt werden, der nur mit vertrauenswürdigen Web-Servern kommunizieren darf; dabei sind weitere Sicherheitsmaßnahmen zu beachten.

Trotz des erheblichen Sicherheitsgewinns für das interne Netz gibt es natürlich auch bei ReCoBS ein verbleibendes Risiko. Der ReCoBS-Server ist so eingerichtet, dass eine kurzzeitige Kompromittierung keine gravierenden Schäden verursacht. Dies kann – abhängig von den Anforderungen des Betreibers – in der Regel in Kauf genommen werden. Ein Vordringen des Angreifers ins LAN mithilfe von ReCoBS ist abhängig vom Missbrauchspotenzial der grafischen Informationen und des verwendeten Terminalserver-Protokolls. Je kleiner der Funktionsumfang von Client-Software und Protokoll ist, umso leichter ist ein Missbrauchspotenzial zu beherrschen. Das verbleibende Risiko ist bei Einhaltung der vorgestellten Sicherheitsanforderungen als vergleichsweise gering einzuschätzen. In jedem Fall ist ein solches System zur Verarbeitung grafischer Daten wesentlich schwieriger für einen Angriff zu missbrauchen als aktive Inhalte auf einem ungeschützten Browser am Arbeitsplatz-PC.

Empfehlungen

Ob ReCoBS die geeignete Lösung für den Web-Zugang ist, hängt von den konkreten Anforderungen auf der Anwenderseite ab (s. [4]). Da die Realisierung einen gewissen Aufwand erfordert, richtet sich diese Lösung eher an Institutionen als an Privatanwender. Der Realisierungsaufwand kann unter anderem durch folgende Aspekte gerechtfertigt werden:

Auch wenn ReCoBS für hohen Schutzbedarf gedacht ist, sollte die Einführung eines solchen Systems nur bei solchen Netzen in Betracht gezogen werden, bei denen schon bisher auf die ein oder andere Art ein Internet-Zugang vertretbar war. Wird ein Netz, das bislang vollständig vom Internet getrennt war, ans Internet angeschlossen, kann auch ReCoBS nicht verhindern, dass das Sicherheitsniveau sinkt. Für Behörden gilt: In Netzen mit ReCoBS dürfen unter Einhaltung entsprechender Sicherheitsmaßnahmen allenfalls als "VS – Nur für den Dienstgebrauch" (VS-NfD) eingestufte Informationen verarbeitet werden.

Für Netze, bei denen aktive Inhalte aus unsicheren Quellen bis zu den Arbeitsplätzen gelangen, führt die Einführung von ReCoBS zu einem erheblichen Sicherheitsgewinn. Bei Netzen, die schon heute eine Web-Zugangsmethode auf hohem Sicherheitsniveau verwenden (vgl. [4]), würde man ReCoBS eher aus Gründen der Web-Funktionalität oder Bedienbarkeit einführen. Hier wäre eine detaillierte Sicherheitsanalyse zur Abwägung erforderlich.

ReCoBS ist kein fertiges Produkt, sondern eine Konzeption für den Web-Zugang durch Anpassung entsprechender Standardprodukte. Die auf der Webseite des BSI bereitgestellten Informationen (Anforderungen, Sicherheitskonzeption, Risikoanalyse, Topologiediskussion usw.) sollten größere Institutionen oder IT-Systemhäuser (als Auftragnehmer) in die Lage versetzen, entsprechende Systeme zu realisieren [7]. Das BSI plant, die Einführung von ReCoBS durch weitere Veröffentlichungen speziell zur Realisierung zu unterstützen.

Literatur

[1]
Marion Atts, Aktive Inhalte (Teil 1), Grundlagen und Gefahren, <kes>/BSI-Forum 2005#5, S. 55
[2]
BSI, E-Government-Handbuch, Modul "Sicherer Internet-Auftritt im E-Government", Abschnitt 7, Aktive Inhalte, S. 37, [externer Link] www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf
[3]
BSI, E-Government-Handbuch, Modul "E-Government ohne Aktive Inhalte", [externer Link] www.bsi.bund.de/fachthem/egov/download/4_EGovoAI.pdf und [externer Link] www.ohne-aktive-inhalte.de
[4]
Jörn-Uwe Heyder, Marion Atts, Aktive Inhalte (Teil 2), Sichere Nutzung – Überblick und Empfehlungen, <kes> 2005#6/BSI-Forum, S. 54
[5]
Björn Dehms, Konzeption von Sicherheitsgateways, <kes>/BSI-Forum 2005#2, S. 39
[6]
BSI-Grundschutzhandbuch, [externer Link] www.bsi.bund.de/gshb/
[7]
BSI, ReCoBS-Webseite, [externer Link] www.bsi.bund.de/fachthem/sinet/aktiveinhalte/schutzmoeglichkeiten/recobs/