VoIP PortRange

Auf dieser Seite möchte ich mal eine Lanze für VoIP und die verwendeten Ports brechen. Denn allzu oft sind natürlich die großen Portbereiche ein Thema bei der Diskussion mit Firewall Administratoren. Natürlich könnte ich mich auf den Standpunkt stellen, dass das eben so sei und wenn die Ports nicht freigeschaltet werden, dann geht das Produkt nicht. Diese Eskalation muss ich aber gar nicht fahren, wenn ich stattdessen erläutere, wie jedes VoIP-System funktioniert und warum es gerade gut ist, dass eine Portrange genutzt wird.

So arbeitet VoIP

Wenn zwei VoIP-Endpunkte miteinander kommunizieren wollen, dann passiert das auf klar definierten Wegen. Die meisten Administratoren oder Firewall-Verwalter glauben das auch zu wissen aber vielleicht haben Sie nicht alle Informationen immer präsent. Das ist in Ordnung. Ich kenne die Details aber bin dafür nicht immer auf dem letzten Stand was Firewalls und Inspection betrifft.

SIP ist das darunterliegenden Signalisierungsprotokoll, über welches die Clients mit dem Registrar sprechen, an dem Sie sich anmelden. Intern kommt hier Port 5060/5061 TCP zum Einsatz. Lync und Skype for Business nutzen dazu per Default 5061 und da dieser Port aus dem Internet von Providern gerne geblockt wird, ist 443/TLS der Fallback. Diese Ports und Protokolle sind gut bekannt Die Datenmenge für Signalisierung ist bekannt und auch vom Timing her toleranter.

Interessanter bei SIP sind aber die Dienste "Sprache/Video", denn hier geht es um Millisekunden und ein Grundprinzip ist hier möglich kurze Wege zu habe. Daher versuchen die beiden Endpunkte zuerst eine direkte Verbindung zu etablieren. So eine Peer 2 Peer-Verbindung ist aber in normalen Netzwerken aber erst einmal untypisch. Üblicherweise greifen die Clients ja auf bekannte zentrale Services zu. Eine direkte Verbindung funktioniert natürlich nur, wenn beide Endpunkte in einem gerouteten Netzwerk sind. Sobald Firewalls oder NAT-Grenzen eine direkte Verbindung verhindern, kommen STUN und TURN zum Einsatz, um einen alternativen Weg zu ermitteln. Im Extremfall verbinden sich die Client mit einem TURN-Server, der als Media Relay agiert. So ein Relay bedient natürlich mehrere Endgeräte parallel und schon wird klar, warum dieses System eine etwas größere Anzahl an Ports nutzen möchte.

Portranges

Für Audio kommen in der Regel folgende Ports zum Einsatz. Wobei für Audio/Video natürlich UDP als Protokoll einer Verbindung über TCP vorgezogen wird. TCP ist "aufwändiger" und es lohnt sich nicht, ein verlorenes Sprachpaket im noch mal zu übertragen. Wenn aber UDP nicht geht, dann wird TCP genutzt.

Name Protokoll Range Beschreibung

Client P2P AV

UDP

min 20 Port per GPO konfigurierbar

Normalerweise nutzt ein Client zu 20 Ports je Funktion (Audio, Video, Collaboration). Die Port sind per Gruppenrichtline steuerbar.


Quelle: https://technet.microsoft.com/en-us/library/gg398833.aspx 

Client P2P AV

TCP

min 20 Port per GPO konfigurierbar

Edge AV

UDP

50.000-59990

Der Edge Server agiert als Media Relay und benutzt dabei natürlich deutlich mehr Ports. Per Default werden hier 10.000 Port im Bereich 50.000-59.999 genutzt, wenn diese in der Firewall freigegeben sind.


Quelle: https://technet.microsoft.com/en-us/library/jj204756.aspx 

Edge AV

TCP

50.000-59990

Edge TURN

