Direct Routing SBC Security

Mit dem Einsatz von Direct Routing muss sich der lokale Administrator auch um die Sicherheit der SBC-Kopplung zu Teams Online Gedanken machen. Microsoft und SBC-Herstellern führen Beispiele für gültige Konfigurationen auf. Aber bei vielen Firmen gibt es eigene Ansichten zur Sicherheit und den Schutzvorkehrungen. Nicht immer lassen sich diese unverändert in Übereinstimmung bringen.

SBC und Internet?

Ein richtig konfigurierter Session Border Controller ist aus meiner Sicht die beste SIP-Firewall, die man sich vorstellen kann und alle mal besser als eine klassische Firewall oder Proxy, selbst wenn diese neben Portfiltern noch "Deep Inspection" und "Application Layer Security" versprechen. Direct Routing nutzt nämlich MTLS und damit ist ein SSL-Aufbrechen sehr aufwändig.

Eine SBC mit einem Bein ins Internet zu stellen ist nun zum Glück keine seltene Konstellation. Im Internet stehen ganz viele SBCs und SIP-Registrare, die einfach erreichbar sind. Ein Portscan auf 5060/5061 liefert sehr viele Geräte. Da ist aber nicht schlimmer als ein Webserver, der auch per TCP, nur eben auf Port 443, erreichbar ist oder ein Mailserver oder SMTP-Relay. Aber für alle Systeme gilt: Sie müssen „sicher“ konfiguriert sein, damit nur legitime, authentifizierte Anwender und Gegenstellen den Service nutzen können. Was ein "Open Relay" für einen SMTP-Server oder ein Webserver mit ungesicherter Web-Shell oder Wordpress-Plug-in ist, ist bei SIP ein SBC, über den Angreifer andere Ziel anrufen können. Da gibt es dann drei Schadszenarien:

  • "Kostenfreies Telefonieren
    Im einfachsten Fall kann jemand auf ihre Kosten "Telefonieren
  • Premium-Telefonieren
    Teurer wird es, wenn der Anrufer ihren SBC missbraucht, um gebühren pflichtige Rufnummern (z.B.: 0900) anwählt und an den Gebühren mitverdient.
  • Anruferverschleierung
    Gefährlich ist auch der Missbrauch, bei dem z.B. Drohanrufe etc. durchgeführt werden und eine Ermittlung dann auf ihren SBC zurückzuführen ist. Selbst wenn Sie alle Anrufe genau protokollieren, können Sie ja maximal die IP-Adresse der initiierenden Station ermitteln. Und die ist nach einigen Wochen nicht wirklich aussagekräftig.

Wer also einen SBC betreibt muss sich um die Absicherung kümmern.

Authentifizierung mit Direct Routing

Einen anonymen Zugang per SIP zu einem SBC sollten Sie gar nicht erst in Betracht ziehen. Auch Microsoft betreibt seine SIP-Gegenstellen direkt im Internet und natürlich gibt es Schutz-Level, um die Verbindungen zu validieren. Für Teams Direct Routing ist es aber erforderlich, dass Sie einen SBC mit Microsoft Teams über das Internet und ohne „Preauthentication“, ohne VPN o.ä. betreiben. Daher kommen anderen Ansätze zum Einsatz:

  • MTLS
    Die SBCs von Microsoft sprechen gar nicht erst SIP/TCP sondern erzwingen SIP/TLS über Port 5061 und erwarten auch eine kompatible Gegenstelle. Ohne öffentlichen DNS-Namen samt Zertifikat, der auf ihren SBC verweist, und die Authentifizierung mit einem Client-Zertifikat (MTLS) geht gar nichts. Auch für ihr Setup sollten Sie die gleiche Vorgabe festlegen, dass sich auch eingehende Verbindungen über das Internet per SIP/TLS verbinden und ihr Zertifikat vorweisen müssen.
    Sie können dann im SBC sehr einfach eine Beschränkung anhand des Namens im Zertifikat durchsetzen und fremde Verbindungen sehr früh abblocken.
  • Source-IP
    Zusätzlich veröffentlicht Microsoft die Liste der IP-Adressen, welche mit dem SBC kommunizieren. Bei Direct Routing ist es nicht gewollt und nicht erforderlich, das beliebige Clients im Internet mit ihrem lokalen SBC kommunizieren. Daher kann eine Firewall auf dem SBC oder vor dem SBC unerwünschte Verbindungen schon komplett abblocken, so dass es gar keines TLS-Handshake mehr bedarf.

