Voice over IP-Gateway mit VPN-Anbindung

Transkript

1 Voice over IP-Gateway mit VPN-Anbindung Daniel Albers 30. Oktober

2 INHALTSVERZEICHNIS INHALTSVERZEICHNIS Inhaltsverzeichnis 1 Ausgangssituation Umfeld Ziele Ist -Zustand Soll -Konzept Schnittstellen Planung Kosten Personal Sachmittel Aufstellung Termine Ablauf Entscheidungen, Alternativen Software VoIP Sicherheit Realisierung Serverinstallation Betriebssystem Zertifikate IPSec L2TP VoIP DHCP und DNS Paketfilter Abschlussphase Modultests IPSec L2TP, DHCP VoIP Systemtest Resultate Vergleich Soll Ist Abweichungen, Probleme Erweiterbarkeit A Meilensteine 17 1

3 ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS B Abnahmeprotokoll 17 C Auszüge der Konfigurationsdateien 17 D Perl-Skript zum Auslesen der Mitarbeiterdatenbank 17 E Kundendokumentation 18 E.1 Zertifikate hinzufügen Abbildungsverzeichnis 1 Netzstruktur Vermittlungsebenen Tabellenverzeichnis 1 Kostenaufstellung Zeitbedarfsplanung Softwareauswahl

4 1 AUSGANGSSITUATION Projektbezeichnung Voice over IP-Gateway mit VPN-Anbindung 1 Ausgangssituation 1.1 Umfeld Das Projekt wird bei der IQDoQ GmbH realisiert. Die IQDoQ GmbH ist als ein hundertprozentiges Tochterunternehmen der MATERNA Unternehmensgruppe für die Themenbereiche Enterprise-Content-, Dokumentenund Output-Management, sowie elektronische Archivierung verantwortlich tätig. 1.2 Ziele 1.3 Ist -Zustand Marketing-, Vertriebs- und Supportmitarbeiter der IQDoQ GmbH sind häufig im Außendienst tätig. Grade bei Problemanalysen, die beim Kunden vor Ort stattfinden, kommt es vor, dass ein Mitarbeiter im Außendiensteinsatz Rücksprache mit einem anderen Kollegen halten möchte. Normalerweise werden diese Telefonate nicht über Telefone des jeweiligen Kunden getätigt, da dies für den Kunden Aufwand und Kosten bedeuten würde, die ihm nicht angelastet werden sollen. Außerdem bestünde ggf. das Risiko der Preisgabe von Telefonnummern, die nur zur firmeninternen Verbreitung bestimmt sind. Aus diesen Gründen werden in solchen Situationen Gespräche über Mobiltelefone abgewickelt, was zu vergleichsweise hohen Kosten, sowie ggf. qualitativ schlechten und unzuverlässigen Verbindungen führt. 1.4 Soll -Konzept Da mittlerweile an vielen Orten kostenlose und unkompliziert nutzbare Zugriffsmöglichkeiten auf das Internet bestehen und dies auch bei vielen Kunden der Fall ist, soll Außendienstmitarbeiten als kostengünstige Alternative zu herkömmlichen Telefonaten die Telefonie über den Internetzugang (Voice over Internet Protocol, VoIP) ermöglicht werden. Zu diesem Zweck wird in der Geschäftsstelle Dortmund ein Server eingerichtet, der Telefonate von oder an Mitarbeiter über das Internet entgegennimmt und über die firmeninterne Telefonanlage ohne weitere Verbindungskosten Gespräche zum jeweiligen Mitarbeiter durchstellt. Um eine verlässliche Zugangskontrolle, sowie Schutz vor dem Abhören der Telefonate zu erreichen, werden die Verbindungen vom Außendienstmitarbeiter zum VoIP-Gateway durch die Verwendung eines virtuellen, privaten Netzwerks (VPN) gesichert. 3

5 1.4 Soll -Konzept 1 AUSGANGSSITUATION Abbildung 1: Netzstruktur Erläuterung Der Anwender für den dieses Projekt konzeptioniert ist, verfügt über einen Laptop mit Windows NT 4 oder neuer, Zugriff aufs Internet, einem Programm zur Internettelefonie (Softphone) und einem Headset bzw. integriertem Mikrofon. Der VoIP-Server ist hinter einer Firewall angeschlossen, welche nur Pakete, die zu bestehenden VPN-Verbindungen gehören, sowie Pakete, die zur Initialisierung einer VPN-Verbindungen dienen, zum Server durchlässt. Der VoIP-Server selbst leitet aus Sicherheitsgründen keine ankommenden Pakete an andere Systeme im Netzwerk weiter. Somit entspricht der Aufbau einem Endpunkt-zu-Endpunkt- VPN. Möchte der Anwender einen Anruf tätigen, stellt er zunächst eine Verbindung zum VPN her. Dies geschieht über die Windows-DFÜ-Einwahl. Im Laufe dieses Prozesses übermittelt der Rechner ein X.509-Zertifikat[1], das vorab durch einen Mitarbeiter von der IQDoQ-Zertifizierungsstelle (CA) ausgestellt und beglaubigt wurde. Mittels dieses Zertifikats und eines vom Benutzer anzugebenden Passwortes beweist das System dem VPN-Dienst auf dem VoIP-Server seine Zugriffslegitimation. Auch der VPN-Dienst weist sich gegenüber der Gegenstelle mittels eines Zertifikates aus. Der Aufbau stellt somit eine Public Key Infrastructure (PKI) dar. Haben beide Systeme die Identität und Legitimation des jeweils andere Systems verifiziert, wird die Anmeldung abgeschlossen und die Verbindung zur Nutzung durch andere Programme freigegeben. Da der Client nun den VoIP-Dienst auf dem Server erreichen kann, kann der Anwender über die Telefonie-Software seine Registrierung am VoIP-Dienst veranlassen. Wird diese Anmeldung erfolgreich abgeschlossen, gilt der Benutzer beim VoIP- Dienst als registriert und kann Anrufe tätigen und empfangen. Über seine ISDN-Karte ist der VoIP-Server mit der firmeninternen Telefonanlage verbunden. Sie stellt die Schnittstelle zwischen den Mitarbeitertelefonanschlüssen in den jeweilgen Büros und dem VoIP-Dienst dar. Diesen Funktionsweise bezeichnet man auch als Media-Gateway. 4

