HTML und JavaScript-Rewriting im SSL-VPN-Gateway

Posted by hob Wed, 06 Jul 2016 09:15:00 GMT

HTML Java Script Rewriting SSL

In unserem heutigen  Blogpost erklären wir Ihnen, wie ein SSL-VPN-Gateway Websites samt JavaScript-Programmen zum Browser des Users tunnelt.

Sogenannte SSL-VPN-Gateways funktionieren folgendermaßen: Der User verbindet sich mittels Browser über SSL (TLS) / HTTPS mit einem SSL-VPN-Gateway. Dieses verbindet sich über das Internet mit einem Webserver. Die Verbindungskette sieht folglich so aus:

SSL VPN Gateway Rewriting

Das SSL-VPN-Gateway lädt die Website vom Server und schickt sie verschlüsselt an den Browser des Users.

In diesem Szenario gibt es folgendes Problem: Die meisten Websites laden Ressourcen von anderen Websites oder verweisen mit Links direkt auf Websites. Wenn der User einem dieser Links folgt, verbindet sich sein Browser direkt mit der verknüpften Website. Das SSL-VPN-Gateway wird dabei außen vor gelassen, weswegen der User auf bestimmte Ziele nicht mehr zugreifen kann; beispielsweise den firmeninternen Fileserver.

Diese Problematik gilt nur für absolute Links mit vollständiger Web-Adresse. Relative Links sind unproblematisch. Absolute Links können hingegen an beliebige Stellen im Web verweisen – vergleichbar mit Längen- und Breitengrad auf Landkarten.
Relative Links beinhalten nur den relativen Pfad zum neuen Dokument, abhängig vom Pfad des aktuellen Dokuments. Sie sind vergleichbar mit einer Wegbeschreibung. Relative Links haben entsprechend eine verkürzte URL ohne „http://www.“ am Anfang.

Damit auch die Websites von absoluten Links über das SSL-VPN-Gateway zum User getunnelt werden, gibt es diese traditionelle Lösung: Das SSL-VPN-Gateway analysiert die Antworten des Webservers und ändert die Links so ab, dass sie auf das SSL-VPN-Gateway verweisen statt direkt auf den Webserver. Für HTML ist das eine gängige Praxis. Auch der Webserver von Apache führt dieses sogenannte HTML-Rewriting durch. Die geänderten URLs bestehen aus der Internetadresse des SSL-VPN-Gateways und dem ursprünglichen Link. Oft benötigt das SSL-VPN-Gateway noch zusätzliche Informationen, um den ursprünglichen Webserver zu finden.

Viele Websites bestehen allerdings nicht nur aus statischem HTML. Stattdessen werden oft JavaScript-Programme vom Webserver in den Browser des Users geladen und dort ausgeführt. Diese Programme bestimmen erst beim User das genaue Aussehen der Website. Außerdem können diese Programme auch Links auf der Website erstellen und abändern. Zusätzlich können sie sich mit dem Webserver verbinden, um Teile der Website im Browser des Users zu aktualisieren.

Wenn ein SSL-VPN-Gateway zwischen Browser und Webserver geschaltet ist, muss der SSL-VPN-Gateway auch das Verhalten der JavaScript-Programme ändern. Diese JavaScript-Programme und ihre erzeugten Links müssen nämlich wie die HTML-Links auf den SSL-VPN-Gateway verweisen, anstatt direkt auf den Webserver. Das kann man erreichen, indem das SSL-VPN-Gateway das JavaScript-Programm analysiert und so verändert, dass das JavaScript-Programm Links so erstellt bzw. abändert, dass sie über das SSL-VPN-Gateway gehen. Der SSL-VPN-Gateway ruft die Website samt JavaScript-Programmen auf, ändert beide und sendet sie erst dann zum Browser des Users weiter.

