Provisierungsordner schützen - wie?

[ciscoX]

Hallo,

bin mal wieder auf ein großes Problem mit der 3CX Anlage gestoßen.
Ist es gewollt, dass jeder Zugriff auf den Provisierungsordner hat, der die URL kennt? Ganz ohne Authentifizierung?! Finde ich äussert unsicher und ein absolutes No Go von 3CX!!! Da kann man von Glück sprechen, dass 3CX beim API Zugriff (noch) nicht versagt hat.

Kann mir jemand helfen? Meine Anlage läuft selbst gehostet auf Linux. Mal funktionierte die .htpasswd ... na ja bis zum Neustart des Servers. Bisher habe ich es nicht mehr geschafft, dass die phonebook.xml mit der .htpasswd geschützt wird.

Habe mir sogar dank 3CX den gesamten Server zerschossen, bzw. habe mich auf eine Vorgabe verlassen, die mich vom Server ausgesperrt hat, deshalb will ich nichts mehr groß verändern, "nur" wegen 3CX. Hab von Linux keine Ahnung und will mich damit auch nicht weiter auseinandersetzen. Ich will doch einfach nur, dass mein Telefonbuch nicht im Netz "umherschwirrt".

/etc/.htpasswd liegt vor und in /etc/nginx.conf steht folgende Zeile:

