Sicherheitsbewertung der Open Source Telefonanlage (Soft-PBX) Asterisk

Heidrich, Jens

Sicherheitsbewertung der Open Source Telefonanlage (Soft-PBX) Asterisk

Unter besonderer Berücksichtigung verschiedener VoIP-Protokolle

von Jens Heidrich (Autor:in)

Informatik - IT-Security

Zusammenfassung

Inhaltsangabe:Problemstellung:
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. VoIP-Telefonie wird dabei zunehmend zur Konkurrenz der klassischen Telefonie. Große Telefonkonzerne erweitern ihr Portfolio um VoIP-Lösungen 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 Verschmelzung der Telefon- und Datennetze ermöglicht werden. Weltweite Erreichbarkeit, neue Anwendungen 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 existieren 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 Inititation 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 Bedingungen die Herstellung einer Verbindung unmöglich gemacht werden kann, bzw. wie eine bestehende 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 Authentifizierungsinformationen. Diese beiden […]

Leseprobe

Inhaltsverzeichnis

ID 9589

Heidrich, Jens: Sicherheitsbewertung der Open Source Telefonanlage (Soft-PBX) Asterisk -

Unter besonderer Berücksichtigung verschiedener VoIP-Protokolle

Druck Diplomica GmbH, Hamburg, 2006

Zugl.: Universität Duisburg-Essen, Standort Essen, Diplomarbeit, 2006

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2006

Printed in Germany

I INHALTSVERZEICHNIS

II ABBILDUNGSVERZEICHNIS ______________________________________ 4

III TABELLENVERZEICHNIS ________________________________________ 6

IV ABKÜRZUNGSVERZEICHNIS_____________________________________ 7

1. EINLEITUNG ___________________________________________________ 9

1.1 UNTERSCHIEDE ZWISCHEN KLASSISCHER TELEFONIE UND VOIP-TELEFONIE ___ 10

1.2 VOR- UND NACHTEILE VON VOIP GEGENÜBER KLASSISCHER TELEFONIE ______ 11

2. GRUNDLAGEN DER IP-BASIERTEN NETZE ________________________ 14

2.1 DAS TCP/IP-MODELL _____________________________________________________ 14

2.2 ADRESSIERUNG IN TCP/IP-NETZEN ________________________________________ 17

2.3 DAS ADDRESS RESOLUTION PROTOCOL (ARP) ______________________________ 18

2.4 DAS INTERNET PROTOCOL (IP) ____________________________________________ 19

2.5 DAS INTERNET CONTROL MESSAGE PROTOCOL (ICMP) ______________________ 21

2.6 DAS TRANSMISSION CONTROL PROTOCOL (TCP) ____________________________ 22

2.7 DAS USER DATAGRAMM PROTOCOL (UDP) _________________________________ 23

3. GEGENSTAND DER UNTERSUCHUNG ____________________________ 24

3.1 ASTERISK UND ASTERISK@HOME _________________________________________ 24

3.2 ARCHITEKTUR UND FUNKTIONSWEISE VON ASTERISK _______________________ 26

3.3 AUFBAU DER TESTUMGEBUNG____________________________________________ 28

3.4 VORSTELLUNG DER VERWENDETEN SOFTPHONES UND HARDPHONES ________ 31

4. AUFBAU DER VERWENDETEN VOIP-PROTOKOLLE_________________ 32

4.1 DAS SESSION INITIATION PROTOCOL (SIP)__________________________________ 32

4.2 DAS SESSION DESCRIPTION PROTOCOL (SDP) ______________________________ 35

4.3 DAS REAL-TIME TRANSPORT PROTOCOL (RTP)______________________________ 36

4.4 DAS INTER-ASTERISK EXCHANGE PROTOKOLL (IAX) _________________________ 39

4.4.1 Datagramm-Struktur ___________________________________________________ 39

4.4.2 IAX-Verbindungen zwischen Endgeräten ___________________________________ 41

4.4.3 IAX-Verbindungen zwischen zwei Asterisk-Servern___________________________ 44

5. DURCHFÜHRUNG DER SICHERHEITSBEWERTUNG_________________ 45

5.1 INFORMATIONSBESCHAFFUNG UND -AUSWERTUNG _________________________ 46

5.1.1 Auffinden von Hosts ___________________________________________________ 46

5.1.1.1 ICMP Echo Scanning