Da die SIP-Kommunikation selbst verschlüsselt ist, kann eine Firewall dort nur sehr schwer reinschauen und auch die RTP-Kommunikation ist verschlüsselt.

SBC-Standort und Links

Dennoch gibt es in Firmen immer wieder die Diskussion nach dem richtigen Standort und der sicheren Veröffentlichung. Bei den einen Firmen steht der SBC "intern", da er ja auch an die interne TK-Technik angebunden wird und die internen Teams-Clients spricht. Wenn aber die TK-Anlage schon in einem anderen Segment als die Clients sind, müssen Sie sich überlegen, wie die Signalisierung und insbesondere Audio/Video (UDP) sinnvoll erlaubt werden. Zum Glück unterstützen eigentlich alle SBCs die Nutzung von VLANs und mehrere Schnittstellen, so das es eine ganze Menge von Kombinationen gibt.

Für Mailserver gibt es Relays und für Webzugriffe entsprechende Proxy-Server, die zwischen dem internen Client und dem externen System geschaltet werden, um das Schutzpotential zu heben und Adressen umzusetzen

Das sind aber klar definierte Kommunikationswege zwischen bekannten Endpunkten. Ein SIP-Client oder Teams-Client ist aber mobil im LAN unterwegs und kein statischer Mailserver. Zudem ist das Konzept einer "DMZ" und klassischer Zonen sowieso schon überholt. Man darf eigentlich niemandem mehr trauen (Zero Trust). Dennoch nutze ich hier noch das klassische Modell um ein paar Optionen einer SBC-Platzierung vorzustellen.

Bild

Beschreibung

SBC mit Public IP

Diese Konstellation ist das, was Microsoft wohl am ehesten sich vorstellt. der SBC des Kunden hat ein direktes Interface mit einer öffentlichen IP-Adresse. Das Interface kann dabei direkt auf im externen Subnetz sein oder sie nutzen öffentliche IP-Adressen in der DMZ und die externe Firewall routet einfach die Pakete.

Die vorgeschaltete Firewall kann dann als zweite Instanz z.B. die Port-Range und die Source-IP-Adressen von Office 365 filtern und damit den SBC vor störenden Paketen schützen. Die meisten SBCs haben natürlich auch selbst Paketfilter, um anhand der Quell-IP-Adresse und Ports zu filtern. Allerdings ist für viele Firmen die Kombination beider Funktionen auf einem System nicht tolerierbar.

Öffentliche IP-Adressen in einer DMZ bedeutet natürlich, dass sie nicht nur ein paar IP-Adressen sondern ein kleines Subnetz zur Verfügung haben.

SBC mit NAT

Die zweite Konstellation nutzt die Funktion NAT, um den Zugriff auf die externe IP-Adresse auf eine interne private Adresse umzusetzen. Diese Umsetzung macht dabei meist die externe Firewall, die zuerst die Quell-IP-Adresse und die Ports filtert und dann eingehende Pakete aber auch ausgehende Pakete umschreibt:

  • Eingehend:
    Die Ziel-IP wird auf die private Adresse umgesetzt
    Die Quell-IP bleibt erhalten
  • Ausgehend:
    Die private Quell-IP wird auf die öffentliche IP umgesetzt
    Die öffentliche Ziel-IP wird nicht verändert
  • Ports
    In allen Fällen ist sicherzustellen, dass die verwendeten Port genau 1:1 umgesetzt werden. Die von Direct Rsouting genutzten IP-Ports (5061 und RTPPorts) dürfen nicht von anderen Anwendungen genutzt werden. Aber 80,443,25 u.a. Ports sind frei, d.h. sie könnten ausgewählte Ports der öffentlichen IP-Adresse von Direct Routing durchaus auch zu anderen Systemen eingehende per NAT weiter geben.

