Sichere VoIP-Telefonie über unsichere Netzwerke

Posted by ittnerkn Wed, 22 Sep 2010 08:55:00 GMT

Das Internet hat die Welt verändert. Menschen schreiben keine Briefe mehr sondern E-Mails, das Tagebuch heißt nun Blog und wird öffentlich geführt und man ist weltweit über eine Festnetznummer erreichbar.

Sie fragen sich wie das funktionieren soll? Die Antwort lautet VoIP1. Die meisten größeren Unternehmen verwenden bereits IP-Telefonie für die interne Kommunikation. Durch Verwendung von gesicherten Tunnelverbindungen lassen sich weltumfassende Telefonnetze aufspannen welche die vorhandenen Netzwerke und das Internet nutzen. Hierdurch entfallen die sonst notwendigen Kosten für die Verwendung herkömmlicher Telefonie. Auch externe Mitarbeiter oder Heimarbeiter lassen sich auf diese Weise an das Firmennetzwerk angliedern und sind so über ihre Firmennummer erreichbar und können bei ausgehenden Telefonaten mit der Rufnummer der Firma in Erscheinung treten.

Die Umsetzung gestaltet sich jedoch nicht so einfach wie es hier scheinen mag, da zunächst einige grundlegende technische Probleme gelöst werden müssen. Einige werden im folgenden Text näher beschrieben.

VPN-Lösungen benötigen Administration

Die Integration externer Rechner ins Firmennetzwerk erfordert administrative Tätigkeiten sowohl auf dem Client-Rechner als auch auf den betroffenen Rechnern des Firmennetzwerks. Damit ein Administrator die Sicherheit des Netzwerks garantieren kann ist es erforderlich, dass die Nutzer keine Veränderungen an den betroffenen Systemen vornehmen können. Somit ist der Einsatz am heimischen PC des Mitarbeiters nicht möglich. Die Nutzung ist nur mit firmeneigenen Rechnern möglich – eine nicht besonders flexible Lösung. Zudem verringert sich die Sicherheit des Firmennetzwerkes, da potentielle Einfallstore geöffnet werden müssen.

SIP und RTP sind (manchmal) sicher

Die gängigen Protokolle SIP2 und RTP3 verfügen zwar über sichere Varianten (SIPS bzw. SRTP), diese werden jedoch nur verwendet wenn beide/alle Gesprächsteilnehmer diese unterstützen und entsprechend konfiguriert sind. Im Regelfall ist davon auszugehen dass die ungesicherten Varianten zum Einsatz kommen.

Netzwerke haben Grenzen

Betrachten wir ein internes Gespräch:

Zum Aufbau des Gesprächs sendet der Anrufende eine bestimmte Nachricht, ein sogenanntes INVITE (Einladung) an den Gesprächspartner. Diese Nachricht enthält neben der Nummer und dem Namen des Anrufers auch die IP des Telefons. Als Anlage zu der Einladung werden über ein zweites Protokoll Informationen zu den unterstützten Medienformaten ausgetauscht (SDP4). Dies beinhaltet auch den Port des Telefons, auf dem der Anrufende Daten des jeweiligen Medientyps empfangen möchte.

Der Angerufene sendet, insofern er das Telefonat annehmen möchte, eine OK-Nachricht zurück, an die ebenfalls SDP-Informationen angehängt sind. Hierzu entfernt er alle nicht unterstützten Formate aus der empfangenen SDP-Nachricht und ergänzt seine eigenen IP- und Portdaten.

Auf Protokollebene wird nicht unterschieden, ob der Angerufene ein Endgerät oder ein Telefonieserver ist. Telefonieserver vermitteln die SIP-Nachrichten an den tatsächlichen Empfänger und nehmen hierzu ggf. Veränderungen an den Inhalten vor. Für die Gesprächsteilnehmer ist dieser Vorgang nicht relevant.

Befindet sich der Anrufer nun hinter einer Firewall außerhalb des Firmennetzwerkes und versucht über den firmeneigenen Telefonieserver zu telefonieren ergibt sich folgendes Bild:

Für die Firewall des Unternehmens stellt der Anrufer einen fremden Rechner dar, der versucht mit einem bestimmten Rechner innerhalb der Firma in Verbindung zu treten. Damit dies funktionieren kann benötigt der Telefonieserver eine öffentliche IP oder Anfragen müssen von der Firewall entsprechend umgesetzt werden.

Beides ist aus dem Blickwinkel der Datensicherheit keine bevorzugte Lösung, da eine sensible Komponente der Firmeninfrastruktur – der Kommunikationsknoten – für Angreifer erreichbar wird.

Failure by design – das SIP-NAT-Problem

Ein weiteres Problem liegt im SIP-Protokoll selbst. Wie zuvor beschrieben beinhalten die Protokollnachrichten die IPs der jeweiligen Quell- und Zielrechner. In der Regel werden sich Endgeräte jedoch hinter einer Firewall und/oder einem Router befinden und verfügen deshalb über eine IP aus den nicht-öffentlichen Bereichen (10.0.0.* oder 192.168.*.*). Somit sind diese nicht aus dem Internet erreichbar. Selbst wenn ein Telefonieserver durch die Firewall erreichbar ist, wird der Verbindungsaufbau fehlschlagen, da der Anrufende eine private IP genannt hat und somit vom Telefonieserver nicht erreichbar sein wird.