Diese Methode kann erweitert werden, um auch komplexere Web-Applikationen entsprechend zu ändern. Dann bindet das SSL-VPN-Gateway speziellen JavaScript-Code in die Website ein, der den ursprünglichen JavaScript-Code der Website erst dann modifiziert, wenn er im Browser des Users ausgeführt wird. In komplexeren Web-Applikationen kann es sogar vorkommen, dass JavaScript-Programme dynamisch JavaScript-Code generieren und ihn bei Bedarf ausführen. Das JavaScript-Rewriting im SSL-VPN-Gateway kann so etwas nicht vorhersehen. In diesem Fall ist eben beschriebenes JavaScript-Rewriting auf Seiten des Users obligatorisch.

Trotz dieser Techniken treten beim Rewriting von manch komplexeren Web-Applikationen Fehler auf, die eine korrekte Ausführung unmöglich machen. Beim Rewriting muss die Logik erkannt werden, mit der Links generiert werden. Diese Logik kann von Website zu Website unterschiedlich sein, sodass das Rewriting auf der einen Website problemlos funktionieren kann, während es auf einer anderen Website überhaupt nicht klappt.

Mehr Informationen zu unseren IT-Security Lösungen erhalten Sie auf www.hob.de

keine Kommentare |

Business Continuity und Compliance: Alles möglich mit Remote Access!

Posted by HOB Marketing Tue, 12 May 2009 16:27:00 GMT

Der Wunsch zu Hause zu arbeiten kann unfreiwillig zum Zwang werden, wie derzeit diskutierte Maßnahmenpläne im Fall einer ernsten Influenza-Welle beweisen. Um die Business Continuity für den erfolgreichen Betrieb auch von externen Standorten aufrecht halten zu können, sollten Unternehmen zeitgerecht leistungsstarke Remote Access-Lösungen einrichten.

Die Diskussion, wie Unternehmen im Ernstfall einer Influenza-Pandemie ihre Business Continuity aufrecht erhalten, ist kein neues Thema: Bereits im August 2007 gab das Schweizer Pharmaunternehmen Roche bekannt, dass der Notfallplan den Schutz der Mitarbeiter durch Arbeit von zu Hause aus vorsehe. „Der wichtigste Service, den wir definiert haben, ist der Remote-Zugriff unserer Mitarbeiter auf die Computer-Systeme“, erläuterte damals Jennifer Allerton.

Allerdings ergab eine Studie der Unternehmensberatung Mercer im Jahr 2007, dass nur 47 Prozent der großen Unternehmen einen Notfallplan erstellt und nur 17 Prozent ein Budget für die Pandemievorsorge eingeplant haben.

Nicht nur Probleme im eigenen Land können Unternehmen beeinträchtigen, wie der aktuelle Fall Anfang Mai in Hongkong zeigt: Dort saßen Gäste in einem Hotel fest, weil die chinesischen Gesundheitsbehörden dieses wegen eines mexikanischen Gastes unter Quarantäne gestellt hatten.

Business Continuity von außen sichern

Während man im Zusammenhang mit Business Continuity bislang eher an sichere Rechenzentren und Datenbanken, Backup und Wiederanlaufzeiten dachte, bekommt das Thema beim Gedanken an nicht verfügbare Mitarbeiter eine andere Dimension: In diesem Fall muss das Unternehmen zwei Ziele verfolgen:

  • Die Systeme müssen remote sicher weiter zu betreiben und zu administrieren sein.

  • Mitarbeiter müssen von zu Hause oder anderen entfernten Standorten arbeiten können

Die Lösung: Remote Access

Unternehmen, die ihren Geschäftsbetriebes auch in solchen Krisenzeiten sicher stellen wollen, wenn nur noch eine Rumpfmannschaft im Unternehmen arbeiten kann, benötigen eine hochverfügbare, performante und leicht bedienbare Remote Access Lösung. Dass damit auch die Attraktivität des Arbeitsplatzes und damit des gesamten Unternehmens erhöht und so mancher Kundenwunsch allumfassend erfüllt wird, ist eine willkommene Begleiterscheinung. In vielen Fällen können durch die Nutzung von Home Offices oder den Einsatz freier Mitarbeiter zudem Kosten eingespart werden.