Beachten Sie aber, dass Sie nur genau einmal ein "NAT" machen dürfen.

Andere Konstellationen

Natürlich gibt es noch ganz viele andere Konstellationen. So habe ich auch SBCs in einer eigenen "TK-Zone" (sowas wie eine DMZ) gesehen, die auf beiden Seiten von Firewalls eingerahmt waren. Per Firewall wurde der externe Zugriff per NAT bereitgestellt aber auch die internen Systeme mussten durch die innere Firewall erst zugelassen werden. Häufig ist diese Konstellation dann zu finden, wenn der SBC intern keine sichere Authentifizierung verlangt, weil die nachgeschaltete TK-Technik z.B. keine Zertifikate oder sichere Kennwort unterstützt und daher IP-Adressen gefiltert wurden.

Eine andere Lösung wurde als Hintereinanderschaltung von zwei SBCs umgesetzt. Die SIP-Trunks der Carrier und damit deren Subnetze sind in einem "TK-Netzwerkbereich" angekommen und durften nicht direkt mit dem "Datacenter-LAN" verschaltet werden. Der externe SBC wurde vom Carrier verwaltet und der Kunde hatten keinen Zugriff. Daher hat er einen internen SBC noch dazu geschaltet.

NAT: Ja oder Nein?

Wenn der SBC nicht mit einem Bein im Internet steht oder eine öffentliche Adresse in der DMZ bekommt, dann kommt das Thema NAT zum Einsatz. Öffentliche Adressen müssen auf private Adressen umgesetzt werden, wenn der SBC nicht selbst direkt eine öffentliche Adresse hat. Microsoft erlaubt dies, aber schiebt die Verantwortung auf den SBC:

"Eine öffentliche IP-Adresse, die zum Herstellen einer Verbindung mit dem SBC verwendet werden kann. Basierend auf dem SBC-Typ kann der SBC NAT verwenden. "
Quelle: https://docs.microsoft.com/de-de/microsoftteams/direct-routing-plan#media-traffic-port-ranges

Die Besonderheit bei NAT mit Direct Routing ist die Definition der Kandidaten im SDP-Paket. Der SBC muss dazu seine öffentliche Adresse kennen, damit er erst einen dynamischen Port auf seinem privaten externen Interface öffnet und dann die private Adresse durch die öffentliche Adresse ersetzt und im SDP der Gegenseite anbietet. Das ist auch der Grund, warum Es eine 1:1 Zuordnung von Ports auf der öffentlichen Adresse zur privaten Adresse geben muss.

Beachten Sie: NAT ist kein Sicherheitsgewinn und keine Firewall, sondern nur eine Adressumsetzung, die auch "böse Pakete" umsetzt. NAT macht aber die Verwaltung komplizierter, wenn Fehlersuche, Tracing und Logging auch die Adressen umsetzen müssen. Das macht ja gerade IPv6 zukünftig interessant, wenn Sie ohne NAT arbeiten können.

Aktuell unterstützt Direct Routing noch kein IPv6 (Stand Okt 2020)

Sie können also NAT nutzen aber müssen im SBC die Umschreibung des SDP konfigurieren. Am besten orientieren Sie sich an den Beschreibungen der SBC-Hersteller. Exemplarisch zitiere ich hier Ausschnitte von Audiocodes.

Das Bild zeigt, dass Audiocodes den SBC hier intern sieht mit einem Interface zu einer DMZ und das andere Interface zum LAN. Über NAT steht hier aber noch nichts, denn diese Konstellation mit einem Interface in der DMZ erlaubt natürlich den Betrieb mit einer öffentlichen IP-Adresse als auch einer per NAT umgesetzten Adresse.


Quelle: https://www.audiocodes.com/media/13253/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-enterprise-model-configuration-note.pdf

Auf die weitere Konfiguration mit NAT geht Audiocodes nicht explizit ein, aber die Herausforderungen sind ja nicht neu. Ich habe Sie schon zu Skype for Business-Zeiten beschrieben

Weitere Links