Sicherheitsbewertung der Open Source Telefonanlage 'Asterisk' unter besonderer Berücksichtigung verschiedener VoIP-Protokolle

INHALTSVERZEICHNIS

II ABBILDUNGSVERZEICHNIS

III TABELLENVERZEICHNIS

IV ABKÜRZUNGSVERZEICHNIS

1. EINLEITUNG
1.1 UNTERSCHIEDE ZWISCHEN KLASSISCHER TELEFONIE UND VOIP-TELEFONIE
1.2 VOR- UND NACHTEILE VON VOIP GEGENÜBER KLASSISCHER TELEFONIE

2. GRUNDLAGEN DER IP-BASIERTEN NETZE
2.1 DAS TCP/IP-MODELL
2.2 ADRESSIERUNG IN TCP/IP-NETZEN
2.3 DAS ADDRESS RESOLUTION PROTOCOL (ARP)
2.4 DAS INTERNET PROTOCOL (IP)
2.5 DAS INTERNET CONTROL MESSAGE PROTOCOL (ICMP)
2.6 DAS TRANSMISSION CONTROL PROTOCOL (TCP)
2.7 DAS USER DATAGRAMM PROTOCOL (UDP)

3. GEGENSTAND DER UNTERSUCHUNG
3.1 ASTERISK UND ASTERISK@HOME
3.2 ARCHITEKTUR UND FUNKTIONSWEISE VON ASTERISK
3.3 AUFBAU DER TESTUMGEBUNG
3.4 VORSTELLUNG DER VERWENDETEN SOFTPHONES UND HARDPHONES

4. AUFBAU DER VERWENDETEN VOIP-PROTOKOLLE
4.1 DAS SESSION INITIATION PROTOCOL (SIP)
4.2 DAS SESSION DESCRIPTION PROTOCOL (SDP)
4.3 DAS REAL-TIME TRANSPORT PROTOCOL (RTP)
4.4 DAS INTER-ASTERISK EXCHANGE PROTOKOLL (IAX)
4.4.1 Datagramm-Struktur
4.4.2 IAX-Verbindungen zwischen Endgeräten
4.4.3 IAX-Verbindungen zwischen zwei Asterisk-Servern

5. DURCHFÜHRUNG DER SICHERHEITSBEWERTUNG
5.1 INFORMATIONSBESCHAFFUNG UND -AUSWERTUNG
5.1.1 Auffinden von Hosts
5.1.1.1 ICMP Echo Scanning
5.1.1.2 ICMP-Broadcast
5.1.1.3 Weitere ICMP-Nachrichten
5.1.1.4 TCP Scanning
5.1.1.5 UDP Scanning
5.1.1.6 ARP Scanning
5.1.1.7 Passives Scanning
5.1.1.8 Praktische Anwendung
5.1.2 Identifizierung von Betriebssystem und angebotenen Services
5.1.2.1 Unterscheidung von Port-Scanning und Fingerprinting
5.1.2.2 Praktische Durchführung von Port-Scanning und Fingerprinting
5.2 AUFDECKEN VON SCHWACHSTELLEN DER VOIP-KOMMUNIKATION
5.2.1 Kompromittierung der Vertraulichkeit
5.2.1.1 Aufzeichnen von SIP-Gesprächen
5.2.1.2 Aufzeichnen von IAX-Verbindungen
5.2.1.3 Auffangen und Entschlüsseln von Passwörtern der VoIP-Kommunikation
5.2.2 Kompromittierung der Authentizität
5.2.2.1 Replay-Attacken auf SIP-Verbindungen
5.2.2.2 Einspielen und Abhören eines RTP-Stroms in Echtzeit
5.2.2.3 Vortäuschung einer fremden Identität
5.2.3 Beeinträchtigung der Verfügbarkeit
5.2.3.1 Ausnutzung von Implementierungsfehlern der Protokolle
5.2.3.2 Ressourcenüberlastung durch Einsatz von DoS-Tools

6. EMPFEHLUNGEN ZUR ERHÖHUNG DER SICHERHEIT
6.1 ERWEITERUNGEN DES SIP-PROTOKOLLS
6.1.1 SIP mit S/MIME-Bodies
6.1.2 SIP-Secure (SIPS)
6.1.3 Secure RTP (SRTP)
6.1.4 SIP über IPSec
6.2 SICHERHEITSEMPFEHLUNGEN FÜR ASTERISK UND DAS IAX-PROTOKOLL

7. AUSBLICK UND FAZIT

ANHANG A - Ausschnitt aus den Konfigurationsdateien von Asterisk

ANHANG B - Ergebnisse der Nmap -Scans

LITERATUR- UND QUELLENVERZEICHNIS

II Abbildungsverzeichnis

Abbildung 1: Funktionsweise eines Jitter-Buffers

Abbildung 2: Vergleich zwischen OSI-Modell und TCP/IP-Modell

Abbildung 3: Prinzip der Datenkapselung

Abbildung 4: Datenbezeichner auf den einzelnen Schichten des TCP/IP-Modells

Abbildung 5: Aufbau eines Ethernet-Rahmens

Abbildung 6: Aufbau eines ARP-Paketes

Abbildung 7: Aufbau des IP-Datagramm-Header

Abbildung 8: Aufbau eines TCP-Segmentes

Abbildung 9: Der Drei-Wege-Handshake -Mechanismus von TCP

Abbildung 10: Aufbau eines UDP-Headers

Abbildung 11: Architektur von Asterisk

Abbildung 12: Darstellung der Testumgebung

Abbildung 13: Registrierung der Endgeräte an den Asterisk-Servern

Abbildung 14: SIP-Verbindungsaufbau

Abbildung 15: Beispiel einer SDP-Nachricht

Abbildung 16: Aufbau eines RTP-Headers

Abbildung 17: Beispiel eines RTP-Headers

Abbildung 18: Beispiel eines RTCP-Paketes

Abbildung 19: IAX Full-Frame Binär Format

Abbildung 20: IAX Mini-Frame Binär Format

Abbildung 21: IAX Peer Registration

Abbildung 22: Vollständiger Ende-zu-Ende Medien-Austausch

Abbildung 23: Die ICMP-Broadcast-Methode

Abbildung 24: ARP-Request und -Reply

Abbildung 25: Ergebnis des Ping-Scans von Nmap

Abbildung 26: Darstellung des Nmap -Ping-Scan in Ethereal

Abbildung 27: Ergebnis des TCP-Version-Scan des Asterisk-Servers

Abbildung 28: Ergebnis des UDP-Scan des Asterisk-Servers

Abbildung 29: Durchführung eines ARP-Spoofing

Abbildung 30: Abhörmöglichkeiten bei Einsatz eines SIP-Proxy-Servers / Asterisk-Servers

Abbildung 31: IAX-Kommunikations-Szenario bei Einsatz von CommView

Abbildung 32: Abspielen aufgezeichneter IAX-Pakete mit Hilfe von CommView

Abbildung 33: Weiterleitung des Verbindungsaufbaus zwischen Asterisk-Server und Windows-Client

Abbildung 34: Auswahl der IAX-Mini-Frames in CommView

Abbildung 35: Abweichung der Timestamps bei Replay von IAX-Paketen

Abbildung 36: Austausch von Authentifizierungsinformationen bei Aufbau einer SIP-Verbindung

Abbildung 37: Darstellung einer SIP-INVITE-Nachricht

Abbildung 38: Austausch von Authentifizierungsinformationen bei der Registrierung eines SIP-UA

Abbildung 39: Screenshot des SIP-Passwort-Bereiches in Cain & Abel

Abbildung 40: Screenshot des Passwort-Crackers von Cain & Abel

Abbildung 41: Registrierung des IAXComm -Client

Abbildung 42: REGREQ-Nachricht mit MD5-Challenge-Result

Abbildung 43: Verwendete UDP-Ports der RTP-Medienströme

Abbildung 44: Problematische Header-Felder bei Replay von RTP-Paketen

Abbildung 45: Unterschiedliche SSRC’s bei Replay von RTP-Paketen in eine neue Verbindung

Abbildung 46: Konfiguration des RTP-Stroms in JMStudio

Abbildung 47: Eingabe der Ziel-Adresse in JMStudio

Abbildung 48: Abhören von Kommunikation in Echtzeit

Abbildung 49: Anzeige der Reregistrierung in der Log-Datei von Asterisk

Abbildung 50: Standard-SIP-INVITE-Request von SIPp

Abbildung 51: SIP-Verbindungsaufbau durch SIPp

Abbildung 52: Von SIPp gesendeter, korrekter INVITE-Request

