Produkte

Sicherheit im Unified CallManager 4, 5 und dem Unified Communications Manager 6 – eine Übersicht

Schon der Windows-basierte Unified Callmanager 4.1 bot eine Reihe von Sicherheitsmerkmalen, die ihn seit 2004 zum marktweit sichersten IP-Telefonieserver machen (unter anderem bewiesen durch einen Test von Miercom). Mit der Einführung des Unified CallManagers 5 standen neben der Übernahme dieser Merkmale, SIP-Line-Side-Erweiterungen und der Portabilität auf ein Appliance- Modell weitere tief greifende Sicherheitserweiterungen im Vordergrund. Diese wurden vom Unified Communications Manager 6 übernommen, der noch mehr Leistungsmerkmale bietet.

Der CallManager 4 bot neben einem

• gehärteten System
• dem Cisco Security Agent
• 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 die Sicherheitsmerkmale im Hinblick auf die SIP-Terminals und auf die Appliance- Plattform hinzugekommen:

• Das Betriebssystem der Plattform ist nicht mehr zugänglich.
• Die Unterstützung von TLS und SRTP wurde auf weitere Endpunkte und Protokolle ausgedehnt
• und die LDAP-Integration und -Sicherheit wurde signifikant verbessert.

Unified CallManager 5/Unified Communications Manager 6: Plattform und Applikation

Der fundamentale Gedanke des Appliance-Modells besteht darin, das unterliegende OS und Dateisystem des Servers für User und Administratoren unerreichbar zu machen. Jede Appliance, sei es eine Firewall, eine Content Engine oder TK-Anlage, hat ein zugrunde liegendes OS mit Systemkonfigurationsparametern, Dateizugriffsrechten, User-Accounts und ausführbaren Images. Vielen Administratoren ist nicht bewusst, dass sie auf einem kommerziell verfügbaren OS arbeiten, wenn sie auf dem GUI oder der CLI tätig sind. Das Appliance-Modell hebt in dieser Hinsicht nun die TKAnlage auf den selben Status wie beispielsweise eine Firewall. Damit einhergehend sind Aspekte der OS-Härtung (Guest-Accounts, Abschalten ungenutzter Services), das Konzept des „Least Privilege“ und die Security Passphrase (mit Überprüfung der Komplexität) adressiert worden. Da aber auf dem CCM auch keine Applikation von einer Shell, einem File System oder der Konsole aus gestartet werden kann, die Netzwerkzugriff hat, sind Virus- und Wurmangriffe signifikant minimiert, da solche Schädlinge meist durch User-Anwendungen (Mailer) eindringen. 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 User ein CLI-Kommando ausgeführt, das einen zeitlich eng begrenzten, Server-spezifischen Account kreiert, der dann vom Cisco TAC genutzt werden kann.