UDP 3478

3478

Über 3478/UDP werden Pakete mitteln TURN übertragen. Ein Client kann sich über den Port beim Edge-Server öffentliche Kandidaten anfordern und alle Pakete an diese Kandidaten werden dann über die etablierte UDP-Verbindung zum Client geleitet und vom Client an den Server gesendet. Ein Client, der die TURN-Services des Edge-Servers nutzt, kommuniziert also über Port 3478 mit dem Edge, damit der Edge über seine High-Ports mit anderen Gegenstellen kommunizieren kann.

Der Edge kann aber auch selbst über 3478 mit anderen Gegenstelle kontakt aufnehmen

Edge TURN

TCP443

445

Als letzter Fallback kann ein Edge Server auch über 443/TLS erreicht werden. Ein Client kann also (fast) so tun, als könnte er den Edge-Server per HTTPS erreichen. Leider ist das aber nicht wirklich HTTP über TLS sondern eher eine TURN over TLS-Verbindung. Wenn als ein Proxy etwas genauer in die Verschlüsselung reinschaut, dann kann er den TLS-Handshake erkennen aber wird sehen, dass darin nicht zwingend HTTP gesprochen wird.

Die sind nur die wichtigen Ports für Media-Traffic. Natürlich sind noch weitere Ports z.B. für die Signalisierung (SIP 5061/TLS oder SIP/443) erforderlich und ein Skype for Business Client nutzt natürlich auch noch Webservices (443/HTTPS) für LyncDiscover, GroupExpansion, Zertifikat, Exchange EWS und einiges mehr. Ich lege auf dieser Seite aber den Schwerpunkt auf die "Ranges", die immer zur Diskussion führen. Interessanterweise sind die meisten Firewall Administratoren sehr unkritisch was den Port 443 betrifft, während Sie bei 3478 schon mal genauer nachfragen und die Range von 50.000-59.999 eigentlich immer stark hinterfragt wird 

Ports, Security und Skalierbarkeit

Es ist das gute Recht und sogar ihre Pflicht genau nachzufragen, wenn der Wunsch nach einer Öffnung von Ports an das Firewall-Team herangetragen wird. Und ich sehe es durchaus auch als meine Pflicht an, hier Rede und Antwort zu stehen und zu erklären, warum die entsprechenden Ports benötigt werden und auch welches Risiko aber auch welche Change sich damit auftun. Allein mit einer "Ober sticht Unter"-Mentalität kommt man hier sowieso nicht weiter, verzögert ein Projekt und vergiftet die Stimmung. Dabei dreht es sich doch "nur" um Audio/Video. und die Kette ist einfach aufgezählt:

  1. payload = Audio Video
    Im Rahmen der Einführung von Skype for Business gibt es die Anforderung, dass Audio/Video/Desktop/Sharing
  2. Audio/Video und Bandbreiten
    Zur Sicherung der Qualität sollte mit QoS bevorzugt behandelt werden aber auch eine Überlastung durch Audio/Video verhindert werden. Aktive Komponenten oder eine entsprechende Kennzeichnung muss die Erkennung von Audio/Video ermöglichen.
  3. Optimierter Verkehr
    Die Übertragungswege sollen aufgrund der Besonderheit von Audio/Video möglichst direkt und mit dem passenden Protokoll erfolgen. UDP ist TCP vorzuziehen und ein "Einpacken" in anderen Protokollen wie z.B. VPN IPSec, HTTPS o.ä. sollte vermieden werden. Aufgrund der "Flüchtigkeit" der Daten und der unwahrscheinlichen Mehrfachübertragung ist eine "Optimierung" (Riverbed Steelhead, Cisco WAAS etc.) kritisch zu sehen
  4. Sicherheit
    Die Verbindungen sollen nicht für andere Datenübertragungen genutzt werden dürfen. Eine einfache Portfreischaltung ohne weitere Inspektion ist kritisch zu sehen