Um dieses Problem zu lösen wurde ein weiteres Protokoll entwickelt, das sogenannte STUN5-Protokoll. Dieses ermöglicht es einem Gerät bei einem STUN-Server im Internet anzufragen und hierdurch die eigene IP-Adresse und den verwendeten Port zu ermitteln. Der STUN -Server muss im Internet direkt erreichbar sein. Um Spoofing-Attacken, also das Vortäuschen einer anderen IP und somit das Abfangen der Datenpakete zu verhindern muss der STUN-Server vertrauenswürdig sein. Dies erfordert eine umfassende Absicherung und somit zusätzlichen administrativen Aufwand. Trotzdem ist die Funktion nicht gewährleistet, da die Anfrage mit einem Port X erfolgen kann, die Firewall des Anrufers jedoch beim Aufbau des Telefonats den Port Y verwendet. Um die Funktionssicherheit zu erhöhen müssen UDP-Ports dauerhaft geöffnet werden, was wiederum die Sicherheit verringert.

Quo vadis VoIP?

In der vorangehenden Darstellung lassen sich folgende Problembereiche identifizieren:

  • Anbindung externer Endgeräte erfordern hohen administrativen Aufwand bei der Verwendung virtueller Netzwerke.
  • Verwendung der sicheren Protokollvarianten erfordert zwingend die Verwendung von entsprechenden Endgeräten.
  • Verwendung über das Internet erfordert die Verwendung von STUN-Servern in Verbindung mit festgelegten und geöffneten Ports. Dies erhöht wiederum den Aufwand und senkt die Sicherheit des eigenen Netzwerks.

Ist VoIP-Telefonie deshalb unsicher?

Ja und nein. Im internen Netzwerk ist VoIP-Telefonie als hinreichend sicher zu betrachten, da hier durch andere Maßnahmen die Integrität und Sicherheit gewährleistet werden kann.

Netzwerk übergreifend ist eine hinreichende Sicherheit bei VoIP-Telefonie nicht oder nur mit hohem technischen Aufwand gewährleistet. VPN-Lösungen erfordern Administration und sind somit unflexibel. STUN-Server verringern die Sicherheit und erhöhen den Aufwand. Firewalls die SIP-Nachrichten manipulieren und entsprechende Änderungen vornehmen sind zwar verfügbar, jedoch haben diese auch ihren Preis und erzwingen in der Regel die Bindung an einen bestimmten Hersteller.

Eine mögliche Lösung – HOB RD VPN

Keine der gezeigten Varianten erfüllt die Anforderungen an geringen administrativen Aufwand und gleichzeitig hinreichender Sicherheit der Gesprächsdaten und -inhalte. Aus diesem Grund entwickelt HOB derzeit einen eigenes Softphone als Erweiterung zu HOB RD VPN.

Kernfunktionen dieses Softphones sind unter anderem:

  • Keine lokale Installation notwendig. Eine aktuelle Java6 VM auf dem verwendeten Rechner ist ausreichend.
  • Zentrale Konfiguration: der Nutzer erhält seine Konfiguration automatisch beim Applikationsstart.
  • Gesicherte Kommunikation über TCP/SSL bzw. UDP/SRTP unabhängig von den Fähigkeiten der anderen Gesprächsteilnehmer (betrifft den Datenverkehr im Internet).
  • Kommunikation über Standard-Ports mit Komponenten die höchste Sicherheitsstandards erfüllen.
  • Keine zusätzliche Konfiguration der Firewall erforderlich (abhängig vom gewählten Betriebsmodus sind minimale Änderungen notwendig).

HOB RD VPN verfügt somit über die Fähigkeit ohne großen Aufwand das firmeneigene Telefonnetz flexibel zu erweitern und gibt Mitarbeitern die Möglichkeit unabhängig von ihrem Schreibtisch telefonisch erreichbar zu sein.

September 2010, Dipl. Ing. IT Heino Stömmer

1 VoIP: Voice over IP – Bezeichnung für die Verwendung von Sprachkommunikation über IP-Netzwerke
2 SIP: Session Initiation Protocol – Eine Empfehlung der IETF zum Aufbau von Sitzungen jeglicher Art, nicht ausschließlich Telefonaten
http://tools.ietf.org/html/rfc3261
3 RTP: Real-Time Transport Protocol – Ein Datenaustauschprotokoll für Mediendaten (Audio/Video)
http://tools.ietf.org/html/rfc1889
4 SDP: Session Description Protocol – Ein Protokoll zum Ermitteln gemeinsamer Formate und deren Parameter
http://tools.ietf.org/search/rfc4566
5 Session Traversal Utilities for NAT – ein Protokoll um die Internet-IP eines Gerätes zu ermitteln das sich hinter einer Firewall befindet
http://tools.ietf.org/html/rfc5389
6 Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

keine Kommentare |


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