6 2 PLANUNG Zur Anwahl des jeweiligen Mitarbeitertelefons kann sowohl die Durchwahl, als auch die -Adresse des Mitarbeiters verwendet werden. So dient der VoIP-Gateway gleichzeitig auch als Telefonverzeichnis Schnittstellen Grafik Folgende Schnittstellen ergeben sich aus dem Konzept. Abbildung 2: Vermittlungsebenen Ablauf 1. Der Mitarbeiter wählt sich ins VPN ein. 2. Nach erfolgreicher Identifikation und Authentifikation wird die verschlüsselte Verbindung hergestellt. 3. Per Softphone registriert sich der Anwender beim VoIP-Server. 4. Tätigt der Mitarbeiter einen Anruf, signalisiert der VoIP-Gateway dies dem entsprechenden Anschluss über seine ISDN-Karte. 5. Wenn der gewünschte Gesprächspartner das Gespräch entgegennimmt, kann die Verständigung über Mikrofon und Kopfhörer, resp. Telefon beginnen. 2 Planung 2.1 Kosten Personal Zur Realisierung des Projekts werden 35 Arbeitsstunden zu einem internen Stundensatz von 7 aufgewendet. Es entstehen somit Gesamtpersonalkosten von

7 2.2 Aufstellung 2 PLANUNG Sachmittel Software In diesem Projekt kommt ausschließlich unter GNU GPL (General Public License) oder vergleichbaren Open-Source-Lizenzen veröffentlichte Software zum Einsatz. Kosten für die Lizenzierung entstehen somit keine. Die Software wird aus dem Internet heruntergeladen oder ist bereits lokal vorhanden. Für die Beschaffung wird daher keine weitere Kostenberücksichtigung vorgenommen. Hardware Die angeführte Software wird auf einem einzelnen System installiert. Hierfür steht ein nicht mehr genutzter Rechner samt ISDN- und Netzwerkkarte mit einem aktuellen Wert von ca. 49,- 1 zur Verfügung. 2.2 Aufstellung Bezeichnung Typ Kosten Personal Personenstunden 35 â 7 245,00 Software SuSE Linux Distribution Betriebssystem 0,00 Digium Asterisk Software-Nebenstellenanlage 0,00 ipsec-utils, racoon, Samba pppd, RP l2tpd VPN 0,00 Hardware PC 400MHz, ISDN, FastEthernet VoIP-Server 49,00 1 Tabelle 1: Kostenaufstellung Gesamt 294, Termine Durchführungszeitraum realisiert. Das Projekt wird im Zeitraum vom bis zum Ablauf Folgende Projektphasen von angegebener Dauer sind vorgesehen: 1 Quelle: 6