____________________________________________________ 46

5.1.1.2 ICMP-Broadcast

________________________________________________________ 47

5.1.1.3 Weitere ICMP-Nachrichten

_______________________________________________ 47

5.1.1.4 TCP Scanning

__________________________________________________________ 48

5.1.1.5 UDP Scanning

_________________________________________________________ 48

5.1.1.6 ARP Scanning

__________________________________________________________ 48

5.1.1.7 Passives Scanning

______________________________________________________ 49

5.1.1.8 Praktische Anwendung

__________________________________________________ 50

5.1.2 Identifizierung von Betriebssystem und angebotenen Services __________________ 51

5.1.2.1 Unterscheidung von Port-Scanning und Fingerprinting

_______________________ 51

5.1.2.2 Praktische Durchführung von Port-Scanning und Fingerprinting

_______________ 52

5.2 AUFDECKEN VON SCHWACHSTELLEN DER VOIP-KOMMUNIKATION ____________ 55

5.2.1 Kompromittierung der Vertraulichkeit ______________________________________ 56

5.2.1.1 Aufzeichnen von SIP-Gesprächen

_________________________________________ 59

5.2.1.2 Aufzeichnen von IAX-Verbindungen

_______________________________________ 60

5.2.1.3 Auffangen und Entschlüsseln von Passwörtern der VoIP-Kommunikation

_______ 66

5.2.2 Kompromittierung der Authentizität________________________________________ 74

5.2.2.1 Replay-Attacken auf SIP-Verbindungen

____________________________________ 75

5.2.2.2 Einspielen und Abhören eines RTP-Stroms in Echtzeit

_______________________ 80

5.2.2.3 Vortäuschung einer fremden Identität

______________________________________ 84

5.2.3 Beeinträchtigung der Verfügbarkeit________________________________________ 94

5.2.3.1 Ausnutzung von Implementierungsfehlern der Protokolle

_____________________ 95

5.2.3.2 Ressourcenüberlastung durch Einsatz von DoS-Tools

______________________ 106

6. EMPFEHLUNGEN ZUR ERHÖHUNG DER SICHERHEIT ______________ 110

6.1 ERWEITERUNGEN DES SIP-PROTOKOLLS__________________________________ 111

6.1.1 SIP mit S/MIME-Bodies________________________________________________ 111

6.1.2 SIP-Secure (SIPS) ___________________________________________________ 112

6.1.3 Secure RTP (SRTP) __________________________________________________ 112

6.1.4 SIP über IPSec ______________________________________________________ 115

6.2 SICHERHEITSEMPFEHLUNGEN FÜR ASTERISK UND DAS IAX-PROTOKOLL _____ 115

7. AUSBLICK UND FAZIT ________________________________________ 117

ANHANG A Ausschnitt aus den Konfigurationsdateien von Asterisk ______ 120

ANHANG B - Ergebnisse der Nmap-Scans __________________________ 123

LITERATUR- UND QUELLENVERZEICHNIS _________________________ 125

EIDESSTATTLICHE VERSICHERUNG _____________________________ 130

II Abbildungsverzeichnis

Abbildung 1: Funktionsweise eines Jitter-Buffers ... 13

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

Abbildung 3: Prinzip der Datenkapselung ... 16

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

Abbildung 5: Aufbau eines Ethernet-Rahmens... 18

Abbildung 6: Aufbau eines ARP-Paketes... 19

Abbildung 7: Aufbau des IP-Datagramm-Header ... 20

Abbildung 8: Aufbau eines TCP-Segmentes ... 22

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

Abbildung 10: Aufbau eines UDP-Headers ... 24

Abbildung 11: Architektur von Asterisk... 27

Abbildung 12: Darstellung der Testumgebung ... 29

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

Abbildung 14: SIP-Verbindungsaufbau ... 34

Abbildung 15: Beispiel einer SDP-Nachricht ... 36

Abbildung 16: Aufbau eines RTP-Headers... 37

Abbildung 17: Beispiel eines RTP-Headers ... 38

Abbildung 18: Beispiel eines RTCP-Paketes... 38

Abbildung 19: IAX Full-Frame Binär Format... 40

Abbildung 20: IAX Mini-Frame Binär Format... 41

Abbildung 21: IAX Peer Registration... 42

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

Abbildung 23: Die ICMP-Broadcast-Methode... 47

Abbildung 24: ARP-Request und -Reply ... 49

