Unternehmensübergreifende IP-Videokonferenzen

Sichere Kommunikation über Firewalls hinweg

12. Juni 2005, 23:06 Uhr | Dr. Andreas Barsch/pf Dr. Andreas Barsch ist Geschäftsführer von Isys-Team.

IP-Videokonferenzen sind bislang in der Regel auf das Unternehmensnetz beschränkt. H.323-Kommunikation über Firewalls und NAT hinweg ist technisch problematisch und erfordert hohen administrativen Aufwand. Doch die Hersteller bieten inzwischen spezielle Lösungen für solche Anwendungszenarios. Ein Beispiel ist Expressway von Tandberg. Der Beitrag erklärt das technische Prinzip und beschreibt die Einsatzmöglichkeiten in der Praxis.

Die Technik der IP-Videokonferenzsysteme ist ausgefeilt und – zumindest unternehmensintern – gut
einsetzbar. Allerdings entsteht der eigentliche Wert der visuellen Kommunikation erst dann, wenn
sie auch problemlos unternehmensübergreifend genutzt werden kann. Bisher kamen hierfür
entsprechende Gateways zum Einsatz, die IP-basierende Videokonferenzen aus dem Inhouse-Netz auf das
öffentliche ISDN umsetzen. Die damit verbundenen Kosten für Gateway und Verbindungen
(Kanalbündelung mehrerer ISDN-Kanäle, um adäquate Bandbreite zu erreichen) sind nicht zu
unterschätzen. Eine interessante Alternative zeichnet sich mit durchgängig IP-basierenden
Videokonferenzen ab. Allerdings haben zwei Aspekte die Verbreitung solcher IP-basierender Lösungen
bisher stark behindert:

Security: Die Firewalls der Unternehmen verhindern das Einwählen fremder
Videokonferenzteilnehmer.

Rufnummernplan: Es existiert kein einheitliches unternehmensübergreifendes
Adressierungsschema.

Firewalls dienen der Unterbindung ungeplanter, also unerlaubter Kommunikationsbeziehungen von
außerhalb des Unternehmens nach innen. Dies verhindert insbesondere Attacken auf die Ressourcen des
internen Kommunikationssystems. Aus diesem Grund sind typischerweise nur Kommunikationsbeziehungen
von innen nach außen zulässig. Im Fall der visuellen Kommunikation geht es aber zunehmend mehr um
Ad-hoc-Verbindungen zwischen verschiedenen Teilnehmern mit externen Initiatoren. Das eingesetzte
Protokoll H.323 verwendet dynamische Ports und etabliert drei Kommunikationsbeziehungen:

Signalisierung (TCP),

Video-Stream (UDP) und

Voice-Stream (UDP).

Für eine klassische Firewall ist es daher fast unmöglich, einen sinnvollen Kompromiss aus
Sicherheitsbedürfnis und Kommunikationserlaubnis zu etablieren. Inzwischen haben sich
Firewall-Hersteller auf dieses Thema eingestellt und ihre Lösungen mit den verschiedensten
Mechanismen ausgestattet, um das H.323-Protokoll und seine Unterprotokolle kontrolliert passieren
zu lassen. Cisco Systems stattet beispielsweise ihre Pix-Firewall mit einer "
Con-text-Based-Access-Control"-Funktion aus (CBAC), die dynamisch Ports öffnet und schließt. Auch
andere Hersteller haben mit so genannten H.323-Proxies Lösungen geschaffen, die dem Problem
Rechnung tragen. Allerdings bedeutet jede der diesbezüglichen Varianten eine komplette Umstellung
der Firewalls oder wenigstens ein Upgrade mit dem entsprechenden administrativen Aufwand.

Tunnel für Videokonferenzen

Einen völlig anderen Weg geht beispielsweise der norwegische Hersteller für
Videokonferenzsysteme (VC) Tandberg: Die kürzlich vorgestellte Lösung namens Expressway besteht aus
mehreren Komponenten, die je nach Anwendungsszenario zum Einsatz kommen. Kernstück des Ensembles
ist ein so genannter Border Controller, der auf der öffentlichen Seite der Firewall oder in der DMZ
zu positionieren ist. Zu diesem Border Controller unterhalten "Expressway-fähige" interne
VC-Clients eine entsprechende Kommunikationsbeziehung, die im Wesentlichen aus einem
Registrierungsvorgang und einer zyklischen Keep-alive-Sequenz besteht. "Expressway-fähig" sind
allerdings nur bestimmte Produkte dieses Herstellers wie beispielsweise alle MXP-Systeme und der
Gatekeeper von Tandberg. Durch letztgenanntes Gerät können aber auch alle älteren Systeme sowie
standardkonforme Produkte anderer Hersteller von dieser Lösung profitieren.

Aus der Sicht der Firewall sind jetzt nur die Kommunikationsbeziehungen der internen Geräte mit
dem Border Controller zu legitimieren und entsprechend drei Ports zu öffnen. Da es sich hier um
ausgehende Kommunikation handelt, entstehen keine Sicherheitsrisiken. Administrativ bleibt der
Aufwand minimal. Der wichtigste Aspekt ist jedoch, dass keine Einschränkungen hinsichtlich des
Firewall-Typs existieren: Dieses Szenario lässt sich mit jeder beliebigen Firewall realisieren.