Früher zugängliche Services wie DHCP, DNS, PING, Logfile-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-Log-Off bei Untätigkeit). Die sicherheitsrelevanten Logfiles (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 Policiess entworfen, 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 verwaltet werden, „eigene Zertifikate“ angelegt werden, oder auch „fremde Zertifikate“ eingepflegt und eine externe Certificate Authority (CA) angelegt werden. Das noch im Unified CallManager 4 genutzte „Simple Certificate Enrolment Protocol“ (SCEP) wurde durch das CSR-Protokoll (Certificate Signature Request) ergänzt, mit dem sich eine Nachfrage bei der CA, etwa ein Zertifikat zu erzeugen, signieren lässt.

Erweiterungen bei SRTP (RFC 3711) und TLS

Cisco benutzt ein bidirektionales Austauschen der X.509v3-Zertifikate als Basis der beiderseitigen Vertrauensbeziehung. Ein CTL File (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-Service 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-File selbst vom Administrator signiert wird. Korrespondierend müssen aber auch die Unified CallManager, TFTPServer 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 (RFC 22 46) 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. Von 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 Unified CallManager Capacity Tool ist in der Lage, Kapazitätsberechnungen auch für TLS-betriebene Telefone vorzunehmen. Generell nutzen Telefone 36kb mehr Speicher und 3-5 Prozent mehr CPU auf dem CCM als Telefone ohne TLS. Mit dem Unified CallManager 5.1 kam ein Mechanismus hinzu, der die TLS- Speicher- Allokation auslagerte und somit den gesamten Prozess noch besser skalierbar gestaltete. Die Implementierung von Cisco ist die marktweit skalierbarste, umfassendste und am weitesten entwickelte Implementierung auf diesem Gebiet.

Erweiterte Unterstützung von Endgeräten

Die im Unified CallManager 4 mit SRTP unterstützten Geräte wie die Telefone 7911/40/60/41/61/70/71, das UMS Unity4.0(5), IPCC 7.0 und MGCP-Gateways wurden seit dem CallManager 5 sehr entscheidend erweitert. Es ist die SIP Line-Site für alle bisher nur mit SCCP unterstützten Telefone (TLS und SRTP) dazugekommen. Zusätzlich werden zur erhöhten Sicherheit nunmehr die Session Encryption Keys nicht mehr (wie bei SCCP) im Telefon selbst, sondern zur erhöhten Entropie im CCM5/6 erzeugt. Auch H.323-Gateways sind mittlerweile mit SRTP unterstützt. SRTP-Calls, die das Cluster verlassen, sind seit der Version 5 mit SRTP sicherbar. Die Konfiguration wurde mithilfe eines zusätzlichen Abstraktionslayers, des „Security Profile“, vereinfacht. Damit können Gruppen von Geräten einfacher mit gemeinsamen Sicherheitseinstellungen versehen werden.

Man darf natürlich auch die Rolle des Unified CallManagers als Protokollkonverter nicht vergessen. Telefonate zwischen SCCP, SIP, MGCP, H.323, CTI, Q.SIG und anderen Protokollen müssen auch nach Protokollkonvertierung sicher bleiben – und sind es mit den neuen Merkmalen der CCM5 und 6 auch.

Generell können SIP-Telefone im Peer-to-Peer-Modus direkt mit anderen SIP-Clients kommunizieren. Solche Telefone ignorieren allerdings in CCM-Umgebungen derartige Signalisierung und senden alle Call Setups zum CCM. Dies gilt auch für die Verschlüsselungssignalisierung. So ist in SIP-Umgebungen eine End-to-End-Verschlüsselung umsetzbar, aber trotzdem volle Interoperabilität zu SIP-Proxys, Registrars und Backend Services gegeben.

Sogar SRTP zu IP-IP-Gateways ist unterstützt, da der IP-IP-GW aus der CCM-Perspektive nur ein H.323-Gateway ist. Insgesamt lassen sich aber damit bedeutend erweiterte Sicherheitsarchitekturen umsetzen, was sowohl für „Flow-Through“-, wie auch für „Flow-Around“-Konfigurationen gilt. SIP-Trunks können seit dem CCM5 auch mit TLS konfiguriert werden. Digest Authentication (RFC 2617) wird unterstützt.

Sicherheit im Zusammenhang mit TFTP

Viele Firmen haben die Policy, TFTP aus Sicherheitsgründen ganz aus den Netzen zu verbannen. TFTP selbst bietet auch keinen ausreichenden Schutz in Bezug auf Identität, Integrität oder Privacy. Da aber TFTP etwa für zentralisierte Telefon-Updates benutzt wird, hat Cisco drei Phasen umgesetzt, um TFTP zu sichern:

In der 1. Phase (CCM 3.3+) wurden Images durch Signaturen gesichert, die in einer Cisco CA wurzeln. Updates werden nur nach erfolgreicher Erkennung der Signaturen durch die „Vorgänger“- Images akzeptiert.

In Phase 2 (CCM 4+) kam zusätzlich die Möglichkeit hinzu, die Daten mit einem Zertifikat zu signieren, das via CTL- File dem TFTP- Server zuzuordnen ist.

In Phase 3 (CCM 5+) kam dazu noch die Möglichkeit, Konfigurationsfiles, die ja auch auf dem TFTP- Server liegen, zu verschlüsseln.

Firewall/NAT Traversal

Firewalls werden an den Netzgrenzen zum Fernhalten von ungewolltem Verkehr, und im Innern zum dynamischen Öffnen von „kleinen Löchern“ genutzt, deren Portbereiche dediziert bekannt sind. Dies wird durch das Überwachen des Signalisierungsverkehrs ermöglicht. Ist die Sprache (besser: der Signalisierungsverkehr für Sprache) nun aber verschlüsselt, kann eine Standard-Firewall dieser Aufgabe nicht mehr gerecht werden. Mit dem CCM 5.1 und Cisco’s PIX/ASA 8.0 ist es nun erstmals trotzdem möglich, in den Verkehr zu „horchen“, indem ein Zertifikat der Firewall in das CTL- File geschrieben wird. Damit wird die Firewall als vertrauenswürdig angesehen und kann als „Man in the Middle“ die TLS-Session zwischen den Telefonen und dem CCM5.1+ terminieren. Gleichzeitig kann man so in großen Netzen Last vom CCM nehmen, da er die Sessions 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 Session Keys über gesicherte CTI-Interfaces im „Packet Capture Mode“ abzugreifen. Auch im Zusammenhang mit Lawful Intercept („Sprachaufzeichnung“) wird dies verwendet.

Unified CallManager 5/6 LDAP-Sicherheit

Unified CallManager-Versionen vor 5.0 hatten ein eingebautes LDAP-Verzeichnis. Mit der Version 5.0 kam eine Methode dazu, LDAP-Verzeichnisse abzufragen, und die User 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-Strings und multiple Suchinstanzen erlauben die dedizierte Extraktion nur der wirklich benötigten Usernamen 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 Usern: „Enduser“ und „Application User“. Der Unterschied besteht darin, dass Application User immer gegen die interne Directory-Datenbank authentifiziert werden, wogegen Enduser auch gegen externe LDAP-Directorys 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 hier auch, was der Authentifikation gegen dieselben Credentials gleichkommt und daher die Administration vereinfacht.