Cisco Callmanager

Cisco Unified Communications Manager (Callmanager)
Entwickler:	Cisco Systems, Inc.
Aktuelle Version:	6.1(2) (6. Mai 2008)
Betriebssystem:	Linux, Windows 2000, Windows 2003
Kategorie:	VoIP (Software)
Lizenz:	proprietär
Deutschsprachig:	Adminschnittstelle: teilweise, Telefon- und Benutzerwebschnittstelle: ja
Cisco Unified Communications Manager (Callmanager)

Der Cisco Unified Communications Manager (Callmanager) (kurz: CUCM) ist eine Software zur Steuerung und Vermittlung von Telefonsystemen die auf dem IP-Protokoll basieren. Ein derartiges System wird auch als IP-Telefonie-Lösung oder Voice-over-IP (VoIP)-System bezeichnet. Der CallManager-Server übernimmt wesentliche Funktionen einer klassischen Telefonanlage und integriert zunehmend Video, Mobility, CTI- und Collaboration-Anwendungen. Bei anderen Herstellern findet man häufig den Begriff Soft-PBX.

Historie

Im Jahr 1994 wurde auf HP-UX der „Multimedia Manager 1.0“ veröffentlicht, der der Vermittlung von Videotelefonaten diente. Nach der Portierung auf Windows NT 3.51 und der Umbenennung in „Selsius Callmanager“ wurde der Softswitch für die Vermittlung von Voice-only-Gesprächen optimiert. Die Firma „Selsius“ wurde 1998 von Cisco Systems, Inc. aufgekauft. Das dann nochmals umbenannte Produkt „CallManager“ wurde forthin als Cisco CallManager verkauft. Am 6. März 2006 wurde Cisco CallManager in Cisco Unified CallManager umbenannt. Die im März 2007 erschienene Version 6 der IP-PBX wurde in Cisco Unified Communications Manager umbenannt. Ein seit dem auch erhältlicher Abkömmling davon ist der Cisco Unified CallManager Business Edition, der zusätzlich zu den bekannten Services noch Presence Messaging und Unified Messaging auf einem Server, unter einer Oberfläche bedienbar, vereint. Hierfür ist ein spezieller Server, der MCS7828 nötig.

Funktionen

Der CUCM steuert alle notwendigen Komponenten und Funktionen einer IP-Telefonie-Anlage (VoIP). Zu den Komponenten gehören im wesentlichen IP-Telefone, Voice-Gateways, Applikationsserver und Konferenzbrücken. Alle Einstellungen, Betriebszustände und Auswertungen werden vom CUCM in einer SQL Datenbank gespeichert. Mehrere CUCM können zu einer CUCM-Gruppe (Cluster) zusammengeschaltet werden um die Betriebssicherheit zu erhöhen, einzelne CUCM für spezielle Aufgaben zu separieren (TFTP-Server) und/oder die Leistungsfähigkeit zu erhöhen. In einem Cluster werden Konfigurationsänderungen grundsätzlich nur auf einem CUCM durchgeführt. Die (geänderten) Konfigurationsinformationen dieser Datenbank werden regelmäßig zu den restlichen CUCM im Cluster repliziert. Dieser CUCM wird als Publisher, die anderen CUCM als Subscriber (Teilnehmer) bezeichnet.

Leistungsmerkmale

• Skalierbarkeit:
  • Bis zu 7.500 Rufnummern pro Server
  • Bis zu 5.000 Benutzerprofile pro Server
  • Bis zu 9 Server pro Cluster (1 Publisher + 8 Subscriber = 60.000 Rufnummern/Cluster)
  • Verwaltung von über 1.000.000 Teilnehmern an über 100 Standorten bei Vernetzung mehrerer Cluster^[1]
• Mögliche Hardwareplatformen:
  • Cisco Media Convergence Server 7815, 7825, 7835, 7845
  • HP ProLiant DL380 G5, DL385 G5
  • IBM System x3650
  • Zu Testzwecken ist die Installation auf einer virtuellen Maschine (VM-Ware) möglich. Virtualisierung wird aber momentan (noch) nicht offiziell unterstützt.

