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 bis 11: Plattform und Applikation

Ab Version 5 wird als Betriebssystem Red Hat Enterprise Linux verwendet. 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. Ein direkter Root-Zugriff des Anwenders/Administrators auf das Betriebssystem mit Red Hat Linux-Werkzeugen (Shell etc.) ist nicht gestattet. Dem Administrator steht für Basisdienste eine proprietäre Kommandozeile (CLI) zu Verfügung. Die überwiegende Konfiguration erfolgt mit einem Web Browser über Webseiten.

Als Datenbankmanagementsystem (DBMS) wird Informix von IBM eingesetzt.

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 ein zeitlich eng begrenztes, serverspezifisches Konto kreiert, welches 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 können. 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 gemanagt, „eigene Zertifikate“ angelegt 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 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 LSCs (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 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.

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 zugutekommt. Viele Applikationen wie Unity, Meeting Place und IPCC integrieren sich hier auch, was der Authentifikation gegen dieselben Credentials gleichkommt und daher die Administration vereinfacht.