Abbildung 25: Ergebnis des Ping-Scans von Nmap ... 50

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

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

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

Abbildung 29: Durchführung eines ARP-Spoofing... 57

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

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

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

Abbildung 33: Weiterleitung des Verbindungsaufbaus zwischen Asterisk-Server und

Windows-Client... 63

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

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

Abbildung 36: Austausch von Authentifizierungsinformationen bei Aufbau einer

SIP-Verbindung ... 67

Abbildung 37: Darstellung einer SIP-INVITE-Nachricht ... 67

Abbildung 38: Austausch von Authentifizierungsinformationen bei der Registrierung

eines SIP-UA... 69

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

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

Abbildung 41: Registrierung des IAXComm-Client ... 72

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

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

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

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

Verbindung... 80

Abbildung 46: Konfiguration des RTP-Stroms in JMStudio... 81

Abbildung 47: Eingabe der Ziel-Adresse in JMStudio... 82

Abbildung 48: Abhören von Kommunikation in Echtzeit... 84

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

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

Abbildung 51: SIP-Verbindungsaufbau durch SIPp ... 87

Abbildung 52: Von SIPp gesendeter, korrekter INVITE-Request ... 87

Abbildung 53: INVITE-Request mit Call-ID... 89

Abbildung 54: Erstellung einer Refer-Nachricht in SiVuS ... 90

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

Abbildung 56: Transfer Request zur Verbindung von Endgeräten ... 94

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

Abbildung 58: Erstellung einer NOTIFY-Nachricht in SiVuS ... 98

Abbildung 59: Nachrichtenfluss bei Aufbau einer NOTIFY-Subscription ... 99

Abbildung 60: Generierung einer INFO-Nachricht in SiVuS... 100

Abbildung 61: Vulnerability-Scanner von SiVuS... 102

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

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

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

Abbildung 65: Aufbau eines SRTP-Paketes... 113

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

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

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

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

III Tabellenverzeichnis

Tabelle 1: Gerätekonfiguration der Testumgebung ...29

Tabelle 2: Telefonnummernvergabe ...30

Tabelle 3: Auszug aus Datei ,,sip.conf" von Asterisk ...120

Tabelle 4: Auszug aus der Datei ,,iax.conf" von Asterisk ...121

Tabelle 5: Auszug aus der Datei ,,extensions.conf" von Asterisk...122

IV Abkürzungsverzeichnis

3DES ... Triple Data Encryption Standard

ADPCM... Adaptive Differential Pulse Code Modulation

AES ... Advanced Encryption Standard

AMP... Asterisk Management Portal

API... Application Programming Interface

ARP ... Adress Resolution Protocol

Codec ... Coder/Decoder

CRC... Cyclic Redundancy Check

DNS ... Domain Name System

DSA ... Digital Signature Algorithm

DSL... Digital Subscriber Line

DTMF... Dual Tone Multifrequency

FTP... File Transfer Protocol

GPL ... General Public License

HTTP ... Hypertext Transfer Protocol

IANA ... Internet Assigned Numbers Authority

IAX... Inter Asterisk Exchange

IETF... Internet Engineering Taskforce

iLBC... internet Low Bitrate Codec

ISDN... Integrated Services Digital Network

GSM ... Global System for Mobile Communications

GUI ... Graphical User Interface

ICMP... Internet Control Message Protocol

IETF... Internet Engineering Taskforce

IP ... Internet Protocol

IPSec ... IP Security

LCR ... Least Cost Routing (Router)

MAC... Media Access Control

MD5... Message Digest algorithm 5

MGCP... Media Gateway Control Protocol

MIKEY ... Multimedia Internet Keying

MIME ... Multipurpose Internet Mail Extensions

NAT ... Network Address Translation

PAR ... Positive Acknowledgement with Re-transmission

PBX ... Private Branch Exchange

PCM... Pulse Code Modulation

PDA ... Personal Digital Assistant

PSTN... Public Switched Telephone Network

QoS ... Quality of Service

RFC ... Request for Comment

RSA ... Rivest, Shamir, Adleman (Synonym für ein asymmetrisches Kryptosystem)

RTP ... Real-Time Transport Protocol

RTCP... Real-Time Transport Control Protocol

S/MIME... Secure MIME

SCCP... Skinny Call Control Protocol

SDP ... Session Description Protocol

