VoIP Sicherheit

Wer einen Dienst anbietet, muss sich natürlich auch Gedanken über die Sicherheit und Absicherung machen. Schließlich werden dabei zum einen schützenswerte Daten übertragen und zweitens fallen natürlich auch Betriebsdaten an, die geschützt werden müssen.

Schützenswerte Daten

Hier mal eine Auswahl:

Thema Beschreibung Lync / Skype für Business

Abhörsicherheit

Beim Einsatz von VoIP ist das natürlich immer der erste Ansatz, der in den Fokus einer Sicherheitsbetrachtung fällt: Wie sicher ist die Technik gegen "abhören" ?.

In diese Fragestellung fällt sowohl die Netzwerksicherheit, d.h. z.: die Abschottung der Übertragungswege mit VLAN und 802.1x aber natürlich die die Wahl der Protokolle bei der Signalisierung und Nutzdatenübertragung.

Per Default werden alle Signalisierungsdaten (SIP) per TLS verschlüsselt. Es musst schon manuell dieser Verschlüsselungszwang abgeschaltet werden.

Auch die Audio/Video-Daten werden per Default per SRTP verschlüsselt. Es gibt aber Teilstrecken außerhalb, die eventuell nicht verschlüsselt sind, z.B. ein SIP-Trunk zu einem Carrier oder TK-Anlage.

Gespeicherte Inhalte

Sobald ExchangeUM ins Spiel kommt, können Anrufer natürlich auch Nachrichten im Exchange Postfach hinterlassen oder ihre Nachrichten per Sprache abrufen.

Auch hier stellt sich dann die Frage, wie sicher zum, einen der Anlageort und welche Vorkehrungen gegen unerlaubten Zugriff getroffen wurden. Bei Exchange und OCS ist eine Anmeldung am Client erforderlich, die dann zum Exchange weiter gegeben wird oder die Eingabe einer PIN. Über die "Sicherheit" der EDB-Anlage gibt es schon entsprechende Analysen.

Bei TK-Anlagen ist hier auch zum einen der Ablageplatz (teilweise ungesicherte MP3-Dateien auf Festplatten ) und der Zugriff (Teilweise vom eigenen Telefon ohne weitere PIN) zu betrachten. Eine "Putzkraft" im Büro könnte also unter umständen die Sprachnachrichten abhören.

Die Verbindung zu Exchange UM ist natürlich ebenfalls per Default sowohl per SIP/TLS als auch SRTP verschlüsselt. Das müsste ein Administrator schon abschalten.

Die Mails im Postfach selbst nicht normal nicht verschlüsselt. Sie könnten aber z.B. über eine Transportregel auch RMS-geschützt werden.

Bewegungsdaten

Was für die TK-Anlage der "Einzelverbindungsnachweis" ist, ist in OCS z.B. die Monitoring-Rolle und in Exchange das Messagetracking. Auch diese Daten müssen gegen fremde Einsichtnahme oder unerlaubte Auswertungen gesichert sein.

Lync und Skype für Business können solche Daten in der CDR/QoS-Datenbank speichern, auf die je nach Konfiguration nur wenige Personen Zugrif haben.

SYSLOG-Meldungen von Gateways werden allerdings meist unverschlüsselt gesendet.

Hier ist es also besonders wichtig den Kreis der Personen mit Zugriff einzuschränken.

Authentifizierung und Authorisierung

Wenn Daten nur für autorisierte Benutzer zugänglich sein sollen, dann kommt die Frage der Authentifizierung selbst in den Fokus. Bei Windows ist es recht einfach über Gruppenrichtlinien und Lockout-Policies die Benutzer anzuhalten, ausreichend komplexe und regelmäßig zu ändernde Kennworte zu vergeben. Zudem werden Fehlversuche protokolliert und ein Konto notfalls auch ausgesperrt.

Solche ausgefeilten Verfahren suchen Sie bei klassischen Telefonanlagen meist vergeblich. Zumal es ja oft gar nicht gewünscht ist, dass die Benutzer viele Konten immer wieder ändern müssen. Der "SingleSignOn"-Ansatz eines Active Directory bietet hier schon immense Vorteile gegenüber autarken Systemen.