Kommunikationssuchende externe (Expressway-fähige) VC-Clients benutzen den Border Controller als
Vermittlungsstelle und adressieren darüber den gewünschten internen Partner. Eine Verbindung wird
nur zu direkt registrierten internen Teilnehmern oder über den internen Gatekeeper hergestellt.
Dies erfolgt unter Nutzung der zuvor von innen etablierten Verbindungen. Diese "Tunnel" erlauben
das problemlose und gefahrlose Passieren der Firewall für die externen Kommunikationsbeziehungen.
Der Border Controller fungiert dabei de facto als Relay: Die Verbindungen mit den externen
VC-Clients werden nicht direkt in den "Tunnel" geleitet, sondern immer über den Border Controller
gehalten. Dieses Prinzip löst auch das Problem der Adressübersetzung (NAT), das aus Sicherheits-
und Adresseinspargründen fast überall zum Einsatz kommt. Folglich besteht weiterhin komplette
Anonymität für die beteiligten Kommunikationspartner: Keiner kennt die wahren IP-Adressen des
anderen.

Praxistest

Derartige neue Techniken und Produkte erzeugen Neugier und Skepsis. So wurde in den Labors des
Berliner IP-Telefonieintegrators Isys-Team ein relativ aufwändiger Praxistest aufgesetzt, der
Aufschluss über die Tauglichkeit der Lösung im Alltag geben sollte. Aus früheren Tests waren die
komplexen Firewall-Konstrukte zur unternehmensübergreifenden IP-Kommunikation noch bestens bekannt.
Es wurde zunächst ein Szenario entsprechend Bild 1 realisiert. Die reinen H.323-Clients (Microsoft
Netmeeting und Tandberg 1000) sind dabei über den Gatekeeper (Tandberg) beim Border Controller (BC)
registriert, während Client 3 und 4 als Expressway-fähige Clients (Tandberg MXP) direkt am BC
angemeldet sind. Für die internen Kommunikationspartner des Border Controllers sind lediglich die
entsprechenden Ports zur ausgehenden Kommunikation an der Firewall freigeschaltet. Tatsächlich ließ
sich bereits nach wenigen administrativen Schritten auf BC und Gatekeeper die Kommunikation von
Client 4 zu allen internen Clients ohne Einschränkungen aufbauen. Die verwendete Firewall war
Linux-basierend (Suse).

Rufnummernplan in der Praxis

Zwischen verschiedenen Unternehmen existiert zum Zweck der IP-basierenden Ad-hoc-Kommunikation
(Video, Voice) bislang kein einheitlicher Rufnummernplan. Als Alternative kamen bisher sowohl
Voice- als auch Video-Gateways mit Übergang in das öffentliche ISDN-Netz zum Einsatz. Mit der
Expressway-Lösung ist dieser Umweg überflüssig, da der im Internet etablierte Domain Name Service
(DNS) einen adäquaten Ansatz erlaubt. Border Controller lassen sich mit ihrer öffentlichen
IP-Adresse und dem bereitgestellten Service (H.323) im DNS registrieren, sodass bei bekannter
Domain die IP-Adresse auflösbar ist. Wegen der schon beschriebenen Anmeldung interner Clients am
jeweils lokalen BC lässt sich jetzt der Weg zu jedem internen Client eines anderen Unternehmens
(andere Domäne) finden und über Firewalls hinweg eine Kommunikation dorthin aufbauen. Bild 2
illustriert eine entsprechende Infrastruktur, die zur Verifikation der Funktionalität im Praxistest
zum Einsatz kam. Das benutzte Wählverfahren heißt URI-Dialing (Uniform Resource Identifier) und
adressiert – wie bei einer E-Mail-Adresse – das Ziel (Client 3) als Teilnehmer an einer Domäne, zum
Beispiel "client3@isys-team.de". Der rufende Teilnehmer (Client 4) wählt "client3@isys-team.de" auf
seiner Tastatur und erreicht seinen lokalen Border Controller (BC2), der sich per DNS nach der
IP-Adresse des Border Controllers (Protokoll: H.323) der Domäne isys-team.de erkundigt.

Nach deren Ermittlung nimmt BC2 Verbindung mit BC1 auf und signalisiert den Verbindungswunsch.
Da Client 3 bei BC1 bekannt ist, wird über die Firewall bei diesem ein Verbindungswunsch
signalisiert und bei Annahme eine entsprechende Bestätigung über BC1 nach BC2 zu Client 4 geleitet.
Anschließend steht die Voice- und Videoverbindung über die beiden Border Controller und durch die
beiden Firewalls hindurch, ohne dass die IP-Adressen unternehmensübergreifend bekannt sein müssen.
Die Domäne repräsentiert im übertragenen Sinn die Vorwahl des Unternehmens und der Teilnehmername
die Durchwahl. In der Praxis ließ sich diese Verfahrensweise nach Bekanntmachung der Border
Controller im öffentlichen DNS-System problemlos verifizieren.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lampertz GmbH & Co. KG

Matchmaker+