Abbildung 53: INVITE-Request mit Call-ID

Abbildung 54: Erstellung einer Refer-Nachricht in SiVuS

Abbildung 55: IAX-NEW-Nachricht in CommView -Editor

Abbildung 56: Transfer Request zur Verbindung von Endgeräten

Abbildung 57: Erstellung und Versand einer BYE-Nachricht in SiVuS

Abbildung 58: Erstellung einer NOTIFY-Nachricht in SiVuS

Abbildung 59: Nachrichtenfluss bei Aufbau einer NOTIFY-Subscription

Abbildung 60: Generierung einer INFO-Nachricht in SiVuS

Abbildung 61: Vulnerability-Scanner von SiVuS

Abbildung 62: HTML-Report einer SiVuS -Evaluierung des Asterisk-Servers

Abbildung 63: Änderung der Source Call Number in einem IAX-Mini-Frame

Abbildung 64: Upload-Kapazität des Linux-Rechners bei Verwendung von FUDP

Abbildung 65: Aufbau eines SRTP-Paketes

Abbildung 66: Ergebnis des TCP-Version-Scan des Linux-PC

Abbildung 67: Ergebnis des TCP-Version-Scan des Cisco-Telefons

Abbildung 68: Ergebnis des UDP-Scans des Linux-PC

Abbildung 69: Ergebnis des UDP-Scans des Cisco-Telefons

III Tabellenverzeichnis

Tabelle 1: Gerätekonfiguration der Testumgebung

Tabelle 2: Telefonnummernvergabe

Tabelle 3: Auszug aus Datei „sip.conf“ von Asterisk

Tabelle 4: Auszug aus der Datei „iax.conf“ von Asterisk

Tabelle 5: Auszug aus der Datei „extensions.conf“ von Asterisk

IV Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Das Voice over Internet Protocol (VoIP) beschäftigt sich mit der Übertragung von Echtzeitkommunikation in paketorientierten Netzen wie dem Internet, im Gegensatz zur klassischen verbindungsorientierten Kommunikation, wie dies beim durchschaltevermittelten Telefonnetz der Fall ist. VoIPTelefonie wird dabei zunehmend zur Konkurrenz der klassischen Telefonie. Große Telefonkonzerne erweitern ihr Portfolio um VoIP-Lösungen [ARC05] und auch kleinere Unternehmen bieten Produkte für Firmenkunden und Privatverbraucher an.

Durch die Einführung der VoIP-Technologie ergeben sich für den Kunden Vorteile, die durch Ver- schmelzung der Telefon- und Datennetze ermöglicht werden. Weltweite Erreichbarkeit, neue An- wendungen wie „Click-To-Dial“¹ und nicht zuletzt Kosteneinsparungen durch Reduzierung der Netzwerkinfrastruktur sind schlagkräftige Argumente, die für eine weitere Durchsetzung der VoIP- Telefonie sprechen. Obwohl es möglich ist, sich mittels Hard- oder Softphone direkt beim eigenen Provider anzumelden, wird dies bei steigender Anzahl der Endgeräte, sowie bei höheren Ansprü- chen an die Komfortfunktionen der eigenen Telefonanlage, unpraktikabel. Zu diesem Zweck exis- tieren Telefonnebenstellenanlagen (Private Branch Exchange, PBX), die sowohl die Verwaltung angeschlossener Endgeräte übernehmen, als auch zusätzliche Funktionen wie Least-Cost-Routing (LCR), Voice-Mail-Systeme oder Warteschlangen- und Spracherkennungsmodule, z. B. für den Einsatz in einem Call-Center, bieten.

Da die Bedeutung von VoIP kontinuierlich steigt, soll diese Arbeit Aufschluss darüber geben, wie sicher bzw. unsicher Kommunikation per VoIP ist. Dabei wird der Schwerpunkt insbesondere auf das auch kommerziell weit verbreitete Session Initiation Protocol (SIP) sowie die Software- Telefonanlage Asterisk und dessen proprietäres Protokoll Inter Asterisk eXchange (IAX) gelegt. Zusätzlich soll gezeigt werden, welchen Einfluss Asterisk auf die Sicherheit der Kommunikation hat, d. h. ob durch Einsatz eines Asterisk-Servers evtl. neue Schwachstellen entstehen oder ob dieser zur Reduktion der Risiken beitragen kann. Es soll untersucht werden, unter welchen Bedin- gungen die Herstellung einer Verbindung unmöglich gemacht werden kann, bzw. wie eine beste- hende Verbindung gestört oder unterbrochen werden kann. Ein weiterer Aspekt ist das Aufzeigen von Möglichkeiten zum Abhören einer Kommunikationsverbindung und zum Fälschen von Authen- tifizierungsinformationen. Diese beiden Möglichkeiten bieten dabei auch das größte Schadenspo- tential, da Angriffe im Regelfall unbemerkt durchgeführt werden und einerseits sensible Informatio- nen in den Besitz des Angreifers gelangen können sowie andererseits die Authentifizierungsinfor- mationen z. B. dazu genutzt werden können, um auf Kosten des Opfers zu telefonieren. Zur kon- kreten Beschreibung, welche Verfahren angewandt werden können, um die erwähnten Angriffe zu realisieren, wird eine Testumgebung eingerichtet, die aus verschiedenen Endgeräten und zwei Asterisk-Servern besteht. Eine genaue Beschreibung von Asterisk und des Aufbaus der Testum- gebung folgt in Kapitel 3. Anhand der Ergebnisse der Untersuchungen sollen zum Abschluss eine qualifizierte Bewertung des tatsächlichen Gefahrenpotentials sowie Empfehlungen zur Reduktion des Sicherheitsrisikos bei VoIP-Telefonaten erfolgen. Da es in der Fachliteratur bisher wenige Quellen gibt, die sich mit diesem Thema und insbesondere Asterisk bzw. dem IAX-Protokoll beschäftigen, resultiert daraus nicht zuletzt auch eine praktische Relevanz.

1.1 Unterschiede zwischen klassischer Telefonie und VoIP-Telefonie

Bevor näher auf die Protokolle eingegangen wird, auf denen die VoIP-Technologie basiert, sollen zunächst die grundlegenden Unterschiede zwischen der klassischen Telefonie und der Telefonie über IP-basierte Netze erläutert werden.

Das klassische Telefonnetz basiert auf einem durchschaltevermittelten Netzwerk. Dieses, auch Public Switched Telephone Network (oder PSTN) genannte Netzwerk, stellt eine direkte Verbin- dung zwischen Gesprächsteilnehmern her, indem exklusiv ein Kanal reserviert wird, über den alle Daten zwischen Quelle und Ziel fließen. Da Netzwerk-Ressourcen dem Kanal zugeordnet werden, führt dies im Allgemeinen zu einem zeit-basierten Abrechnungssystem. Die Verbindung wird im Regelfall aufgrund der von der rufenden Endstelle vorgegebenen Zielinformationen aufgebaut und nach Beendigung des Nachrichtenaustausches wieder abgebaut [Bat02]. Die Steuerung des Auf- und Abbaus der Verbindung wird von Vermittlungsstellen vorgenommen, wobei im öffentlichen Telefonnetz zwei Arten zum Einsatz kommen: zum einen Fernvermittlungsstellen, die die oberste Ebene bilden und stark miteinander vermascht sind. Diese besitzen häufig Netzübergangsfunktio- nen, um Gespräche aus dem eigenen Netz in die Netze anderer nationaler Telefongesellschaften weiterleiten zu können. Die untere Ebene bilden dagegen Ortsvermittlungsstellen, die sternförmig an die Fernvermittlungsstellen angeschlossen werden und die Kundenanschlüsse verwalten.

In Deutschland wurden im Jahr 1996 die letzten analogen Vermittlungsstellen durch digitale Ver- mittlungsstellen ersetzt. Diese wandeln die analoge Sprache in digitale Daten um, die dann über den reservierten Kanal ausgetauscht werden, der in der Regel eine Bandbreite von konstant 64 kbit/s bzw. ein ganzzahliges Mehrfaches davon (z. B. für Videokonferenzen) aufweist [WIK05]. Die Umwandlung der analogen Sprachsignale in digitale Daten wird mit Hilfe der Puls-Code- Modulation (PCM) vorgenommen, wobei das analoge Signal mit einer bestimmten Frequenz in zeitgleichen Abständen abgetastet wird, in diesem Fall mit einer Abtastrate von 8 kHz. Da jeder Wert als 8-Bit-Zahl übertragen wird, wird so die Bandbreite von 64 kbit/s erreicht (8 kHz * 8 bit = 64 kbit/s) [DaP00].