Der erste Schritt: Bedarf analysieren

Die Grundsatzfrage in einem Remote-Access-Projekt ist zunächst, ob das Prinzip der externen Zugänge und damit Arbeit z.B. im Home Office nur für den Krisenfall eingerichtet werden oder ob sie grundsätzlich in die Unternehmensphilosophie aufgenommen werden soll.

Dem entsprechend sind die Mitarbeiter bzw. Arbeitsplätze festzulegen, die den Remote Access nutzen sollen. Je nach Stellenprofil ist zu überlegen, wie umfassend der Zugriff sein soll: Nur auf den eigenen Arbeitsplatz oder auf alle Firmenssysteme.

Schlussendlich stellt sich die Frage nach der Technik. Hier sind Sicherheit, Verfügbarkeit, Performance und eventuell auch Kosten entscheidend. Denn das Internet bringt zwar Arbeitsplatz-Desktops und Systeme virtuell in alle Welt, birgt aber auch Sicherheitsrisiken.

Welcher Zugang wofür?

Die technischen Voraussetzungen für den Remote Zugriff in Home Offices sind heute praktisch überall vorhanden: Nahezu jeder besitzt einen PC und nutzt preiswerte DSL-Anschlüsse. Für Dienstreisen gibt es Notebooks oder PDAs, im Notfall kann man im Internet-Café oder auf dem PC in der Hotellobby seine eMails lesen.

Als neuere Lösungen haben sich hier zwei sichere Wege bewährt, die sich im Wesentlichen durch den Verschlüsselungsstandard unterscheiden: IPSec- und SSL-basierte Zugänge.

Sichere End-to-End-Verbindung via SSL: HOB RD VPN

Die nach Meinung der IT-Experten zunehmend verbreitete Variante für den sicheren Remote Access ist das SSL-Protokoll. HOB RD VPN ermöglicht mit Hilfe von HOBLink JWT, dem Java Remote Desktop eine End-to-End-Verbindung auf Applikationsebene, die in jeder Umgebung funktioniert und nur in ganz wenigen Fällen geblockt wird.

HOB RD VPN erfordert auf dem Remote Rechner keinerlei besondere Installationen, Treiber oder Administratorrechte, sondern lediglich einen Browser.

HOB RD VPN enthält neben dem sicheren Zugriff auf Intranet, Web-Anwendungen und File Server auch leistungsfähige Java-Clients für RDP- und klassische Terminalverbindungen, die ohne lokale Installation auskommen. Auch hier ist bei Bedarf ein voller Netzwerkzugriff möglich, den HOB über den sog. PPP-Tunnel realisiert. Somit kann der User – soweit es das Berechtigungsmodell zulässt – auch von fremden Rechnern aus unkompliziert auf seine Daten, ja sogar seinen Desktop zugreifen.

Voller Netzwerkzugriff über IPSec: HOBLink VPN

Für den Zugriff über IPSec bietet HOB sein Produkt HOBLink VPN, das mit Hilfe der „Silent Installation“ einfach zentral zu implementieren und auch zu verwalten ist. Dabei erfolgt der unternehmensweite Rollout durch eine Client-CD, die nach dem Start alle festgelegten Features, Regelwerke und Add-Ons automatisch installiert.

Nachdem der Anwender seinen Usernamen und Password eingegeben hat, kann er sich an seinem Unternehmensnetz anmelden und je nach Berechtigungskonzept direkt auf seine Anwendungen und Daten zugreifen.

Tags: Mobilanwender, Remote Access, Java RDP Client

Posted in | keine Kommentare |


emplates.arcsin.se/'), link_to("Frédéric de Villamil", 'http://fredericdevillamil.com')) %>
Powered by typo