[FRAGE] mass deployment: Auch Passwortgeschützt?

stefvoip

Neuer User
Mitglied seit
9 Mai 2007
Beiträge
16
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen.

Ich muss ein mass deployment über einen entfernten Server im Internet (WAN) starten. Ist es möglich, die Konfig-Files mit Zugangsdaten zu schützen welche man dann auf dem Telefon eingeben kann? Ansonsten kann ja Jeder die Files herunterladen und die empfindlichen Daten einsehen?!

Den Beitrag über mass deployment im Snom-Wiki hab ich gelesen, die gehen aber soweit ich gesehen habe nur von einem Server im LAN aus. :(

Hat wer ne Ahnung? :noidea:

Grüsse
Stef
 
Du kannst die Settings alle in eine MySQL Datenbank packen und mit einer PHP Settingsdatei auslesen. Bei der Anzeige dieser Datei wird man nichts sehen können...

mfg Guard-X
 
Guard-X schrieb:
Du kannst die Settings alle in eine MySQL Datenbank packen und mit einer PHP Settingsdatei auslesen. Bei der Anzeige dieser Datei wird man nichts sehen können...

mfg Guard-X

Mal ganz dumm gefragt: Wie "sieht" dann das Snom-Telefon etwas (also die Einstellungen), wenn der Webbrowser des bösen Buben es nicht kann? Wird die php-Datei mit bestimmten Parametern aufgerufen (?var=wert) und nur dann gibt sie den Inhalt preis?
 
Mal ganz dumm gefragt: Wie "sieht" dann das Snom-Telefon etwas (also die Einstellungen), wenn der Webbrowser des bösen Buben es nicht kann? Wird die php-Datei mit bestimmten Parametern aufgerufen (?var=wert) und nur dann gibt sie den Inhalt preis?

Naja, das Snom-Telefon kommt mit der MAC-Adresse daher, aber die könnte man ja auch Spoofen.... hmmm

Im Prinzip fehlt's da an einer Funktion im Telefon oder?
Cool wäre z.B. sowas: http://user:p[email protected]/settings.php?mac={mac}
aber das geht leider nicht.
 
Guard-X schrieb:
Du kannst die Settings alle in eine MySQL Datenbank packen und mit einer PHP Settingsdatei auslesen. Bei der Anzeige dieser Datei wird man nichts sehen können...
Was soll das bringen? Irgendwie muß man dem PHP-Script doch die MAC-Adresse als GET-Variable mit übergeben. Das Telefon kann seine MAC-Adresse ja nur im URL substituieren.

stefvoip schrieb:
Naja, das Snom-Telefon kommt mit der MAC-Adresse daher, aber die könnte man ja auch Spoofen.... hmmm
Genau. Man kann die MAC-Adressen auch einfach stumpf durchprobieren. Wenn Dein Settings-Server schnell genug ist, dann merkst Du als Administrator gar nichts davon, bevor ein Script alle möglichen (00:04:13:XX.XX:XX) MAC-Adressen durchprobiert hat.

Um wenigstens zu verhindern, daß Anwender mit Ihrem Webbrowser die Settings abrufen, könntest Du den User Agent prüfen, so wie es auch die Beispielscripts für das Firmwareupdate im Wiki von Snom tun.

Gruß
Henning
 
Um wenigstens zu verhindern, daß Anwender mit Ihrem Webbrowser die Settings abrufen, könntest Du den User Agent prüfen, so wie es auch die Beispielscripts für das Firmwareupdate im Wiki von Snom tun.

Hast du mir da einen Link? Ich bin nicht zu faul, aber wohl zu blöd um was zu finden, meine Suche blieb erfolglos :confused:
 
Damit erreichst Du aber keine Sicherheit, in fast jedem Browser kannst Du den UserAgent-Header frei setzen genauso wie bei einem wget Aufruf.
Gegen wen willst Du dein System schützen?
 
Da in den Konfig-Files unter Anderem auch die Userdaten für die Anmeldung an die PBX stehen, möchte ich natürlich diese heiklen Daten vor unberechtigten Zugriffen schützen. Also es sollen nur die Telefone, welche berechtigt sind diese Daten zu lesen, darauf zugreiffen können. Alle anderen Zugriffe müssen geblockt werden.

Evtl. kann man das auch mit einer IP-Rule lösen, am liebsten wäre es mir aber, wenn das Telefon selbst eine Auth.-Funktion unterstützen würde. Ansonsten komm ich wohl nicht drum herum, an der Firewall gewisse Rules zu setzen.

Grüsse
 
stefvoip schrieb:
Ansonsten kann ja Jeder die Files herunterladen und die empfindlichen Daten einsehen?!
Ist die Frage, ob der User den Ort dieser Datei kennt (er hat ja nicht das Adminkennwort) und die MAC-Adresse seines Rechners fälschen kann.

Dann wäre mein System überlistet, das stimmt...

mfg Guard-X
 
Guard-X schrieb:
Ist die Frage, ob der User den Ort dieser Datei kennt (er hat ja nicht das Adminkennwort) und die MAC-Adresse seines Rechners fälschen kann.

Security by Obscurity ;-)