Administration und Konfiguration

Die Konfiguration des CUCM erfolgt primär über ein Webinterface. Als Browser wird der Microsoft Internet Explorer (ab Version 5.x) und Mozilla Firefox unterstützt. Für umfangreiche Importe, Exporte und Änderungen steht das Bulk Administration Tool (BAT) zu Verfügung. Ein Excel-Template, um z.B. eine Vielzahl von Benutzer- oder Rufnummerdaten einzuspielen oder zu ändern. Neben einem administrativem Webzugang besteht auch für jeden Benutzer die Möglichkeit, Änderungen seiner Telefoniefunktionen vorzunehmen.

Der Zugriff auf das Linux-Betriebssystem (Root-Zugriff) und die Datenbank ist ab CUCM Version 5.x grundsätzlich nicht mehr möglich. Es steht lediglich ein Command Line Interface (CLI) mit einem eingeschränktem Befehlssatz zum Troubleshooting oder dem Abfragen von System-und Datenbankinformationen zu Verfügung. Root-Zugriff ist dem technischem Support von Cisco (TAC) vorbehalten.

Der Einsatz von HP Integrated Lights-Out (iLO) ist nicht zur Installation oder für ein Update des CUCM geeignet.

Sicherheitsmerkmale des Cisco Unified Callmanagers

Eine Historische Übersicht

Der (Windows-basierte) Callmanager 4 bot neben einem gehärteten System, https (Webzugriff), SLDAP (Secure LDAP, oder LDAP via SSL, auch „LDAPS“ genannt), Zertifikats-basiertem TLS und SRTP zu Telefonen und MGCP-Gateways später dann auch SRTP für H.323-Gateways und SRTP-Unterstützung bei der Fall-Back-Telefonie.

Im Unified Callmanager 5 wurden diese Funktionen übernommen und erweitert. So sind einige Sicherheitsmerkmale im Hinblick auf die SIP-Terminals und auf die Appliance-Plattform hinzugekommen.

Unified Callmanager 5 / Unified Communications Manager 6: Platform und Applikation

Der CCM 5 und CUCM 6 basiert wie Telekommunikationsanlagen anderer Hersteller auf Linux (Red Hat Enterprise Linux 3). Damit einhergehend sind Aspekte der OS-Härtung (Gastkonten, Abschalten ungenutzter Dienste, …), das Konzept des „Least Privilege“ und die Security Passphrase (mit Überprüfung der Komplexität, …) adressiert worden.

Als Datenbankmanagementsystem (DBMS) kommt Informix von IBM zum Einsatz.

Da aber auf dem CUCM auch keine Applikation von einer Shell, einem Dateisystem oder der Konsole aus gestartet werden kann die Netzwerkzugriff hat, sind Virus- und Wurmangriffe signifikant erschwert. Es gibt einen dedizierten Mechanismus, der es dem Cisco TAC für Trouble Shooting Arbeiten ermöglicht, einen privilegierten Remote Access Account zu erstellen. Hierfür wird durch den Benutzer ein CLI-Kommando ausgeführt, das einen zeitlich eng begrenzten, serverspezifisches Konto kreiert, der dann vom Cisco TAC genutzt werden kann.

Früher zugängliche Dienste wie DHCP, DNS, PING, Logdatei-Zugang etc. sind nun nur noch über das GUI via https oder das CLI via SSH zugänglich. Die Images für den Unified Callmanager sind digital signiert. Dies stellt sicher, dass bei Updates nur Images von Cisco die nicht verändert wurden auf dem Unified Callmanager installiert werden können. Der CCM5/6 benutzt eine dynamische Firewall, die den Intra-Cluster-Verkehr ausschließlich auf bekannte Geräte limitiert. Daher muss bei einer Installation (anders als noch beim CCM4) auch erst der Publisher komplett laufen, bevor dem Cluster weitere Server hinzugefügt werden können. Die Interfaces des CCM5/6 sind bis auf wenige Ausnahmen durch Verschlüsselung gesichert (HTTPS, SLDAP, SSH, SFTP, SNMPv3). Web-Applikationen sind speziell gesichert (30 min-Auto-Logoff bei Untätigkeit, …) Die sicherheitsrelevanten Logdateien (Security/Event/CSA-Agent) sind nur durch das „Real-Time-Monitoring-Tool“ (RTMT) welches ausschließlich via SSH mit dem CCM5/6 kommuniziert, abrufbar. SFTP ist eine Alternative hierzu.