Diese vier Punkten vier Punkt sind in der Regel für alle Teilnehmer in der Gesprächsrunde zustimmungsfähig.

Häufige Fehleinschätzungen

Zugleich sind Sie aber auch der Ausgangspunkt für einige kritische Fragen oder Behauptungen. Meist scheiden sich die Geister an den "vielen High-Ports". Wenn man diese aber diskutiert, dann stelle ich folgende Fragen:

Fragestellung Bewertung

High-Ports sind generell kritisch zu sehen.

Es gibt natürlich Alternativen zur Nutzung von "High-Ports". aber ist es euch denn lieber, wenn alles in 3478 oder 443 eingepackt wird,

  • getunnelte Protokolle sind durch eine Inspection Firewall sehr viel schwerer zu analysieren
    Schließlich ist das eigentliche Protokoll nicht mehr direkt sichtbar.
  • getunnelte Protokolle lassen sich schwer priorisieren oder begrenzen
    Speziell wenn alles nur noch 443/TLS spricht
  • getunnelte Protokolle brauchen mehr Bandbreite
    Die zusätzlichen "Rahmeninformationen" erhöhen die Datenmenge. Bei VoIP ist das noch signifikant höher, da hier sehr viele sehr kleine Pakete gesendet werden.
  • getunnelte Protokolle verändern den Handshake
    Dies gilt insbesondere, wenn ein Protokollwechsel von UDP auf TCP erfolgt. VoIP arbeitet bevorzugt mit UDP und benötigt keine "Retransmissions", wenn mal ein Paket verloren geht. Bei einem Tunnel über TCP kommt diese überflüssige Fehlersicherung mit.

Wir wünschen und eine "Allow"-Regeln mit möglichst wenig Ports pro Dienst.

Nur weil eine Applikation wenige oder gar nur einen Port nutzt, ist sie nicht sicherer. Genau genommen sind alle Ports gleich gut oder schlecht und nur weil 443/TCP der Standardport für HTTPS ist, kann er durchaus auch für andere Dienste genutzt werden. Eine Filterung über Ports ist daher nur die erste Verteidigungslinie eines Hosts, der nur über definiert Services zu erreichen sein soll.

Ausgehend werden schon immer High-Ports als Quell-Port genutzt. Die meisten Regeln gehen darauf aber nicht explizit ein, sondern filtern nach Quell-Netzwerk, ZielNetzwerk und Zielport. Alle Zugriffe auf Webserver erfolgen z.B. von Client mit einem "High-Port" als Quellport. Beim Einsatz von VoIP mit UDP kommen aber High-Ports sowohl als Quell als auch als Ziel-Port vor. Bei einer externen Kommunikation kommt diese hohe Portrange nur von genau einem System - dem Edge-Server. Und das ist auch gut so, damit viele parallele Verbindungen effektiv genutzt werden können.

Unsere Firewall kann RTP behandeln

Gute Firewalls versuchen mehr zu verstehen als nur die Quell und Ziel-Port und eventuell die Namen und Dienste von Ziel-IP-Adressen. Moderne Firewalls können so z.B. sehr gut Zugriffe auf Facebook, Twitter und andere Dienste erfassen und getrennt ausweisen und berechtigen. Allerdings sollten Sie hierzu wissen, dass auch Firewalls nicht in SSL-Verbindungen schauen können und welchen Dienst der Anwender hier z.B.: nutzt, ist nicht zuverlässig zu bestimmen. Meist erhalten diese Firewalls vom Herstellern entsprechende Regelsätze, die letztlich doch die IP-Adresse des Ziels als wichtigstes Kriterium nutzt.

Viele Firewalls schauen sich aber schon die Pakete genauer an und RTP ist eigentlich ganz einfach zu erkennen und zu verstehen. Das Format der Frames ist festgelegt und selbst die Nummer des Codec ist zu erkennen. Über RTCP kann sogar die Qualität ausgewertet werden. Insofern kann eine Firewall hier schon wissen, was übertragen wird