SHA-1 ... Secure Hash Algorithm-1

SIP... Session Initiation Protocol

SRTP ... Secure RTP

SSH ... Secure Shell

SSRC... Synchronization Source

TCP ... Transmission Control Protocol

TFTP... Trivial File Transfer Protocol

TLS... Transport Layer Security

TTL ... Time To Live

UA ... User Agent

UDP ... User Datagramm Protocol

URI ... Uniform Resource Identifier

VoIP... Voice over Internet Protocol

1. Einleitung

Das Voice over Internet Protocol (VoIP) beschäftigt sich mit der Übertragung von Echtzeitkommu-

nikation in paketorientierten Netzen wie dem Internet, im Gegensatz zur klassischen verbindungs-

orientierten Kommunikation, wie dies beim durchschaltevermittelten Telefonnetz der Fall ist. VoIP-

Telefonie wird dabei zunehmend zur Konkurrenz der klassischen Telefonie. Große Telefonkonzer-

ne erweitern ihr Portfolio um VoIP-Lösungen [ARC05] und auch kleinere Unternehmen bieten Pro-

dukte 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

Hierbei handelt es sich um eine Technik, bei der durch das Klicken auf einen Webseiten-Link automatisch

eine direkte Telefonverbindung hergestellt wird.

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 be-

schä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ähi-

gen, 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ön-

nen 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 be-

nutzt werden, basieren dabei auf den Protokollen des TCP/IP-Modells, welches in Kapitel 2 aus-

fü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über-

mittlung 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 Sprach-

und 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 vorzufin-

den sind. So kann beim Aufbau eines VoIP-Netzes auf bereits vorhandene Netzwerkkom-

ponenten zurückgegriffen werden, die bisher für Anwendungen wie Internet-Zugriff, verteil-

te 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ötig-

te 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 Pro-

duktivitä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ä-

Unified Messaging bezeichnet die Integration verschiedenster Kommunikationsdienste, wie z. B. E-Mail,

Videokonferenz oder Voicechat, in eine einzige Kommunikationsplattform.

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 wer-

den, 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 Sprach-

verbindung akzeptierbar; unter höheren Latenzzeiten leidet die Verbindungsqualität, da die Teil-

nehmer 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 Netzwerk-

Verzögerung, die auftritt, wenn Netzwerkanbindungen überlastet sind und Pakete deswegen zu-

rückgehalten werden.

Verzögerungsschwankungen werden auch als Jitter bezeichnet. Hierunter ist die Abweichung zwi-

schen 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 verwor-

fen. Ein zu großer Puffer hingegen erhöht die absolute Verzögerung, da erst eine bestimmte An-

zahl von Paketen im Puffer gesammelt werden muss [DaP00].

Abbildung 1: Funktionsweise eines Jitter-Buffers

Jitter Buffer

Ausgabe der Pakete alle 10 ms

Pakete mit Verzögerungsschwankungen

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 ei-

nem 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 Funkti-

onsweise dieser Netze geschaffen werden. Es werden die Protokolle und Mechanismen des

TCP/IP-Modells erläutert, da die im weiteren Verlauf der Untersuchung vorgestellten VoIP-

Protokolle auf diesen aufbauen und das Verständnis der beschriebenen Angriffsmethoden eben-

falls 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übertragungs-

und Datensicherungsschicht des OSI-Modells zu einer Schicht, sowie die oberen drei Schichten

des OSI-Modells zu einer Anwendungsschicht, zusammengefasst sind [Hol02].

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 3: Prinzip der Datenkapselung (vgl. [Hun97])

Jede Schicht hat ihre eigenen, unabhängigen Datenstrukturen und damit auch eine eigene Termi-

nologie für diese. Anwendungen, die TCP verwenden, bezeichnen ihre Daten als Strom, wohinge-

gen Anwendungen, die UDP als Transportprotokoll einsetzen, ihre Daten als Nachrichten bezeich-

nen. 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 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 5: Aufbau eines Ethernet-Rahmens [TEC05]

Die Präambel dient der Synchronisation des Empfängers und zeigt den Start des Ethernet-

Rahmens an. Darauf folgen die Ziel- und Quelladressen sowie ein Längenfeld, das auch als Typ-

feld 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 IP-

Adressen, die ARP-Tabelle oder auch ARP-Cache genannt wird. Die Tabelle wird dynamisch ver-