8 2.4 Entscheidungen, Alternativen 2 PLANUNG Projektphase Teilphase Zeitbedarf Definition Ist-Analyse 1,0h Soll-Konzept 1,0h Planung Hardware-Beschaffung 1,0h Software, Ablauf, Kosten 2,0h Realisierung Serverinstallation 2,0h PPP-, L2TP-Dienst konfigurieren 3,0h IPSec-Richtlinien einrichten, Zertifikate ausstellen 3,0h VoIP-Dienst konfigurieren 2,0h Paketfilter einrichten 0,5h Anbindung VoIP-Server Telefonverzeichnis 0,5h DHCP-Dienst konfigurieren 0,5h Abschluss Checklisten 3,0h Sprachqualität-, Performancetests 1,0h VoIP-Clients Auswahl, Empfehlungen 1,0h Fehlerkorrekturen 2,5h Abnahme 1,0h Projektdokumentation 8,0h Benutzerdokumentation 2,0h Zeit gesamt 35,0h Tabelle 2: Zeitbedarfsplanung 2.4 Entscheidungen, Alternativen Software Für die Erfüllung der VoIP-Anforderungen Registrar - Verwaltet die Zuordnung von Benutzern und Endgeräten Location-Server - Sorgt für die Vermittlung von Verbindungen Media-Gateway - Ermöglicht die transparente Nutzung verschiedener Übertragungsprotokolle und -medien, z.b. ISDN + SIP kommt die Software Asterisk 2 zum Einsatz, da diese die Anforderungen erfüllt, die ausgereifteste verfügbare Lösung darstellt und zudem kostenlos ist. Da Asterisk für die Benutzung auf unix-artigen Systemen ausgelegt ist, wird als Betriebssystem Su- SE Linux verwendet. Um sich auf den Laptopclients, bei denen es sich ausschließlich um Windows und Windows XP-Systeme handelt, die Installation zusätzlicher Software zu ersparen, wird für die Implementierung des VPN der von Windows nativ unterstützte Ansatz über L2TP/IPSec verwendet. Für die automatische Adressvergabe im VPN wird ein DHCP-Server konfiguriert, sowie für die Auflösung von Namen und Adressen ein DNS-Server eingerichtet. Die serverseitige Umsetzung erfolgt mit den folgenden Komponenten, die jeweils bewährte Standardimplementierungen auf ihrem Gebiet darstellen: 2 7

9 2.4 Entscheidungen, Alternativen 2 PLANUNG IPSec Linux-Kernel-Implementierung ISAKMP, Security Associations KAME-Werkzeuge 3 L2TP Samba 4 pppd und RP 5 l2tpd DHCP, DNS ISC 6 dhcpd und bind Tabelle 3: Softwareauswahl VoIP Für die Voice over IP-Übertragungen in diesem Projekt kommt das SIP [?, Session Initiation Protocol] in Verbindung mit SDP [2, Session Description Protocol] und RTP [?, Real-Time Transport Protocol] zum Einsatz. Es zeichnet sich ab, dass diese Kombination zum quasi-standard für VoIP-Netze geringer bis mittlerer Größe wird. Daher lässt sich eine rege und kontinuierliche Weiterentwicklung der häufig noch mit vielen Fehlern behafteten Anwender- und Serversoftware erwarten. Des Weiteren sind alle verwendeten Standards offen gelegt, was die größtmögliche Kompatibilität der verschiedenen Komponenten ermöglicht. Da das gesamte Themengebiet VoIP noch am Anfang seiner Entwicklung steht, liegen für die wenigsten Anwendungsfälle bewährte Lösungen oder Erfahrungswerte vor. Frühere VoIP-Implementierungen basierten hauptsächlich auf proprietären Protokollen, wie z.b. Skype, oder auf sehr komplexen Implementierungen, wie z.b. H.323[?]. Ein proprietäres Protokoll wie Skype eignet sich für die Verwendung in diesem Projekt aus verschiedenen Gründen nicht: Schnittstellen: Nur wenige Implementierungen von Schnittstellen mit anderer Soft- und Hardware sind vorhanden. Die Möglichkeiten zur Erstellung eigener Implementierungen sind vom Hersteller abhängig und berücksichtigen spezielle Anforderungen häufig nicht. Flexibilität und Kompatibilität: Die Programme sind nur auf den vom Hersteller berücksichtigten Betriebssystemen und Plattformen verwendbar. Quelloffene Software ließe hier beispielsweise das eigenständige Übersetzen und ggf. Anpassungen zu. Sicherheit: Bei der Implementierung von Sicherheitsmechanismen und dem Umgang mit Daten ist man gewzungen, dem Hersteller zu vertrauen. Eigene Möglichkeiten zur Überprüfung, z.b. durch Code-Audits, sind nicht oder nur sehr eingeschränkt vorhanden. Sollten Sicherheitslücken oder Programmfehler auftauchen, ist man wiederum auf die Behebung durch den Hersteller angewiesen. Auch der offene Standard H.323 ist hier ungeeignet: Komplexität: Während SIP sich auf die Funktion als Signalisierungsprotokoll beschränkt, schreibt der H.323-Standard eine komplexe Multimedia-Architektur vor und legt alle Einzelheiten der Implementierung fest. Flexibilität: Durch die exakte Definition der möglichen Arten von Nutzlasten ist der Umfang der Verwendungs- und Erweiterungsmöglichkeiten sehr gering. 8