Besonders bei Telefonkonferenzen ist das ein Problem, wenn es keine personalisierten "Zugänge" gibt und allein die Nummer des Konferenzraums in Verbindung mit einer "Konferenz-ID" schon den Zugang erlaubt. Einige Systeme erlauben eine "Lobby", d.h. dass jemand nicht direkt in den Konferenzraum zugeschaltet wird.

Bei Lync und Skype für Business geht fast nicht ohne vorherige Anmeldung. Das erfolgt per sicherer Authentifizierung (SIP/TLS und sicheres Anmeldeverfahren) und später per Client-Zertifikat.

Ohne Anmeldung kommen eigentlich nur Konferenzteilnehmer über den Meeting-Link in den Genuss von Diensten. hier gibt es aber die Lobby.

Identifizierung

Sie können alle die Funktion, dass ein Anrufer gleich mit Nummer oder Name angezeigt wird und auch bei einer Mail der Absender direkt ersichtlich ist. Doch wie vertrauenswürdig sind diese Angaben und können diese Angaben absichtlich (Rufnummernunterdrückung oder Anzeige einer Gruppennummer statt der Durchwahl) oder sogar böswillig (Vortäuschen einer anderen Person) geändert werden ?.

Gerade im Telefonie-Sektor ist es mit "ClipNoScreening" möglich, auch komplett falsche Nummern zu senden. Interessant wird dies z.B. bei der Anzeige der Teilnehmer in einer Telefonkonferenz.

Bei der Signalisierung werden die Namen von internen Anrufern gemeldet. Externe Anrufer übermitteln eine Rufnummer, die angezeigt und ggfls. gegen das lokale Adressbuch aufgelöst werden.

DoS und andere Angriffe

Selbst wenn alle Daten gesichert und geschützt sind, so ist z.B. genau die Authentifizierung auch eine mögliche Schwäche. Ein Angreifer könnte versuchen, einen Zugang zu "erraten" und indirekt damit ein Konto zu sperren. für den rechtmäßigen Anwender natürlich störend. Besonders wenn der Zugang auch "aus dem Internet" möglich ist ist dies zumindest ein mögliches Störszenario.

Jedes System kann irgendwie immer überlastet werden und wenn es nur die Überlastung der Leitung durch Anfragen ist.

Missbrauchsschutz

Viele Dienste nutzen die Rufnummer des Anrufers, um benutzerorientiert Dienste anzubieten. So "erkennt" Exchange UM, wenn ein an OCS authentifizierter Anwender seine Mailbox anruft und erlaubt den Zugriff ohne weitere Authentifizierung, Der Anrufer ist aber z.B. auch für die Abrechnung von Diensten relevant. Insofern muss auch hier es zumindest erschwert sein, hier Missbrauch zu begehen.

Bislang sind hier keine Schwächen bekannt.

OCS hat hier schon systembedingt viele Risiken reduziert, z.B. indem per Default die SIP-Signalisierung als auch die Datenübertragung verschlüsselt ist und mit dem Active Directory als Plattform eine robuste und sichere Infrastruktur genutzt wird. Allerdings muss eine Firma eben diese Systeme professionell verwalten. Kennwortrichtlinien, Protokollierung und Überwachung sind genauso wichtige Komponenten wie ein sauberes Administrationsmodell, dass die Verwaltung klar geregelt ist.

Eine abschließende Beurteilung kann diese Seite natürlich nicht sein. Aber vielleicht haben Sie einige Ideen und Ansätze mitgenommen, die bei der Betrachtung einer VoIP oder sogar OCS-Umgebung zu berücksichtigen sind, um ein sicheres und zuverlässiges System zu installieren und zu betreiben. Sicherheit ist aber ein immer vorwährender Prozess und keine einmalige Sache.

SIP Signalisierung

