IP-basierte Sprachkommunikation ist in internen Unternehmensnetzen zunehmend etabliert und weiterhin auf dem Vormarsch. Doch wie steht es um das Thema Sicherheit in der internen Infrastruktur und was sind mögliche Methoden und Verfahren, damit Unternehmen ihr Know-how oder unternehmenskritische Informationen nicht leichtfertig aufs Spiel setzten beziehungsweise ungewollt preisgeben?
Beim Blick auf den Status quo wird deutlich, dass sich der Wandel hin zu All-IP noch immer in der Phase mit zunehmender Beschleunigung befindet. Das heißt, neben all jenen Aktivitäten, die derzeit durch Netzbetreiber und Carrier vorangetrieben werden, um ihre Kunden weg von klassischen Netzzugängen via ISDN oder Analog zu bewegen, wird bereits in den internen Netzwerkinfrastrukturen seit längerer Zeit IP-basierte Sprachkommunikation eingesetzt und zunehmend umgesetzt. Nicht zuletzt durch die Tatsache, dass die interne Kommunikation von Unternehmen in jüngster Zeit verstärkt mit den Themen UC (Unified-Communications) und UCC (Unified-Communications & Collaboration) konfrontiert wurde, finden sich in vielen Unternehmen bereits heute, zum Teil tief integrierte, IP-basierte Kommunikationsdienste und Applikationen. Diese sind essenzieller Bestandteil des Austauschs mit Kunden und Geschäftspartnern. Folglich ist eine Abhängigkeit entstanden, die ihre Empfindlichkeiten hat.
Dieselbe Infrastruktur für alle Dienste und Anwendungen
Beim Thema Verfügbarkeit ist man bereits sehr sensibel geworden. Blickt man in diesem Kontext auf das Thema Sicherheit, so sollte dies mindestens genauso sorg-fältig behandelt werden. Allerdings wird man feststellen, dass bei einer nicht zu vernachlässigenden Anzahl dieser Lösungen der Aspekt Sicherheit unterrepräsentiert ist. Durch den Wegfall der physikalischen Trennung von Sprach- und Datennetzen ist ein grundlegendes Sicherheitsmerkmal im „Vorbeigehen“ verschwunden. Es gibt nur noch ein Kabel für alle Dienste. Die Dichte der Dienste und Applikationen in der Netzwerkinfrastruktur nimmt weiter zu und somit auch die Notwendigkeit, sich Gedanken über deren Sicherheit zu machen. Oftmals liegt es nicht daran, dass die jeweiligen Dienste und Services keine Sicherheitsfunktionalitäten bereitstellen, sondern schlicht daran, dass diese Sicherheitsmerkmale nicht mit implementiert werden.
Beim Transport von Sprachdaten werden in der Regel zwei getrennte Protokollströme verwendet. Mit SIP (Session-Initiation-Protocol) werden die für die Verbindung notwendigen Signalisierungsdaten transportiert. Eingebettet befindet sich das Protokoll SDP (Session-Description-Protocol), das diejenigen Daten beinhaltet, die die Eigenschaften und Parameter des Nutzdatenstroms beschreiben, der mittels des Protokolls RTP (Real-Time Transport-Protocol) transportiert wird. Sieht man sich die Inhalte eines Verbindungsaufbaus mittels SIP und SDP etwas genauer an, so sind die Parameter wie Sender- und Empfängerdaten, Sprachcodecs und unterstützte Funktionalitäten, die für eine Verbindung zur Verfügung stehen, zu sehen. Wollte man einen Vergleich zur klassischen ISDN-Technologie ziehen, so könnte man eine gewisse funktionale Ähnlichkeit zum ISDN-D-Kanal annehmen. Allerdings steckt in SIP viel mehr, da es nicht auf die Signalisierung von Verbindungen für Sprachdaten limitiert ist.
Bei Betrachtung der SDP-Pakete wird eine Problematik sofort offensichtlich: Die über das Netzwerk übertragenen Informationen sind im Klartext vergleichbar mit dem Zugriff auf eine Webseite mittels HTTP. Mit etwas Übung können hier nahezu sämtliche Parameter sofort verstanden und interpretiert werden. Das heißt, es bereitet kaum Schwierigkeiten, sich Kenntnis über die Verbindungspartner und Eigenschaften einer ungesicherten VoIP-Verbindung zu verschaffen. Zudem bietet jeder Zugangspunkt eines Netzwerks, zum Beispiel ungesicherte Netzwerkdosen oder Wifi-Zugänge, einen potenziellen Angriffspunkt. In den Daten aus SIP und SDP sind allerdings keine Informationen des eigentlichen Gesprächsinhaltes – Audiodaten – enthalten. Diese werden im Nutzdatenstrom mittels RTP zwischen Sender und Empfänger transportiert. Mit einem der gängigsten Sprachcodecs, dem G.711 mit 64 kBit/s Bandbreite und identischer Sprachqualität wie ISDN, werden VoIP-Pakete alle 20 ms übertragen – also 50 Pakete pro Sekunde:
64.000 Bits / 50 Pakete = 1.280 Bits pro Paket = 160 Bytes pro Paket.
Um die Daten als VoIP-Daten zu kennzeichnen, benötigt das Paket einen 12 Byte großen RTP-Header. Für den Transport über ein IP-basiertes Ethernet-Netzwerk kommen noch weitere Header hinzu.
Ein UDP-Header (User-Datagram-Protocol, 8 Bytes), ein IP-Header (20 Bytes) und ein Ethernet-Header (22 Bytes) mit CRC-Prüfsumme (Cyclic-Redundancy-Code, 4 Bytes).
160 Bytes + 12 Bytes + 8 Bytes + 20 Bytes + 22 Bytes + 4 Bytes = 226 Bytes
Ein VoIP-Paket ist demnach in einem Netzwerk 226 Bytes groß. Ein dreiminütiges Telefonat ergibt somit eine relativ überschaubare Datenmenge von wenigen Megabytes. Kennt man nun Verbindungseigenschaften, Adressen von Sender und Empfänger, so ist der Weg zum Aufzeichnen der Gesprächsdaten nicht mehr allzu weit. Ein unzureichend konzipiertes Netzwerk und ungeeignete Komponenten würden ihr übriges dazu beitragen, dem interessierten Sprachdatenschnüffler Tür und Tor zu öffnen.