Um wirklich VoIP zu verstehen müsste Sie aber auch die SIP-Signalisierung analysieren. Dort wird aktiv übermittelt, welche IP-Adressen und Ports als Kandidaten für die Übertragung angeboten und letztlich vereinbart werden. Allerdings hilft es nicht wenn die Firewall dann erst die Ports dynamisch zulassen würde, denn die Clients versuchen schon vorher eine Verbindung und nutzen nur die Verbindung, die auch "schon" funktioniert.

Der Edge -Server ist ja nur ein RTP-Relay

Es gibt sicher einige Produkte von Microsoft, die primäre eine Funktion bereitstellen und die Sicherheit aus Sicht von klassischen Firewalls haben vermissen lassen. So war der frühere MSProxy 2.0 wirklich nur ein HTTP-proxy und auhc als ISA-Server oder TMG konnte er mit den großen Firewalls kaum in Konkurrenz treten. Aber einige Dinge konnte TMG schon besser, als viele gute Firewalls, z.B. die Veröffentlichung von Exchange mit Preauthentication.

Der Edge-Server in einer Skype for Business Umgebung ist aber weit mehr als nur ein "Port Forwarder". Er ist quasi die Application Firewall für SIP und RTP, für die wir eine große Portrange freigeschaltet haben wollen. Die Ports sind aber allesamt per Default "geschlossen". Erst wenn ein Client per TURN authentifiziert einen Post für eine RTP-Verbindung anfordert, wird dieser Port solange geöffnet, wie der Client diesen Port reserviert.

Natives RTP mit Payload ist viel besser

Ich habe ein paar "Trace-Beispiele" beigefügt, welche Daten von einer RTP-Verbindung in den verschiedenen Techniken sichtbar sind.

  • Native RTP
    Dies ist ein Paket mit ca. 20ms Ton. Es ist gut zu sehen, dass hier G722 Audio mit 8kHz genutzt wird. Das ist allerdings keine 100 Sicherheit, dass nicht eine Applikation diese "Bits" für die Übertragung anderer Informationen nutzt. Aber so kann eine Firewall zumindest etwas mehr Metadaten über eine Verbindung erhalten, als wenn gleich alles "getunnelt" wird
  • NativeRTCP
    Zu jedem RTP-Paket gehört auch ein RTCP Paket, welches Rückmeldungen zu den Statistiken enthält, damit der Sender seine Aussendung anpassen kann, z.B. durch einen Codec-Wechsel weniger Bandbreite belegt oder mit ECC-Codecs besser Paketverluste kompensieren kann.
  • Turn vom Client zum Server
    Wenn eine direkte RTP-Verbindung nicht möglich ist und auch RTP nicht über NAT laufen kann, dann bleibt nur der Versand per TURN an einen entsprechenden Server
  • TURN vom Server zum Client
    Ebenfalls über eine TURN-Verbindung kann der Client auch Daten erhalten. Das sieht dann so aus:

Sie können aber bei TURN schon sehen, dass die Pakete ca. 30%-100% größer sind. Und das ist hier nur "TURN über UDP". Wenn Sie nun auch noch UDP 3478 blocken, dann werden die Pakete auch noch in 443/TCP eingepackt.

Meine Einschätzung

Auf den ersten Blick erscheinen Portranges von 50.000-59.999 für einen Server sehr hoch gegriffen aber wer die Spezialitäten von VoIP kennt, wird sich davon nicht erschrecken lassen sondern eher es als Vorteil sehen, wenn die Audio- und Video-Verbindungen von einer Firewall direkt begutachtet werden können. Natürlich ist auch die Absicherung durch den Edge-Server eine wichtige und notwendige Komponente zur sicheren Erreichbarkeit von Skype for Business Services im Internet und aus dem Internet.

Weitere Links