Zugriff auf Webclient-URL und App-Registrierungs-URL beschränken?

[OliverTer]

Hallo zusammen,
wir setzen eine 3CX Enterprise self-hosted mit mehreren hundert Nebenstellen ein und haben die Nebenstellen über unsere Niederlassungen in der ganzen Welt verteilt. Aus Sicherheitsgründen müssen wir den Zugriff auf den normalen Webclient (Browser) und auch die Provisionierung der IOS-App (nicht den Betrieb der App, wenn sie einmal provisioniert ist!) für normale Teilnehmer auf bestimmte, durch uns kontrollierte, private IP-Netze einschränken (e.g. 192.168.x.y).
Das haben wir derzeit erreicht durch umfangreiche Tweaking-Maßnahmen des NGINX-Webservers auf der 3CX. Leider sind natürlich diese Tweaks bei jedem Update der 3CX-Anlage verloren und müssen mühsam wieder eingebracht werden, teilweise funktioniert die alte Methode dann auch natürlich nicht mehr (zuletzt beim Update von V18 auf V20 und dann auf V20Update 4) und müssen neu "erforscht" werden.
Da wir nun mal wieder zu einem Update gezwungen werden (Zertifikate, deadline ist Oktober) wäre hier die Frage an die 3CX-Mitarbeiter, ob ein solches Feature für die beiden oben genannten Dinge nicht analog zu der vorhandenen (und auch durch uns genutzten) "Admin Console Restriction" einfach in die GUI der 3CX zusätzlich eingebaut werden könnte? Wir wären auch (in Grenzen) bereit, die Einführung eines solchen Feature finanziell zu unterstützen, da es für uns unverzichtbar ist.

Über eine Rückmeldung vom 3CX-Team würde ich mich sehr freuen.

 

[bitn2]

Den Sinn verstehe ich nicht ganz... Der Zugriff auf den Webclient und die Nutzung der IOS App soll nur aus bestimmten privaten Netzen möglich sein? Einfach per Firewall den externen Zugriff abdrehen... Die Niederlassungen müssen dann halt per VPN mit der dem Standort der 3cx verbunden sein.

 

[fxbastler]

Wenn HTTPS Verkehr und Internetzugang dann regeln wir das über einen Reverse Proxy. Dort wird dann nur zugelassen was wir wollen.
Problematisch ist evtl. die Provisionierungs URL per Barcode parallel zur Verwendung z.B. des Webclient von außen.

Wenn es um weitere Beschränkungen auch in privater Netzsegmenten gehen soll, dann muss der SSL Proxy halt generell vor die 3CX.

Aber wir sind ja nicht die Firma 3CX und um die geht es ja im letzten Satz des TO.
Ich als Premium Kunde hätte das meinen Partner oder 3CX Vertriebsbeauftragten gefragt.

 

[OliverTer]

Den Sinn verstehe ich nicht ganz... Der Zugriff auf den Webclient und die Nutzung der IOS App soll nur aus bestimmten privaten Netzen möglich sein? Einfach per Firewall den externen Zugriff abdrehen... Die Niederlassungen müssen dann halt per VPN mit der dem Standort der 3cx verbunden sein.

Nicht die Nutzung der App, wie ich oben schon schrieb, nur die Provisionierung der App, damit wir kontrollieren können, auf WELCHE devices die App provisioniert wird und der User nicht einfach selbst unzählige Devices provisionieren (und nutzen) kann. Die Nutzung der App (einmal provisioniert) muss natürlich über das Internet möglich sein. Daher kann auch nicht einfach per Firewall der Port 443 geschlossen werden.

 

[OliverTer]

Wenn HTTPS Verkehr und Internetzugang dann regeln wir das über einen Reverse Proxy. Dort wird dann nur zugelassen was wir wollen.
Problematisch ist evtl. die Provisionierungs URL per Barcode parallel zur Verwendung z.B. des Webclient von außen.

Wenn es um weitere Beschränkungen auch in privater Netzsegmenten gehen soll, dann muss der SSL Proxy halt generell vor die 3CX.

Aber wir sind ja nicht die Firma 3CX und um die geht es ja im letzten Satz des TO.
Ich als Premium Kunde hätte das meinen Partner oder 3CX Vertriebsbeauftragten gefragt.

ja, darauf sind wir auch schon gekommen. Allerdings hatte das zwei Probleme. 1.) die entsprechenden Links sind seit V20 unter einem einzigen URL-string zusammengefasst, also hat der Proxy nichts mehr zum unterscheiden... (zumindest haben wir es nicht mehr gefunden, bei V18 ging das noch so.) 2.) die Performance des Webproxys ist anscheinend manchmal ein Problem, wir hatten signifikant viele Verbindungsabbrüche auf allen möglichen Services, daher betreiben wir die Anlage aktuell ohne Reverse Proxy. Daher ist die bisher einzige (nicht gemochte) Lösung, den NGINX zu tweaken...

 

[fxbastler]

... 1.) die entsprechenden Links sind seit V20 unter einem einzigen URL-string zusammengefasst, also hat der Proxy nichts mehr zum unterscheiden... (zumindest haben wir es nicht mehr gefunden, bei V18 ging das noch so.)

Die URL im Barcode der Provisionierung von Smartphones unterscheidet sich erheblich von der Provisionierungs URL für Endgeräte wie z.B. IP Phones, DECT Basen, Router Phones oder Smartphone Konfigurationsanforderungen. Das kann man mit einem Reverse Proxy unterbinden soweit ich das sehe. Wenn das generell nicht gewünscht ist, dann auch den Proxy intern betreiben und nur auf Zuruf - wenn eine Provisionierung gewünscht ist - freigeben. Problem ist immer die Nutzung des Webclient in so einem Konstrukt.

2.) die Performance des Webproxys ist anscheinend manchmal ein Problem, wir hatten signifikant viele Verbindungsabbrüche auf allen möglichen Services, daher betreiben wir die Anlage aktuell ohne Reverse Proxy.

Damit haben wir keine Probleme.