VoIP PortRange

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.

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.