10 2.4 Entscheidungen, Alternativen 2 PLANUNG Verbreitung: Aufgrund der schon angesprochenen Aspekte ist die Verbreitung von H.323 im Bereich kleiner bis mittlerer VoIP-Netze rückläufig. Die Berücksichtigung durch andere Software, sowie Weiterentwicklung bestehender Implementierungen wird sich daher voraussichtlich verschlechtern Sicherheit Schutzziele Da für weite Teile der vorgesehenen Gesprächsübertragungen in diesem Projekt die Nutzung fremder, nicht vertrauenswürdiger Netzwerke vorgesehen ist, sind Maßnahmen zum Schutz gegen unbefugte Mithörer (Vertraulichkeit) von großer Wichtigkeit. Auch die übrigen klassischen Schutzziele allgemeiner Kommunikationssysteme - Integrität und Verfügbarkeit - sollen erfüllt werden, treten aber gegenüber der Vertraulichkeit mehr in den Hintergrund, da schon über die natürlichen Wiedererkennungsmerkmale der Sprache in diesem kleinen Benutzerkreis ein Schutz vor Integritätsverletzungen besteht. Die Verfügbarkeit bezeichnet im Zusammenhang mit VoIP-Systemen vor allem die Erreichbarkeit des Dienstes, das Erreichen einer ausreichenden Sprachqualität, sowie den Schutz vor der gezielten Zurückhaltung bestimmter Informationen. Diese Ziele können nur insoweit sichergestellt werden, als dass für die netzwerktechnische Erreichbarkeit des Dienstes aus dem Internet Sorge getragen wird und alle Anfragen protokollkonform beantwortet werden. Einfluss auf Beeinträchtigungen bei der Benutzung fremder Netzwerke besteht nur durch die Auswahl und Empfehlung möglichst anspruchsloser Kodierungsmethoden. Außerdem wird durch die Sicherstellung der Vertraulichkeit einem Angreifer die Möglichkeit genommen, gezielt die Übermittlung von Teilinformationen - z.b. das Anrufen einer bestimmten Person - zu unterbinden, da er keinen Einblick in die übermittelten Informationen hat. Sicherungsmechanismen Sicherungsmöglichkeiten auf verschiedenen Ebenen. Für die verwendeten Komponenten existieren diverse SRTP Das Secure Realtime Transport Protocol[?] ist eine Weiterentwicklung des RTP. Es sichert die Erfüllung der Schutzziele Integrität, Vertraulichkeit, Authentizität und erkennt und verhindert Replay-Angriffe. Des Weiteren ist es speziell für die Echtzeitübertragung von Daten ausgelegt und bietet als Endgerät-zu- Endgerät-Protokoll Unabhängigkeit von der genutzten Netzstruktur. Die Protokollspezifikation ist relativ neu und gilt bislang als sicher. Aus dem geringen Alter der Spezifikation ergibt sich mit der sehr geringen Unterstützung durch Anwendersoftware aber auch der entscheidende Nachteil dieses Sicherungsmechanismusses. Somit ist es für die Verwendung in diesem Projekt ungeeignet. Mit zunehmender Verbreitung und Unterstützung dieses Protokolls würde jedoch in allen VoIP-Netzen eine sicherere Kommunikation möglich. Dank seiner transparenten Implementierung oberhalb der Transportschicht kann SIP in Kombination mit den bereits für darunterliegende Schichten vorhandenen Sicherungsmechanismen verwendet werden. 9