Im Gegensatz dazu handelt es sich bei IP-basierten Netzen um paketvermittelte Netze. Hierbei wird keine feste Leitung zwischen Gesprächsteilnehmern vermittelt, sondern Nachrichten werden in einzelne Datenpakete, sog. Datagramme, verpackt und als eigenständige Einheiten an den Empfänger gesendet. In jedes Datagramm werden Kontrollinformationen integriert, die es befähigen, sich den Weg zum Empfänger unabhängig von anderen Datagrammen zu suchen. Pakete müssen daher den Empfänger nicht unbedingt in der korrekten Reihenfolge erreichen, bzw. können auf dem Weg zum Empfänger verloren gehen.

In VoIP-Netzen wird Sprache in Echtzeit in Pakete umgewandelt. Protokolle werden verwendet, um Signalisierungsinformationen auszutauschen, mit denen ein Gespräch auf- oder abgebaut werden kann sowie um die eigentlichen Sprachdaten auszutauschen. Die VoIP-Protokolle, die hierfür benutzt werden, basieren dabei auf den Protokollen des TCP/IP-Modells, welches in Kapitel 2 ausführlich erläutert wird.

Die Paketierung und Versendung von Sprache verläuft nach diesem Schema [Bat02]:

1. Das analoge Sprachsignal wird per PCM in einen digitalen Strom von 128 kbit/s umge- wandelt.
2. Das Leitungs-Echo wird aus dem PCM-Strom entfernt und evtl. eine „Silence Suppression“ durchgeführt, mit der verhindert werden soll, Daten derjenigen Zeit zu senden, in der der Sender nicht spricht.
3. Der resultierende PCM-Strom wird durch ein Codierungsverfahren, wie z. B. G.729A komprimiert, was zu einem 10 ms langen Rahmen mit 10 Byte Sprachdaten führt.
4. Die einzelnen Rahmen werden in Sprach-Pakete integriert. Wird SIP als VoIP-Protokoll eingesetzt, erfolgt die Übertragung der Sprach-Pakete per Realtime Transfer Protocol (RTP). Der Rahmen wird in ein RTP-Paket verpackt, welches an ein UDP-Paket ange- hängt wird. Das UDP-Paket wiederum wird an einen IP-Header angefügt. Dieses Prinzip der Kapselung wird in Kapitel 2 veranschaulicht.
5. Das Paket wird durch das Netz geschickt, wobei Router und Switches das Paket anhand der Ziel-Adresse in den Header-Informationen an den Empfänger weiterleiten.
6. Erhält der Empfänger ein Paket, so durchläuft dieses den Prozess aus 4. in der umgekehr- ten Reihenfolge. Zusätzlich muss der Empfänger, ausgehend von den Header- Informationen der Pakete, dafür sorgen, dass die Pakete in der korrekten zeitlichen Rei- henfolge zu Sprachinformationen zusammengesetzt werden.

1.2 Vor- und Nachteile von VoIP gegenüber klassischer Telefonie

Obwohl dem PSTN eine etablierte Technik zugrunde liegt, ist insbesondere in der Geschäftswelt in letzter Zeit der Wunsch entstanden, in eine neue Technologie zu investieren, bei der Sprachübermittlung in einem Datennetzwerk stattfindet. Dies hat folgende Gründe [DaP00]:

- Daten haben Sprache als den primären Verkehr auf den ursprünglich nur für Sprache aus- gelegten Netzen abgelöst. Daten-Verkehr besitzt allerdings andere Charakteristika als Sprach-Verkehr, beispielsweise die Nachfrage nach höherer Bandbreite und die variable Belegung der Bandbreite.
- Im PSTN können neue Funktionen nicht schnell genug entwickelt und eingesetzt werden: Mit zunehmendem Wettbewerb im Telekommunikationsmarkt, suchen Anbieter nach Mög- lichkeiten, sich von Konkurrenten abzusetzen. Dies kann durch das Anbieten neuer Funk- tionen und Anwendungen geschehen. Das PSTN beruht allerdings auf einer Infrastruktur, bei der allein die Hersteller der Systeme Anwendungen für diese entwickeln können.

Die Einführung der VoIP-Technologie entspricht dem Wunsch der Zusammenführung von Sprachund Datennetz. Der Einsatz von VoIP bietet dem Anwender eine Reihe von Vorteilen gegenüber dem PSTN [Wal05]:

- Die Konvergenz von Sprach- und Datennetzen bei Einsatz von VoIP führt zu Kostenein- sparungen, da die IP-Netzwerke, auf denen VoIP basiert, in jedem Unternehmen vorzufinden sind. So kann beim Aufbau eines VoIP-Netzes auf bereits vorhandene Netzwerkkomponenten zurückgegriffen werden, die bisher für Anwendungen wie Internet-Zugriff, verteilte Datenbanken o. ä. eingesetzt werden.
- Eine effizientere Verwendung der verfügbaren Bandbreite ist möglich: Im PSTN wird für je- de Verbindung ein 64 kbit/s-Kanal reserviert, wohingegen VoIP nur die tatsächlich benötigte Bandbreite für den Austausch von Paketen belegt.
- VoIP ermöglicht neue Anwendungen, wie Unified Messaging² oder Click-To-Dial, und bie- tet auf diese Weise Anbietern von VoIP-Telefonie die Möglichkeit, sich von Mitbewerbern abzugrenzen. Den Endanwendern versprechen diese Applikationen eine gesteigerte Produktivität und eine Erhöhung des Komforts.
- Ein flexibler Zugriff auf Kommunikationsgeräte wird möglich. Dies bedeutet auf der einen Seite, dass ein Anwender überall auf der Welt mit seinen VoIP-Zugangsdaten erreichbar sein kann. Da VoIP auf der IP-Technologie basiert, können auf der anderen Seite neue Ar- ten von Endgeräten, die über einen geeigneten Netzwerkanschluss verfügen, für die Kom- munikation per VoIP erschlossen werden, z. B. Set-Top-Boxen oder Personal Digital As- sistants (PDA’s).
- Bandbreite wird beim Einsatz von VoIP dynamisch zugewiesen, daher lassen sich variable Abrechnungstarife einführen. So kann z. B. statt der gängigen Abrechnung nach der Dauer der Verbindung auch eine Abrechnung nach übertragenem Daten-Volumen stattfinden.
- Pakete können sich eine neue Route durch das Netzwerk suchen, falls einzelne Teile des Netzes ausfallen sollten. Fällt ein an der Kommunikation beteiligtes System im PSTN aus, wird die Verbindung unterbrochen.

Doch VoIP besitzt im Vergleich mit dem PSTN auch einige Nachteile, die insbesondere die Qualität der Verbindung betreffen: da keine dedizierten Kanäle mit einer reservierten Bandbreite zwischen Endpunkten geschaltet, sondern nur logische Verbindungen aufgebaut werden, können keine Dienstgütegarantien für eine Verbindung getroffen werden. Die Dienstgüte von Übertragungskanä- len wird auch Quality of Service (QoS) genannt und setzt sich aus einer Reihe von Eigenschaften wie Paketverlustrate, Latenz und Verzögerungsschwankungen zusammen.

Paketverluste in Datennetzen können durch zuverlässige Protokolle wie TCP ausgeglichen werden, indem verlorene Pakete erneut gesendet werden. Bei der VoIP-Telefonie kommt es jedoch auf eine verzögerungsfreie Übertragung der Daten in Echtzeit an, so dass für den Transport auf ein unzuverlässiges Protokoll wie UDP zurückgegriffen werden muss (s. Kapitel 2). Ein IP-Netz kann Pakete verwerfen, wenn das Netz stark überlastet ist. Bestimmte Codec-Algorithmen können zwar geringe Mengen von Paketverlusten korrigieren; ein zu hoher Verlust von Paketen bedingt jedoch eine schlechte Verbindungsqualität durch Sprünge und Aussetzer.

Unter der Latenz oder auch absoluten Verzögerung wird die Zeit verstanden, die es dauert, Pakete vom Sender zum Empfänger zu schicken. Eine Verzögerung von ca. 150 ms ist für eine Sprachverbindung akzeptierbar; unter höheren Latenzzeiten leidet die Verbindungsqualität, da die Teilnehmer eine deutliche Pause in der Übertragung wahrnehmen.

Die Latenz setzt sich aus zwei Komponenten zusammen: der fixen Netzwerk-Verzögerung, die u. a. durch die Encodierung und Paketierung der Sprache entsteht und der variablen NetzwerkVerzögerung, die auftritt, wenn Netzwerkanbindungen überlastet sind und Pakete deswegen zurückgehalten werden.