waltet, 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 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 Transportproto-

kollen 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 dazwi-

schen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enthält keine Funk-

tionen 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 7: Aufbau des IP-Datagramm-Header [Hun97]

Die Felder haben folgende Bedeutung [RFC81]:

- ,,Version":

Version spezifiziert die IP-Version; momentan ist dies IPv4.

- ,,IHL":

Der Internet Header Length beschreibt die Länge des Headers in

Vielfachen von 32 Bit.

- ,,ToS":

Der Type of Service kann für die Priorisierung von Datenpaketen

eingesetzt und ausgewertet werden.

- ,,Total Length":

Dies beinhaltet die Länge des gesamten Paketes inkl. Header.

- ,,Identification":

Das Feld wird, zusammen mit den beiden folgenden, für die Zu-

sammensetzung von zuvor fragmentierten Paketen benutzt und

enthält eine eindeutige Kennung des Datagramms.

- ,,Flags":

Flags implementiert Kontroll-Schalter, die bestimmen, ob ein Paket

fragmentiert werden darf oder ob es sich um das letzte Fragment

einer Reihe von Fragmenten handelt.

- ,,Fragment Offset":

Dieses Feld gibt bei fragmentierten Paketen an, welche Position

das Paket innerhalb der Fragmente einnimmt.

- ,,Time to Live":

Der Wert gibt die Lebensdauer des Paketes an. Jede Station auf

dem Weg des Paketes verringert diesen Wert; erreicht Time to

Live den Wert null, so wird das Paket verworfen.

- ,,Protocol":

Protocol bezeichnet das Protokoll, dessen Daten im Anschluss an

den IP-Header übertragen werden (z. B. 0x06 für TCP).

- ,,Header Checksum":

Dies ist eine Prüfsumme für den IP-Header.

- ,,Source Address":

Enthält die Quell-Adresse des IP-Paketes.

- ,,Destination Address": Enthält die Ziel-Adresse des IP-Paketes.

- ,,Options":

In diesem Feld können Optionen enthalten sein, wie z. B. Loose

Source Routing oder Strict Source Routing, die beide genutzt

werden, um das Datagramm basierend auf Informationen des

Senders zu routen.

- ,,Padding":

Das Padding-Feld wird verwendet, um sicherzugehen, dass der

IP-Header eine Länge besitzt, die ein Vielfaches von 32 Bit ist.

Hierzu wird, falls nötig, mit 0-Bits aufgefüllt.

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 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 wie-

derholt 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 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.

SYN, Seq.-Nr. = X

SYN/ACK, Ack.-Nr. = X+1, Seq.-Nr. = Y

ACK, Ack.-Nr. = Y+1, Seq.-Nr. = X+1

Host A

Host B

Der Header eines UDP-Paketes besitzt das Format:

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 Protokol-

le SIP und IAX erläutert, die von den Geräten verwendet werden und damit die Basis der VoIP-

Kommunikation 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 Vi-

deodaten komprimieren und dekomprimieren zu können. Weiterhin realisiert Asterisk Zusatzfunkti-

onen wie Voice-Mail, Conference Calls und Call Bridging.

s. [VOV05]

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. entwi-

ckelt [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 ent-

hä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. fol-

gende 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

s. a.

http://www.centos.org

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 Ver-

stä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 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 Applikatio-

nen 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 konfigu-

rierten 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 Verwal-

tung der Applikationen und Channels übernehmen, um eine optimale Performance unter allen

denkbaren Auslastungssituationen sicherzustellen.

Asterisk Application API

Codec

Translator

Application

Launcher

Scheduler

und

I/O Manager

PBX Switching

Core

Dynamic

Module

Loader

Asterisk Channel API

div. Applikationen

VoiceMail

Conferencing

ile

SIP

ISDN

H.323

div. Hardware

VoFR

GSM

G.723

A-Law

µ-Law

Linear

ADPCM

MP3

GSM

G.723

WAV

MP3

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2006
ISBN (eBook): 9783832495893
ISBN (Paperback): 9783838695891
DOI: 10.3239/9783832495893
Dateigröße: 7.9 MB
Sprache: Deutsch
Institution / Hochschule: Universität Duisburg-Essen – Wirtschaftswissenschaften
Erscheinungsdatum: 2006 (Mai)
Note: 1,0
Schlagworte: voice sicherheit

Autor

Jens Heidrich (Autor:in)