Die Signalisierung von Verbindungen erfolgt bei VoIP über SIP. SIP kann sowohl das Transportprotokoll UDP, TCP oder TLS nutzen. Skype vor Business nutzt eigentlich immer TLS. Nur auf dem Weg zu Gateways oder bei SIP-Trunks wird manchmal auf TCP gebaut. Das ist dann aber kein Problem von Skype for Business oder Lync, sondern eher von der Gegenstelle, die vielleicht kein TLS kann. Oder des Betreibers, der sich mit Zertifikaten eben nicht gut genug auskennt. Jedes von Microsoft zertifizierte Gateway, jeder Session Border Controller oder SIP-Trunk muss auch TLS unterstützen, um von Microsoft für Skype for Business zertifiziert zu sein.

Auch die Clients nutzen SIP/TLS oder mittlerweile auch HTTPS über die UCWA-Schnittstelle und WebServices. An der Stelle ist es für einen "Lauscher auf der Leitung" nicht möglich, die Daten abzugreifen, es sei denn er hat ein Zertifikat auf den Namen, den der Client anspricht und von einer RootCA kommt, der der Client vertraut. Das ist durchaus denkbar. Häufig ist das sogar die Regel wenn Firmen intern Firewalls einsetzen, dass diese Zertifikate für eine SSL-Verbindung ausstellen. Solange es zum "Firmen-Computer" handelt, ist es kein Problem auch dort eine eigene RootCA einzubinden. Allerdings fällt dies dann auf, wenn der Client ebenfalls ein Client-Zertifikat zur Anmeldung verwendet, wie Skype for Business dies macht. Die Verschlüsselung auf dem Transportweg dürfte also nur schwer zu knacken sein.

Was anderes sind natürlich die Relay-Stationen, die bei der Übertragung eines SIP-Pakets vom Sender zum Ziel passiert werden. Ähnlich wie bei SMTP werden die SIP-Meldungen nicht direkt vom Sender an den Empfänger zugesellt, sondern gehen über SIP-Proxies und SIP Registrare. Hier liegen die Daten dann wieder unverschlüsselt auf dem Server vor. Schließlich muss der SIP-Service die Daten ja interpretieren und zum nächsten Hop weiter leiten. Technisch kann also ein Provider sehr wohl in die SIP-Informationen rein schauen.

Über SIP werden auch die "Instant Messages" übertragen. Diese Informationen könnte ein Provider, der ihre SIP-Pakete weiter leitet, natürlich auch ausleiten. In Skype for Business gibt es sogar extra eine "Archiv-Rolle", mit der eben diese Kommunikationen erfasst und für Compliance-Zwecke auch gespeichert werden können.

Audio, Video u.a. über RTP

Über das SIP-Protokoll findet aber nur die Signalisierung statt. Die Nutzdaten wie Audio, Video aber auch Desktop-Sharing oder Dateitransfer werden unabhängig von SIP übertragen. Dazu bauen die Endpunkte eine Verbindung untereinander auf, die entweder direkt (in einem gerouteten Netzwerk mit erreichbaren IP-Adressen) über NAT oder einen TURN-Server auf. Diese direkt oder indirekte Verbindung nutzt in der Regel UDP für Audio/Video und "Video based Screen Sharing" TCP für RPT und Dateitransfers. Diese Daten sind natürlich auch ein begehrtes Ziel um z.B. zu sehen, welche Daten auf einem Bildschirm erscheinen oder welche Tastatureingaben, insbesondere Kennworte, eingegeben werden. Aber auch die "Tonspur" eines Gesprächs ist durchaus interessant.

Auch hier geht Skype for Business aber mit gutem Beispiel voran und nutzt als Default-Einstellung ein "Encryption Required". Alle Endpunkte in Skype for Business nutzen SRTP, d.h. verschlüsseln die Nutzdaten, die per RTP übertragen werden. Diese Einstellung kann natürlich gelockert werden auf ein "Encryption preferred" oder "unencrypted". Früher war dies in Verbindung mit bestimmte 3rd Party Systemen sogar erforderlich, damit diese mit Skype for Business, Lync oder sogar OCS-Clients kommunizieren können. Heute sollte es kein Problem mehr sein, auch die RTP-Daten zu verschlüsseln.