Für den "normalen handelsüblichen" Mitarbeiter ist dieser PHP/MySQL Ansatz sicherlich ausreichend sicher, finde ich. Für alle anderen Dinge ist schon eine größere kriminelle Energie nötig.

Wer betreibt schon den Aufwand, die MAC auszuspionieren, diese sich selbst zu geben, damit dem DHCP Server die Options zu entlocken (“server-name” und “filename”) um dann damit vom http-Server die Daten zu bekommen?
Oder den Netzwerkverkehr mitzulauschen, das Snom-Telefon zu rebooten und dann die übermittelten Daten mitzuschneiden.
Oder gleich die sip-Anmeldedaten mitzuschneiden.

Wer macht so was schon ernsthaft? Ist doch sinnlose Zeitverschwendung. Die Leute sollen arbeiten und nicht spionieren. :p
 
microsaft schrieb:
Für den "normalen handelsüblichen" Mitarbeiter ist dieser PHP/MySQL Ansatz sicherlich ausreichend sicher, finde ich. Für alle anderen Dinge ist schon eine größere kriminelle Energie nötig.

Wer betreibt schon den Aufwand, die MAC auszuspionieren, diese sich selbst zu geben, damit dem DHCP Server die Options zu entlocken (“server-name” und “filename”) um dann damit vom http-Server die Daten zu bekommen?
Aaalso: PHP und MySQL machen die Provisionierung der Snom-Telefone kein bisschen sicherer oder unsicherer. Um die MAC-Adresse "auszuspionieren", muß man nur das Telefon umdrehen ;-) Darüber hinaus können die 16,8 Mio möglichen MAC-Adressen von Snom durchaus in endlicher Zeit durchprobiert werden. Man muß dazu keine MAC-Adresse des angreifenden PCs verändern, denn die MAC-Adresse wird vom Telefon im URL an den Provisionierungs-Server übergeben. Kriminelle Energie ist nur notwendig, um den Provisionierungs-URL herauszufinden. Hierzu reicht es in der Regel aus, einen PC an das Telefonnetz anzuschließen und aus der Antwort des DHCP-Servers den TFTP-Server auszulesen.

Kurzum: die Autoprovisionierung der Snom-Telefone ist unsicher. Aber sie muß auch gar nicht sicher sein, denn sie ist für den Betrieb in größeren Netzen gedacht, wo (hoffentlich) übergeordnete Sicherheitsmechanismen greifen.

Ansonsten kann ich mich nur microsaft anschließen ;-)

microsaft schrieb:
Wer macht so was schon ernsthaft? Ist doch sinnlose Zeitverschwendung. Die Leute sollen arbeiten und nicht spionieren. :p

Gruß
Henning
 