Der Cisco Security Agent (CSA)

In der Pre-CCM5/6-Ära war es möglich, den CSA als managed CSA zu installieren. Da hierfür der Client von der Management Konsole kompiliert wird unterstützten die CCM5/6 diese Variante nicht mehr. Dies geschieht deshalb, damit die Policy und der Public Key der Management Konsole in das Image des Clients eingefügt werden kann. Die neueren CallManager akzeptieren ausschließlich signierte Images, wodurch nur die durch Cisco direkt bereitgestellten COP-Dateien für Updates und Policies des CSA zur Verfügung stehen. Gleichzeitig werden von Cisco speziell optimierte Policys designed, deren Anwendung Fehlkonfigurationen durch die Administratoren vermeidet und deren Arbeit vereinfacht.

IPSec-Philosophie

Die neueren Cisco Unified CallManger unterstützen nur authentifizierte oder authentifizierte und gleichzeitig verschlüsselte IPSec-Verbindungen zu Remote-Geräten (Pre Shared Keys oder Zertifikate). Das gilt für Gateways (MGCP und H.323) wie auch für Inter Cluster Trunks. Entsprechende Kommandos sind sowohl auf der CLI wie auch im GUI vorhanden. So können mit ihrer Hilfe Zertifikate gemanaged werden, „eigene Zertifikate“ angelegt werden, oder auch „fremde Zertifikate“ eingepflegt und externe Certificate Authority (CA) angelegt werden. Das noch im Unified Callmanager 4 genutzte „Simple Certificate Enrolment Protocol“ (SCEP) wurde durch das CSR (Certificate Signature Request) Protokoll ergänzt, mit dem sich eine Nachfrage bei der CA, z. B. ein Zertifikat zu erzeugen, signieren lässt.

Erweiterungen bei SRTP ^[2] und TLS

Cisco benutzt ein bidirektionales Austauschen der X.509v3-Zertifikate als Basis der beiderseitigen Vertrauensbeziehung. Eine CTL-Datei (Certificate Trust List) wird erzeugt und zu den Telefonen übertragen, in dem die Zertifikate und eine Liste der vertrauenswürdigen Geräte enthalten ist. Beispielsweise der TFTP-Dienst ist hierin enthalten, wie auch die CAPF-Server. Die Telefone müssen aber auch die Zertifikate der eTokens kennen, die die Zertifikate mitbringen, mit denen das CTL-Datei selbst vom Administrator signiert wird. Korrespondierend müssen aber auch die Unified CallManager, TFTP-Server und diverse Services den Telefonen vertrauen können. So genannte LSC’s (Locally Significant Certificates), die durch die CAPF (Certificate Authority Proxy Function) erzeugt werden (oder zur CA geroutet werden), und MSC’s (Manufacturer Signed Certificates) bilden hierfür die Grundlage. Sie werden über eine gesicherte TLS-Verbindung ^[3] zum Unified Callmanager übertragen. Bei Gateways kommt IPSEC zur Sicherung zum Einsatz. Einmal authentifiziert und autorisiert, wird ein „Preshared Master Secret“ erzeugt, von dem die diversen SALT- und HMAC-Werte abgeleitet werden. Ab da an ist eine Vertrauensbeziehung für alle Geräte etabliert. Verschiedene Modi für den Zertifikatsaustausch sind wählbar, wie auch verschiedene Kombinationen bei der Authentifizierung. Es ist so möglich, einen matrixartig gemischten Betrieb Authentifiziert/Verschlüsselt optional/obligatorisch im Netz zu konfigurieren. Damit werden je nach eingesetzter Technik auch Mischkonstellationen umsetzbar. Das „Cisco Callmanager Capacity Tool“ ist in der Lage, Kapazitätsberechnungen auch für TLS-betriebene Telefone vorzunehmen. Generell nutzen Telefone 36 kb mehr Speicher und 3–5 % mehr CPU auf dem CCM als Telefone ohne TLS. Mit dem Unified CallManager 5.1 kam allerdings auch ein Mechanismus hinzu, der die TLS-Speicher-Allokation auslagerte und somit den gesamten Prozess noch skalierbarer gestaltete.