Verzögerungsschwankungen werden auch als Jitter bezeichnet. Hierunter ist die Abweichung zwischen der erwarteten Ankunftszeit und der tatsächlichen Ankunftszeit eines Paketes zu verstehen. VoIP-Geräte besitzen einen sog. Jitter Buffer, in dem Pakete zwischengespeichert werden, um Verzögerungsschwankungen in einen konstanten Paketfluss umzuwandeln. Wenn neue Pakete eintreffen, der Puffer jedoch gefüllt ist, da er zu gering dimensioniert ist, so werden Pakete verworfen. Ein zu großer Puffer hingegen erhöht die absolute Verzögerung, da erst eine bestimmte Anzahl von Paketen im Puffer gesammelt werden muss [DaP00].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Funktionsweise eines Jitter-Buffers

Neben diesen Nachteilen, die die Verbindungsqualität betreffen, existieren auch Nachteile, die aus der für VoIP verwendeten Infrastruktur resultieren. So sind die verwendeten Computersysteme z. B. anfällig gegen Viren und auch Fehlkonfigurationen von Programmen oder Systemen können eine Kommunikation per VoIP unmöglich machen. Ein weiteres Problem, das die Telefonie über Datennetze kennzeichnet, betrifft den Sicherheitsaspekt. Da Datennetze seit jeher von Angreifern bedroht werden, besteht diese Gefahr auch für die VoIP-Telefonie. Welche Möglichkeiten sich einem Angreifer bieten, um Authentizität, Vertraulichkeit und Verfügbarkeit von VoIP-Systemen zu gefährden, wird in Kapitel 5 dargelegt.

2. Grundlagen der IP-basierten Netze

Die VoIP-Technologie beruht auf IP-basierten Netzen, daher soll ein Verständnis für die Funktionsweise dieser Netze geschaffen werden. Es werden die Protokolle und Mechanismen des TCP/IP-Modells erläutert, da die im weiteren Verlauf der Untersuchung vorgestellten VoIPProtokolle auf diesen aufbauen und das Verständnis der beschriebenen Angriffsmethoden ebenfalls nur mit diesem Wissen möglich ist.

2.1 Das TCP/IP-Modell

Zum Verständnis der Abläufe in einem Netzwerk ist eine standardisierte Darstellung der verschie- denen Protokollebenen hilfreich. Zu diesem Zweck wurde für die Internet-Protokoll-Familie das TCP/IP-Modell entwickelt, bei dem es sich um ein Schichtenmodell handelt, das den Aufbau und das Zusammenwirken der Netzwerkprotokolle beschreibt. Es existieren vier aufeinander aufbauen- de Schichten mit jeweils eigenen Protokollen, so dass auch der Begriff „Protokollstapel“ gebräuch- lich ist. Das Prinzip der Schichten wurde eingeführt, damit eine Schicht die angebotenen Dienste der darunter liegenden Schicht in Anspruch nehmen kann. Daher braucht die Schicht, die die Dienstleistung in Anspruch nimmt, keine Kenntnisse darüber zu haben, auf welche Weise die ge- forderten Daten erbracht werden. So wird eine strikte Aufgabenteilung der Schichten erreicht.

Das TCP/IP-Modell ähnelt in seiner Struktur dem Open Systems Interconnection- (OSI)- Referenzmodell, wurde jedoch vor diesem entwickelt und besitzt anstatt der sieben Schichten des OSI-Modells nur vier Schichten. Dies beruht darauf, dass im TCP/IP-Modell die Bitübertragungsund Datensicherungsschicht des OSI-Modells zu einer Schicht, sowie die oberen drei Schichten des OSI-Modells zu einer Anwendungsschicht, zusammengefasst sind [Hol02].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Vergleich zwischen OSI-Modell und TCP/IP-Modell [Tan98]

Die einzelnen Schichten erfüllen folgende Funktionen:

- Anwendungsschicht: Die Anwendungsschicht umfasst alle höherschichtigen Protokolle, die mit Anwendungsprogrammen zusammenarbeiten, wie z. B. FTP (File Transfer Protocol) oder HTTP (Hypertext Transfer Protocol).
- Transportschicht: Die Transportschicht ermöglicht die Kommunikation zwischen Quell- und Ziel-Hosts, indem eine Ende-zu-Ende-Verbindung hergestellt wird. Es werden auf dieser Ebene mehrere Protokolle definiert. Eines dieser Protokolle ist das Transmission Control Protocol (TCP), durch das Daten zuverlässig und verbindungsorientiert übermittelt werden können. Das User Datagram Protocol (UDP) hingegen ist ein unzuverlässiges und verbin- dungsloses Protokoll mit wenig Protokolloverhead, das in erster Linie verwendet wird, wenn eine schnelle Datenübermittlung erforderlich ist.
- Internetschicht: Die Internetschicht ist für die Weitervermittlung und das Routing der Pakete zuständig. Daher ist es die Aufgabe dieser Schicht, das nächste Zwischenziel (Hop) für ein empfangenes Paket zu ermitteln und das Paket dorthin weiterzuleiten. Protokolle auf die- ser Ebene sind u. a. das Internet Protocol (IP) und das Address Resolution Protocol (ARP).
- Datensicherungs- und Bitübertragungsschicht (auch: Netzwerkschicht): Diese Schicht enthält keine Protokolle der TCP/IP-Familie, stattdessen macht das TCP/IP-Modell an dieser Stel- le Gebrauch von bereits definierten Protokollen wie Ethernet (IEEE 802.3) oder WLAN (IEEE 802.11) [Hol02].

Durch die Aufgabentrennung der einzelnen Schichten durchlaufen Daten, die von einer Anwen- dung über das Netzwerk verschickt werden, den TCP/IP-Protokollstapel von der Anwendungs- schicht bis zur Netzwerkschicht. An die Daten fügt jede Schicht Kontrollinformationen in Form ei- nes Protokollkopfes an, die für das Routing der Daten benötigt werden. Dieses Vorgehen wird Kapselung genannt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Prinzip der Datenkapselung (vgl. [Hun97])

Jede Schicht hat ihre eigenen, unabhängigen Datenstrukturen und damit auch eine eigene Terminologie für diese. Anwendungen, die TCP verwenden, bezeichnen ihre Daten als Strom, wohingegen Anwendungen, die UDP als Transportprotokoll einsetzen, ihre Daten als Nachrichten bezeichnen. In TCP werden Daten Segmente genannt; in UDP heisst die Datenstruktur Paket. Auf der Internetschicht werden alle Daten als Blöcke angesehen, die Datagramme genannt werden. Das auf der Netzwerkschicht eingesetzte Ethernet-Protokoll bezeichnet zu übermittelnde Daten als Frames oder Rahmen [Hun97]. Auch unabhängig von dem verwendeten Protokoll oder dessen Schicht, ist der Begriff des „Paketes“ für einen Datenblock gebräuchlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Datenbezeichner auf den einzelnen Schichten des TCP/IP-Modells (vgl. [Hun97])

2.2 Adressierung in TCP/IP-Netzen

Im Rahmen dieser Arbeit wird ein Ethernet-Netzwerk verwendet. Unter dem Begriff Ethernet fasst man eine Reihe von Netztechnologien zusammen, die die Adressierungart, das Rahmenformat und die Zugriffskontrolle auf das Übertragungsmedium gemeinsam haben. Die Ethernet-Spezifikation wurde von der Organisation Institute of Electrical and Electronics Engineers (IEEE) entwickelt. Das Synonym Ethernet steht seitdem stellvertretend für alle unter der Arbeitsgruppe 802.3 standardi- sierten Spezifikationen, die sich durch die Übertragungsgeschwindigkeit, das Übertragungsverfah- ren und die verwendete Verkabelung unterscheiden lassen. Dass im Versuchsaufbau eingesetzte Netzwerk kann z. B. als ein 100Base-TX-Ethernet nach der Spezifikation 802.3u klassifiziert wer- den, da die Systeme Netzwerkkarten mit einer Kapazität von 100 MBit/s verwenden und diese mit sog. Twisted Pair -Netzwerkkabeln der Kategorie 5 an einen Switch mit einer Kapazität von 1000 MBit/s angeschlossen sind.

