Kommmentar: Sicherheit mittels SBC
Gründe für einen eigenen Session-Border-Controller
Die Verwirrung um das Session-Initiation-Protocol,kurz SIP, wird noch größer, wenn es um die Session-Border-Controller (SBC) geht. Die meisten Telefoner wissen, dass ein SBC ein Teil einer SIP-Lösung ist, aber sie sind sich nicht sicher, warum genau man diese Komponente benötigt.
Das Session Initiation Protocol (SIP) ist bereits seit dem Jahr 2000 verfügbar, aber noch immer gibt es Verwirrung darüber, was genau die Aufgabe dieses Protokolls ist und welche Funktionen es erbringt. Die meisten Telefoner haben jedoch verstanden, dass SIP die Telefonie grundlegend verändert und neben der Sprache auch Video übermitteln kann. In vielen Fällen ist das Verständnis des SIP-Protokolls jedoch sehr lückenhaft.
Leider verfügen viele Telefonie-Verantwortliche nur über ein rudimentäres Verständnis von einem SBC und sind immer wieder darüber verwirrt, wo genau man einen SBC im Netzwerk platziert. Gehört der SBC an den Netzwerkrand oder wird dieses Gerät innerhalb der DMZ installiert? In welcher Beziehung steht ein SBC zu den vorhandenen Daten-Firewalls im Unternehmen? Kann man zwei SBCs zwischen unsere geographisch getrennten Rechenzentren einfügen? Auch auf die Frage: "Mein SIP Provider hat in seinem Netzwerk bereits einen SBC installiert, benötige ich trotzdem einen eigenen SBC?“, gibt es keine einfachen Antworten. Im Prinzip ist die Antwort auf diese Frage, ein schlichtes "Ja!", aber die Details dieser Antwort sind in der Realität wesentlich komplizierter.
Ein simpler Vergleich: Ich lebe in einem sicheren Teil meiner Kleinstadt. Muss ich trotzdem meine Haustüre abschließen? Mein Internet-Zugang in meinem Home-Office wird von der Telekom bereitgestellt. Ich bin überzeugt, dass mein Provider mit einer Firewall meine Verbindung absichert. Diese Tatsache bedeutet jedoch nicht, dass mein WLAN-Router und die darüber erreichbaren PCs keine eigenen Firewalls benötigen. Die Firewall ist so konzipiert, dass das Telekom-Netzwerk vor allem Übel aus meinem Netzwerk geschützt wird. Es gehört nicht zu den Aufgaben der Telekom-Firewall, mich (oder mein Netzwerk) vor allem Bösen des Internets zu schützen. Dieser Schutz obliegt meiner Verantwortung.
Das gleiche gilt für einen Session-Border-Controller. Ein SIP-Carrier wird immer sein VoIP-Netzwerk mit Hilfe eines (oder mehrerer) SBCs schützen. In meinem Unternehmen bin ich persönlich für die Sicherheit und die Kontrolle meiner Ressourcen zuständig. Aus diesem Grund bin ich nicht bereit, darauf zu vertrauen, dass jemand anderes mich (und meine VoIP-Ressourcen) umfassend beschützen kann. Aus diesem Grund ist meine Aufgabe, mein Unternehmen mit einer zusätzlichen VoIP- Verteidigungslinie (in Form eines SBC) auszurüsten, diesen entsprechend meiner Sicherheitsregeln zu konfigurieren und zu verwalten.
SIP-Firewall
In seinem Kern ist ein SBC eine Art von SIP-Firewall. Ein SBC führt eine Deep-Packet-Inspection durch und stellt sicher, dass nur ordnungsgemäße SIP-Nachrichten in das Netzwerk des betreffenden Unternehmens gelangen. Ein SBC „kennt“ auch die bekannten "SIP-Viren" (beispielsweise Vicious-SIP) und verhindert, dass diese Schaden anrichten können. Auch verhindert diese Komponente Denial-of-Service- (DoS-) und Distributed-Denial-of-Service- (DDoS-)Attacken. Man kann auch Positiv- beziehungsweise Negativlisten von IP-Adressen beispielsweise von bekannten Angreifern anlegen. Dabei werden fehlgeschlagene Anmeldeversuche registriert und anschließend der potenzielle Hacker blockiert. Dies verhindert das Überfluten des Call-Servers mit Registrierungsnachrichten.
Call-Admission-Control (CAC)
Da nur der Netzadministrator die verfügbare Bandbreite im Netzwerk kennt, macht es Sinn, dass der Unternehmens-SBC die Aufgabe der Anrufsteuerung beziehungsweise der Durchleitung der parallelen Anrufe vornimmt. Natürlich muss diese Aufgabe auf alle Formen der Kommunikation erweitern werden. Dabei ist zu beachten, dass ein Videoanruf erheblich größere Bandbreiten benötigt als eine normale Sprachverbindung. Ein SBC stellt sicher, dass die Qualität der Verbindung unabhängig von der gewählten Form der Kommunikation erhalten bleibt.
Network-Address-Translation (NAT)
Vor langer Zeit gingen der Welt bereits die verfügbaren IPv4-Adressen aus. Aus diesem Grund verwendet fast jedes Unternehmen eine große Anzahl von privaten IP-Adressen, die auf eine oder mehrere öffentliche IP-Adressen übersetzt werden. Da die IP-Adressen innerhalb von SIP-Nachrichten eingebettet werden, müssen die privaten und öffentlichen IP-Adressen angepasst werden. Hierzu stellt der SBC den Unternehmen die Network-Address-Translation- (NAT-)Funktion bereit. Ohne ein funktionierendes NAT-Element ist eine SIP-Kommunikation außerhalb der Grenzen des eigenen Netzwerks nicht möglich.
Protokollanpassung
Ich beschäftige mich mit den Problemen mittlerer und großer Unternehmen auf einer täglichen Basis und nicht selten verhindert ein Sammelsurium an SIP-Inkompatibilitäten der unterschiedlichen Kommunikationssysteme, Software-Versionen und Anwendungen die problemlose Kommunikation. Leider werden von vielen Produkten (auch von namhaften Herstellern) die SIP-Normen nicht eingehalten oder die Hersteller nutzen ihre interpretatorische Freiheit zu Integration einer SIP-Variante.
Mit Hilfe von den in den SBCs implementierten Werkzeugen lassen sich die unterschiedlichen SIP-Nachrichtenformen anpassen und somit die verschiedenen Anbieter und Produkte aneinander anpassen.
Medienanpassung
Wenn wir in einem Contact-Center anrufen hören wir meist die Worte: "Dieser Anruf wird zu Qualitätszwecken aufgezeichnet....." In der klassischen TDM-Welt wurde mit spezieller Hardware der Sprachstrom gesplittet und an den eigentlichen Empfänger und das Aufzeichnungsgerät übermittelt. Bei einigen SBCs lässt sich diese Funktion per Software realisieren und Mitschnitte von Sprachströmen lassen sich kostengünstig und schnell umsetzen.
Transcoding und Translation
Das Transcoding und die Übersetzung wird erforderlich, wenn zwei verschiedene Kommunikationselemente miteinander interagieren müssen, aber nicht über eine gemeinsame Basis (Standards) verfügen. Beispielsweise kann die H.323-Signalisierung in die SIP-Funktionen übersetzt werden. Möglicherweise müssen auch die Codecs „transcodiert“ werden, wenn beispielsweise die G.711- in G.729-Sprachströme gewandelt werden. Zu den anderen Transcoding/Übersetzungsmöglichkeiten eines SBCs gehören: IPV6 <-> IPv4, SRTP <-> RTP und TLS <-> in unverschlüsseltes SIP.
- Gründe für einen eigenen Session-Border-Controller
- Echtzeitströme und Routing
Lesen Sie mehr zum Thema