Firewall/NAT Traversal

Ist die Sprache (besser: der Signalisierungsverkehr für Sprache) verschlüsselt, kann eine Firewall den Signalisierungsverkehr nicht mehr monitoren und dynamisch Ports öffnen/schließen oder umsetzen. Gleiches gilt für Session Border Controller. Mit dem CCM 5.1 und Cisco’s Firewall-Familie (PIX/ASA seit Version 8.0) gibt es eine spezielle Funktion um in den Verkehr zu „horchen“, indem ein Zertifikat der Firewall in die CTL-Datei geschrieben wird. Damit wird die Firewall als vertrauenswürdig angesehen und kann als „Man in the Middle“ die TLS-Sitzung zwischen den Telefonen und dem CCM5.1+ terminieren. Gleichzeitig kann man so in großen Netzen Last vom CCM nehmen, da er die Sitzungen nicht mehr selbst terminieren muss. Das entsprechende Leistungsmerkmal nennt sich „TLS-Proxy“.

Das Trouble Shooting solcher Techniken kann sehr komplex werden. Cisco hat diverse Hilfen explizit dafür in den CCM5+ eingebaut, wie auch Schnittstellen, um Sitzungsschlüssel über gesicherte CTI-Schnittstellen im „Packet Capture Mode“ abzugreifen. Auch im Zusammenhang mit Lawful Intercept („Sprachaufzeichnung“) wird dies verwendet, um berechtigten Servern Mitschneidemöglichkeiten für verschlüsselte Gespräche zu bieten.

Unified Callmanager 5/6 LDAP Sicherheit

Unified CallManagerversionen vor 4.0 hatten ein eingebautes LDAP-Verzeichnis. Mit der Version 5.0 kam eine Methode dazu, LDAP-Verzeichnisse abzufragen, und die Benutzer in der internen Datenbank des Unified CallManagers (nicht etwa einem internen LDAP!) zu speichern. Damit war es nun möglich, sich in externe LDAP-Verzeichnisse über zwei getrennte Prozesse zu integrieren: 1. Synchronisation, 2. Authentifikation. Eindeutige Such-Zeichenfolgen und multiple Suchinstanzen erlauben die dedizierte Extraktion nur der wirklich benötigten Benutzernamen im externen Directory. Ein Authentifizierungsprozess (genannt „Identity Management System“, IMS) bestimmt, ob Authentifizierungsnachfragen entweder durch die interne Datenbank beantwortet werden oder via SLDAP zum externen Directory weitergeleitet werden. Der Unified Callmanager 5+ kennt zwei Arten von Benutzern: „Enduser“ und „Application User“. Der Unterschied besteht darin, dass Application User immer gegen die interne Verzeichnisdatenbank authentifiziert werden, wogegen Enduser auch gegen externe LDAP-Verzeichnisse geparst werden. Vorkehrungen für die vereinfachte Integration in Directorys wie Microsofts AD, Netscape, iPlanet, SUN ONE wurden getroffen, was einer extrem vereinfachten Konfiguration bei diesen Directories bei Synchronisation, Moves Adds and Changes und der Datensicherheit bei Migrationsaufgaben und Netzproblemen zugute kommt. Viele Applikationen wie Unity, Meeting Place und IPCC integrieren sich hier auch, was der Authentifikation gegen dieselben Credentials gleich kommt und daher die Administration vereinfacht.

Quellen

1. ↑ http://www.cisco.com/web/DE/solutions/unified_communication/unified-communications-manager.html
2. ↑ RFC 3711
3. ↑ RFC 2246

Weblinks

• Offizielle Cisco-Produktseite (englisch)
• Vergleichbar ist das Clarity Communication Center (deutsch)