Einstellungen Sophos UTM für Starface App

  • Hallo Starface Gemeinde,


    Ich bin auf der Suche nach einer Anleitung für die Konfiguration (gern aber auch Best Practice) einer Sophos UTM für die STARFACE App. Unsere UTM meine ich größtenteils mit DNAT Regeln richtig eingerichtet zu haben, da zumindest Login, Journalabfrage und so funktioniert. Scheitern tut es noch irgendwie an der Audiodatenübertragung. Ein Anruf lässt sich starten aber es kommt kein Ton über. Ich kann mir vorstellen dass neben NAT und Firewallregeln auch SIP Einstellungen getätigt werden müssen.
    Die UTM hat wohl irgendwelche Mechanismen dass man Einstellungen die via Menüs nicht über Umwege genauso konfigurieren kann.



    des Weiteren habe ich noch ein wenig bedenken bei Port 443 da gleichzeitig das Webinterface für die STARFACE freigeschaltet würde. Sollte man in diesem Falle mit der Webapplication Firewall nutzen, und wenn ja, wie sind da die korrekten Einstellungen.


    Meine Sophos UTM SG230 ist ausgestattet mit Version 9.408

  • Besorg Dir die IP-Adress-Bereiche Deiner SIP-Provider und lasse Kommunikation zur STARFACE ausschliesslich von diesen Servern zu. Dann reicht es gegen "aussen" lediglich die SIP-, XMPP- und RTP-Ports freizugeben. Im internen Netz hast Du weiterhin Zugriff auf das Webinterface.


    Sollte es dennoch notwendig sein, von aussen auf die STARFACE zuzugreifen, dann nur über einen VPN-Tunnel. Das Selbe gilt für den Anlagenverbund.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Wenn "nur" die Audioübertragung nicht funktioniert, sind es möglicherweise die RTP-Ports die nicht korrekt freigeschaltet sind. Vielleicht noch mal eine Blick in das entsprechende Cheatsheet werfen:


    https://knowledge.starface.de/…obile%20Clients%206.4.pdf


    Will heissen, damit ich den Mobile Client ohne VPN-Tunnel nutzen kann muss ich zwingend die Ports 10000-65535 UDP offen lassen wie ein Scheunentor ? Einen Bereich von über 50'000 Ports ?


    Aus Security-Sicht ist das nicht sinnvoll. Vernünftigerweise sollten auch Mobile-Clients über VPN angebunden werden.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Will heissen, damit ich den Mobile Client ohne VPN-Tunnel nutzen kann muss ich zwingend die Ports 10000-65535 UDP offen lassen wie ein Scheunentor ? Einen Bereich von über 50'000 Ports ?


    Aus Security-Sicht ist das nicht sinnvoll. Vernünftigerweise sollten auch Mobile-Clients über VPN angebunden werden.


    Aus Security-Sicht sind 50.000 "offene" Ports in der Firewall nicht schlimmer als einer. Der Dienst dahinter ist der selbe. Der mobile Client kommuniziert – wie die anderen Clients auch – über XMPP auf Port 5222/TCP. Wer das Softphone nutzen will, muß natürlich eine Audiokommunikation ermöglichen.
    Bei der genannten Portrange handelt es sich um zufällig ausgehandelte Kombinationen für ein- und ausgehende Audiodaten. Es ist nicht so, dass da dauerhaft ein Dienst auf eingehende Verbindungen wartet.

  • Wenn "nur" die Audioübertragung nicht funktioniert, sind es möglicherweise die RTP-Ports die nicht korrekt freigeschaltet sind. Vielleicht noch mal eine Blick in das entsprechende Cheatsheet werfen


    jo, ist alles mit NAT eingerichtet.
    wobei das Cheatsheet einen kleinen aber feinen Fehler enthalten dürfte:
    10000 bis 20000 (UDP)eingehende RTP Audiodaten
    20000 bis 65535 (UDP) ausgehende RTP Audiodaten
    es müsste eingehend bis 20000 und ausgehend ab 200001 heißen


    und ich vermisse Port 5060 und 3478 (STUN)


    -----


    des Weiteren muss ich sagen dass ich noch keinen SIP Provider habe, es geht mir für den Anfang erstmal um Verbindung von Außen zu Intern, ohne VPN per App oder per UCC Client und dachte, dass das direkt geht. Oder liege ich da komplett falsch?


    Wie ich eingangs schon erwähnte kann ich wahrscheinlich NAT technisch für Port 5060 und 5061 so viel einstellen wie ich will, das wird nicht greifen weil das nicht über Network Protection - VoIP konfiguriert ist. Hat da schon jemand Erfahrung mit?

  • Guten Morgen!


    stell mal deine Regeln in der Network Protection auf protokolliert und geh dann ins Live-Log.
    a) siehst du dort die von den Regeln betroffenen Pakete grün
    b) kannst du dann anhand der IP-Adresse filtern und schauen ob noch Pakete verworfen werden


    Und dann die Frage ob dort in Verbindung mit der Endgeräte IP noch Pakete verworfen werden?


    Die Konfiguration im Bereich Networkprotection VoIP dient dazu das Problem mit der großen Portrange zu umgehen. Die Sophos kann über die SIP Pakete die verwendeten Ports auslesen und temporär freischalten. Geh am besten mal in das Menü VoIP und klick rechts oben auf das Fragezeichen. Dort wird es dann detailierter Erklärt.


    Gruß
    Dome

  • logging habe ich jetzt mal aktiviert und ich sehe jetzt folgendes (HandyApp --> Starface):


    Live Log_ Firewall.png
    also von meinem Mobilgerät versucht die App wohl zweierlei: einmal auf die externe IP per NAT wird durchgelassen und einmal auf die interne IP der Starface wo natürlich gedroppt wird. Ich hoffe das wird durch den Screenshot ersichtlich.

  • Ich vermute du hast deine Regeln falsch angelegt.
    Und solange deine Pakete gedroppt werden, kann es natürlich nicht funktionieren ;)


    Im Log ist es so eingetragen weil du NAT machst
    Endgerät -> öffentliche IP (NAT)
    Endgerät -> Ziel IP (Firewall)


    Du musst deine Regeln so anlegen:
    Internet IPv4/v6 -> PORTS -> STARFACE (lokal)


    Gern kannst du mir auch mal per PN oder per Mail (dominik.gilgen@parit.de) deine NAT und Firewall Regeln per Screenshot schicken

  • Mach mal im ersten Schritt die Regel wieder an die du angelegt hast:
    Internet IPv4 -> Starface Protokolle -> Starface Telefonanlage
    Und nimm in deinem Regelwerk auch SIP (5060) mit auf, sonst geht es natürlich auch nicht.


    Schalt da auch mal die Protokollierung an und prüfe ob die verworfenen Pakete von deinem Screenshot nun durch kommen.
    Ohne die Regel wird es nicht funktionieren ;)


    Das DNAT in der Sophos macht dir nen Portforwarding auf die STARFACE. Das Ziel ist dann aber auch im Regelwerk die STARFACE und nicht die WAN-Schnittstelle.
    Deshalb brauchst du eine Regel die entsprechend Internet -> Protokoll -> Endgerät aufmacht.


    In deiner Konfig kannst du erstmal die VoIP Settings in der Network-Protection weglassen und in die Regel deine RTP Ports die du angelegt hast mit aufnehmen.
    Ich bin mir aktuell nicht 100%ig sicher ob der VoIP Helper in deinem Szenario auch greift. Primär ist das dafür gedacht Client/TK zu nem externen SIP Provider zu verbinden.
    Wenn dann müsste glaub auch eher bei SIP Server Networks das Netz rein in dem die STARFACE steht und SIP Client Networks müsste dann Internet IPv4/v6 sein (ggf. auch genau verdreht, das geht aus der Doku nicht ganz einher, weil die von ner anderen Situation ausgehen).

  • Fabian hat recht. Von einem Security-Standpoint sind 50.000 offene Ports nicht schlimmer als ein offener Port.
    Der Listenerdaemon dahinter (asterisk) nimmt eh nur Pakete aus bestehenden, ausgehandelten SIP-Sessions an.


    Ich poste mal meine laufende Konfiguration.
    Bei DNAT das erstellen der Firewallregeln anhaken.


    DNAT
    2016-11-28 11_25_52-WebAdmin - User admin - Device gateway.janz.online.png


    Definitionen
    SIP(S)
    sips.png


    XMPP
    xmpp.png


    RTP
    2016-11-28 11_31_46-WebAdmin - User admin - Device gateway.janz.online.png


    Sonstiges
    Network Protection -> VoIP unbedingt ausschalten.
    Das ist ein SIP ALG was die Funktionsweise der STARFACE beeinträchtigt.


    Port 443 ist durch einen Reverse Proxy (NGINX) belegt, der u.A. das Webinterface und die REST-API der STARFACE rausreicht.

    Einmal editiert, zuletzt von DerGerät ()

  • Fabian hat recht. Von einem Security-Standpoint sind 50.000 offene Ports nicht schlimmer als ein offener Port.


    Das heisst aber nicht, dass ich einem "Suchenden" 50'000 statt nur den benötigten Ports anbieten muss; ich muss ja den bösen Buben nicht die Arbeit erleichtern um ein Einfallstor zu finden.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Hallo Thomas,


    naja klar, aber man kann neben den offenen Ports ja nun auch vorgeben, WER diese Ports und vor allem WOHIN nutzen darf - das beschränkt as Ganze dann auch wieder, oder?


    Aber ich muss doch nicht erst ne "Einladung" bereitstellen. Eine Tür die nicht da ist, muss ich auch nicht noch zusätzlich absichern.


    Es macht doch keinen Sinn erst etwas das nie benötigt wird bereit zu stellen um dann den Zugriff darauf wieder einzuschränken.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Hi Thomas,


    Aber ich muss doch nicht erst ne "Einladung" bereitstellen. Eine Tür die nicht da ist, muss ich auch nicht noch zusätzlich absichern.


    Es macht doch keinen Sinn erst etwas das nie benötigt wird bereit zu stellen um dann den Zugriff darauf wieder einzuschränken.


    Ich glaube da gibt es ein Missverständnis. Es wird ja nicht wirklich bereitgestellt.


    Die STARFACE antwortet auf einen Verbindungsversuch auf einen dieser Ports mit einem ICMP/Port Unreachable – teilt dem Anfragenden also mit, dass kein Dienst auf diesem Port lauscht.
    Wenn Du in der Firewall das ganze per DROP abweist, gibt es keine Antwort, mit einem REJECT in der Firewall ist das Ergebnis das selbe: Es wird per ICMP eine Nichterreichbarkeit angezeigt – standardmäßig, wenn kein Reject-Type angegeben wird, wird (zumindest mit iptables) ebenfalls ein ICMP/Port Unreachable gesendet.


    Das heißt: Die Ports in der Firwall weiterzuleiten oder ein REJECT zu machen ist für den Anfragenden identisch.
    Lediglich beim DROP würde die Anfrage verworfen, ohne eine ICMP-Antwort zu generieren.

  • Hallo Thomas,


    das mit dem "nie benötigt" kann man so pauschal ja leider nicht sagen - ich verstehe aber was Du meinst. wenn Du aber auch nur enen Port für ALLE öffnest statt mehrere Ports für ganz bestimmte Quellen und Ziele zu beschränken, ergibt sich auch kein Vorteil, eher umgekehrt. Ist vermutlich eine Philosophiefrage ...


    Wir hier halten es in der Regel so: soviel wie nötig für genau nur die Parteien, für die das tatsächlich benötigt wird. In Ergänzung zu dem was Fabian aufgeführt hat und was Du für bestimmte Kommnuikationstypen brauchst, hilft Dir die Beschränkung auf bestimmte Quellen/Ziele ja, die Sicherheit ausreichend hoch zu halten. Persönlich würde ich für die externe Anbindng auch das von Dir erwähnte VPN bevorzugen - ansonsten gibt es aber auch ein paar Mechanismen, um externe Zugriffe zumindest - sagen wir mal: "sicherer" zu machen. Ich teile ansonsten Deine Meinung.


    Ergänzung:


    Fabian hat das gerade sehr schön ergänzt ...

  • Die RTP Ports 10000-20000 sollten eingehend von deinem VoIP-Provider und allen extern angebundenen Teilnehmern erreichbar sein (Portforwarding, DNAT, ...).
    Hinter diesen Ports steckt im Normalfall kein Daemon, eingehende Pakete werden nicht beantwortet.


    Das kann jeder für sich mittels nmap (Industriereferenz für Netzwerkscanner) überprüfen:
    nmap -sC -sU -p U:10000-20000 hostname


    Der Scan läuft bei mir noch, ETA 3 Stunden, nach 30 Minuten (bzw. 8%) noch keine einzige Antwort. Und das obwohl die Ports für mich "offen" sind. :p


    Warum ist das so?



    Erst wenn eine SIP Session aufgebaut wurde und im SDP die Mediaports ausgehandelt wurden (STARFACE wird einen zufälligen Port zwischen 10000-20000 anbieten)
    wartet hier ein Thread des Asterisk-Daemon auf Sprachpakete und nichts anderes.


    Nur und exklusiv Pakete von der IP Adresse die als Media-Contact im SDP angegeben war werden bearbeitet und beantwortet.

    Warum also forwarden?


    Kurz:
    Sonst kann es dazu kommen, das eine SIP Session aufgebaut wird, die Firewall aber die eingehenden RTP-Pakete verwirft. Man hört sich nicht.


    Ausführlich(er):
    Für die Firewall gibt es erstmal keinen Zusammenhang zwischen der SIP Session und der RTP (Media) Session, die Ports werden nicht in der NAT-Tabelle festgehalten und erreichen den Host (in dem Fall die STARFACE) nicht.
    Also muss man der Firewall sagen, das Pakete auf diese Ports immer für die STARFACE bestimmt sind und umgeleitet werden sollen.



    Ich hoffe ein bisschen Licht in die Sache gebracht zu haben, würde euch aber bitten nun beim Topic zu bleiben.
    Falls Ihr weitere Fragen zu dem Thema habt, macht doch einen eigenen Thread auf.

    Viele Grüße
    Niklas


    - Ex STARFACE Support: 2014-2020 -

  • Ich muss die Diskussion vom letzten Jahr nochmals aufgreifen und hoffe auf Erkenntnisse.


    Hallo erstmal zusammen!


    Ich kämpfe seit einiger Zeit damit, das ich mit das ich mit dem Starface APP extern nicht telefonieren kann. Im lokalen Netz ist alles i.O.


    Szenario:
    Starface TK Anlage im VM-Ware Umgebung
    Firewall: Sophos UTM
    SIP Provider: SIPGATE / Starface Connect
    Carrier: Vodafone Kabel mit Modem im Bridge Mode
    DNAT Regeln von Any zur TK Anlage für folgende Ports:
    SIP RTP 10000-20000 UDP
    HTTPS 443
    SIP 5060 TCP/UDP
    SIP SSL 5061 TCP
    XMPP 5222 TCP
    XMPP SSL 5223 TCP
    SIP RTP OUT 20001:65535 UDP
    SIP RTP 5004:5020 UDP (sipgate)
    SIP Activity 25060 TCP/UDP (sipgate)
    STUN 3478 UDP
    Timesync 123 UDP
    Autoprovisionierung 50080:50081 TCP
    Anlagenverbund 3090 TCP/UDP


    Firewall Regeln entsprechend aktiv!


    Ich bekomme am App Anrufe signalisiert, aber es findet keine Audioübertragung statt.
    Wenn ich auf der TK Anlage den Portdump mitlaufen lasse, sehe ich im Bereich 10000-20000 auch keinerlei Aktivitäten.


    Kann es sein, das Vodafone Kabel diese Ports trotz Bridge Mode für sich einbehält???

    ITSPEZI.com
    Ihr Partner in Ostthüringen
    Tel.: 0365 25762376-0
    Fax : 0365 25762376-9
    E-Mail: info @ itspezi.com
    Web: http://www.itspezi.com


  • Offenbar waren einige DNS Server noch nicht aktualisiert, so das nicht einheitlich die XMPP Domäne erreichbar war.
    Nach Umstellung des Modems in den Bridge Mode, scheint es jetzt dann doch zu funktionieren.

    ITSPEZI.com
    Ihr Partner in Ostthüringen
    Tel.: 0365 25762376-0
    Fax : 0365 25762376-9
    E-Mail: info @ itspezi.com
    Web: http://www.itspezi.com

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!