Das Session Initiation Protocol (SIP) ist mit einem im Jahr 2002 veröffentlichten RFC noch vergleichsweise jung. Dennoch hat SIP schon große Aufmerksamkeit erregt, weil zahlreiche Applikationen das Protokoll nutzen. Dies betrifft auch bereits bestehende Applikationen, die von anderen Protokollen zu SIP migriert werden, wie beispielsweise VoIP, Instant Messaging oder Video-Konferenzen.
Hinsichtlich des Designs ähnelt SIP den Protokollen SMTP und HTTP. Dadurch ist es robust, skalierbar und kann mit Hard- und Software-Angeboten einer Vielzahl von Herstellern interagieren. Diese Tatsache macht SIP allerdings verwundbar für die Angriffe, die schon von E-Mail- und Webumgebungen bekannt sind. Es ist also zwingend notwendig, die Sicherheit von SIP-Applikationen genauer ins Visier zu nehmen und die Lücken zu schließen.
Im ersten Teil dieser Serie lesen Sie die potenziellen Angriffsvektoren gegen SIP. Dieser zweite Teil dreht sich um die Absicherung von SIP-Systemen mittels herkömmlicher und dedizierter Systeme.
Die Notwendigkeit von SIP-Sicherheit
Wie bei jeder Netzwerkapplikation müssen auch die Benutzer von SIP-Applikationen vor bekannten Schwachstellen geschützt werden. Zwei Aspekte machen hierbei eine gut durchdachte Sicherheitslösung unabdingbar. Der erste bezieht sich auf das Design von SIP und die Art und Weise, wie es sich aus traditionellen Telekommunikationskonzepten heraus entwickelt hat. Der zweite beruht auf der Einhaltung gesetzlicher Regularien auf Grund der über SIP vermittelten Daten.
SIP-Design
Wie schon beschrieben, dient SIP der Verwaltung von Kommunikation. Wenn SIP beispielsweise in einer VoIP-Applikation zum Einsatz kommt, übernimmt es dieselbe Rolle, die das Protokoll SS7 in der traditionellen Telefonie innehat. Das Signalisierungssystem 7 ist eine Architektur, die den Aufbau, die Weiterleitung, die Abrechnung und den Informationsaustausch des öffentlichen, vermittelten Telefonnetzes unterstützt.
Dies entspricht den Funktionen von SIP, der Unterschied liegt allerdings in der Art und Weise, wie sie implementiert sind, und in ihrer Sichtbarkeit. Bei SS7 handelt es sich um ein Protokoll, das über geschlossene Verbindungen zwischen Vermittlungsstellen übertragen wird. Der Benutzer sieht es nicht und kann es nicht beeinflussen. Tatsächlich haben die meisten Benutzer noch nie etwas von SS7 gehört, obwohl sie es täglich nutzen.
SS7 kommt gar nicht am Endgerät des Benutzers an. Somit benötigt ein Angreifer schon detailliertes Wissen, eine spezielle Ausrüstung und physischen Zugriff auf geschützte Teile des Telefonnetzwerks, um SS7 anzugreifen und normale Telefongespräche zu beeinflussen.
SIP dagegen ist auf der Internet-Applikationsebene implementiert, obwohl es eine sehr grundlegende Funktion erfüllt, nämlich den Aufbau von Verbindungen. Zudem erreicht es das Endgerät und wird für gewöhnlich im Klartext übertragen. Somit kann praktisch jeder Benutzer mit einem handelsüblichen Computer das SIP-Protokoll überwachen oder gar stören.
Die Tatsache, dass essenzielle Funktionen wie „der Aufbau, die Weiterleitung, die Abrechnung und der Informationsaustausch“ derart exponiert sind, erzwingt gesonderte Sicherheitsmaßnahmen in allen SIP-Implementationen.
Regularien und SIP-Datenaustausch
Industriezweige, die am stärksten von den technischen und kommerziellen Vorteilen von SIP-Diensten profitieren, gehören zu den Früheinsteigern in die Technologie. Dazu zählen Firmen und Abteilungen mit hohem Telefonaufkommen, wie beispielsweise Finanzinstitute oder Callcenter. Auch Letztere müssen sich mit gesetzlichen Auflagen beschäftigen. So gilt in den USA beispielsweise der „Gramm-Leach-Bliley Act“, der Firmen unter anderem dazu zwingt, bei einem Bruch der Sicherheit jeden potenziell betroffenen Benutzer zu informieren. Allein diese Bestimmung sollte Anreiz genug sein, weit reichende Sicherheitsmaßnahmen zu ergreifen.
Angriffsvektoren
Für gewöhnlich werden SIP-basierte Applikationen als Bestandteil einer ganzen Anwendungsumgebung implementiert und eingeführt, da SIP zunächst die Integration von Sprachkommunikation und E-Mail ermöglicht, und im Folgenden Zusatzdienste wie Instant Messaging. Dazu kommt noch die Option, ortsunabhängig erreichbar zu sein.
Das bedeutet aber auch, dass Angriffe auf SIP-Komponenten nicht zwangsläufig über das SIP-Protokoll erfolgen müssen, der Angriff kann durchaus von einer E-Mail mit schädlichem Inhalt ausgehen. Ebenso ist die Gegenrichtung denkbar, also die Übermittlung von Schadcode via SIP, um E-Mail-Systeme oder andere Netzwerkkomponenten anzugreifen. Der Angriffsvektor und das Ziel des Angriffs müssen also nicht zwangsläufig identisch sein.
Integrierte Messaging-Applikationen, wie beispielsweise der Live Communications Server von Microsoft, ziehen eine Reihe ähnlicher Dienste zusammen, die jedoch über komplett verschiedene Mechanismen zur Auslieferung verfügen. Hier steigt das Risiko von applikationsübergreifenden Angriffen massiv an.
Insgesamt lässt sich feststellen, dass man SIP-Sicherheit nicht isoliert betrachten darf. Jegliche Sicherheitslösung muss in ein Konzept eingebettet sein, das alle Komponenten einer integrierten Messaging-Applikation adressiert.
Konventionelle Sicherheitslösungen
Konventionelle Sicherheitslösungen wie Firewalls oder spezialisierte SIP-Proxies werden derzeit eingesetzt, um die offensichtlichen Sicherheitsprobleme bei SIP anzugehen. Keiner dieser Ansätze bietet jedoch eine übergreifende Lösung. Sie erzielen zwar einen gewissen Grad an grundsätzlicher Sicherheit, bieten aber beispielsweise keinerlei Schutz gegen Spam.
Die Telkos adressieren SIP-Sicherheit mit einer Produktkategorie, die als Session Border Controllers bezeichnet wird. Diese waren originär dazu gedacht, als Gateway zwischen verschiedenen Telkos zu agieren. Die Tatsache, dass sie auch ein gewisses Maß an Kontrolle über SIP-Sessions gewähren, führte dazu, dass sie zunehmend Sicherheitsfunktionen übernehmen sollen. Auf Grund ihrer Telko-Herkunft sind sie allerdings nicht hinsichtlich der Gefahren aus dem Internet optimiert und berücksichtigen andere Internet-Applikationen nicht im Mindesten. Übergreifende Sicherheit können sie also nicht gewährleisten.
Universal-Firewalls
Für eine normale Firewall ist SIP ein schwer zu handhabendes Protokoll, denn es enthält beispielsweise eingebettete IP-Adressen. Da die meisten Firewalls auch gleichzeitig NAT implementieren, benötigen sie ein zusätzliches SIP-Modul, das die eingebetteten IP-Adressen ausliest und übersetzt. Dies erfordert jedoch aus zwei Gründen mehr als nur einen einfachen SIP-Proxy:
1.) Obwohl SIP einen so genannten Well Known Port registriert hat (5060 TCP und UDP), erlaubt die Spezifikation die Benutzung beliebiger Ports. Ein SIP-Server wird zwar höchstwahrscheinlich den registrierten Port benutzen, ein Client kann aber den Port frei wählen, über den er Antworten empfangen will. Dieser Port wird über das Feld VIA im SIP-Header mitgeteilt. Eine Firewall muss also zusätzlich in der Lage sein, den Port auszulesen und per Port Address Translation (PAT) zu übersetzen.
2.) In den meisten Anwendungen ist SIP lediglich für Aufbau und Beendigung des Anrufs zuständig. Ein anderes Protokoll wie beispielsweise RTP übernimmt die Übertragung der eigentlichen Kommunikationsdaten. Es gibt zwar auch für RTP einen Well Known Port, aber RTP-Sitzungen können einen beliebigen Port verwenden. Dies ist auch regelmäßig der Fall. Ports und IP-Adressen werden mittels SDP (Session Description Protocol) im „SIP INVITE“-Header (Aufbau des Anrufs) verhandelt.
Also muss die Firewall neben NAT und PAT für SIP auch noch NAT und PAT für SDP und RTP zur Verfügung stellen. Die meisten Produkte können dies nicht.
SIP- und SDP-Header
INVITE sip: 32374@207.236.65.226:5060 SIP/2.0
Expires: 180
Content-Type: application/sdp
Via SIP/2.0/UDP 207.236.63.221:5060;branch=1FV1xhfvxGJ0K9rWcKdAKOA
Via: SIP/2.0/UDP 10.80.17.138:5060
To:<sip:32374@207.236.65.226>
From: sip:22347@10.80.17.138
Call-ID: c2943000-50405d-6af10a-382e3031@10.80.17.138
CSeq: 100 INVITE
Contact: sip:22347@10.80.17.138:5060
Content-Length:219
User Agent: Cisco IP Phone/Rev.1/SIP enabled
Accept: application/sdp
Record-Route: <sip:32374@207.236.65.226:5060; maddr=207.236.65.226>
v=0
o=CiscoSystemsSIP -IPPhone-UserAgent 17045 11864 IN IP4 10.80.17.138
s=SIP Call
c=IN IP4 10.80.17.138
t=00
m=audio 29118 RTP/Avp 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
SIP-Proxies
Die komplexe Kombination aus den Protokollen SIP, SDP und RTP führte zu einer neuen, spezialisierten Produktkategorie, dem SIP-Proxy. Dieser hat die Aufgabe, die NAT- und PAT-Funktionen bereitzustellen, die das Protokoll benötigt.
Das Design von SIP ist besonders darauf ausgerichtet, die Implementierung von Proxies möglichst einfach zu gestalten. Im entsprechenden RFC ist ein zustandsloser Proxy definiert, der SIP-Daten weiterleitet und dabei die notwendigen NAT- und PAT-Transformationen durchführt - allerdings ohne Informationen über den aktuellen Status der Transaktion mitzuführen.
Ein solcher zustandsloser Proxy hat also keinerlei Informationen über bestehende Kommunikationsverbindungen, er kann SIP-Anfragen nur auf Grund sehr beschränkter Daten validieren. Wenn beispielsweise ein Proxy eine BYE- oder eine CANCEL-Anfrage erhält, die zum Beenden bestehender Verbindungen dient, kann er nicht verifizieren, ob sie tatsächlich von einem der Kommunikationspartner stammt. Seine einzige Möglichkeit ist es, die Anfrage so weiterzuleiten. Unverlangte BYE- oder CANCEL-Anfragen werden in vielen der oben beschriebenen DoS-Angriffe verwendet.
Session Border Controllers
SBCs kommen normalerweise im Zuge des Peerings zwischen den Netzwerken zweier Service Provider zum Einsatz, finden aber auch zwischen dem Zugangsnetzwerk und dem Backbone Verwendung. Sie liefern grundlegende Perimetersicherheit mit Zugangskontrolle, Verschleierung der Topologie, einfachen Schutz vor DoS, NAT-Traversal, Netzwerkmanagement für QoS und in manchen Fällen die Umwandlung von Legacy-Protokollen (H.323, MGCP / Megaco, SIP).
SBCs enthalten einige Sicherheitsfunktionen, verlassen sich für diese Funktionen aber oft auf normale Firewalls. Auch die Kombination von SBC und Firewall bietet nicht die notwendigen Merkmale für eine sichere SIP-Umgebung.
Manche SBCs bieten Authentifizierung für SIP-Befehle, schützen also vor einigen der beschriebenen DoS- und Registrierungsangriffen. Sie agieren jedoch weiterhin primär als Protokoll-Konverter und Zugriffskontrolle für die Netzwerkgrenze. Das heißt, sie konzentrieren sich darauf, den Aufbau der Kommunikation zu kontrollieren, bieten jedoch keinen Schutz gegenüber Angriffen wie Spam oder Malware. Zudem können Sie nur eingeschränkt auf Low-Level-Angriffe aus dem Internet wie ungültige Pakete oder Flooding reagieren.
Aufgaben einer SIP-Sicherheitslösung
Eine umfassende Sicherheitslösung für SIP muss eine Reihe von Aufgaben übernehmen. Um sie von normalen SIP-Proxies abzugrenzen, verwendet Borderware den Begriff „SIP Edge Proxy“. Ein solcher Edge Proxy ist ein am Perimeter installiertes Gerät, das die komplette Bandbreite möglicher Angriffe abdecken soll. Zudem liefert der Edge Proxy NAT und PAT für SIP und die dazugehörigen Protokolle wie beispielsweise RTP.
SIPassure von Borderware, die kommerzielle Implementation eines Edge Proxy, basiert auf einem gehärteten Firewall-Betriebssystem, das die SIP-Applikationen vor Angriffen auf der Netzwerkebene und vor Versuchen schützt, ungeprüfte Puffer mit einem Buffer Overflow auszunutzen. Gegen spezifische Angriffe auf die Applikation sollen folgende Funktionen helfen:
SIP-Nachrichtenvalidierung
Der Edge Proxy muss alle SIP-Nachrichten validieren. Dazu gehört auch, dass alle benötigten Felder vorhanden, richtig formatiert und vor allem nicht zu lang sind.
SIP-Authentifizierung
Der Edge Proxy bietet einen Authentifizierungs-Service, der gegebenenfalls erzwingt, dass sich Clients anmelden, bevor sie die Funktionen SIP REGISTER oder SIP INVITE benutzen dürfen. Bei Clients in einem vertrauenswürdigen Netzwerk reicht die einfache Anmeldung mit Benutzernamen und Passwort, von außerhalb sollten robustere Anmeldeverfahren zum Einsatz kommen.
SIP Session Table
Viele SIP-Systeme halten keine Statusinformationen über Clients und Anrufe vor, da es wie bereits beschrieben im Protokoll nicht zwingend vorgeschrieben ist. Ein Edge Proxy dagegen führt eine Tabelle aller SIP Sessions, insbesondere über REGISTER- und INVITE-Anfragen. Über diese Tabelle kann er später eingehende Anfragen validieren und somit eine Reihe der Lücken von SIP vermeiden.
Die Tabelle muss groß genug sein, um alle aktiven Sitzungen mitverfolgen zu können und effiziente Nachschlagemechanismen bieten, um eine ausreichend hohe Anrufrate verarbeiten zu können.
SIP-Nachrichtenüberprüfung
Der Edge Proxy überprüft eingehende SIP-Nachrichten anhand der Session Table, wenn dies notwendig ist. Dies stellt beispielsweise sicher, dass ein SIP CANCEL nur von einem Teilnehmer einer Nachrichtensitzung stammt. Damit wird verhindert, dass ein unautorisiertes CANCEL eine bestehende Session unterbricht. Folgende SIP-Nachrichten sind zu überprüfen:
SIP-Nachricht | Grund |
CANCEL | Verhindert unautorisiertes Beenden eines Verbindungsaufbaus. |
REFER | Verhindert unautorisiertes Umleiten einer Verbindung. |
BYE | Verhindert unautorisiertes Beenden einer Verbindung. |
Positiv- und Negativlisten
Mittels Positiv- und Negativlisten kontrolliert der Edge Proxy, aus welchen Adressbereichen SIP-Nachrichten eingehen dürfen oder nicht. Dabei gibt es statische und dynamische Einträge. Erstere blockieren oder öffnen einen Bereich auf Dauer, Letztere lassen sich dynamisch für einen gewissen Zeitraum schalten. Dies kann beispielsweise von einem Spam-Filter geschehen, der eine IP-Adresse für eine gewisse Zeit sperrt, wenn von dort Spam eingeht.
Spam-Kontrolle
Da eine inhaltliche Analyse bei VoIP nicht realisierbar ist, kann ein Spam-Filter sich nur auf Faktoren wie die Anzahl eingehender Verbindungen pro Zeiteinheit verlassen. Versucht eine Domain oder eine IP-Adresse, zu viele Verbindungen aufzubauen, gibt es einen Eintrag in der temporären Negativliste. Damit werden auch Angriffe wie Harvesting und DoS verhindert.
Beschränkung der Anrufe
Um wichtige Anrufe wie beispielsweise einen Notruf absetzen zu können, muss genügend Bandbreite vorhanden sein. Der Edge Proxy sollte also in der Lage sein, bestehende Verbindungen zu terminieren, um genügend Bandbreite freizuschaufeln.
Gesamtkonzept
Und zu guter Letzt muss sich ein SIP Edge Proxy gegebenenfalls in ein übergreifendes Sicherheitskonzept integrieren, das alle Nachrichtenapplikationen wie beispielsweise E-Mail und Browser-basierte Anwendungen wie Web und FTP genauso adressiert wie SIP-basierten Nachrichtenaustausch.
Fazit und Ausblick
Mit SIP erhält VoIP neuen Auftrieb und eine bisher ungeahnte Akzeptanz. Dazu kommt noch die Integration von zusätzlichen Messaging-Fähigkeiten wie Chat oder Video-Konferenz. Damit dieses Messaging-Framework aber dieselbe Vertrauenswürdigkeit und Stabilität erhält wie die gute alte Telefonie, muss der Administrator eine Reihe von Sicherheitsrisiken beachten und ausschalten. Er ist dabei sogar gezwungen, Faktoren zu berücksichtigen, die bis dato von der Telefongesellschaft für ihn abgehandelt wurden.
Ist die sichere Kommunikationsumgebung allerdings erst einmal geschaffen, bietet sie der Firma Möglichkeiten, die bisher nur schwer oder unter hohem Kostenaufwand zu realisieren waren. So zum Beispiel die ständige Erreichbarkeit unter einer Telefonnummer, egal wo man sich auf der Welt gerade aufhält, oder gemischte Umgebungen mit Video, Voice, Chat und Whiteboarding. (mha)
Dieser Artikel basiert auf einem Whitepaper von Peter Cox, Vice President Product Management bei Borderware. Borderware ist Hersteller von Messaging-Security-Lösungen, darunter auch SIPassure, einem SIP Edge Proxy.