Das Ethernet ist ein packetvermittelndes Netz, d. h. Daten werden in einzelne Pakete aufgeteilt, die Frames oder Rahmen genannt werden. Ein Rahmen enthält neben den eigentlichen Daten auch die Zieladresse, die Quelladresse sowie Steuerinformationen. Die Adressen des Ethernet bestehen aus sechs Bytes, die meist durch je zwei Hexadezimal-Zeichen pro Byte und getrennt durch einen Doppelpunkt, dargestellt werden. Jede Netzwerkkarte besitzt eine weltweit eindeutige Ethernetad- resse, die auch Media Access Control, oder MAC-Adresse genannt wird. Der erste Teil der MAC- Adresse enthält einen herstellerspezifischen Code, wobei dem ersten Bit eine besondere Bedeu- tung zukommt. Wird dieses Bit gesetzt, handelt es sich nicht um eine individuelle Adresse, sondern um eine Multicast -Adresse, die eine Gruppe von Empfängern bestimmt. Werden alle Bits der MAC- Adresse gesetzt, so handelt es sich um eine Broadcast-Adresse, so dass der Rahmen an alle Sys- teme des Subnetzes gesendet wird [TEC05].

Ein Ethernet-Rahmen hat folgenden Aufbau:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Aufbau eines Ethernet-Rahmens [TEC05]

Die Präambel dient der Synchronisation des Empfängers und zeigt den Start des EthernetRahmens an. Darauf folgen die Ziel- und Quelladressen sowie ein Längenfeld, das auch als Typfeld bezeichnet wird und den Typ des Protokolls angibt (z. B. IP oder ARP). Anschließend folgt ein Datenfeld, das mind. 46 Byte und max. 1500 Byte an Daten enthalten kann sowie zum Abschluss ein Cyclic Redundancy Check -Feld (CRC-Feld), das eine Prüfsumme beinhaltet, die es ermöglicht, Übertragungsfehler zu erkennen [TEC05].

Um eine Zuordnung der physikalischen Ethernet-MAC-Adressen zu den vom IP-Protokoll verwen- deten logischen Adressen zu ermöglichen, wird das Address Resolution Protocol (ARP) verwendet.

2.3 Das Address Resolution Protocol (ARP)

Die Zuordnung von Ethernet-Adressen zu IP-Adressen geschieht mit Hilfe des ARP-Protokolls. Jeder Knoten in einem Netzwerk führt eine Tabelle mit Zuordnungsdaten von Ethernet- zu IPAdressen, die ARP-Tabelle oder auch ARP-Cache genannt wird. Die Tabelle wird dynamisch verwaltet, da sich die Zuordnungen jederzeit ändern können.

Möchte ein Knoten A ein Datagramm an einen Knoten B schicken, dessen IP-Adresse noch nicht im ARP-Cache von A hinterlegt ist, so schickt A eine Anfrage an alle Knoten im eigenen Netz. Dies geschieht, indem ein ARP-Request an die Broadcastadresse des eigenen Netzes gesendet wird und von dort an alle Knoten verteilt wird. Der Request enthält die Ziel-IP-Adresse von B und die eigene IP-Adresse von A. Erkennt Knoten B seine eigene Adresse in dem ARP-Request, so sendet er ein ARP-Reply mit seiner Ethernet-Adresse an A. Zusätzlich ergänzt er seinen ARP-Cache mit der Adresse von A, da B davon ausgeht, in Zukunft Daten mit A auszutauschen. Knoten A erhält nun die Antwort und aktualisiert seinerseits den ARP-Cache. Sobald dieser Schritt abgeschlossen ist, kann A beginnen, Daten an B zu senden. Damit der ARP-Cache aktuell bleibt, werden nicht benutzte Einträge nach 15 Minuten entfernt [TEC05].

Ein ARP-Paket besitzt den folgenden Aufbau:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Aufbau eines ARP-Paketes [UNI06]

Das Paket schließt direkt an den Ethernet-Header an und da es sehr kurz ist, müssen in der Regel zwischen dem ARP-Paket und dem CRC-Feld des Ethernet-Headers zusätzliche Bytes eingefügt werden, um die minimale Länge eines Ethernet-Rahmens von 64 Byte zu erreichen. Zusätzlich zu den physikalischen und logischen Adressen enthält das Paket einen Hardwaread resstyp, der den Typ der MAC-Adresse bestimmt („1“ für Ethernet) und einen Protokolladresstyp, der den Protokolltyp beinhaltet, der für die MAC-Adresse angefordert wird. Das Feld Operation enthält den Wert „1“ für einen ARP-Request und „2“ für ein ARP-Reply [UNI06].

2.4 Das Internet Protocol (IP)

Das Internet Protocol ist im Request for Comment (RFC) 791 spezifiziert und stellt die Basisdienste für die Übermittlung von Daten in TCP/IP-basierten Netzen bereit. Da IP ein verbindungsloses und unzuverlässiges Protokoll ist, müssen diese Funktionen, falls gewünscht, von den Transportprotokollen der Transportschicht, z. B. TCP, übernommen werden [Hol02].

IP definiert als Dateneinheiten Datagramme sowie ein Adressierungsschema, mit dessen Hilfe die Datagramme durch das Netz geroutet werden können. Außerdem stellt IP die Schnittstelle zwi- schen der Transportschicht und der Netzwerkschicht dar und erlaubt so eine Übermittlung der Da- ten zwischen diesen beiden. Die Fragmentierung und die Zusammensetzung von übergroßen Da- tagrammen gehören ebenfalls zum Funktionsumfang von IP, da dies erforderlich wird, wenn ein max. 65536 Byte langes IP-Paket z. B. per Ethernet übertragen wird. Ethernet-Rahmen besitzen eine max. Länge von 1500 Byte und somit muss das IP-Paket in mehrere Datagramme aufgeteilt werden.

„Hauptaufgaben des Internet Protokolls sind die Adressierung von Hosts und das Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemühen (‚best effort’) von der Quelle zum Ziel befördert, unabhängig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enthält keine Funktionen für die Ende-zu-Ende-Sicherung oder für die Flusskontrolle.“ [Hol02]

IP-Adressen sind 32 Bit lang und im Gegensatz zu Ethernet-Adressen hierarchisch aufgebaut.

„Der erste Teil der IP-Adresse bezeichnet ein Netzwerk und der zweite Teil einen Knoten. Dadurch vereinfacht sich das Routing, da zunächst nur die Netzwerkadresse ausgewertet werden muss.“ [TEC05]

Es existieren die fünf Klassen A-E, in die IP-Adressen eingeteilt werden können, von denen für praktische Anwendungen nur die Klassen A-D von Interesse sind. Jede Klasse besitzt eine be- stimmte Anzahl von Netzen und Knoten, die zur Verfügung stehen. Ein Netz der Klasse B kann beispielsweise 65.534 Knoten verwalten. Durch die Erstellung von Subnetzen lassen sich diese Netze weiter unterteilen; dies bringt z. B. Performance-Vorteile, da ein Paket, das an die Broad- cast-Adresse gesendet wird, nur noch an die Hosts des Subnetzes weitergeleitet wird.

Möchte ein Knoten ein Datagramm verschicken, muss die IP-Adresse analysiert werden. Zu Be- ginn wird die Netzwerkadresse überprüft; stimmt diese mit der Netzwerkadresse des Knotens überein, liegt das Ziel in dessen eigenem Netz und der Knoten kann die physikalische Adresse ermitteln und das Datagramm zustellen. Wenn sich das Ziel außerhalb des eigenen Netzwerkes befindet, so wird das Datagramm an einen Router weitergeleitet, der als Schnittstelle zu externen Netzen dient [TEC05].

Ein IP-Header hat das Format:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Aufbau des IP-Datagramm-Header [Hun97]

Die Felder haben folgende Bedeutung [RFC81]:

Abbildung in dieser Leseprobe nicht enthalten

Im Anschluss an den Header eines IP-Paketes folgen die Nutzdaten, die wiederum aus Daten- strukturen der darüber liegenden Schicht bestehen. Die wichtigsten Protokolle sollen im Folgenden erläutert werden.

2.5 Das Internet Control Message Protocol (ICMP)

Mit dem ICMP-Protokoll, das Bestandteil jeder IP-Implementierung ist, lassen sich Fehler- und Diagnoseinformationen zwischen den Hosts eines Netzwerkes austauschen. Wichtige Nachrichten des ICMP-Protokolls sind [Pos81]:

- Destination unreachable: Diese Nachricht kommt z. B. zum Einsatz, wenn das Netzwerk, der Host, der Port oder das Protokoll, an die ein Paket geschickt wurde, nicht erreichbar sind.
- Source Quench: Wenn ein Host so viele Pakete sendet, dass diese aufgrund fehlender Kapazitäten vom Empfänger nicht mehr verarbeitet werden können, so sendet dieser eine Source Quench-Nachricht. Der Host muss daraufhin die Rate, mit der Pakete versendet werden, verringern.
- Echo Request: Mit dieser Nachricht lässt sich feststellen, ob ein Host erreichbar ist, denn dieser muss mit einer Echo-Reply-Nachricht antworten. Diese Nachricht wird im allg. auch als „Ping“ bezeichnet.