hehol schrieb:
Aaalso: PHP und MySQL machen die Provisionierung der Snom-Telefone kein bisschen sicherer oder unsicherer.

Doch ein bischen. Man kann, wie schon geschrieben wurde, den User-Agent abfragen oder könnte in dem PHP Script eine Funktion einbauen, welcher die anfragende IP bzw. anfragende MAC prüft. Dann sieht man, wenn man die URL an einem unveränderten Arbeitsplatz aufruft, nichts. Wenn die URL hingegen nur http://server/snom-0123456789AB.html heißt, geht das schon einfacher. ;-)

hehol schrieb:
Um die MAC-Adresse "auszuspionieren", muß man nur das Telefon umdrehen ;-)

Vorausgesetzt man hat physikalischen Zugriff auf das Telefon und dann kann man noch ganz andere Sachen damit machen z.B. per Kreuzkabel auf das Telefon eine eigene Firmware aufspielen, mit der man ssh-Rootzugriff bekommt. Oder einfach lauschen, welche URL das Telefon beim Booten abfragt.
MACs könnte man auch remote durch "arp" heraus finden.

hehol schrieb:
Darüber hinaus können die 16,8 Mio möglichen MAC-Adressen von Snom durchaus in endlicher Zeit durchprobiert werden.

Also ein normaler Büroangestellter hat bestimmt keine solchen Fähigkeiten, dies zu tun. Da gehört auf jeden Fall kriminelle Energie dazu - wie ich finde.
Wenn man weiß, wo sie liegen und das Script die Daten ungeprüft (nur anhand des Paramters) liefert. Und dann muss man auch noch den Datenwust auf den konkreten Benutzer/das Telefon zuordnen können.
Und im (virtuell-dedizierten) Webserver ist natürlich eingestellt, dass nur bestimmte IP Ranges darauf Zugriff haben und jede Anfrage erst nach 10 Sekunden beantwortet wird + nur eine Anfrage gleichzeitig von der gleichen IP kommen darf. Dann dauert die Suche lange genug, um im Monitoring des Admins aufzutauchen.

hehol schrieb:
Man muß dazu keine MAC-Adresse des angreifenden PCs verändern, denn die MAC-Adresse wird vom Telefon im URL an den Provisionierungs-Server übergeben.

Und genau darauf kann er filtern. Bei größeren Firmennetzen sind die Switch-Ports MAC-Based "gedongelt", sodass ein Ändern Alarm schlägt und den Port abschaltet.

hehol schrieb:
Kriminelle Energie ist nur notwendig, um den Provisionierungs-URL herauszufinden. Hierzu reicht es in der Regel aus, einen PC an das Telefonnetz anzuschließen und aus der Antwort des DHCP-Servers den TFTP-Server auszulesen.

Aber nur, wenn Dein dhcp-Server die Settings nicht MAC-Based verteilt. In vielen Netzen (auch in unserem) gibt es solche MAC-Weichen. Dann bekommst Du diese Options nicht geliefert, wenn die ersten drei Stellen der MAC nicht von Snom kommen. “server-name” und “filename” werden ja nicht nur von den Snoms ausgewertet.


hehol schrieb:
Kurzum: die Autoprovisionierung der Snom-Telefone ist unsicher. Aber sie muß auch gar nicht sicher sein, denn sie ist für den Betrieb in größeren Netzen gedacht, wo (hoffentlich) übergeordnete Sicherheitsmechanismen greifen.

Ja das simmt. Aber wenn Peter an Klaus ne Mail schreibt "Hey geht mal auf http://server/snom-0123456789AB.html !!! Da steht ja das Kennwort vom Heinz!!!! :))))). Ich leit' das gleich mal an den Sicherheitsbeauftragen weiter. Mal schauen, wie der das findet.", dann ist das für den Admin weniger witzig.


hehol schrieb:
Ansonsten kann ich mich nur microsaft anschließen ;-)

Ansonsten kann ich mich nur hehol anschließen ;-)


Gruß
Frank
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.