Mit HOB Secure Communications Server (SCS) besitzt HOB eine flexible Betriebssystem Plattform als Ergänzung zu den HOB Server und Security Produkten.

Schon lange gab es bei HOB Überlegungen die qualitativ hochwertigen eigens entwickelten Produkte zusammen mit einem sicheren und stabilen Betriebssystem auszuliefern.

Im Jahre 2006 wurde zu diesem Zweck die Abteilung HOB Operating Systems gegründet. HOB Operating Systems beschäftigt sich überwiegend mit Open Source Betriebssystemen, vor allem GNU/Linux und FreeBSD.

Obwohl FreeBSD für HOB einige Vorteile gegenüber GNU/Linux besitzt, wurde GNU/Linux, aufgrund der größeren Treiberunterstützung, als Basis für SCS verwendet (Alternativ wird derzeit der Einsatz von FreeBSD geprüft).

Bei der Entwicklung für HOB SCS gab es anfangs die Überlegung eine vorhandene Linux Distribution anzupassen. Linux Distributionen gibt es sehr viele. Distrowatch listet über 600 verschiedene auf, die überwiegend Anpassungen vorhandener Distributionen darstellen.

Der Gedanke eine vorhandene Distribution anzupassen, wurde sehr schnell verworfen, da diese Distributionen für unseren Einsatzzweck zu umfangreich oder zu unflexibel erschienen. Auch die bekannten Linux Builder wie SuSE Studio oder rPath ermöglichten nicht die Anpassungen, die von uns gewünscht wurden. Daher wurde HOB SCS von Grund auf direkt aus den verfügbaren Quellcodes entwickelt. Die Verwirklichung eines eigenen Betriebssystems ohne Einbeziehung einer vorhandenen Distribution ist sicherlich schwieriger und langwieriger, bei HOB wurde diese Entscheidung aber nie bereut, da wir somit den größtmöglichen Einfluss auf unser Betriebssystem haben.

Zur Administration und Konfiguration von HOB SCS wurde HOBmin entwickelt. HOBmin ermöglicht die Verwaltung des Betriebssystems HOB SCS mittels Browser. Dabei wird der Zugriff auf die Verwaltungsoberfläche mit SSL verschlüsselt.

Nach gut zwei Jahren Entwicklung, im November 2008, war es dann soweit. HOB SCS konnte zusammen mit HOB RD VPN, der HOB Software-Lösungsfamilie für den Remote-Zugriff (SSL-VPN), ausgeliefert werden.

Die Reaktionen am Markt waren durchaus positiv. HOB SCS zusammen mit HOB RD VPN ermöglichte als Software Appliance den universellen Einsatz als SSL VPN mit den Vorteilen einer Appliance Lösung bei freier Hardwarewahl, da HOB SCS mit RD VPN im Gegensatz zu den meisten anderen SSL VPN Appliances keine Hardware Lösung ist, sondern nur auf Software basiert. Ein weiterer Vorteil einer Software Appliance ist die Bereitstellung als virtuelle Appliance, dabei wird HOB SCS im Open Virtualization Format (OVF) mit den VMware Tools zum Import für VMware vSphere angeboten.

Durch die Bereitstellung des Betriebssystems SCS ergeben sich für HOB (und damit auch für unsere Kunden) viele Vorteile, beispielsweise können wir Probleme die sich durch das Zusammenspiel von Betriebssystem und Applikation ergeben nahezu ausschließen. Patches, Updates und Erweiterungen bekommt der Kunde aus einer Hand.

Momentan wird HOB SCS sehr aktiv weiterentwickelt. Die nächste Version (die in einigen Wochen verfügbar sein soll) wird neben aktualisierten Paketen zukünftig weitere HOB Produkte integrieren (HOBLink VPN, HOB RD VPN Compact etc). Zusätzlich bekommt HOBmin, unser Administrationsservice, einen deutlich erweiterten Funktionsumfang. Der für die Konfiguration und Administration keinerlei Wünsche offen läßt.

Weitere Informationen zu HOB SCS

Wie bereits in anderen Einträgen im HOB-Techtalk Blog erwähnt wurde, haben SSL VPN Lösungen die IPsec VPN Lösungen immer noch nicht vollständig ersetzt, wobei allerdings eine zunehmende Tendenz zu beobachten ist.

Während IPsec VPNs einen kompletten Netzwerkzugriff ermöglichen, bieten SSL VPNs die Möglichkeit den Zugriff, falls gewollt, zu beschränken. Soll einem Benutzer nur Zugriff auf einen internen Webserver gewährleistet werden, kann der Administrator ihm auch nur diesen freischalten. Sollte dem User nur Zugriff auf einen bestimmten Terminalserver oder nur auf seinen eigenen Desktop PC ermöglicht werden, kann der Administrator ihn auch auf diesen begrenzen. Um die Zugangsbeschränkungen zu realisieren, benötigen SSL VPNs allerdings die entsprechenden „Werkzeuge“.

Stellen Sie sich vor, es gäbe ein gesichertes Gebäude, an dem man mit einer Karte entweder alle Türen öffnen kann oder keine einzige und komplett abgewiesen wird. Das wäre Ihr IPsec-Gateway. Jetzt stellen Sie sich ein verbessertes System vor, bei dem Sie die Karten so verschlüsseln können, dass individuelle, personalisierte Zutrittsbereiche realisiert werden können. Was nutzt das aber, wenn es keinen Aufzug oder Gang gibt, der zu diesen Türen die Sie öffnen dürfen führt?

Während die IPsec Lösungen für den Zugang vorwiegend die am Client-Rechner installierte Software benutzen, stellen SSL VPN Anwendungen diese Software selbst bereit. Dabei ist das Ziel, die Anforderung am Client-PC auf nur bereits installiertes zu begrenzen (d.h. ein Webbrowser und Extras wie Java oder ActiveX). Das erleichtert die  Arbeit der Administratoren (arbeiten an einer einzigen, bekannten, zugänglichen Stelle) und macht die Benutzeroberfläche unabhängiger vom PC. Aus diesem Grund verfügen diese Anwendungen über viele Extras und decken somit die meisten Anforderungen eines gewöhnlichen Benutzers ab. Aber dann gibt es noch Zugänge, die nicht so oft genutzt werden, oder anders gesagt, manche Client-PCs  sind noch unterschiedlicher als der gewöhnliche Rechner – und gerade solche Fälle sind nicht von einer „out-of-the-box“ Anwendung gedeckt. In so einem Fall werden die Vorteile solch einer Lösung schnell zum Nachteil: Nicht nur der Administrator ist bei den Anwendungsmöglichkeiten eingeschränkt, sondern auch der Benutzer kann an seinem benutzerdefinierten Client-System nichts ändern. Die Anwendungssoftware muss sich weiterentwickeln.

So kommt es, dass immer mehr SSL VPN Benutzer Interesse an unserem Java RDP Client zeigen: HOBLink JWT.

Die meisten SSL VPN Anwendungen sind mit einem gewöhnlichen RDP-Client, Microsoft, Citrix, und einem „open source“ Java-Client ausgestattet. Dies deckt im Grunde genommen die Bedürfnisse eines Microsoft OS Clients ab und wenn Sie von einem Mac oder Linux eine Verbindung aufbauen wollen, sollte der „open source“ Client Ihre Grundbedürfnisse erfüllen – zumindest so lange bis Sie etwas Besseres gefunden haben.

Doch immer mehr Kunden finden „das ist nicht gut genug“. Es sollte doch möglich sein, eine Verbindung von einem Mac zu einem Desktop PC zu erstellen, ohne auf eine Tastaturbelegung, Drucker, Dual-Screen-Monitor oder sonstige notwendigen und normalen Optionen zu verzichten.

Wie ist es mit einem 64-bit OS? Diese sind keine Seltenheiten mehr und sollten unterstützt werden (Die Weltbevölkerung wächst mit der Zeit und es steht außer Zweifel, dass die Computer-Welt sich viel schneller ändert!).

HOBLink JWT ist unsere Antwort darauf. Ein Java RDP-Client, welcher auf einem Webserver hinter Ihrer SSL VPN Anwendung gehostet werden kann (d.h. weder eine Installation auf dem Client noch auf dem Terminal Server / Office PC), mit voller Funktionalität und das ganze Plattformunabhängig.

Wir folgten der Nachfrage und begannen mit dem Marktführer der SSL-VPNs: Juniper. Immer mehr Kunden hosten HOBLink JWT auf einem Webserver hinter dem VPN, und erhalten die Funktionalität eines Hyperlink (Bookmark) auf der Benutzeroberfläche. Aber das genügte uns nicht und deshalb arbeiteten wir mit den Möglichkeiten des Juniper VPNs um Java Applets direkt auf der Anwendung zu hosten. Dies erübrigt nicht nur den Webserver, es verbessert auch die Verbindungsgeschwindigkeit. In Zusammenarbeit mit Juniper war das mit JWT 3.2  möglich und jetzt weiterentwickelt mit JWT 3.3 auf den Juniper Freigaben 6.4R1+.