2.6 Das Transmission Control Protocol (TCP)

Bei TCP handelt es sich um ein zuverlässiges und verbindungsorientiertes Protokoll, d. h. die Hauptaufgabe von TCP ist der sichere Transport von Daten durch ein Netzwerk. Aus Sicht einer Anwendung überträgt TCP einen Byte-Strom, d. h. die Anwendung kann einzelne Bytes schreiben oder lesen. Da das IP-Protokoll Pakete überträgt, setzt TCP den Byte-Strom in eine Folge von Segmenten um [TEC05]. Ein Segment besitzt den Aufbau:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Aufbau eines TCP-Segmentes [Hol02]

TCP arbeitet mit Punkt-zu-Punkt-Verbindungen. Ein Endpunkt dieser Verbindung, auch Socket genannt, wird spezifiziert durch eine IP-Adresse und einen Port. Ports werden auf der Transport- ebene zur Adressierung von Anwendungen verwendet; so ist Port 80 standardmäßig für einen HTTP-Dienst reserviert. Die beiden Sockets von Quelle und Ziel identifizieren eine Verbindung eindeutig [Hol02].

Die Zuverlässigkeit der übertragenen Daten wird bei TCP durch einen Mechanismus, der als Posi tive Acknowledgement with Re-Transmission (PAR) bezeichnet wird, gesichert. Der Sender wiederholt die Übertragung der Daten hierbei solange, bis vom Empfänger eine positive Bestätigung über den Erhalt der Daten gesendet wird.

Die Dateneinheiten des TCP-Protokolls werden Segmente genannt. Im Header der Segmente ist eine Prüfsumme enthalten, anhand derer der Empfänger ersehen kann, ob die Daten fehlerfrei sind. Ist dies der Fall, wird eine Empfangsbestätigung an den Sender geschickt. Sind die Daten fehlerhaft, wird das Segment verworfen und keine Empfangsbestätigung geschickt.

Eine Verbindungsorientierung entsteht bei TCP durch Einsatz des sog. Drei-Wege-Handshake - Mechanismus. Durch diesen werden Steuerinformationen ausgetauscht, die eine logische Ende- zu-Ende-Verbindung zwischen den Hosts etablieren. Möchte ein Host A eine Verbindung zu einem Host B aufbauen, so sendet er ein Segment, welches ein gesetztes SYN-Flag im Header enthält. Dieses Flag informiert Host B, dass A eine Verbindung herstellen möchte. Zusätzlich enthält das von Host A gesendete Segment eine Sequenznummer. Die Sequenznummern werden von TCP verwendet, um die korrekte Reihenfolge der empfangenen Segmente sicherzustellen. Host B kann die von Host A angeforderte Verbindung nun annehmen oder ablehnen. Nimmt er sie an, sendet er ein Paket mit gesetztem SYN- und ACK-Flag. In diesem Paket gibt er zusätzlich seine Sequenz- nummer und eine Acknowledgement -Nummer an. Diese wird auf den Wert „Sequenznummer von A+1“ gesetzt und zeigt an, welches Byte als nächstes zu erwarten ist. Als abschließenden Schritt bestätigt Host A den Empfang dieses Paketes, indem er ein Segment mit gesetztem ACK-Flag an B schickt. Das Vorgehen wird in Abbildung 7 veranschaulicht. Sobald dieser Schritt abgeschlossen wurde, kann die Datenübertragung stattfinden [Hun97].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Der Drei-Wege-Handshake -Mechanismus von TCP (vgl. [Hun97])

2.7 Das User Datagramm Protocol (UDP)

Bei UDP handelt es sich im Gegensatz zu TCP um ein unzuverlässiges, verbindungsloses Proto- koll, d. h. UDP stellt keinerlei Mechanismen zur Verfügung, die sicherstellen, dass verschickte Da- ten beim Ziel-Host eintreffen. Hierdurch kann der Header eines UDP-Paketes einfacher strukturiert werden als der Header eines TCP-Paketes. Dies führt zu einem geringeren Protokolloverhead bei Einsatz des UDP-Protokolls, so dass UDP effizienter ist als TCP und insbesondere für Anwendun- gen eingesetzt werden kann, bei denen es primär um die Geschwindigkeit der Datenübertragung geht. Eine Gemeinsamkeit mit TCP bildet die Verwendung von Portnummern, die, im Zusammen- spiel mit IP-Adressen, auch im UDP-Protokoll die Endpunkte der Quell- und Zielmaschine bestim- men.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Aufbau eines UDP-Headers [Hol02]

3. Gegenstand der Untersuchung

Wie bereits erwähnt, soll diese Arbeit Aufschluss darüber geben, wie sicher bzw. unsicher Kom- munikation per VoIP ist. Neben der Untersuchung der eigentlichen VoIP-Protokolle steht hierbei die Telefonanlage Asterisk im Mittelpunkt der Betrachtung. Asterisk wurde ausgewählt, weil es zum einen die Vermittlung zwischen VoIP und klassischer Telefonie gewährleisten kann. Zum anderen besitzt Asterisk gegenüber weiteren Software-Telefonanlagen wie z. B. VOCAL³ den Vorteil des IAX-VoIP-Protokolls, das eigens für Asterisk entwickelt wurde. Das IAX-Protokoll besitzt einige Vorzüge, die es klar von SIP abheben; dies wird im Laufe dieser Arbeit im direkten Vergleich der beiden Protokolle deutlich.

Zu Beginn dieses Kapitels werden Asterisk und Asterisk@Home vorgestellt sowie im Anschluss daran der Versuchsaufbau und die eingesetzten Geräte. Hiernach werden ausführlich die Protokolle SIP und IAX erläutert, die von den Geräten verwendet werden und damit die Basis der VoIPKommunikation bilden.

3.1 Asterisk und Asterisk@Home

Bei Asterisk handelt es sich um eine softwarebasierte Telefonanlage, die die Vermittlung zwischen unterschiedlichen Telefontechnologien ermöglicht. Unterstützt wird die traditionelle Analog- und ISDN-Technologie; im Bereich VoIP sind die wichtigsten unterstützten Protokolle das SIP-Protokoll und H.323 sowie das proprietäre Asterisk-Protokoll IAX. Hinzu kommt die Integration einer Reihe von Codecs wie z. B. ADPCM, GSM und G.711 (A-Law- und µ-Law-Format), um Audio- und Videodaten komprimieren und dekomprimieren zu können. Weiterhin realisiert Asterisk Zusatzfunktionen wie Voice-Mail, Conference Calls und Call Bridging.

Asterisk ist ein Open Source Projekt, d. h. der Quellcode ist veröffentlicht und daher für jeden Inte- ressierten einsehbar. Ein Vorteil dieses Ansatzes ist, dass sich weitere Module nachrüsten lassen, die von einer beständig wachsenden Nutzergemeinde entwickelt werden. So existieren beispiels- weise ein LCR-Modul sowie web-basierte Bedienoberflächen zur Konfiguration von Asterisk. Ein weiterer Vorteil ist, dass Asterisk als Download frei im Internet erhältlich ist und sich somit sowohl für Privatanwender, als auch für kleinere und mittelgroße Unternehmen anbietet, die nur geringe Mittel zur Finanzierung ihrer Telekommunikationsinfrastruktur aufwenden können bzw. möchten. Aufgrund dieser Vorteile hat Asterisk bereits eine weite Verbreitung gefunden, so dass es auch im Rahmen dieser Arbeit die Grundlage für die Vermittlung der VoIP-Kommunikation bildet.

Asterisk wurde hauptsächlich von Mark Spencer, einem Mitarbeiter der Firma Digium, Inc. entwickelt [AST05]. Es wurde speziell für Linux entworfen, aber auch Portierungen nach FreeBSD, Mac OS X und Solaris existieren.

Eine der vielversprechendsten Entwicklungen der Open Source Gemeinde ist Asterisk@Home [AAH05], ein Projekt das sich zum Ziel gesetzt hat, eine Stand-alone Implementierung von Asterisk zu bieten, die alle zur Inbetriebnahme einer Telefonanlage benötigten Softwarekomponenten enthält. Asterisk@Home lässt sich als ISO-Image von der Homepage des Projekts herunterladen, und kann dann auf CD gebrannt werden. Damit steht eine Installations-CD zur Verfügung die u. a. folgende Komponenten enthält (Stand Asterisk@Home 1.1):