server {
listen 80;
server_name _;
return 301 https://example.com$request_uri;

location /provisioning/example/cisco_phonebook.xml {
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
root /var/lib/3cxpbx/Instance1/Data/Http/Interface;
deny all;


}


Natürlich ist "example" jeweils spezifisch festgelegt. Sämtliche Tutorials im Netz gehen nicht. Die XML Datei bleibt frei zugänglich, da kann ich an der NGINX rumbasteln, wie ich will...meine Nerven liegen blank...HILFE!!!






Grüße

PS: Bin genervt von 3CX - aber gewaltig!

 

[bitn2]

Was genau möchtest du? Wie sollte jemand diesen Link erraten (der ist dynamisch)? Wie sollen die Telefone das Telefonbuch ziehen wenn du es sperrst?

 

[fxbastler]

der ist dynamisch

Der ist leider nicht dynamisch. Aber ein Reverse Proxy schafft da Abhilfe.

 

[bitn2]

Der ist leider nicht dynamisch. Aber ein Reverse Proxy schafft da Abhilfe.

Ist das nicht der Link der auch zur Config führt? Der wird doch generiert wenn man eine Nebenstelle erstellt oder seh ich das grad falsch?

 

[fxbastler]

Wenn du diesen meinst:
http://fqdn:5000/provisioning/<provisioning-directory>




nein

 

[fxbastler]

Habe mir sogar dank 3CX den gesamten Server zerschossen, bzw. habe mich auf eine Vorgabe verlassen, die mich vom Server ausgesperrt hat, deshalb will ich nichts mehr groß verändern, "nur" wegen 3CX. Hab von Linux keine Ahnung und will mich damit auch nicht weiter auseinandersetzen.

Eine Debian 3CX sollte per 3CX ISO Installationsmedium installiert werden. Auf dieser Debian Installation sollte dann auch nichts Wesentliches anderes laufen. Sonst kein Support, keine Lösung bei irgendwelchen solchen Problemen usw.. Wenn du so eine Installation hast (deine Formulierung von 'den ganzen Server zerschossen' legt es nahe), brauchst du hier gar nicht weiter fragen. Noch dazu, wenn ich den Satz lese 'Hab von Linux keine Ahnung ...'.

Dann lass es.

 

[avraammich_3CX]

Hi,

Enable Provisioning Secret Key / Erstellung eines geheimen Schlüssels aktivieren(Dashboard->Sicherheit->Angriffsschutz)

Erst dann dynamisch.

 

[bitn2]

Hi,

Enable Provisioning Secret Key / Erstellung eines geheimen Schlüssels aktivieren(Dashboard->Sicherheit->Angriffsschutz)

Erst dann dynamisch.

Ach das wars, das habe ich aktiviert...

 

[fxbastler]

Enable Provisioning Secret Key / Erstellung eines geheimen Schlüssels aktivieren(Dashboard->Sicherheit->Angriffsschutz)

Erst dann dynamisch.

Das hilft aber nicht gegen den unberechtigten Telefonbuchzugriff u.a. was im Provisionierungsordner liegt. Sehe ich das richtig?

 

[bitn2]

Nein, nur das der Key bei jeder Nebenstelle anders ist.

 

[bitn2]

Ich halte es aber grundsätzlich sehr unwahrscheinlich das jemand den Link ausnutzt. Dafür müsste er den ja erstmal kenne und woher soll er das. Weder auf das Telefon noch auf die Admin Console haben Benutzer irgend einen Zugriff.

 

[fxbastler]

Ich halte es aber grundsätzlich sehr unwahrscheinlich das jemand den Link ausnutzt.

Unwahrscheinlich heißt nicht nicht und auch nicht nie.

Dafür müsste er den ja erstmal kenne und woher soll er das.

Das ist auch eine rhetorische Frage. Security by Obscurity hat noch nie geholfen.

Weder auf das Telefon noch auf die Admin Console haben Benutzer irgend einen Zugriff.

Es geht um die Daten die im Provisionierungsverzeichnis liegen, inkl. eben auch dem Telefonbuch. Diese Daten sind überall abrufbar, eben auch per https aus dem Internet.

Ja, den individuellen Provisionierungslink bzw. den der Anlage geheim zu halten hilft vielleicht eine Zeitlang, aber eben nicht immer. Dieser Link bleibt zeitlebens der Anlage gleich.

Enable Provisioning Secret Key / Erstellung eines geheimen Schlüssels aktivieren(Dashboard->Sicherheit->Angriffsschutz)

Warum diese Option standardmäßig (auch bei neuen Anlagen) nicht gesetzt ist, erschließt sich mir auch nicht.

 

[avraammich_3CX]

Hi @fxbastler,

Warum diese Option standardmäßig (auch bei neuen Anlagen) nicht gesetzt ist, erschließt sich mir auch nicht.

Evtl. in einer neuen Build Nummer/Version default aktiviert.
Entwicklung entscheid ob option aktiviert bei default/neu Installation.
Gerne auf Ideas posten.

 

[bitn2]

@fxbastler da muss ich dir recht geben, nur weil die Wahrscheinlichkeit gering ist, heißt es nicht das es nicht passieren kann. Wenn ich das aber richtig sehe, müssen diese Daten ohne Login dort liegen da die Telefone sich die einfach ziehen ohne sich irgendwo anzumelden. Die Anmeldung der Nebenstelle ist das einzige mit Login, sehe ich das richtig? Ob das nun gut ist oder nicht, aber mir scheint es so das man diese Daten nicht mit einem Login schützen kann da die Telefone da sonst nicht mehr dran kommen.

 

[fxbastler]

Wenn ich das aber richtig sehe, müssen diese Daten ohne Login dort liegen da die Telefone sich die einfach ziehen ohne sich irgendwo anzumelden.

Dass die intern erreichbar sind ist tlw. problematisch, kann ich aber verstehen und mit Abstrichen akzeptieren.

Die Frage ist: muss dieser / müssen diese Ordner auch ohne Authentifizierung aus dem Internet heraus erreichbar sein?

 

[bitn2]

Die Frage ist: muss dieser / müssen diese Ordner auch ohne Authentifizierung aus dem Internet heraus erreichbar sein?

Das ist eine gute Frage... Wenn ein Telefon extern provisioniert ist, könnte das schon nötig sein. Aber wenn man eh einen SBC oder so nutzt, müsste man das irgendwie deaktivieren können.

 

[fxbastler]

Wenn ein Telefon extern provisioniert ist, könnte das schon nötig sein.

Was genau meinst du mit 'extern provisioniert'?

 

[bitn2]

Was genau meinst du mit 'extern provisioniert'?

zB per Stun..

 

[fxbastler]

Friends do not let friends do STUN.
Aber das Telefonbuch sollte da so nicht benötigt werden, nicht ohne Passwort und Auth per https - oder eben gar nicht. Müsste ich mal mitmeisseln.

 

[bitn2]

Genau, oder eben gar nicht. Dann muss man das halt manuel einbinden. Aber so ist das Datenschutztechnisch ne 6 wie mein Kollege grad sagte.