In Kürze wird HOBLink JWT direkt in der Anwendung integriert sein, was für die Endkunden den ganzen Prozeß erleichtern soll.

SSL VPNs nehmen den nächsten Schritt um IPSec VPN Lösungen zu ersetzen. Ihre Zugangsmöglichkeiten werden bald viel flexibler sein - jedoch nicht weniger sicher.

Weitere Informationen finden Sie unter

www.hob.de

11.05.2010 Laurent « Chipper » Vaucheret

Traditionelle Telefonanlagen sind teuer und unflexibel

Viele Unternehmen klagen über die hohen laufenden und undurchsichtigen Kosten ihrer Telefonanlagen. Die Telefonanlagenanbieter schließen mit ihren Kunden Miet-, Kauf-, Wartungs- und Schutzverträge ab, aus welchen die Leistungen nur schwer ersichtlich sind und oft werden Zusatzleistungen extra berechnet. Die Unternehmen haben bezüglich Wartung und Pflege kaum Ausweichmöglichkeiten, sie müssen sich sozusagen voll und ganz in die Hände der Telefonanlagenhersteller begeben. Auch bei den Endgeräten gibt es keinerlei Möglichkeit umzusteigen: An den Anlagen der großen Hersteller können nur deren Telefone betrieben werden.

Enstehungsgeschichte von Asterisk

All dies erkannte Mark Spencer im Jahre 1999 als er beabsichtigte eine Telefonanlage für sein Unternehmen zu kaufen. Er wollte all das nicht und begann eine Telefonanlage zu programmieren. So entstand die Open-Source Telefonanlage Asterisk. Inzwischen ist diese zum de-facto Standard bei modernen VoIP TK-Anlagen geworden. Wegen ihrer mächtigen und flexiblen Struktur wird sie auch in kommerziellen VoIP-Anlagen verwendet, denn viele TK-Anlagen-Hersteller haben erkannt, dass es sinnlos wäre, mit proprietären Eigenentwicklungen dagegen anzutreten. Asterisk ist eine Open Source Software PBX ((Private Branch Exchange) = Softwaretelefonanlage) an der sich mittlerweile hunderte von Entwicklern weltweit beteiligen. Wie bei allen Open Source Projekten ist die Software als solche kostenlos und kann in der aktuellsten Version unter http://www.asterisk.org geladen werden. Die Hauptarbeit liefert immer noch Mark Spencer und seine Firma Digium, welche ca. 50 Personen beschäftigt und einen Umsatz von $10 Millionen macht, mit dem Verkauf von Hardware und einer Business Edition der ansonsten freien Software Asterisk.

Lizenzierung

Asterisk wird unter einer dualen Lizenz zur Verfügen gestellt. Es gibt eine freie GNU General Public (GPL) Softwarelizenz, als auch eine proprietäre Lizenz, welche es den Lizenznehmern gestattet, nichtöffentliche Bestandteile auszuliefern.

Marktanteil

Eine Umfrage von 2008 der Eastern Management Group ergab, dass in Nordamerika der Marktanteil von Telefonanlagen mit OpenSource größer ist, als der jedes anderen Herstellers und Asterisk mit 88% die herausragende Führungsposition der OpenSource Anlagen einnimmt. Asterisk hat sich seit der Erstveröffentlichung 1999 von einer kleinen Nischenanwendung zu einer führenden Lösungsplattform für Telefonie entwickelt. Die Tatsache, dass VoIP Provider, zusätzlich zu SIP, immer häufiger auch das asteriskproprietäre IAX2 Protokoll zur Anbindung anbieten, ist ein deutlicher Hinweis auf die Verbreitung der Telefonanlage.

Funktionsumfang

Wie bei jeder professionellen Telefonanlage können angeschlossene Telefone untereinander telefonieren und die Anlage kann Kontakt zur Außenwelt aufnehmen, sowohl über PSTN (public switched telephone network) als auch über VoIP (Voice over IP) Dienste. Die Featureliste ist umfangreich, hier ein kleiner Auszug der Funktionen, welche außer den üblichen Leistungsmerkmalen (weiterleiten, makeln, anklopfen, parken usw.) zur Verfügung stehen:

Installationen und Projekte

In großen Installationen wie bei der Stadt Pforzheim, der technischen Universität Chemnitz oder der Universität des Saarlandes in Saarbrücken kann Asterisk schon seit Jahren seine Leistungsfähigkeit unter Beweis stellen. Die Software wird in vielen Call-Centern, Unternehmen und bei vielen VoIP Anbietern erfolgreich eingesetzt.
Daneben gibt es auch eine Menge von sehr innovativen Projekten rund um Asterisk:

Integrierte, hochverfügbare Telefonanlagen

Die TK-Anlage wird durch VoIP ein integraler Bestandteil der IT-Infrastruktur, genau so wie ein Mail- oder Fileserver.  Sie wird einfach in bestehende Backup-, Notstrom- und Management-Systeme integriert und läuft auf der gleichen, standardisierten Server-Hardware, wie andere Server auch. Die Extraverkabelung für die Telefonie entfällt, wenn SIP-Telefone genutzt werden.
Weil Asterisk auf Standard x86 Hardware und unter Linux Betriebssystemen läuft, ist es sehr gut skalierbar, und es können, mittels Linux Bordmitteln wie dem Keepalivedeamon, Linux-HA und Rsync, hochverfügbare Systeme aufgebaut werden. Zusätzlich läuft Asterisk auf BSD Plattformen, Mac OS X und es gibt Portierungen für Windows. In der Regel wird Asterisk auf Linux Systemen installiert.

Distributionen

Von verschiedenen Anbietern gibt es Distributionen, die das Betriebssystem, einen Webserver, Datenbanken und die Asterisksoftware beinhalten. Sie setzen unterschiedliche Schwerpunkte und haben somit verschiedene Stärken. Während Trixbox, AsteriskNow oder FreePBX eher auf den amerikanischen Markt zugeschnitten sind, was sich durch das Fehlen von ISDN Einbindungen bemerkbar macht, sind MobyDick und GEMEINSCHAFT eher auf den deutschsprachigen Raum optimiert. Zusätzlich muss man unterscheiden zwischen frei erhältlichen, und kommerziellen Distributionen. Letztere werden nicht von einer Community, sondern von professionellen Entwicklern vorangebracht. Auch erhält der Administrator Support vom Hersteller zu den kommerziellen Produkten, was bei freien Distributionen wie z. B. Trixbox und AsteriskNow nicht gegeben ist und oft ein großes Problem darstellt.
Alle diese Distributionen beinhalten jeweils eine eigens programmierte Weboberfläche zur Konfiguration der Anlage, welche sich in manchen Fällen auf die individuellen Bedürfnisse anpassen lässt und teilweise auch die Provisionierung/Konfiguration der Telefone zentral von der Anlage aus zulässt.

Protokolle und Codecs

Ursprünglich war Asterisk als Telefonanlage für analoge Anschlüsse konzipiert. Angetrieben durch die deutsche Firma Junghanns kam später ISDN hinzu, gefolgt von VoIP mit Protokollen wie SIP, H.323, SCCP, MGCP und IAX2. Unterstützt werden aktuell die Codecs G.711a, G.711u, GSM, G.723.1, G.726AAL2, ADPCM, SLIN, LPC10, G.729A, SpeeX, iLBC, G.726, die Videocodecs H.261, H.263, H.263+ und in den neuesten Asterisk Versionen wird auch der freie Wideband-Codec G.722 unterstützt.

Asterisk und SER

In kleinen bis mittleren Installationen (bis ca. 1000 User) läuft Asterisk äußerst stabil. Wenn die Anzahl der Gespräche in den fünfstelligen Bereich pro Tag geht, sollte der Betreiber überlegen, ob es sinnvoll ist, den OpenSource SIP-Proxy SER (SIP Express Router) von IPTel.org als SIP Router einzusetzen. SER ist eine SIP-only Telefonanlage die den SIP Standard nach RFC 3261 konsequent umsetzt und man sagt ihm eine hohe Performance und Skalierbarkeit nach. Deswegen wird SER vor allem bei großen VoIP Providern eingesetzt. Lösungen, welche die Stärken aus Asterisk (unterschiedliche nutzbare Protokolle, viele Features) und SER (sehr viele gleichzeitige Verbindungen) nutzen, ermöglichen den Aufbau von Telefonanlagen für mehrere tausend User.