- Als Betriebssystem kommt CentOS⁴ in der Version 3.4 zur Anwendung. Hierbei handelt es sich um ein auf Red Hat Linux basierendes Betriebssystem ohne grafische Oberfläche
- Asterisk in der Version 1.0.7
- Das Asterisk Management Portal (AMP), ein web-basiertes GUI zur Konfiguration von Asterisk und zur Abfrage statistischer Informationen
- Ein Apache-Webserver zur Bereitstellung des AMP
- Eine MySQL-Datenbank, in der Verbindungsinformationen für statistische Auswertun- gen gespeichert werden

Im Rahmen dieser Arbeit wird Asterisk@Home in der Version 1.1 verwendet. Zwar existierte zum Zeitpunkt des Aufbaus der Testumgebung schon die Versionen 1.2 und 1.3, doch diese führten auf den zur Verfügung stehenden Rechnern reproduzierbar zu Abstürzen während der Installation des Betriebssystems. Da ab Asterisk@Home 1.2 als Betriebssystem CentOS 3.5 zum Einsatz kommt, muss davon ausgegangen werden, dass hier eine Inkompatibilität zur verwendeten Hardware vor- liegt. Neben einer neuen Version von CentOS wurde auch die neuere Asterisk Version 1.0.9 integ- riert; Änderungen zu Version 1.0.7 sind im Changelog unter [ACL05] ersichtlich.

Nach der Installation des Betriebssystems werden automatisch Asterisk und alle weiteren Pakete installiert und vorkonfiguriert. Auf diese Weise steht nach Abschluss der kompletten Installation ein einsatzbereiter Asterisk-Server zur Verfügung. Dieser muss zur Inbetriebnahme allerdings noch um die Daten der zu verwendenden Endgeräte ergänzt werden, indem die Konfigurationsdateien von Asterisk editiert werden. Im Kapitel zur Vorstellung der Testumgebung wird darauf im Einzelnen eingegangen. Doch zuvor soll der grundlegende Aufbau von Asterisk erläutert werden, um ein Verständnis für die Arbeitsweise von Asterisk zu schaffen.

3.2 Architektur und Funktionsweise von Asterisk

Asterisk ist als eine Vermittlungsstelle zwischen verschiedenen Telefonietechnologien anzusehen. Zu diesen gehören sowohl VoIP-Protokolle wie SIP und IAX, als auch herkömmliche ISDN- und Analog-Telefonie. Durch speziell entwickelte Module lassen sich zusätzliche Protokolle integrieren, wie z. B. H.323 durch Einsatz des Moduls „OpenH323“ [MKE5]. Diese Technologien werden in Asterisk durch eigene sog. Channels repräsentiert, die separat konfiguriert werden können. Die grundlegende Architektur von Asterisk ist nun darauf ausgerichtet, eine konsistente Umgebung zur Verfügung zu stellen, die diese Vermittlung zwischen Channels garantieren kann. Ein Beispiel ist die Vermittlung einer Verbindung zwischen einem SIP- und einem H.323-Endgerät oder einem IAX- und einem ISDN-Gerät. Um dies zu ermöglichen, besteht Asterisk aus mehreren Kernkompo- nenten, die in Abbildung 11 veranschaulicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Architektur von Asterisk (vgl. [SAR03])

Sobald Asterisk startet, wird zuerst der Dynamic Module Loader aufgerufen, der die Module lädt und initialisiert, die u. a. für die verwendeten Übertragungs-Codecs, Dateiformate und Applikationen benötigt werden. Danach wird ein Linking mit den entsprechenden internen APIs (Application Programming Interfaces) ausgeführt.

Der PBX Switching Core von Asterisk vermittelt ein- und ausgehende Anrufe gemäß den konfigurierten Wählplänen, die in der Datei „extensions.conf“ festgelegt wurden. Zudem wird dabei der Application Launcher benutzt, um die entsprechenden Aktionen einzuleiten, wie z. B. Telefone klingeln lassen, eine Verbindung zum Voice Mail System herzustellen, etc.

Zu den weiteren Kernbestandteilen gehören ein Scheduler und ein I/O Manager, die die Verwaltung der Applikationen und Channels übernehmen, um eine optimale Performance unter allen denkbaren Auslastungssituationen sicherzustellen.

Das letzte grundlegende Element ist der Codec Translator, der Module für jeden benutzten Codec bereitstellt, um so eine Übersetzung zwischen den Codecs und damit eine reibungslose Kommunikation zwischen Channels mit verschiedenen Codecs zu ermöglichen [SAR03].

Um VoIP-Endgeräte mittels Asterisk ansprechen zu können, müssen sich diese am Asterisk-Server registrieren können. Auf diese Weise wird Asterisk mitgeteilt, dass ein Gerät zur Verfügung steht. Realisiert wird dies in Asterisk durch sog. Extensions. Extensions werden angelegt, indem be- stimmte, je nach verwendetem Protokoll unterschiedliche, Konfigurationsdateien mit Parametern editiert werden. Soll z. B. ein SIP-Endgerät hinzugefügt werden, muss die Datei „sip.conf“ um die Daten des Endgerätes erweitert werden. Zusätzlich ist ein Eintrag in der Datei „extensions.conf“ nötig, die den Wählplan des Servers enthält. Sämtliche Konfigurationsdateien liegen dabei im Ver- zeichnis „/ect/asterisk“. Ausschnitte aus den Konfigurationsdateien für SIP- und IAX-Geräte sind in Anhang A ersichtlich.

3.3 Aufbau der Testumgebung

Um alle Aspekte der Kommunikation zwischen SIP- und IAX-Geräten berücksichtigen zu können, kommen in der Testumgebung sowohl Softphones auf Windows- und Linux-Basis, als auch Hardphones vom Typ Cisco 9740 zum Einsatz. Desweiteren sind zwei Asterisk-Server im Einsatz, um auch die Kommunikation zwischen diesen beiden mittels IAX-Protokoll untersuchen zu können. Aus diesen Vorgaben lässt sich die folgende Testumgebung realisieren:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Gerätekonfiguration der Testumgebung⁵

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Darstellung der Testumgebung

Zur Anbindung der verwendeten Hardware an die Netzwerkinfrastruktur wird ein Gigabit-Switch verwendet, an den die Geräte sternförmig angeschlossen werden. Alle Hardwarekomponenten sind dabei mit einer 100 Mbit/s - fähigen Ethernet-Netzwerkkarte ausgestattet. Für den Zeitraum der Versuche steht ein eigenes Subnetz zur Verfügung, dass folgendermaßen gewählt wurde:

Abbildung in dieser Leseprobe nicht enthalten

Dabei ist der Bereich von .200 bis .209 für Asterisk Server reserviert, der Bereich von .210 bis .220 für Endgeräte. Die IP-Nummern der Endgeräte werden nun aufsteigend vergeben. Da die vorgenommenen Experimente auf den Protokollen IAX und SIP basieren, wird für jedes der beiden Protokolle ein eigener Rufnummernkreis angelegt. Telefonnummern der Clients, die mit IAX kommunizieren, fangen mit einer 1 an, diejenigen die mit SIP kommunizieren mit einer 2. Die folgenden drei Stellen zur Identifikation des Endgerätes leiten sich aus dem letzten Teil der IP-Nummer ab. Die folgende Tabelle verdeutlicht die Nummernzuweisung:

Abbildung in dieser Leseprobe nicht enthalten⁶

Tabelle 2: Telefonnummernvergabe

Im Versuchsaufbau kommen sowohl Windows XP als auch Linux als Betriebssysteme zum Einsatz, um evtl. Unterschiede in der Kommunikation der Windows- und Linux-Softphones mit dem Cisco Hardphone erkennen zu können. Zusätzlich besteht so die Möglichkeit, eine Verbindung ausschließlich zwischen Softphones untersuchen zu können.

Wie schon erwähnt, müssen sich Endgeräte an einem Asterisk-Server registrieren, um für andere Endgeräte erreichbar zu sein. Durch die Wahl von zwei Asterisk-Servern im Versuchsaufbau be- steht die Möglichkeit, neben der direkten Kommunikation zwischen Endgeräten, auch die Kommu- nikation zu untersuchen, die entsteht, wenn Gespräche zwischen Endgeräten vermittelt werden müssen, die an verschiedenen Asterisk-Servern registriert sind. Dies geschieht durch das sog. Trunking, bei dem sich Asterisk-Server gegenseitig registrieren, um ihre Endgeräte zur Verfügung zu stellen. Sämtliche Kommunikation zwischen den beiden Asterisk-Servern wird dabei mit Hilfe des IAX-Protokolls ausgetauscht. Abbildung 13 stellt die im Versuchsaufbau realisierte Registrie- rung dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Registrierung der Endgeräte an den Asterisk-Servern