Das Schlüsselmaterial hierzu sind aber einmalig erstellte Schlüssel, die über die SIP-Verbindung bei der Signalisierung des Rufs mit übertragen werden. Insofern macht SRTP nur sinn, wenn sie auch SIP/TLS einsetzen, da ohne SIP-Verschlüsselung ein Angreifer auf der Leitung natürlich auch die Schlüssel mitlesen kann. In einem SIP-INVITE finden sie z.B. Zeilen wie diese:

a=candidate:5 1 TCP-ACT 1684797439 192.168.102.45 23927 typ srflx raddr 192.168.102.45 rport 23927 
a=candidate:5 2 TCP-ACT 1684796926 192.168.102.45 23927 typ srflx raddr 192.168.102.45 rport 23927 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:11whvvvh+zKVGWEhzgewWzeT0jiEgNaKYUKXM+9w|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:11whvvvh+zKVGWEhzgewWzeT0jiEgNaKYUKXM+9w|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:11whvvvh+zKVGWEhzgewWzeT0jiEgNaKYUKXM+9w|2^31a=maxptime:200a=rtcp:246

Das ist das Schlüsselmaterial für die Medien-Verschlüsselung.

Sonderfall TURN-Server

Ein Lauscher auf der Leitung kann die Kommunikation in der Regel daher nicht belauschen, wenn er nicht auf dem Client schon Vorkehrungen trifft, um z.B. die Verschlüsselung zu verhindern oder die Schlüssel abfischen kann. Anders sieht dies aber bei der Nutzung eines TURN-Servers aus, der in der Regel vom gleichen Provider gestellt wird, der ihnen auch den SIP-Service bereit stellt. Zwar sind auch bei der Nutzung eines TURN-Servers die RTP-Streams verschlüsselt und der TURN-Server ändert auch keine Verschlüsselung. Aber der Provider hat natürlich die SIP-Signalisierung ebenfalls "gesehen".

Er könnte also zu einer neuern Verbindung zum einen die Verschlüsselungsdaten abgreifen und zudem noch die Kandidaten (Candidates) im SDP - Session Description Protocol so verändern, dass eine direkte Verbindung gar nicht erst versucht wird. Er kann die Clients dazu zwingen, den TURN-Server zu nutzen und dann steht er als "Vermittler" zwischen den Clients, leitet deren Media-Streams weiter und hat dank der SIP-Information auch die Daten um die Verbindung abzuhören.

Der Anwender merkt davon eigentlich nur dann etwas, wenn der TURN-Server netzwerktechnisch an einer ungünstigen Stelle steht und damit die Laufzeit der Pakete verlängert wird. Die Sprachqualität kann schlechter werden, wenn vermehrt Pakete verloren gehen und natürlich verzögert sich die Sprache. Das wird dann eher auffallen, wenn beide Clients im gleichen LAN sind und durch den Umweg über den Edge und einer vielleicht belasteten Internet-Leitung dies signifikant ist.

Allerdings könnte genau dieser Sonderfall in einigen Umgebungen sogar zum Regelfall werden. So hat Microsoft vor einiger zeit sogar die Empfehlung gegeben, dass Clients doch besser über den TURN-Server im MGN - Microsoft Global Network gehen, da speziell bei Verbindungen über Kontinente hinweg es besser sei, wenn die Clients lokal den Übergang ins MGN nutzen und die Daten dort intern über das QoS-taugliche Microsoft WAN geroutet werden anstatt über das "öffentliche Internet".

Sonderfall Konferenzen

Auch beim Betrieb von Konferenzen gehen alle Media-Daten über die MCU des Servers und der muss die individuellen Streams natürlich entschlüsseln und an die anderen Teilnehmer weiter geben. Auch hier liegen also Audio, Video und andere RTP-Streams unverschlüsselt auf dem Server vor und könnten ausgeleitet werden.

Diese Funktion wird sogar aktiv z.B.: von verschiedenen Call-Center-Apps genutzt, die alle Gespräche als Konferenz über eine MCU leiten und so auch einen Supervisor "aufschalten" können oder eben Voice Recording erlauben.

Weitere Links