Aufbau und Konfiguration

Die Grundelemente von Asterisk sind Kanäle (SIP, IAX2, ISDN (E1, T1, BRI), Applikationen und der Rufnummernplan. Die Kanäle stellen die Verbindungen zur Außenwelt her (z.B. SIP), die Applikationen sind Konferenzen, VoiceMail oder Warteschlangen. Der Rufnummernplan gibt an, wie die Kanäle mit Applikationen durchgeschaltet werden. Applikationen sind die aktiven Elemente von Asterisk, die Sprachdaten (Audio) senden und empfangen können, Verbindungen auf- und wieder abbauen können, Parameter, wie z.B. die Caller IDs setzen, Datenbankeinträge erstellen oder abfragen und vieles mehr.

Asterisk wird über eine Kommandozeilen-Schnittstelle (Command Line Interface, CLI), bedient, die mit dem MySQL-Prompt oder einer sehr einfachen Shell vergleichbar ist. In der CLI kann man verschiedene Werte abfragen, debuggen oder Testanrufe absetzen. Eine grafische Benutzerschnittstelle (Graphical User Interface, GUI) existiert von Hause aus nicht. Die oben genannten Distributionen bringen jeweils ein webbasierendes GUI für die Konfiguration mit. Dann wird Asterisk ausschließlich über diese GUI konfiguriert, was in nativen Asteriskinstallationen mühevoll und zeitaufwändig über einen Texteditor wie vi oder nano vorgenommen werden muss. Allein die Anzahl von 62 Konfigurationsdateien, welche nach einer nativen Asteriskinstallation im Verzeichnis /etc/asterisk/ zur Verfügung stehen und darauf warten, editiert zu werden, lässt erahnen, wie aufwendig und komplex sich die Konfiguration über den Texteditor gestalten kann. In den webbasierten GUIs wird z. B. pro User ein Account angelegt, ein Endgerät zugeordnet, die Gruppenzuordnung konfiguriert, eine Voicemailbox angelegt, die Warteschlangen- und Rufgruppenzugehörigkeit eingerichtet und vieles mehr. Dies wird dann mit einem Klick aktiviert, wobei die Konfigurationsdateien neu geschrieben und angewandt werden. Für spätere Änderungen, oder zur Fehlersuche gewähren die GUIs Zugriff auf die relevanten Auszüge der Konfigurationsdateien, was die Übersichtlichkeit erhöht.

HOB und Asterisk

Auch HOB trägt zur weiteren Verbreitung von Asterisk tatkräftig bei. Für einen europaweit tätigen Automobilzulieferer, der Niederlassungen in 4 Ländern betreibt, hat HOB ein Telefoniesystem errichtet, welches auf sechs, jeweils redundant ausgelegten Asteriskservern aufbaut und die gesamte Voicekommunikation des Unternehmens abwickelt. Das System hat eine Anbindung an das vorhandene Active Directory, so dass z. B. neue Mitarbeiter, nebst MAC-Adresse ihres Telefons, Telefonnummer usw., nur in das Active Directory eingetragen werden, und schon können sie, egal in welcher der Niederlassungen, ihr Telefon in das Netzwerk einstecken und telefonieren.
Eine Hausverwaltung, die für mehrere tausend Wohneinheiten zuständig ist, telefoniert ausschließlich über ein von HOB eingerichtetes Asterisksystem. Die besondere Herausforderung war hier, die Erreichbarkeit zu erhöhen und die Möglichkeit zu erhalten, auf Tastendruck Gespräche mitzuschneiden. Dies gelang zu einem Bruchteil der Kosten einer traditionellen Telefonanlage.
Auch in einer sehr sensiblen Umgebung hat HOB eine Asterisk Telefonanlage implementiert. Die Ärzte, Schwestern und die Verwaltung eines Krankenhauses in Hannover telefonieren über ein von HOB eingerichtetes Asterisksystem. Dieses ist natürlich auch redundant ausgelegt. Nach einer Testphase war man von der Stabilität so überzeugt, dass nun auch Notrufe an die Ärzte und Reanimationsteams von diesem System weitergeleitet werden. Geplant ist zudem, die Patiententelefonie samt einem umfangreichen Abrechnungssystem einzubinden.
Auch HOB selbst telefoniert seit Jahren über eine Asterisktelefonanlage. Diese wird parallel zu einer traditionellen Telefonanlage betrieben. Asterisk läuft hier auf einem virtuellen Server und nutzt zur Anbindung an das PSTN und zur alten Anlage ein SIP – E1 Gateway.
Asterisk dient HOB auch als Telefonieserver für den javabasierten SIP-Client HOBPhone. Dieser komplettiert unsere Remote Desktop Lösung HOB WebSecureProxy und stellt für den Benutzer zusätzlich zum Remote Desktop auch ein Remote Phone bereit. Vor allem für Heimarbeitsplätze ist es unerlässlich neben dem Desktop auch ein Telefon zur Verfügung gestellt zu bekommen. Z. B. können Callcenter, anhand dieser Lösung, Mitarbeiter beschäftigen, welche von zu Hause arbeiten. Das HOBPhone umgeht elegant alle Probleme, wie RTP über NAT oder nicht vorhandene Verschlüsselung der Gesprächsdaten, die herkömmlichen SIP-Clients eine Remoteanbindung meist verwehrte. Komfortabel für den Außendienstmitarbeiter, den Remoteworker und den Administrator: Man muss nichts installieren, es reicht ein Standardbrowser mit Java-Plugin.

Man sieht, Kommunikationslösungen welche auf Asterisk aufbauen bieten vielerlei Möglichkeiten. Natürlich ist Asterisk auch abhängig von einer guten Umgebung wie hochwertigen Endgeräten, gut gepflegten Directories, eines entsprechend ausgelegten Netzwerks und dergleichen. Diese Bedingungen sind in den meisten Unternehmen vorhanden, oder können in Zusammenarbeit mit HOB errichtet werden. Einer innovativen, stabilen und kostengünstigen Telefonielösung steht nichts im Weg. Rufen Sie uns an.

„You couldn´t set out to build a system like this. No one company could do it all. When you open source, people just keep improving things.” Sagt Mark Spencer.
Asterisk kann die kreative Umsetzung von tausenden unternehmerischen Ideen unterstützen. Spencer hatte dies wohl erkannt, als er die Software nach einem Symbol benannte, das in der Unixsprache für „Alles“ steht.

Mehr Informationen:
Asterisk        www.asterisk.org
HOB              www.hob.de

Heutzutage gehört es für viele Unternehmen zum Standard den Mitarbeitern die Möglichkeit zu bieten von zu Hause aus oder bei einer Geschäftsreise zu arbeiten und dabei auf relevante Firmendaten zugreifen zu können. Um diese Freiheit anzubieten und zu realisieren gibt es für Unternehmen unterschiedliche Möglichkeiten der Umsetzung.

1 Einsatzzweck

In jedem Unternehmen gibt es Webserver, die von den Mitarbeitern zur Verwaltung sensibler Daten genutzt werden. Um diese wichtigen Daten zu schützen, sind diese Webserver nur im Intranet des Unternehmens erreichbar.

Oft möchten Firmen diese Daten ausgewählten Mitarbeitern aber auch unterwegs zur Verfügung stellen, um schnell und einfach zum Beispiel Kundendaten abzufragen oder Emails zu beantworten.

Welche Kriterien müssen erfüllt sein, wenn man sensible Webseiten im Internet erreichbar macht?

1. Die Webseiten dürfen zu keiner Zeit nicht autorisierten Personen zugänglich sein.
2. Die Webanwendung soll für autorisierte Nutzer wie gewohnt funktionieren. d.h.:
   -  Alle Hyperlinks zu weiteren Webanwendungen sind wie bisher verfügbar.
   -  Der Zugriff erfolgt allein über den Browser; es wird keine spezielle Client-Software benötigt.
3. Es sollen möglichst wenige Ports in der Firewall geöffnet werden.
4. Möglichst geringer Konfigurations- und Wartungsaufwand der Lösung.

HOB hat die Lösung, die sicheren Zugriff, gewohnte Nutzung, einfache Konfiguration und einfache Erweiterbarkeit auf vertrauliche Daten vereint:

Das HOB RD VPN Web Server Gate.

Abbildung 1: Funktion des Web Server Gates

2 Key Features

2.1 Sichere Verschlüsselung

Um die sensiblen Daten vor unerwünschtem Zugriff zu schützen wird die gesamte öffentliche Kommunikation durch das Internet mit SSL verschlüsselt, egal ob der interne Webserver SSL unterstützt oder nicht. Es werden alle gängigen Verschlüsselungs-Algorithmen mit bis zu 256 Bit Schlüssellänge unterstützt, damit sind sensible Information perfekt geschützt.

2.2 Sichere Authentifizierung

Bevor ein Benutzer auf einen internen Webserver zugreifen kann, muss er sich authentifizieren, d.h. nur ausgewählte Nutzer können auf die Webanwendung zugreifen. Auch die Authentifizierung ist bereits verschlüsselt. Das HOB RD VPN Web Server Gate unterstützt viele verschiedene Authentifizierungsmethoden, etwa

• Userid und Passwort
• Token mit one-time-password, Radius, Challenge
• Zertifikat für Client-Authentifizierung über SSL, Smartcard

2.3 Dynamische Anpassung der Webapplikation

Der Zugriff auf die internen Webserver erfolgt mit dem Web Server Gate ohne jegliche Konfiguration. Dazu wird die Webapplikation beim Abruf durch den Nutzer dynamisch verändert. Dabei werden alle Hyperlinks in HTTP Header, HTML Seiten, Cascading Stylesheets (CSS) und Javascript so modifiziert, dass ihr Ziel durch das Web Server Gate zeigt.

2.3.1 URL Aufbau

Alle internen Webapplikationen sind über die URL des Web Server Gates https://wsg.hob.de/ erreichbar, zwischen ihnen wird durch Pfadangaben unterschieden.

2.3.2 Beispiel: modifizierte Hyperlinks in HTML

Nehmen wir an, eine Webapplikation http://intern.hob.de/app/ liefert folgende Webseite aus:

<html>
  <head><title>Beispiel</title></head>
  <body>
    <a href="http://www.hob.de/">
        absoluter Hyperlink
    </a>
    <a href="page.htm">
        zum aktuellen Verzeichnis relativer Hyperlink
    </a>
    <a href="/folder/page.htm">
        zum Root Verzeichnis relativer Hyperlink
    </a>
  </body>
</html>

Listing 1: originale Beispielseite http://intern .hob.de/app/

Die Seite enthält verschiedene Hyperlinks:

1. Absoluter Hyperlink:
   Der Browser wechselt zu der URL http://www.hob.de/

2. zum aktuellen Verzeichnis relativer Hyperlink:
   Der Browser wechselt zur der URL http://intern .hob.de/app/page.htm

3. zum Root Verzeichnis relativer Hyperlink:
   Der Browser wechselt zur der URL http://intern .hob.de/folder/page.htm

Das Web Server Gate ändert die Webseite ab:

<html>
  <head><title>Beispiel</title></head>
  <body>
    <a href="/http://www.hob.de/">
        absoluter Hyperlink
    </a>
    <a href="page.htm">
        zum aktuellen Verzeichnis relativer Hyperlink
    </a>
    <a href="/http://intern.hob.de/folder/page.htm">
        zum Root Verzeichnis relativer Hyperlink
    </a>
  </body>
</html>

Listing 2: modifizierte Beispielseite https://wsg.hob.de/http://intern.hob.de/app/

Die Hyperlinks wurden dabei modifiziert:

1. Absoluter Hyperlink wird relativ zum Root Verzeichnis:
   Der Browser wechselt zu der URL https://wsg.hob.de/http://www.hob.de/
2. zum aktuellen Verzeichnis relativer Hyperlink bleibt unverändert:
   Der Browser wechselt zur der URL https://wsg.hob.de/http://intern.hob.de/app/page.htm
3. zum Root Verzeichnis relativer Hyperlink wird erweitert:
   Der Browser wechselt zur der URL https://wsg.hob.de/http://intern.hob.de/folder/page.htm

2.4 Cookies

Cookies sind kleine Informationen, die der Webserver im Browser ablegen kann und die der Browser bei jeder Anfrage wieder zum ausstellenden Webserver liefert. Bei Nutzung des Web Server Gate liegen alle für den Browser erreichbaren internen Webserver in einer URL, der Browser hat also keine Möglichkeit zu entscheiden ob ein vorliegendes Cookie zu http://intern1.hob.de/ oder http://intern2.hob.de/ gesendet werden muss.

Das Web Server Gate verwaltet daher Cookies für alle Webserver für jeden User eigenständig und stellt dem Browser und dem Webserver die jeweils passenden Cookies zur Verfügung.

2.5 Zugriffsbeschränkung: Target Filter

Das Web Server Gate bietet durch sein dynamisches Arbeiten grundsätzlich die Möglichkeit jeden Webserver zu erreichen. Aber nicht jeder User soll auf alle Webserver zugreifen dürfen, oder es sollen nur bestimmte Webserver über das Web Server Gate erreichbar sein.

Um den Zugriff einzuschränken können so genannte Target-Filter konfiguriert werden, die den Zugriff auf bestimmte Webserver einschränken. Diese Einschränkung kann für alle User oder für jeden User einzeln vorgenommen werden.

2.6 Komprimierung der Daten

Die Kommunikation zwischen Client und Web Server Gate kann optional im gzip-Format komprimiert werden. Dadurch werden die Netzwerklast und die Antwortzeiten der Webanwendung reduziert.

2.7 Auto Login: Single SignOn

Das Web Server Gate bietet Möglichkeit den Nutzer automatisch an eine Webapplikation anzumelden, dabei werden HTML Formulare unterstützt.

2.8 Browser Caching ausschalten

Um die Ladezeiten besuchter Webseiten zu verringern, speichert ein Webbrowser normalerweise empfange Daten in dem sog. Cache auf der Festplatte ab. Beim erneuten Laden der Seite muss die gespeicherte Information dann nicht wieder heruntergeladen werden.

Das Web Server Gate kann optional einen erweiterten HTTP Header senden, der den Browser anweist, empfangene Daten nicht zu cachen. Wird das Web Server Gate zum Beispiel aus dem Internetcafe genutzt, kann damit vermieden werden, dass sensible Daten vom Browser abgespeichert werden und nicht autorisierten Nutzern zur Verfügung stehen.

2.9 Navigationsflyer

Das Web Server Gate fügt in jede Webapplikation einen Navigationsflyer ein. Das ermöglicht es dem Benutzer leicht auf die Startseite zurückzukehren oder die Web Server Gate Sitzung zu beenden. Damit der Flyer keine Elemente der Webapplikation verdeckt, ist er im Browserfenster frei verschiebbar.

2.10 Browser Lesezeichen

Benutzer die immer die gleiche interne Webapplikation http://intern .hob.de/ über das Web Server Gate nutzen, können sich ein Browser Lesezeichen mit der URL https://wsg.hob.de/http://intern.hob.de/ anlegen. Beim Aufruf dieses Bookmarks fordert das Web Server Gate zuerst die Authentifierung des Users an und leitet danach automatisch an die Webapplikation weiter.

3. Fazit

Das Web Server Gate stellt eine einfache Möglichkeit dar, um über das Internet sicher auf firmeninterne Daten zuzugreifen, ohne dass dazu aufwändige Änderungen an der IT-Infrastruktur notwendig wären.

04.03.2010 MJ

Einbindung des HOB Windows Terminalserver Clients HOBLink JWT und des 3270 Clients HOBLink J-Term in Eclipse

Ursprünglich wurde Eclipse als integrierte Entwicklungsumgebung, also als Anwendungsprogramm zur Entwicklung von Software für die Programmiersprache Java genutzt. Als Nachfolger von IBM Visual Age for Java 4.0 wurde  der Quellcode für Eclipse  am 7. November 2001 von IBM freigegeben.  Am 2. Februar 2004 beschloss das von IBM geführte Eclipse-Konsortium die Gründung der rechtlich eigenständigen Eclipse Foundation, die seitdem für die Entwicklung von Eclipse verantwortlich ist. Eclipse ist Open Source Software und steht kostenlos zum Download zur Verfügung.

Eclipse wird aufgrund seiner Erweiterbarkeit auch für viele andere Entwicklungsaufgaben eingesetzt. Es gibt es eine Vielzahl von Erweiterungen sowohl quelloffen als auch von kommerziellen Anbietern.

Bis einschließlich zur Version 2.1 war Eclipse als IDE konzipiert. Seit Version 3.0 ist Eclipse selbst nur der Kern, der die einzelnen Plug-ins lädt, die dann die eigentliche Funktionalität zur Verfügung stellen. Eclipse als auch die Plug-ins sind vollständig in Java implementiert. Zur Erstellung der grafischen Oberfläche wurde SWT verwendet. Zur Darstellung der GUI-Komponenten basiert SWT ähnlich wie AWT auf den nativen GUI-Komponenten des jeweiligen Betriebssystems. Die Plug-ins lassen sich durch einen Download direkt von einem Update-Server oder durch einfaches Entpacken installieren.

Immer mehr Unternehmen setzen auf den Einsatz von Java Produkten und immer öfter mit Eclipse als Framework auf den Arbeitsplatzrechnern wegen der damit verbundenen Vorteile. Eine sehr populäre und weit verbreitet Anwendung für den Einsatz unter Eclipse ist Lotus Notes von IBM. Mit dem Lotus Expeditor können die Arbeitsoberflächen für Lotus Notes auf Basis von Eclipse (RCP, Rich Client Platform) erstellt und integriert werden. Eclipse selbst ist in Java geschrieben und kann damit plattformunabhängig auf beliebigen Clientbestriebsystemen eingesetzt werden.

Der Einsatz von Eclipse als Framework auf den Arbeitplatzrechnern in einem Unternehmen schafft folgende Vorteile:

• einheitliche Basis für den Einsatz beliebiger Anwendungsprogramme als Java Plug In in heterogenen Clientumgebungen
• sehr offene und flexible Gestaltung der grafischen Clientoberfläche
• alle als Plug In eingesetzten Anwendungsprogrammen können leicht auf eine einheitliche Darstellungsform gebracht werden
• standardisierte Softwareschnittstellen erlauben die Verkettung der eingesetzten Plug Ins untereinander z.B. zum Datenaustausch etc..
• die Integration der einzelnen Anwendungsprogramme in das Eclipse Framework,  vereinfacht den Rollout auf die Arbeitsplätze und in der Folge den Aufwand für die Administration. 

Nachteilig an diesem Konzept ist die Tatsache, dass es die gewünschten Applikationen nicht immer als Eclipse Plug In zur Verfügung stehen.  Das Bedürfnis von Unternehmen nach Applikationen als Eclipse Plug In hat HOB früh erkannt und so stehen heute zwei wichtige Client Applikationen  als Plug In für Eclipse zur Verfügung:

HOBLink J-Term, die erste und leistungsfähigste 3270 Emulationen in Java

• HOBLink JWT, der RDP Client für den Microsoft Terminal Server in Java

Beide Produkte sind bei namhaften Unternehmen im Einsatz. HOB hat großen Wert darauf gelegt, dass die Versionen als Eclipse Pug In denselben Funktionsumfang haben wie die nativen Versionen.

„Look and Feel“ und der Leistungsumfang zwischen den nativen Versionen und den Eclipse Plug In Versionen von HOB sind absolut identisch. Ein Anwender der zuvor mit einer nativen Version gearbeitet hat und auf die Eclipse Plug In Version wechselt kann sofort ohne Umstellung arbeiten.

Weitere Informationen finden Sie unter

www.hob.de

01.03.2010
Klaus Weinbrenner

Ob beruflich oder privat, Arbeitsplätze sind mehr und mehr mit heterogenen Systemen ausgestattet. Wo früher ausschließlich Windows- oder Unix-, bzw. Linux-Geräte im Einsatz waren, so mischt sich heute immer wieder – vielleicht auch Dank iPod, iPhone und iPad – ein Macintosh Rechner in etablierte Umgebungen. Andererseits, wo einst nur Apple mit seinen Design-Gehäusen glänzte, werden inzwischen viele Arbeiten mit den meist günstigeren Windows-PCs erledigt. Der gegenseitige Zugriff auf den entfernten Desktop ist dabei nicht nur praktisch, sondern auch ressourcenschonend.

Üblicherweise wird eine Desktop-Verbindung zu Mac OS X Rechnern durch das VNC-Protokoll realisiert. Das aus der Windows-Welt bekannte RDP Protokoll hat gegenüber VNC einige Vorteile. Zum einen gilt es in der Bildübertragung als das performantere, zum anderen können automatisch lokale Ressourcen, wie z.B. installierte Drucker oder Laufwerke zum Remote-Server gemappt werden.

HOB MacGate bringt diese Vorteile in die Mac-Welt – auf einfache Weise.

Die Serversoftware wird auf dem Mac installiert. Der (am Server konfigurierbare) RDP Port 3389 muss erreichbar sein. Als Client kann z.B. Microsofts Remotedesktopverbindung (Remote Desktop Connection) verwendet werden. Mit HOBLink JWT bietet HOB außerdem einen leistungsfähigen plattformunabhängigen Java Client der mit Hilfe von HOB RD VPN einen sicheren SSL verschlüsselten Zugang von „unterwegs“ auf firmeninterne Rechner ermöglicht.

Performanz ist wichtig, gerade bei Remote Desktop Verbindungen. Deshalb wurde bei HOB bereits zu Beginn der Entwicklung der Software sehr darauf geachtet, schonend mit den Ressourcen des Servers und der Leitungen umzugehen. Nur wenige Threads sind an der Datenaufbereitung und -übertragung beteiligt. Nur tatsächlich notwendige Bildschirmbereiche werden an den Client gesendet. Gerade hier machte sich die langjährige Erfahrung von HOB im Bereich RDP bezahlt. Dies alles gewährleistet, dass HOB MacGate auch bei „langsamen“ Verbindungen eine optimale Darstellung realisiert.

Vermehrt stellen Unternehmen mögliche IT Investitionen hinsichtlich Rentabilität und Kosten-Nutzen Abwägung genauer auf den Prüfstand. Betriebswirtschaftliche Kennzahlen wie etwa der Return on Investment (ROI) können hierbei die Entscheidungsfindung erleichtern.

Definition ROI

Im Rahmen der unternehmerischen Tätigkeit bietet sich der ROI zur Beurteilung von Einzelinvestitionen an. Definiert ist der ROI als ein allgemeiner Ansatz, um die Erträge von Kapitalinvestitionen anzugeben, wobei der Gewinn als prozentualer Anteil an der Investitionssumme ausgedrückt wird.

ROI = (Gewinnanteil / Kapitaleinsatz) x 100

Grundsätzlich gilt, dass eine Investition nur dann vorteilhaft ist, wenn die Amortisation innerhalb der Nutzungsdauer erfolgt. Wird allerdings die Gewinnschwelle innerhalb von 12 Monaten erreicht, ist die Investition als budgetneutral anzusehen.

ROI von HOB RD VPN

Im folgenden wird eine ROI Betrachtung erläutert, welche die Kostenreduktion, entstanden durch den Austausch von herkömmlichen IPsec Lösungen durch HOB RD VPN, verdeutlichen soll.

Ausgangssituation der Beispielrechnung ist ein Versicherungsunternehmen mit 1.000 Mitarbeitern. Ziel ist es, denn 100 Außendienstmitarbeitern (AD) einen sicheren und schnellen Zugriff auf die unternehmensinternen Daten und Anwendungen zu gewährleisten. Folgende Annahmen werden getroffen:          

• Jährliche Wartung der Laptops aller AD-Mitarbeiter Wartung verursacht einen Zeitaufwand für die IT-Abteilung von 60 Minuten je Laptop
• AD-Mitarbeiter muss ¾ Tag (6 Stunden) auf seinen Laptop verzichten, was seine Produktivität zu 50 % einschränkt
• der interne Stundensatz der IT-Abteilung beträgt 60,00€ je Mitarbeiter
• der interne Stundensatz des AD beträgt 70,00€ je Mitarbeiter
• Maintenance-Gebühr IPsec 16,80€ (21% von Preis je User 80,00€)
• Maintenance-Gebühr HOB im 1. Jahr 7,5% und ab dem 2. Jahr 23,5% vom Listenpreis je User (250,00€)

Die jährlich laufenden Kosten der IPsec-Lösung setzen sich wie folgt zusammen:

Tabelle 1

Durch den Einsatz von HOB RD VPN entstehen im ersten Jahr folgende Kosten:

Tabelle 2

Ab dem zweiten Jahr entstehen durch den Einsatz von HOB RD VPN folgende Kosten:

Tabelle 3

Die Formel für den ROI setzt sich, wie bereits oben erwähnt, aus Gewinnanteil / Kapitaleinsatz zusammen. In diesem Beispiel entspricht der Gewinnanteil den Einsparungen, welche durch den Wegfall der IPsec Lösung innerhalb von fünf Jahren realisiert werden können. Diese belaufen sich auf 143.400,00€ (28.680,00€ x 5 Jahre). Der Kapitaleinsatz für HOB RD VPN setzt sich aus den Gesamtkosten im Jahr 1 und aus 4 x jährliche Gesamtkosten ab Jahr 2 zusammen und entspricht 40.300€. Somit ergibt sich ein ROI von 355,83 %. Der ROI im ersten Jahr nach der Anschaffung beträgt in diesem Beispiel 133,40 %. Da sich in diesem Fall die Anschaffung von HOB RD VPN bereits nach weniger als einem Jahr refinanziert hat, ist die Investition budgetneutral.

Fazit ROI

Die ROI Betrachtung liefert den Unternehmensentscheidern auf einfache Weise leicht und schnell aussagekräftige Prozentwerte. Allerdings muss berücksichtigt werden, dass es sich bei der ROI Berechnung um interpretierbare Werte handelt. In diesem Beispiel wird die eingeschränkte Produktivität der Außendienstmitarbeiter als Kostenfaktor angesehen. Dies sind nur unter der Voraussetzung Kosten, wenn die Mitarbeiter während ihrer Arbeitszeit 100 Prozent Leistung erbringen und nicht unproduktiv die Zeit „absitzen“. Des weiteren ist der fehlende Zeithorizont der ROI Betrachtung kritisch zu sehen, da eine Projektinvestition in der Regel über einen längeren Zeitraum läuft. Diese und noch weitere Gründe machen es notwendig, die ROI Ermittlung durch andere Formen der Rentabilitätsrechnung zu ergänzen.

Net Present Value (NPV)

Bei der Kapitalwertmethode werden unter Berücksichtigung von Zinsen und Inflation künftige Kapitalerträge auf einen bestimmten Zeitpunkt umgerechnet. Die Formel sieht wie folgt aus:

Hierbei bezeichnet ”A” die Investition, ”Z” den Rückfluss (Cash Flow), ”i” den Kalkulationszinsfuß (Discount Rate) und ”n” die Anzahl der Jahre. 
Grundsätzlich gilt: Jedes Projekt mit einem positiven NPV erwirtschaftet mehr Geld als es kostet, und sollte deshalb realisiert werden. Projekte, die einen negativen Kapitalwert generieren, kosten mehr als sie einbringen und sollten daher nicht realisiert werden.

Schwierig bei dieser Methode ist die Ermittlung des genauen Cash Flows. Um falsche Entscheidungen zu vermeiden, dürfen nur Kosten berücksichtigt werden, die in den Investitionszeitraum fallen. Kosten die bereits bezahlt sind, bewirken keine Änderung des Cash Flows und spielen deshalb auch keine Rolle.

NPV von HOB RD VPN

Zur Veranschaulichung folgt die Berechnung des Kapitalwertes von HOB RD VPN. Es gelten die selben Annahmen wie in der obigen ROI Berechnung. Die Höhe der Anschaffungskosten für 100 Lizenzen HOB RD VPN belaufen sich auf 20.000,00€, der Cash Flow im Jahr 1 beträgt 27.180,00€ (setzt sich aus den jährlichen Kosten der IPsec- Lösung abzüglich den Maintenance-Gebühr im 1. Jahr zusammen; siehe Tabelle 1 und 2). Der Cash Flow im Jahr 2 beträgt 23.980,00€ (setzt sich aus den jährlichen Kosten der IPsec-Lösung abzüglich den Maintenance-Gebühr im 2. Jahr zusammen; siehe Tabelle 1 und 3), der Kalkulationszinsfuß beträgt 11% und die Laufzeit 5 Jahre.

Berechnung des NPV:

Wie aus der obigen Darstellung eindeutig hervorgeht, ergibt sich ein positiver NPV in Höhe von 71.510,95€. In diesem Beispiel erhält der Investor sein eingesetztes Kapital zurück und eine Verzinsung der ausstehenden Beträge, die den Kalkulationszinsfuß übersteigen.

Gesamt Fazit

Betriebswirtschaftliche Kennzahlen können die Kaufentscheidung in der IT durchaus unterstützen, sollten aber nicht der ausschlaggebende Punkt sein. Vor allem im Bereich der IT Security ist der Hauptmotivator für eine Investition oftmals in der Risikominimierung zu finden und nicht in der Kostenreduktion.

Mehr Informationen zu HOB RD VPN finden Sie unter www.hob.de

04.02.2010 Matthias Höflinger

VPN (Virtual Private Network) wurde früher mit dem IPSec Protokoll (Internet Protocol Security) realisiert. Neuere Lösungen basieren auf SSL (Secure Sockets Layer). Die Lösungen mit SSL können analog zu IPSec Lösungen eingesetzt werden, mit SSL gibt es aber auch Lösungen die vom Prinzip her anders sind als IPSec Lösungen.

In diesem Dokument werden die Unterschiede und Vorteile von SSL gegenüber IPSec erörtert. Dieses Dokument befasst sich ausschließlich mit Lösungen für den Remote Zugriff von Laptops oder PCs.

Im Bereich von Gateway zu Gateway Verbindungen, welche beispielsweise bei der Anbindung von Außenstellen eingesetzt werden, macht SSL keinen Sinn so dass hier weiterhin IPSec eingesetzt wird.

Auch haben Geräte wie das Apple iPhone oder Handies mit Microsoft Windows mobile standardmäßig einen IPSec Client eingebaut, die Vorteile von SSL treffen hier nicht zu, so dass es hier meist keinen Sinn macht IPSec durch SSL zu ersetzen.

Dieses Dokument ist gegliedert in folgende Abschnitte:

1. Wo kann man SSL einsetzen, aber IPSec funktioniert nicht

2. Architektur von Systemen mit IPSec bzw. SSL

3. Komprimierung bei IPSec bzw. SSL

4. Streaming mit IPSec bzw. SSL

1. Wo kann man SSL einsetzen, aber IPSec funktioniert nicht

1.1. nur Zugriff über TCP Port 80 und 443 möglich

Bereiche des Internets wie in Firmen, Hotels oder Wi-Fi Hotspots sind regelmäßig durch Firewalls vom public Internet abgeschirmt. Weil aber generell ein Zugriff aus den abgeschirmten Bereichen möglich sein soll, vorwiegend für die Benutzung des Web-Browsers, sind in den Firewalls Zugriffe über den HTTP TCP Port 80 und den HTTPS TCP Port 443 erlaubt.

Ist in der Firewall nichts anderes konfiguriert so kann IPSec überhaupt nicht verwendet werden.

1.2. Proxies in Firmen-Netzwerken für den Zugriff aufs Public Internet

In vielen Firmen oder Organisationen werden Proxies eingesetzt welche den Zugriff auf das Public Internet regeln. Verwendet werden dabei die Protokolle Socks4/5 und HTTP. Alle gängigen Browser unterstützen den Zugriff über solche Proxies.

Proxies die hier eingesetzt werden sind z.B. Microsoft ISA Server oder Squid (Open-Source). In den Proxies kann verlangt werden dass sich ein Benutzer bzw. ein Gerät authentifiziert bevor es Zugriff auf das Public Internet erhält.

Für die Authentifizierung werden optional verwendet Userid/Passwort, NTLM oder auch Kerberos.

Es ist möglich in solchen Proxies die eingehenden Web-Seiten (HTTP / HTML) auf Viren zu checken. Mit entsprechenden konstruktiven Merkmalen ist es möglich beliebige Daten über diese Viren-Checker zu bekommen; man bekommt auch Viren darüber aber eben nicht mit dem Web-Browser sondern nur mit SSL-Clients.

Mit IPSec kann man solche Proxies generell nicht benutzen, nur mit TCP bzw. SSL ist der Zugriff möglich.

1.3. SSL über den HTTP TCP Port 80

Es gibt auch Installationen, vor allem in Hotels, wo nur Port 80 offen ist, nicht aber der HTTPS/SSL-Port 443. Es ist aber prinzipiell möglich, SSL-Daten über Port 80 zu schleusen, so dass auch hier der Zugriff mit dem Web-Browser bzw. mit SSL Clients möglich ist.

1.4. Kosten für den Internet-Zugriff in Hotels

Es wurde uns berichtet in manchen Hotels gibt es unterschiedliche Preismodelle für den Internet-Zugriff. Es gibt kostenlosen oder günstigen Zugriff über TCP Port 80 / 443 (da kann man SSL verwenden), will man aber IPSec verwenden so muss man ein anderes Preismodell wählen (teuerer).

1.5. preisgünstige Netzwerk-Komponenten

Z.B. wenn User von Zuhause aus eine VPN-Verbindung in die Zentrale aufbauen möchten dann soll in der Regel der Standard-DSL-Anschluss verwendet werden. In der Regel werden hier DSL-Router eingesetzt die auch NAT machen. Uns wurde berichtet bei solchen DSL-Router kann oft kein IPSec eingesetzt werden, oft auch nicht einmal mit NAT-Traversal.

2. Architektur von Systemen mit IPSec bzw. SSL

2.1. Architektur von Systemen mit IPSec

IPSec Lösungen sind in der Regel so aufgebaut dass am Client ein Treiber installiert wird. Dieser installiert im System einen sogenannten virtuellen Adapter. In der Regel kommt aus der Zentrale die INETA welche zur Kommunikation mit den Anwendungen in der Zentrale verwendet wird. Der Treiber im System fängt alle (oder die betreffenden) IP-Pakete ab, verschlüsselt diese und sendet die Pakete über den IPSec-Tunnel in die Zentrale. Pakete aus der Zentrale gehen den umgekehrten Weg. Es gibt auch IPSec-Lösungen mit Komprimierung.

2.2. Problematik von Treibern

Moderne Betriebssysteme sind so designed dass ein fehlerhaftes Programm weder das Betriebssystem zum Absturz bringen kann noch andere Programme stören oder beschädigen kann. Dies wird dadurch erreicht dass eben nur das Betriebssystem kritische Aktionen wie Input/Output oder Speicherverwaltung durchführen darf.

Benötigen Programme solche Aktionen so springen sie über sogenannte APIs ins Betriebssystem, das Betriebssystem prüft ob die Aktion fehlerfrei durchgeführt werden kann und dann führt das Betriebssystem im Auftrag der Anwendung die kritischen Aktionen durch.

Nun kann aber ein Betriebssystem eben von Hause aus nicht alles, dafür gibt es Treiber, Erweiterungen des Betriebssystems.

Treiber dürfen prinzipiell alle Aktionen ausführen, eben auch die kritischen und gefährlichen. Dies ist notwendig weil sonst ja Anwendungen nur das machen könnten was das standardmäßige Betriebssystem vorsieht.

Aus diesen Umständen ergeben sich mehrere Problematiken. Zum einen können fehlerhafte Treiber das gesamte Betriebssystem zum Absturz bringen, bei Windows spricht man dann von einem "blue screen". Beim Absturz des Betriebssystems hat man oft Datenverlust und es stört den Anwender sehr weil er eben ziemlich lange nicht arbeiten kann, eben so lange bis das Betriebssystem neu gebootet hat.

Für Treiber gibt es jeweils im Betriebssystem bestimmte Schnittstellen. Betriebssysteme entwickeln sich fort so dass auch diese Schnittstellen immer wieder verändert werden müssen. Das bedeutet meist dass man für jede Betriebssystem-Version einen bestimmten Treiber benötigt, der aber bei einer neueren Betriebssystem-Version nicht mehr funktioniert.

Bei normalen Anwendungen gibt es diese Problematik nicht weil die Hersteller bei der Entwicklung der Betriebssysteme darauf achten dass die Schnittstellen zu den Anwendungen (APIs) konstant gehalten werden.

Zur Entwicklung von Treiber braucht man qualifizierte Entwickler, solche sind selten. Und im Vergleich zu normalen Anwendungen sind Treiber viel schwieriger und aufwändiger zu entwickeln, debuggen und zu testen.

Zum Abschluss ist zu sagen dass die überwiegende Anzahl von Betriebssystem-Abstürzen ("blue screen") eben nicht Fehler des Betriebssystems selbst sind sondern eben von Treibern.

Microsoft hat mit Windows XP die Funktion Windows Error Reporting (WER) eingeführt. Dadurch wird Online Crash Analysis (OCA) möglich. Wenn Windows abstürzt und ein blue screen erscheint dann wird ein kleiner Core-Dump erzeugt der nach Nachfrage beim Benutzer zu Microsoft gesendet wird. Microsoft war damals sehr erstaunt über die vielen eingehenden Core-Dumps, die große Anzahl hatte man nicht erwartet. Bei der Auswertung der empfangenen Core-Dumps hat dann Microsoft festgestellt dass fehlerhafte Treiber 85% der Probleme ausmachten, der kleinere Rest waren echte Windows Kernel Probleme. Hat man weniger Treiber im System dann hat man entsprechend weniger Ärger und Probleme.

2.3. voller Netzwerk-Zugriff über SSL

Bei einigen SSL-Lösungen gibt es auch den vollen Netzwerk-Zugriff über SSL, analog zu Lösungen mit IPSec. Bei Standard-Lösungen hier wird wieder ein Treiber im Betriebssystem des Clients installiert, analog zu IPSec.

Bei HOB RD VPN mit dem PPP Tunnel hat man in einem neuartigen und zum Patent angemeldeten Verfahren vollen Netzwerk-Zugriff ohne Treiber, ohne Administrator-Rechte und ganz ohne Installation am Client. Die Lösung PPP Tunnel im HOB RD VPN ist Browser-basiert.

Weil bei dieser Lösung alles in der DMZ in der Zentrale installiert ist, und eben nichts am Client, sind Updates der Software viel einfacher durchzuführen was auch erheblich Kosten einspart.

2.4. Zugriff vom Web-Browser des Clients über ein SSL-VPN auf Web-Server in der Zentrale

Eine der ersten und somit grundlegenden Funktionen von SSL-VPNs war der Zugriff nur über den Web-Browser im Client. Greift ein Benutzer zu, so authentifiziert er sich zuerst am SSL-Gateway und hat dann Zugriff auf alle Web-Server in der Zentrale. Dieser Zugriff kann gegebenfalls eingeschränkt durch die Konfiguration des SSL-VPNs; der Benutzer kann dann nur auf vorbestimmte Web-Server zugreifen.

Die Kommunikation zwischen den Client (Web-Browser) und dem VPN-Gateway ist dann SSL-verschlüsselt bzw. HTTPS, zwischen dem VPN-Gateway und den internen Web-Servern über normales HTTP bzw. bei Bedarf wieder über HTTPS bzw. SSL; man spricht dann von Client-side SSL. Diese Funktion klingt relativ simpel, ist aber doch aufwändig weil im VPN-Gateway alle Links in den Web-Seiten umgerechnet werden müssen. Das ist prinzipiell möglich für:

 - HTML
 - CSS
 - Javascript, jscript
 - Ajax

Bei Web-Seiten mit folgendem Inhalt gibt es aber Einschränkungen und generell Probleme:

 - Active-X
 - Flash
 - Silverlight
 - Java

Zusätzlich kann man über den Browser auch Files mit der Zentrale austauschen, und zwar in beide Richtungen. Nicht alle SSL-VPNs beherrschen diese aufwändigen Verfahren zur Umrechnung von Web-Seiten oder zum Austausch von Files.

Bei HOB RD VPN heißt diese Funktion Web Server Gate. Der Austausch von Files heißt Web File Access. Zum einen werden in vielen Firmen vorwiegend oder grundsätzlich nur Web-Applikationen entwickelt bzw. eingesetzt, zum anderen braucht man eben am Client nur den normalen Web-Browser. Deshalb wird diese Art des Zugriffs über SSL-VPNs sehr oft eingesetzt. Bei IPSec VPNs gibt es keine vergleichbaren Funktionen.

2.5. Umleitung von TCP Datenstrom zu localhost

Ein der Basis-Funktionen von SSL-VPNs ist folgende: auf dem Client wird ein kleiner Proxy gestartet, diese wurde vorher als Java-Applet oder als ActiveX-Control von SSL-VPN heruntergeladen. Nun kann man auf dem Client die gewohnten Applikationen starten, diese verbinden sich dann aber nicht direkt zu dem jeweiligen Server sondern es geht erst mal über localhost zum lokalen Proxy. Dazu muss natürlich die Anwendung etwas anders konfiguriert werden.

Der lokale Proxy verschlüsselt die Daten dann per SSL und sendet diese zum VPN-Gateway. Das VPN-Gateway packt die Daten wieder aus und sendet diese zum gewünschten Ziel bzw. Server. Diese Funktion heißt bei HOB Universal Client, ansonsten wird oft von Port-Forwarding gesprochen. Diese Lösung hat gewisse Einschränkungen und funktioniert nur wenn die Client-Applikation ein TCP-Verbindung zum Server aufbaut; umgekehrt ist keine TCP Verbindung möglich wenn diese der Server zum Client aufbauen möchte. UDP kann man ebenfalls nicht verwenden.

Probleme gibt es auch wenn im in den TCP-Daten IP-Adressen übermittelt werden, was z.B. bei FTP oder RDP der Fall ist. Auch bei SIP und RTP werden in den Daten-Paketen IP-Adressen übermittelt, aber hier wird über UDP kommuniziert und Umleitung über localhost ist prinzipiell nicht möglich.

Bei Arbeiten mit lokalem Proxy kann mit RDP für den Windows Terminal Server das Session-Directory nicht verwendet werden weil der RDP Datenstrom eben über einen lokalen Proxy umgeleitet wird.

Beim HOB RD VPN ist SSL direkt im RDP Java Remote Desktop Client HOBLink JWT und im WebSecureProxy realisiert so dass auch hier die Funktion Session-Directory unterstützt wird, anders als bei Lösungen mit lokalen Proxies und Umleitung über localhost.

Die Funktion mit lokalen Proxies und Umleitung über localhost ist genügend in vielen Fällen, bietet aber keinen vollen Netzwerk-Zugriff. Der volle Netzwerk-Zugriff ist in vielen Fällen auch gar nicht erwünscht.

3. Komprimierung bei IPSec bzw. SSL

3.1. Komprimierung bei IPSec

In vielen IPSec-Lösungen ist Komprimierung eingebaut, nach unterschiedlichen Verfahren, meist aber deflate. Bei IPSec werden die Pakete einzeln komprimiert, ein eventuell verwendetes Dictionary muss bei jedem Paket zurückgesetzt werden. Dies geschieht aus dem Grunde weil IPSec ein Protokoll vom Typ connection-less ist. Das bedeutet, Pakete können verloren gehen, es können sich Pakete überholen oder Pakete können mit falscher Checksum beim Empfänger ankommen und dann verworfen werden. Auch werden von Routern in der Übertragungsstrecke Pakete verworfen wenn die Übertragungsstrecke überlastet ist; das ist ein ganz normaler Vorgang der auch bei allen IP-Stacks entsprechend berücksichtigt ist.

IPSec merkt nicht wenn Pakete nicht beim Empfänger ankommen, diese Problematik wird in den höheren Layers behandelt, z.B. im TCP-Stack. Durch die Tatsache dass bei IPSec bei jedem Paket das Dictionary zurückgesetzt wird ist die Komprimierung wenig wirkungsvoll.

Pakete sind bei IPSec meist klein, MTU = Maximum Transmission Unit oder auch Maximum-Receive-Unit (MRU) ist z.B. bei PPP nach RFC 1661 1.500 Bytes. Bei so kleinen Paketen ist keine gute Komprimierung möglich.

Inzwischen gibt es ab Gigabit-Ethernet Jumbo-Packets, bis 16.000 Bytes, da wäre eine bessere Komprimierung möglich, aber bei WAN kann man bisher keine so großen Pakete austauschen.

3.2. Komprimierung bei SSL

SSL ist connection-oriented, also kann hier effizient Komprimierung eingesetzt werden. Web-Browser beherschen z.B. das Komprimierungs-Verfahren zLib. Dies wird im HTTP-Header angegeben. Der Web-Browser selbst sendet keine komprimierten Daten, die Pakete vom Web-Browser zum Web-Server sind ja in der Regel ziemlich klein. Aber der Web-Server (oder ein SSL-Gateway mit der Funktion Web Server Gate) kann die Antwort mit zLib komprimieren und dadurch werden Web-Seiten entsprechend schneller geladen.

Im HOB RD VPN Web Server Gate ist Komprimierung mit zLib eingebaut. Web-Seiten können komprimiert werden auch wenn der ursprüngliche Web-Server die Daten unkomprimiert sendet.

Bei SSL wird durch ein entsprechendes Verfahren die verwendete Cypher-Suite ausgehandelt, das heißt welche Verschlüsselungs-Algorithmen verwendet werden.

Die Firma Netscape hat ursprünglich SSL erfunden und dabei vorgesehen dass beim Aushandeln der Cypher-Suite auch ein Komprimierungs-Algorithmus ausgehandelt werden kann. Deshalb hat HOB in der entsprechenden SSL-Suite eingebaut dass auch Komprimierung verwendet wird, das funktioniert aber nur wenn sowohl am Client als auch am VPN-Gateway die HOB SSL-Suite eingesetzt wird. Es sind außer HOB keine anderen Hersteller bekannt die auf SSL-Ebene komprimieren.

Wird bei HOB RD VPN der PPP-Tunnel mit Komprimierung eingesetzt, und es werden beispielsweise mit dem Windows Explorer Dateien ausgetauscht so findet hier eine wirkungsvolle Komprimierung statt. In der Praxis wurde beobachtet dass der Datenstrom manchmal bis auf 20% herunterkomprimiert wurde. Der Austausch der Dateien geht dann viel schneller, eben so wie mit einer virtuell fünf mal schnelleren Leitung.

4. Streaming mit IPSec bzw. SSL

Applikationen wie Video oder Audio verwenden Streaming, es wird ein kontinuierlicher Datenstrom gesendet. Ein Sonderfall von Streaming ist Real-Time wie z.B. VoIP = Voice over IP. Damit wir die Eignung von IPSec bzw. SSL für Streaming verstehen wollen wir zuerst die Grundlagen betrachten.

4.1. Übertragungsfehler

Wenn Daten übertragen werden können diese Daten durch physikalische Effekte verfälscht werden. Deshalb werden in den Daten-Paketen Prüfsummen eingebaut. Der Sender erzeugt die Prüfsummen und der Empfänger eines Daten-Pakets vergleicht dann ob die Prüfsummen noch stimmen; wenn nicht wird das Daten-Paket verworfen. Eine andere Möglichkeit hat der Empfänger nicht, der Absender im Daten-Paket kann ja auch verfälscht worden sein und deshalb kann der Empfänger den Absender nicht benachrichtigen.

4.2. Überlauf in Routern

Das Internet-Protokoll, kurz IP, ist connection-less. Nehmen wir an wir haben einen Router an den zwei Datenleitungen angeschlossen sind, eine schnelle Leitung 1 und eine langsame Leitung 2. Wenn jetzt der Router in schneller Folge Pakete von Leitung 1 empfängt die er auf Leitung 2 weitersenden soll so kann der Router diese Pakete nicht so schnell über die langsamere Leitung 2 weitersenden. Ein Lösung für dieses Problem ist dass der Router eben diese Pakete zwischenspeichert und dann die Pakete verzögert senden. Aber der Speicher eines Routers ist endlich und deshalb verwerfen Router die Daten-Pakete wenn sie mehr empfangen als die weitersenden können.

4.3. Das Protokoll UDP

Das Protokoll UDP = User Datagram Protocol ist sehr einfach. Ein Sender sendet Pakete, wenn diese Pakete beim Empfänger ankommen ist es gut, wenn nicht passiert auch nichts weiter. Im UDP Protokoll ist nichts eingebaut dass ein Sender irgendwie merkt dass die gesendeten Daten-Pakete nicht angekommen sind.

4.4. Das Protokoll TCP

Das Protokoll TCP = Transmission Control Protocol ist connection-oriented und komplex. Bei TCP ist sichergestellt dass alle Daten-Pakete die eine Anwendung versendet unversehrt, komplett und in der richtigen Reihenfolge beim Empfänger ankommen.

Vereinfacht dargestellt funktioniert das so: Wenn der IP-Stack eines Rechners ein TCP-Paket versenden dann muss der Empfänger innerhalb einer gewissen Zeit (ein Bruchteil einer Sekunde) eine Bestätigung erhalten. Empfängt der sendende IP-Stack keine Bestätigung, entweder weil das gesendete Paket verloren ging, der Empfänger gar nicht mehr lebt oder auch weil die Bestätigung verloren ging, so wiederholt der sendende IP-Stack dieses Paket. Wenn nach einer gewissen Anzahl von Wiederholungen immer noch keine Bestätigung gekommen ist so meldet der IP-Stack diesen Fehler an die Anwendung.

4.5. Eignung von UDP bzw. TCP für Streaming

Für Streaming, insbesondere Real-Time, verwendet man in der Regel UDP, nicht TCP. Wenn ab und zu ein Paket bei Streaming verloren geht ist das kein großes Problem. Wenn aber wie bei TCP durch Wiederholungen von Paketen das Streaming nicht kontinuierlich funktioniert dann ist das ein gewisses Problem.

4.6. Eignung von IPSec bzw. SSL für Streaming

IPSec ist wie UDP connection-less, Pakete werden vom IPSec-Layer nicht wiederholt, und deshalb ist IPSec gut geeignet für Streaming.

SSL basiert auf TCP. Bei SSL ist konstruktiv eingebaut dass alle Pakete bei Empfänger unversehrt, komplett und in der richtigen Reihenfolge eintreffen müssen, ansonsten funktioniert die Kryptographie von SSL nicht.

SSL ist deshalb weniger gut für Streaming geeignet. Ein Ausweg aus diesem Problem ist parallel zu SSL eine verschlüsselte UDP-Verbindung aufzubauen und dann die Streaming-Daten auf diesem Wege zu versenden, wenn möglich. Genau das ist in der HOB-Lösung VoIP HOBPhone eingebaut.

4.7. Erfahrungen aus der Praxis

Streaming über IPSec funktioniert gut. In der Regel funktioniert Streaming über SSL genauso gut weil Übertragungsfehler heutzutage relativ selten vorkommen.

Quellen:

Microsoft
DEVELOPING DRIVERS WITH THE WINDOWS DRIVER FOUNDATION
Penny Orwick, Guy Smith
ISBN-13: 978-0-7356-2374-3
ISBN-10: 0-7356-2374-0

02.05.09 KB
04.05.09 KB
12.06.09 KB