11 3 REALISIERUNG TLS und S/MIME TLS[3] und S/MIME[?] stellen allgemeine Sicherheitsebenen dar, die sich transparent für die Sicherung verschiedener Dienste höherer Protokollebenen, wie z.b. SIP, einsetzen lassen. Sie bieten die Möglichkeit der Verwendung von Zertifikaten und erfüllen ebenfalls die angesprochenen Schutzziele. Es existieren auch entsprechende Implementierungen, über die die sichere Verwendung von Anwendungen, die selbst keine TLS oder S/MIME-Nutzung vorsehen, durchgeführt werden kann. Dennoch sind sowohl client- wie auch serverseitig keine bewährten oder verbreiteten Implementierungen bekannt, sodass auch von der Verwendung dieses Ansatzes abgesehen wird. IPSec Bei IPSec[4] handelt es sich um eine bewährte Methode zur Sicherung von Daten, die das IP-Protokoll zur Übertragung nutzen. Es umfasst die Spezifikation eines Anwendungsschicht-Protokolls zum Austausch von Geheimnissen für symmetrische Verschlüsselung über ein unsicheres Medium (ISAKMP), sowie die IP-Erweiterungen Authentication Header (AH[5]) und Encapsulationg Security Payload (ESP[6]. Ersteres sichert Authentizität der Daten, letzteres die Vertraulichkeit durch Verschlüsselung. Den Schutz vor Replay-Attacken bieten beide durch die Verwendung von Sequenznummern. In Verbindung mit L2TP (Layer 2 Tunneling Protocol[?], eine Weiterentwicklung von Microsofts PPTP[?]) lässt sich IPSec unter Windows komfortabel nutzen und wird von allen Windows-Versionen seit Windows 98 unterstützt. Durch die Verwendung von L2TP erhält das System außerdem die Möglichkeit eigene, virtuelle IP-Adressen zu definieren und diese transparent für andere Anwendungen nutzbar zu machen. So wird für die Verwendung der verschlüsselten Verbindung nur die Nutzung der IP-Adressen des verschlüsselten Netzwerks in der jeweiligen Software eingetragen und keine weitere Unterstützung nötig. 3 Realisierung 3.1 Serverinstallation Betriebssystem Die Installation der Linux-Distribution erfolgt weitgehend automatisiert über einen Installationsserver. Das Minimalsystem wird installiert, um möglichst keine zusätzlichen Dienste zu installieren, die unnötiger Weise Ressourcen aufbrauchen oder sogar Sicherheitsprobleme verursachen. Zusätzlich werden die Pakete pppd, ipsec-utils, dhcpd und bind9 ausgewählt. Die Nwtzwerkkarte wird eingerichtet, sowie die CAPI-Schnittstelle der ISDN-Karte installiert Zertifikate Für die zuverlässige Identifizierung der Clients und des Servers werden für jedes beteiligte System Zertifikate mit den Attributen des jeweiligen Systems ausgestellt. 10

12 3.1 Serverinstallation 3 REALISIERUNG Außerdem wird ein Zertifikat als übergeordnete Instanz Certificate Authority (CA) benötigt, welches strengster Geheimhaltung unterliegt, da es zur Beglaubigung von Zertifikaten und Überprüfung von Beglaubigungen verwendet wird. Da bei der IQDoQ bisher keine unternehmensweit einheitliche PKI (Public Key Infrastructure) realisiert wurde, ist auch keine Zertifizierungsstelle verfügbar, sodass das CA-Zertifikat mit sich selbst signiert wird. Die Erstellung der Zertifikate erfolgt per OpenSSL 7 mit einer Gültigkeitsdauer von 10 Jahren für das CA-Zertifikat und einer Gültigkeitsdauer von 1 Jahr für die übrigen Zertifikate. Eine CRL (Certificate Revocation List), die für ungültig erklärte Zertifikate auflistet - weil diese beispielsweise kompromittiert wurden - wird mit einer Gültigkeitsdauer von 30 Tagen angelegt. Der 2048 Bit lange RSA-Schlüssel des CA-Zertifikates ist per 3DES verschlüsselt. Die privaten Teile der übrigen Zertifikate bleiben unverschlüsselt, da eine passwortbasierte Zugangskontrolle bereits auf L2TP-Ebene implementiert wird und diese für den Anwender komfortabler zu bedienen ist. Die Zertifikate für die Windows-PCs werden ins PKCS #12-Format[7] gewandelt, da die Zertifikate dort in dieser Form einfacher zu integrieren sind. Der öffentliche Teil des CA-Zertifikates wird darin auch übermittelt. Die Zertifikatserstellung und -signierung muss für jeden neuen Client erneut durchgeführt werden IPSec Bei der Installation des Paketes ipsec-utils wurde die Linux-IPSec-Umbegung um den Schlüsselaustausch-Dienst (ISAKMP) racoon und Werkzeuge zur Anpassung der sog. Security Associations ergänzt. Zur Aktivierung des IPSec-Stacks für die gewünschten Verbindungen werden die entsprechenden Security Associations erstellt. Diese werden so angelegt, dass das System passiv auf IPSec-Verbindungsanfragen von allen Adressen wartet, da die Quelladressen der sog. nomadischen Clients (auch: Roadwarrior ) vorab nicht bekannt sind. Für die Zuordnung von Clients zur entsprechenden Security Association wird daher der ASN.1 Distinguished Name als eindeutiges Identifikationsattribut des Zertifikats verwendet, wenngleich keine weiteren Associations auf dem System eingetragen sind. Die variablen Einstellungen richten sich auch hier hauptsächlich nach der Kompatibilität zu Windows. So wird z.b. die Länge der für den Diffie-Hellman- Schlüsselaustausch verwendeten Primzahl auf 1024 Bits begrenzt. Als Verschlüsselungsalgorithmus wird 3DES verwendet und als Paket-Authentifizierungsmethode HMAC-MD5. Die für jede IPSec-Verbindung nötigen Eintragungen in der Security Policy Database werden dynamisch vom ISAKMP-Dienst erstellt

13 3.1 Serverinstallation 3 REALISIERUNG L2TP Nach dem Kompilieren des Quelltextpakets erfolgt die Installation des L2TP-Dienste in Standardpfade. Über L2TP und PPP wird eine Punkt-zu-Punkt-Verbindung aufgebaut, welche dann für Client und Server jeweils ein zusätzliches, virtuelles Interface bereitstellt und so für andere Programme die verschlüsselte Verbindung transparent nutzbar machen. Analog zur Kapselung der PPP-Daten in L2TP, wird auch der pppd vom rp-l2tp- Dienst aufgerufen. Während der PPP-Verhandlungsphase wird der Client zur Übermittlung eines Passworts aufgefordert, welches der Benutzer angeben muss. Aus diesem Grund wird die Nutzung der von Windows bevorzugten Microsoft-Erweiterungen des CHAP ([8, Challenge Handshake Authentication Protocol]) aktiviert, was für die erfolgreiche Authentifizierung zwar nicht zwingend erforderlich ist, aber das Ändern der Windows-Standardkonfiguration für die DFÜ-Einwahl unnötig macht. In der Konfiguration des PPP-Dienstes werden die jeweiligen Benutzer und Passwörter eingetragen. Dies muss für jeden neuen Benutzer wiederholt werden. Bei den Verhandlungen der Systeme zum Verbindungsaufbau akzeptiert der pppd nur Adressen aus einem gewählten privaten IP-Bereich. Der PPP-Dienst wird um ein Plugin zur Abfrage von DHCP-Servern erweitert und in der Konfiguration des L2TP-Dienstes aktiviert. Dies führt dazu, dass der PPP- Dienst bei den Verbindungsverhandlungen mit dem Client eine DHCP-Anfrage an den lokalem DHCP-Dienst stellt und dem Client die zurückgelieferte Adresse als für die PPP-Verbindung zu verwendende vorgibt. Der PPP-Dienst verhält sich also ähnlich wie ein DHCP-Relay Agent. Die DHCP-Zuordnung basiert jedoch nicht, wie sonst bei DHCP üblich, auf der Client-MAC-Adresse, sondern auf dessen Benutzerkennung, die als Wert der DHCP-Option client-identifier übermittelt wird. Somit ist in der VPN-Umgebung eine klassische, dynamische Adressvergabe realisiert. Ebenfalls im Laufe der Aufbauphase der PPP-Verbindung übermittelt der Dienst seine eigene IP zur Verwendung als DNS-Server durch den Client VoIP Das Asterisk-Quelltextpaket, sowie ein Patch zur Nutzung der CAPI-Schnittstelle werden heruntergeladen, kompiliert und unter den Standardpfaden installiert. Da asterisk, wie auch das ganze Themengebiet VoIP, starker Entwicklung unterliegt, wird darauf geachtet, eine aktuelle Version zu verwenden, um eine möglichst fehlerbereinigte Anwendung zu erhalten. Die Konfiguration der CAPI-Schnittstelle erfordert lediglich die Eingabe der eigenen Durchwahl. Für die einzelnen Benutzer werden SIP-Accounts angelegt. Auch hier ist wieder die Angabe eines Passwortes möglich, es wird das schon bei der L2TP-Einwahl verwendete benutzt. Über die Angabe von Asterisk-Durchwahlen wird die Weiterleitung der Anrufe kon- 12

14 3.1 Serverinstallation 3 REALISIERUNG figuriert. Wählt ein Benutzer eine Telefonnummer, wird die Verbindung je nach Länge der Nummer als interne Durchwahl über die Telefonanlage geleitet oder durch Voranstellen einer 0 ins öffentliche Telefonnetz. Hier sind Beschränkungen zur Minimierung von Kostenrisiken durch Missbrauch möglich, aber wegen des vertrauenswürdigen Benutzerkreises nicht vorgesehen. Mittels eines Perl-Skripts wird eine Zuordnung von -Adressen zu den entsprechenden Telefonnummern aus dem LDAP-Mitarbeiterverzeichnis generiert. Da das für SIP-Adressierung vorgesehene URI-Schema sich exakt auf die -Adressen anwenden lässt, können sie statt einer Telefonnummer als Anwahlziel im Softphone genutzt werden. Das Eintragen der PPP-IP-Adresse des VPN-Interfaces als Parameter für den bind()- Aufruf sorgt dafür, dass asterisk nur Anfragen von VPN-Clients erreichen DHCP und DNS Dem ISC dhcpd wird die Verwaltung der IP-Adressen aus dem für das VPN reservierten Adressbereich übertragen. Für den DNS-Dienst bind werden Zonen für die Forward- und Reverse-Lookups der VPN-IPs angelegt und mit Einträgen nach dem Schema cli45.voip.iqdoq.de gefüllt. Dies hat hauptsächlich kosmetische Wirkungen, bzw. verringert ggf. das Aufkommen von DNS-Anfragen, da diese nicht ins Leere laufen. Größere Bedeutung kommt der Erstellung des SRV-Eintrages in der lokal angelegten Domäne iqdoq.de zu. Hier wird durch den SRV-Verweis von sip. udp.@iqdoq.de auf gw.voip.iqdoq.de, bzw. den VoIPGateway, die Zuständigkeit für alle SIP-Adressen mit der Endung atiqdoq.de deklariert und somit die Gültigkeit der -/SIP- Adressen nach dem Muster Vorname.Nachname@iqdoq.de erreicht Paketfilter Um den VoIP-Gateway aus dem Internet erreichbar zu machen, wird bei der Firewalladministration die Freischaltung von zum Server gerichteten Verbindungen auf dem SchlüsselaustauschPort (500/UDP, IKE) und mit den Protokollen AH (50) und ESP (51), sowie den entsprechenden Antworten beantragt werden. Am Server selbst werden mit dem netfilter-frontend iptables Regeln definiert, die grundsätzlich alle ankommende und abgehende Pakete per ablehnen, jedoch die genannten Verbindungen akzeptiert. Zusätzlich werden aus dem LAN kommende Verbindungen zum SSH-Port akzeptiert, sowie eigene Anfragen zum DNS-Server zugelassen. Auch hier sind die entsprechenden Antwortpakete zu berücksichtigen. Die lokalen Paketfilterregeln werden nur zur zusätzlichen Absicherung verwendet, bei ordnungsgemäßer Funktionsweise der VPN- und VoIP-Komponenten sind den eingewählten Clients nur Verbindungen über die virtuellen VPN-Interfaces möglich. 13

15 4 ABSCHLUSSPHASE 4 Abschlussphase 4.1 Modultests Schon während der Durchführungsphase wurde die Funktionalität von neu implementierten Komponenten getestet und beobachtete Fehler beseitigt. Im Einzelnen wurden folgende Komponenten getestet: IPSec Test Erwartung Ergebnis Test Erwartung Ergebnis Anlegen von IPSec-Security Associations mit festen Schlüsseln auf zwei Systemen und Herstellen eines verschlüsselten Übertragungsweges über einen Gateway Pakete zwischen den beiden Systemen werden verschlüsselt erfolgreich Nach Ausführung eines Pings zwischen den beiden beteiligten Systemen sind am Gateway mittels eines Netzwerksniffers nur AH- und ESP-Nutzlasten zu sehen. Die Endsysteme erhalten und beantworten die Ping-Pakete korrekt. Wie oben; statt fester Schlüssel werden aber Zertifikate erstellt und beglaubigt Ein Schlüsselaustausch findet statt, werden die Pakete zwischen den beiden Systemen verschlüsselt übertragen erfolgreich Nach Ausführung eines Ping-Befehls werden nach dem IKE-Verfahren Schlüssel ausgetauscht und die Ping-Pakete verschlüsselt übertragen L2TP, DHCP Test Erwartung Ergebnis Test Erwartung Ergebnis Auf einem Windows 2000-System wird ein Zertifikat integriert und die DFÜ-Einwahl für ein VPN eingerichtet. Serverseitig werden Benutzername, Passwort und eine feste IP vergeben. Der Client meldet sich an, bekommt die angegebene IP zugewiesen und Übertragungen an den Server finden verschlüsselt statt. erfolgreich Die Validierung der Zertifikate und Benutzerdaten erfolgt, das System bekommt seine IP mitgeteilt und richtet das entsprechende Interface ein. Die Daten werden hierüber verschlüsselt übertragen. Wie oben; statt der festen Zuweisung IP-Adresse wird serverseitig die IP-Ermittlung per DHCP-Anfrage aktiviert. Der Client bekommt basierend auf seiner Nutzerkennung eine IP zugewiesen. Bei einer erneuten Einwahl mit der selben Kennung innerhalb der Lease-Gültigkeit erhält er die selbe IP erneut. erfolgreich Der Client bekommt eine IP aus dem vorgesehenen Adressbereich zugewiesen; bei weiteren Anwahlen erhält er je nach Nutzerkennung unterschiedliche IPs. 14

16 4.2 Systemtest 4 ABSCHLUSSPHASE Test Erwartung Ergebnis Wie oben; jedoch werden bei der Anmeldung ungültige Zertifikate bzw. Benutzerdaten verwendet. Bei Verwendung eines ungültigen Zertifikats scheitert bereits die IPSec-Initialisierung; bei validem Zertifikat werden die Benutzerdaten abgefragt, die Falscheingabe an dieser Stelle führt ebenfalls zum Verbindungsabbruch. erfolgreich Die Verbindung kommt nicht zustande VoIP Test Erwartung Ergebnis In der Asterisk-Konfiguration wird ein Benutzer angelegt, außerdem werden mittels eines Perl-Skripts die klassischen Telefondurchwahlen aus dem LDAP-Mitarbeiterverzeichnis mit den jeweiligen -Adressen als SIP-Adresse verknüpft. Per Softphone wird ein Telefonat geführt. Die Registrierung des Softphones erfolgt; bei der Wahl einer numerischen Durchwahl, bzw. Wahl einer SIP-/ -Adresse wird der Anruf zum Bürotelefon des entsprechenden Mitarbeiters durchgestellt. erfolgreich Die Verbindung kommt zustande; die Sprachqualität ist einwandfrei und ohne spürbare Verzögerungen. 4.2 Systemtest Test Erwartung Ergebnis Ein Anwender wählt sich aus einem entfernten Netzwerk ins VPN ein und führt mittels Softphone ein Telefonat mit einem Mitarbeiter der Dortmunder Geschäftsstelle. Da vor Abschluss des Projekts keine Firewallfreigabe erfolgt, wird der Zugriff aus dem entfernten Netzwerk durch einen Gateway simuliert, der die Verbindung mittels Linux-Traffic-Control begrenzt. Verschiedene SIP- Clients und Sprachkodierungsverfahren werden verwendet. Einwahl und Telefonat kommen zu Stande. Die Sprachqualität variiert nach verfügbarer Bandbreite und Kodierungsverfahren. erfolgreich Die Einwahl und Telefonverbindung funktionieren. Bei einer Bandbreitenbegrenzung auf 64kBit/s und Verwendung verschiedener Kodierungsverfahren lässt sich eine gute Sprachqualität erreichen. Einzig die Verwendung des Kodierungsverfahrens G.711 führt auf Grund der zu großen Bitrate zu ungenügenden Resultaten bei der auf 64kBit/s begrenzten Verbindung. Die zuverlässigsten Resultate bietet das Softphone X-Lite in Verwendung mit GSM-Kodierung. Die Ergebnisse dieses Tests fließen in die Anwenderdokumentation mit ein. 15

17 5 RESULTATE 5 Resultate 5.1 Vergleich Soll Ist Die Projektziele wurden erreicht. Die VoIP-Kommunikation mit Kollegen einer Geschäftsstelle lässt sich als kostengünstige und zuverlässige Alternative zur Mobiltelefonie nutzen. Weiterführende Erfahrungswerte aus dem Praxiseinsatz müssen noch gewonnen werden. 5.2 Abweichungen, Probleme Public Key Infrastructure Da keine unternehmensweite Public Key Infrastruktur vorhanden ist, müssen für das Projekt eigene Zertifikate verwendet werden. Dies erhöht den administrativen Aufwand und widerspricht dem eigentlichen Prinzip der PKI, das vorsieht einzelne zentral verwaltete Zertifikate und Zertifikatsketten in vielen verschiedenen Anwendungen zu nutzen. Bei Verwendung vieler einzelner Zertifikate verliert der Anwender außerdem das Sicherheitsbewusstsein, da er sich an ggf. auftretende Sicherheitswarnungen gewöhnt und diese ignoriert. Rückruf Da der VoIP-Gateway über die interne Telefonanlage nur über eine einzelne Durchwahl (z.b. 1234) zu erreichen ist, kann keine Zuordnung von Telefonnummern zu SIP-Clients erfolgen. Der VoIP-Gateway ist so konfiguriert, dass bei der Anmeldung eines SIP-Clients die Weiterleitung der an der ISDN-Karte ankommenden Anrufe in zu diesem Client erfolgt, spätere, parallel angemeldete Clients auf diese Weise aber nicht erreichbar sind. In Abstimmung mit der zuständigen Administration wäre es aber evtl. möglich, eine komplette Rufnummerngasse (1234-*)zum VoIP-Gateway zu delegieren. Dies würde eine sinnvolle bidirektionale Verwendung ermöglichen. Tests in realistischer Umgebung Wie bereits in 4.2 (S. 15) angesprochen kann die Firewallfreischaltung aufgrund der internen Sicherheitspolitik erst nach Abschluss aller Projektarbeiten und einer gewissen Bearbeitungsdauer durchgeführt werden. Durch die Bandbreitenbegrenzung im Systemtest wurde diesem Umstand Rechnung getragen. 5.3 Erweiterbarkeit Das Projekt wird mit einem Server in der Geschäftsstelle Dortmund realisiert. Daher fallen bei Telefonaten mit Mitarbeitern anderer Geschäftsstellen zusätzliche Telefonkosten an. Diese liegen zwar immer noch unter den Kosten für Mobilfunkverbindungen, schmälern aber die Gesamtersparnis. Durch Anbindung weiterer VoIP- Gateways an den Telefonanlagen der übrigens Standorte ließe sich Nutzung der öffentlichen Telefonleitungen vermeiden und auf die IP-Schicht verlagern, was diese Kosten aufheben würde. Evtl. auftretende Probleme z.b. durch die größeren Latenzen wären zu berücksichtigen. 16

18 D PERL-SKRIPT ZUM AUSLESEN DER MITARBEITERDATENBANK A B C D Meilensteine Abnahmeprotokoll Auszüge der Konfigurationsdateien Perl-Skript zum Auslesen der Mitarbeiterdatenbank 17

19 LITERATUR E KUNDENDOKUMENTATION Literatur [1] R. Housley, W. Ford, W. Polk, and D. Solo. RFC 2459: Internet X.509 public key infrastructure certificate and CRL profile, January Status: PROPO- SED STANDARD. [2] M. Handley and V. Jacobson. RFC 2327: SDP: Session description protocol, April Status: PROPOSED STANDARD. [3] T. Dierks and C. Allen. RFC 2246: The TLS protocol version 1, January Status: PROPOSED STANDARD. [4] S. Kent and R. Atkinson. RFC 2401: Security architecture for the Internet Protocol, November Obsoletes RFC1825 [9]. Status: PROPOSED STAN- DARD. [5] S. Kent and R. Atkinson. RFC 2402: IP authentication header, November Obsoletes RFC1826 [10]. Status: PROPOSED STANDARD. [6] S. Kent and R. Atkinson. RFC 2406: IP Encapsulating Security Payload (ESP), November Obsoletes RFC1827 [11]. Status: PROPOSED STANDARD. [7] RSA Laboratories. PKCS #12 v1.0: Personal Information Exchange Syntax. RSA Data Security, Inc., Redwood City, CA, USA, June [8] G. Zorn and S. Cobb. RFC 2433: Microsoft PPP CHAP extensions, October Status: INFORMATIONAL. [9] R. Atkinson. RFC 1825: Security architecture for the Internet Protocol, August Obsoleted by RFC2401 [4]. Status: PROPOSED STANDARD. [10] R. Atkinson. RFC 1826: IP authentication header, August Obsoleted by RFC2402 [5]. Status: PROPOSED STANDARD. [11] R. Atkinson. RFC 1827: IP encapsulating security payload (ESP), August Obsoleted by RFC2406 [6]. Status: PROPOSED STANDARD. E Kundendokumentation E.1 Zertifikate hinzufügen 18