3.4 Vorstellung der verwendeten Softphones und Hardphones

Im verwendeten Versuchsaufbau kommen neben dem Cisco 7940-Telefon mehrere Softphones zum Einsatz. Unter Windows wird für das SIP-Protokoll das Programm SIPPS der Firma Nero AG in der Version 2.0.51 verwendet. SIPPS ist als Demoversion 30 Tage uneingeschränkt lauffähig, danach wird es in SIPPS Light umgewandelt, dem einige Komfortfunktionen fehlen. Alle TelefonieFunktionen stehen jedoch weiterhin uneingeschränkt zur Verfügung [NER05]. Zu verwendeten Audio-Codecs macht Nero keine Angaben, ausgehend von Untersuchungen des NetzwerkVerkehrs wird aber zumindest G.711 im a-Law- und µ-Law-Format unterstützt.

Unter Linux kommt für das SIP-Protokoll das Softphone X-Lite in der Version 2.0 zum Einsatz, das von der Firma CounterPath Solutions, Inc. (vormals Xten Networks, Inc.) entwickelt wurde und auf deren Internetseite zum Download frei zur Verfügung steht. X-Lite unterstützt die Audio-Codecs G.711 a-Law / µ-Law, GSM, iLBC und Speex [CPS05].

Für das IAX-Protokoll kommt sowohl unter Windows als auch unter Linux das Open-Source Pro- gramm iaxComm in der Version 1.0 Release Candidate 3 zum Einsatz. iaxComm wurde haupt- sächlich von Michael Van Donselaar entwickelt, und steht unter [IAX05] zum Download bereit. Als einzige Hardphones kommen im Versuchsaufbau zwei Telefone des Typs Cisco 7940 zum Einsatz. Diese Telefone unterstützen neben dem SIP-Protokoll das zusammen mit dem Cisco Call- Manager eingesetzte Skinny Call Control Protocol (SCCP), sowie das Media Gateway Control Pro- tocol (MGCP). Weiterhin werden die Audio-Codecs G.711 (a-Law und µ-Law) und G.729a unter- stützt [CIS04]. Im Auslieferungszustand befindet sich auf dem Telefon nur ein SCCP-fähiges Soft- ware-Image, so dass per TFTP-Server eine neue SIP-fähige Firmware aufgespielt werden muss. Auf den beiden Telefonen die für die Experimente zur Verfügung standen, war bereits die SIP- fähige Firmware mit der Boot-Load-ID PC030301 vorhanden, so dass dieser Schritt enfallen konn- te. Lediglich die Konfigurationsdaten mussten noch vom Asterisk-Server auf das Telefon überspielt werden.

4. Aufbau der verwendeten VoIP-Protokolle

Da Angriffe in den meisten Fällen darauf abzielen, Schwachstellen in den Implementierungen der VoIP-Protokolle auszunutzen, ist es nötig, die Funktionsweise der Protokolle zu erläutern. Diese Kenntnis ermöglicht es, Angriffe individuell anpassen und durchführen zu können, bzw. im Gegen- zug, Maßnahmen zur Verhinderung von Angriffen einleiten zu können. Da sich die VoIP-Protokolle stark voneinander unterscheiden, soll jedes der Protokolle einzeln im Detail betrachtet werden. Das Protokoll H.323 wird im Rahmen dieser Arbeitet nicht berücksichtigt, da es sich auf dem Markt nicht durchsetzen konnte und daher kaum noch eine praktische Relevanz besitzt.

4.1 Das Session Initiation Protocol (SIP)

SIP wurde von der Arbeitsgruppe „Multiparty Multimedia Session Control“ (MMUSIC) der IETF ent- wickelt und unter RFC 3261 [Ros02] spezifiziert. Es stellt ein Signalisierungsprotokoll in der An- wendungsschicht dar, das multimediale Sitzungen auf- und abbauen kann. Die Art der multimedia- len Sitzungen beinhaltet dabei einfache Telefongespräche bis hin zu Konferenzschaltungen zwi- schen mehreren Teilnehmern [TBI04]. Neben dem Auf- und Abbau von Sitzungen unterstützt SIP noch weitere Signalisierungsmöglichkeiten, z. B. das Einladen von zusätzlichen Teilnehmern zu bestehenden Sitzungen.

Für die Übertragung der Echtzeitdaten wird allerdings nicht SIP, sondern das Real Time Protocol (RTP) verwendet, auf das anschließend noch näher eingegangen wird und das direkt zwischen Sender und Empfänger vermittelt.

„Da bei SIP die Übertragung von Anforderungen, auch Requests genannt, sehr stark an HTTP ange- lehnt ist (u. a. ähnliche Header-Struktur, ebenfalls textbasiertes Protokoll), wird dessen Definition der Begriffe Client und Server übernommen. Ein Teilnehmer, der einen Request zu einem anderen Teilnehmer senden will, nimmt somit die Rolle des Clients und der Empfänger die des Servers ein, der die entsprechenden Responses schickt. Für das Senden eines Requests vom Client zum Server gibt es zwei Möglichkeiten. Bei der ersten und einfacheren Möglichkeit Proxy Mode wird der Request zu einem lokalen SIP Proxy übermittelt, welcher sich um die korrekte Weiterleitung des Requests kümmert. Die zweite Möglichkeit Redirect Mode ist das direkte Versenden des Requests an den Server, welcher jedoch anhand des Requests erst bestimmt werden muss“ [TBI04].

Ein Client wird im SIP-Umfeld auch als User Agent, oder kurz UA, bezeichnet. Die SIPSpezifikation unterscheidet zusätzlich zwischen dem User Agent Client (UAC), der einen Request generiert, und dem User Agent Server (UAS), der eine Antwort auf einen SIP-Request sendet. Da diese Differenzierung jedoch nur für eine spezifische Nachricht getroffen wird, und ein User Agent im Laufe einer SIP-Verbindung daher sowohl UAS als auch UAC ist, wird im Verlauf dieser Arbeit nur noch von User Agent bzw. Client gesprochen.

Die Adressierung der Teilnehmer wird durch einen sog. Uniform Resource Identifier (URI) ermög- licht. Dieser URI hat das von E-Mail-Adressen bekannte Format „user@domain“, wobei der User- Teil frei wählbar ist und es sich dabei um eine Telefonnummer oder um einen Benutzernamen handeln kann. Der Domain-Teil muss hingegen aus einem Domain-Namen bzw. einer IP-Adresse bestehen. Zusätzlich kann der URI ein Kennwort zur Authentifizierung, Angaben zur verwendeten Portnummer oder andere Parameter enthalten. Ein Beispiel für einen URI ist „sip:2212@132.252.152.200“.

Die Rufsignalisierung mit SIP gleicht im Ablauf dem Drei-Wege-Handshake beim Aufbau einer TCP-Verbindung. Die erforderlichen Nachrichten werden entweder per UDP oder per TCP trans- portiert, wobei UDP das bevorzugte Protokoll ist, da es durch fehlende Fehlererkennung und -korrektur besser für Echtzeitdienste geeignet ist. Sofern nicht anders konfiguriert, benutzt SIP dabei standardmäßig den Port 5060. Unter Verwendung eines Proxy Servers sieht das Herstellen und Beenden einer Verbindung folgendermaßen aus:

[...]

¹ Hierbei handelt es sich um eine Technik, bei der durch das Klicken auf einen Webseiten-Link automatisch eine direkte Telefonverbindung hergestellt wird.

² Unified Messaging bezeichnet die Integration verschiedenster Kommunikationsdienste, wie z. B. E-Mail, Videokonferenz oder Voicechat, in eine einzige Kommunikationsplattform.

³ s. [VOV05]

⁴ s. a. http://www.centos.org

⁵ Dieser Asterisk-Server wurde freundlicherweise von Herrn Klaus Holzenhauer zur Verfügung gestellt, der zur gleichen Zeit an einer wiss. Arbeit zum Thema Asterisk geschrieben hat.

⁶ Dieses Cisco 7940 Telefon wurde ebenfalls von Herrn Klaus Holzenhauer zur Verfügung gestellt, der zur gleichen Zeit an einer wiss. Arbeit zum Thema Asterisk geschrieben hat. Daraus resultiert die Abweichung der Telefonnummer vom gewählten Schema