[Frage] Analyse der Firmware für die Fritz!Box 6360 - Mitstreiter gesucht

Ich finde leider kein passenderes Unterforum, ggf. bitte einfach dahin verschieben.

Nachdem ich innerhalb der letzten 3 Tage wiederholt auf extreme Sturheit beim KDG-Support gestoßen bin und mir - trotz Aussichtslosigkeit dieser Lösung bei meinem konkreten Problem - seitens KDG die Werkseinstellung (auch stur 3x) per Remote-Administration wiederhergestellt wurde, obwohl ich mir das ausdrücklich verbeten hatte, bin ich im Moment dabei, die Möglichkeiten des Fernzugriffs durch den KDG-Support etwas genauer unter die Lupe zu nehmen.

Es geht hier dabei nicht um die - meiner Meinung nach - fragwürdige Rechtslage und auch nicht um physische Eingriffe in die (bei den meisten sicherlich) gemietete Hardware (also JTAG-Anschluß bestücken und MTD auslesen o.ä. fällt aus).

Die Analyse soll ausschließlich durch Interpretation der von der Firmware preisgegebenen Informationen und - soweit möglich - Abklopfen der installierten Firmware auf Lücken erfolgen.

Solange das vom jeweiligen Mieter der Fritz!Box ausgeführt wird, sollten solchen Aktionen eigentlich keine gesetzlichen und/oder vertraglichen (jedenfalls habe ich in den KDG-AGB nichts entsprechendes gefunden) Regelungen entgegenstehen, da die Mietsache dabei ja nicht beschädigt wird (höchsten deren Ansehen bei den Kunden).

Ganz im Gegenteil, ausgehend vom Einsatz von Open Source Software auch auf der Fritz!Box 6360 müßte IMHO eigentlich AVM - oder sogar KDG, wenn sie eigene Veränderungen am Firmware-Image vornehmen - die für eine solche Analyse notwendigen Quellen von sich aus bereitstellen oder sie zumindest auf Verlangen zur Verfügung stellen (bei GPLv1/v2).

Die unter ftp://ftp.avm.de/develper/opensrc/fritzbox6360-source-files-05.29.tar.gz zu findende Version ist jedenfalls sowohl unvollständig (selbst wenn Teile z.B. unter BSD- und Apache-Lizenz nicht als Source veröffentlich werden müssen, ist das geforderte "Nachbauen" einer kompletten Firmware mit den veröffentlichten Teilen unmöglich) als auch nicht aktuell (LG Hamburg, Az. 308 O 10/13, noch nicht rechtskräftig).

Auch wenn ich bisher schon 2 von oder für Kabel Deutschland kastrierte Exemplare der Fritz!Box 6360 untersuchen konnte, ist es nur anhand der ermittelten Daten nicht sicher festzustellen, ob bestimmte Funktionen (bzw. laufende Prozesse) bereits in der von AVM erstellten Firmware vorhanden sind oder erst - auch wenn ich persönlich das eher bezweifele - vom jeweiligen OEM "dazugestrickt" wurden.

Daher suche ich dringend Mitstreiter, die über eine FB6360 eines anderen Anbieters (UM o. KBW) gebieten können und aber auch über grundlegende Kenntnisse (sowohl im Umgang mit Browser und Editor, als idealerweise auch mit der (Linux-)Kommandozeile) verfügen.

Ich möchte zwar die wirklich gesicherten Erkenntnisse dann mit jedem interessierten Leser teilen, aber andererseits will ich auch nicht einfach nur eine weitere Verschwörungstheorie über böse Provider in die Weltgeschichte setzen bzw. irgendeine Sau durchs Dorf treiben. Daher würde ich vorerst den Austausch weiterer Informationen per PN bevorzugen.

Soviel kann ich aber schon einmal feststellen und beweisen:

Es gibt auf der FB6360 (zumindest in der KDG-Version) ein - eher mehr als weniger verstecktes - "DOCSIS management interface", an das im laufenden Betrieb (bei mir !) ein Prozess gebunden ist, dessen Netzwerk-Bindings (UDP 161/162) und dessen Name (snmp_agent_cm in /usr/sbin) zumindest die Vermutung, es handele sich im einen SNMP-Agent (bitte als Anglizismus lesen, dann fehlt auch kein "en"), nicht unwahrscheinlich erscheinen lassen. Lieber immer schön vage formulieren ... :-(

Es mag ja sein, daß das Wissen um diesen SNMP-Zugang schon lange Allgemeingut ist. Ich finde jedenfalls bei einer Suche im Web keine wirklich konkreten Angaben dazu und war eigentlich eher erstaunt, daß nicht nur eine simple TR069-Konfiguration vom ACS möglich ist. So enthält z.B. auch eine über das UI gesicherte Konfiguration bei mir keinen Hinweis auf die für den SNMP-Zugriff notwendigen Firewall-Einstellungen o.ä..

Hier die netstat-Ausgabe, alles außer wartenden Prozessen von mir gelöscht ... eigentlich nichts außergewöhnliches für ein originales Fritz!OS - nur der vermutliche (sic) SNMP-Agent auf UDP 161/162 mit einem zusätzlichen Control-Socket ist auf anderen Modellen meines Wissens nicht vorhanden.

Welche Informationen über den SNMP-Stack nun wirklich zugänglich sind, ist noch nicht eindeutig feststellbar - ich habe jedenfalls bisher nur die "offizielle" DOCSIS-MIB (RFC2670) gefunden. Die Prozessliste und die Reihenfolge der PIDs läßt jedenfalls mit einiger Wahrscheinlichkeit auf eine Erweiterbarkeit eines "Basis"-Agents durch Plugins schließen.

Aber auch aus telefonischen Aussagen von KDG-Support-Mitarbeitern läßt sich verläßlich schließen, daß sensitive Informationen jenseits des DOCSIS-Interfaces zugänglich sind, mindestens die OIDs 1.3.6.1.2.1.1 und 1.3.6.1.2.1.2 sind offensichtlich vorhanden.

Leider verwechseln die KDG-Mitarbeiter die "sysUpTime" gerne mal mit der Aussage "Die Box ist solange schon online.", aber auch ein Zugriff auf das System-Protokoll der FB6360 ist mindestens teilweise (belegbar !) möglich.

Irgendwie muß schließlich ja auch eine "Fern-Einwirkung" realisiert sein (SNMP-SET ist hier sicherlich die logischste Vermutung), denn die Neustarts - ob mit oder ohne Default-Reset - durch KDG-2nd-Level bilde ich mir nicht nur ein.

Was mich jetzt nun aber doch mißtrauisch macht (abgesehen von meiner Wut über das ständige Werks-Reset) ist die Tatsache, daß bei einer Suche auf der AVM- und der KDG-Webpräsenz der Begriff "SNMP" genau gleich oft auftaucht ... es werden nämlich 0 (null) Ergebnisse geliefert.

Wenn der SNMP-Agent von AVM stammen sollte und sie damit auch wenigstens eine - schon oft vorgeschlagene und bei anderen Herstellern lange realisierte - Status-Abfrage (also nur SNMP-GET/GETNEXT) beim ambitionierten Kunden anbieten könnten, wäre das in meinen Augen durchaus ein weiteres werbewirksames Feature und ich kann mir im Moment nicht erklären, warum AVM darauf verzichten sollte. Auch eine Überprüfung durch den Kunden, welche Informationen der Provider über den SNMP-Agent erhält, wäre dann möglich (im Rahmen des Vertrauens auf eine 1:1-Umsetzung).

Dagegen spräche IMHO höchstens die Annahme, daß auch ein Mieter dann schon aus rechtlichen Gründen (Datenschutz, Haftung bei Mißbrauch über WLAN) auch bei einer gemieteten FB6360 dem Zugriff durch den Provider (jedenfalls jenseits der DOCSIS-Schnittstelle) einen Riegel vorschieben können muß, ähnlich wie der TR069-Konfiguration bei anderen Modellen.

Bevor ich aber nun doch noch - entgegen meiner ursprünglichen Absicht - weitere wilde Thesen absondere, würde ich viel lieber erst einmal versuchen, ("read only"-)Zugriff auf den SNMP-Agent zu erlangen und einfach mal die offerierten OIDs selbst abzugrasen. Ich gehe dabei eigentlich nicht von einem echten Zugriffsschutz für den Agent (ab v3) aus, da er ja eigentlich nur an das normalerweise unzugängliche wan0-Interface gebunden wird und gerade viele ältere OSS-Implementierungen (der Kernel meiner FB6360 zeigt immer noch die Version 2.6.28.10) nur SNMP bis v2c unterstützen.

Ein Vergleich, z.B. der laufenden Prozesse, bei verschiedenen Anbietern ist IMHO der erste notwendige Schritt, denn die Wahrscheinlichkeit einer identischen Software-Veränderung durch verschiedene OEMs dürfte gegen Null tendieren und erst dann kann man mit einiger Sicherheit die SNMP-Implementierung einem Verantwortlichen zuordnen und ggf. bei diesem dann dahingehend Druck machen, daß die vom Agent angebotenen OIDs (offizielle und private) und deren jeweilige Endpoints in der Firmware publiziert werden.

[Nix da, Novize]

Es ist mir zumindest schon mal reproduzierbar möglich, meine FB6360 bei Bedarf (ausschließlich durch Änderungen im UI) vor dem SNMP-Management durch KDG zu verstecken und sie trotzdem weiter für den Zugang ins Internet (und bei bereits vorhandener korrekter SIP-Konfiguration auch für Telefonie) zu nutzen.

Also, sollte sich jemand zur Mithilfe berufen fühlen, sollte er diesem Impuls unbedingt nachgeben. ;-)

Hallo Sascha,

SaschaBr schrieb:

Grundkenntnisse im Umgang mit Konsole und Editor sind vorhanden, wobei ich nicht weiß, was mir (bzw. Dir) das bei dieser Box (ohne Telnet) nutzen soll.
Aber wie schon gesagt: "Hacken" werde ich meine Box nicht.

Zum Vergrößern anklicken....

es geht, wie ich deutlich geschrieben habe, nicht um ein "Hacken" der Box. Es gibt immer noch einige Stellen in der Firmware (durch Vergleich z.B. mit den aktuellen FB7390-Quellen feststellbar), wo seitens AVM bzw. KDG nur die offensichtlichen Zugangswege über das UI ausgeblendet bzw. gesperrt wurden und wo über die Modifikation von Requests (daher der Browser und der Editor zur Bearbeitung von Ausgaben vor der Weitergabe an Dritte) ein Zugriff auf weitergehende Informationen möglich ist, für deren Interpretation dann wieder die Kommandozeilen-Kenntnisse hilfreich sind.

Ein derartiger Zugriff ist - gerne lasse ich mich hier von "Novize" korrigieren - meines Erachtens weder illegal noch ein Verstoß gegen (gültige !) Lizenzbedingungen; die alten Aussagen von AVM dazu wurden schon früher (jedenfalls bzgl. der Lizenzbedingungen vollumfänglich, erst recht bei nicht-kommerzieller Verwendung) vom LG Berlin (Az. 16 O 10/10 und das sollte rechtskräftig sein) für ungültig erklärt, nur AVM's Markenanspruch hat das damalige Verfahren halbwegs überstanden und zu einen Teilerfolg für AVM geführt (vereinfacht dargestellt).

Ansonsten würde ich gerne zu PN übergehen ...

Kurzes Update:

Ich hatte schon am 16.07. per Fax (!) eine Anfrage bei KDG zu den - meiner Meinung nach nicht klar kommunizierten oder vertraglich geregelten - Zugriffsmöglichkeiten für den Anbieter (gleichzeitig auch Eigentümer der von mir gemieteten Fritz!Box 6360) gestellt, heute (10 Tage später) kam dann eine E-Mail mit folgendem Text (Auszug):

Betreff: Ihr Anliegen vom 16.07.2013

Sehr geehrter Herr XXX,
als Konzerndatenschutzbeauftragter von Kabel Deutschland bestätige ich Ihnen hiermit den Eingang Ihres Anliegens. Zur Bearbeitung und schriftlichen Rückmeldung benötigen wir 3 - 4 Wochen, wobei wir stets bemüht sind auch kurzfristiger zu reagieren. Bitte sehen Sie in dieser Zeit von Rückfragen ab.
Ich bitte um Ihre Geduld und bedanke mich für Ihr Verständnis.
Mit freundlichen Grüßen
(Unterschrift)

Zum Vergrößern anklicken....

Wenn es also noch 3-4 Wochen dauert, bis KDG wirklich mit belastbaren Aussagen antwortet, würde ich in dieser Zeit gerne nach weiteren Informationen - ich betone es gerne noch einmal: auf legalem Weg - suchen, denn nur die so gewonnenen Erkenntnisse kann man dann auch verwenden, um die Aussagen seitens des Providers (wenn sie denn nicht stimmig oder vollständig sein sollten, wovon ich nach anderen einschlägigen Erfahrungen leider erst einmal ausgehe) zu widerlegen oder eben auch zu überprüfen und zu bestätigen.

Bei UM scheint der von mir beschriebene mutmaßliche SNMP-Agent schon einmal nicht vorhanden zu sein oder nicht verwendet zu werden (bisher leider nur eine einzelne Rückmeldung), für KBW fehlt noch eine Vergleichsmöglichkeit.

Sollte sich also noch ein KBW-Kunde mit einer 6360 finden, wäre ich echt dankbar ... es geht definitiv nicht darum, die Firmware selbst irgendwie auszulesen oder zu verändern, vielleicht habe ich mich da im ersten Posting mißverständlich ausgedrückt.

Man kann die OEM-spezifischen Bestandteile der Firmware und ggf. deren Verwendung auch nur anhand von Daten, die die Fritz!Box freiwillig herausrückt, identifizieren, indem man diese Daten für verschiedene OEMs vergleicht.

Ich weiß ja nicht, wie es anderen Kunden von KDG geht, aber in meinem Vertrag und den dazugehörigen AGB steht nichts von "SNMP-Zugriff" für den Provider und weder die Internetseiten von AVM noch von KDG spucken bei einer Suche nach "SNMP" irgendetwas aus. Das finde ich dann schon ziemlich seltsam ...

KunterBunter schrieb:

Genau das will er ja nun gerade nicht.

Zum Vergrößern anklicken....

Ok, ich sehe ein, daß "Geheimniskrämerei" nichts nutzt oder einen falschen Eindruck erweckt.

Ich wollte nur AVM (oder die Kabel-Anbieter, ich weiß ja immer noch nicht, ob es da noch ein Customizing beim Provider gibt) nicht mit der Nase darauf stoßen, daß sie vielleicht doch nur vergessen haben, den Zugriff auf die Support-Daten zu blockieren. Keine Ahnung, ob von denen jemand IPPF liest, bei AVM bin ich mir aber eigentlich (fast) sicher.

Genauso gut kann es natürlich auch sein, daß gerade AVM auf Erreichbarkeit dieser Seite in der FB6360 besteht, denn sie machen wohl auch für DOCSIS-Boxen den Kundensupport, jedenfalls behauptet KDG das.

Wenn man sich dann einmal diese Ausgabe in Ruhe zu Gemüte führt, stehen da schon lustige Informationen drin, die KDG meiner Meinung nach dem Kunden gar nicht in die Hand geben würde. Das DOCSIS-Management-Interface gehört meines Erachtens dazu.

Es existiert zwar ein offizielles RFC für die DOCSIS-SNMP-MIB, aber - mein bisheriger Stand - nicht alle Provider verwenden auch wirklich SNMP zum Management und wie weit die Möglichkeiten dort gehen, hängt nun einmal nur von der Implementierung des Agents ab, denkbar und machbar ist da praktisch der Zugriff auf alles.

Und ein schnell nachgeschobenes Firmware-Update, das z.B. eine zusätzliche Sicherung beim Aufruf von support.lua oder beim Ausführen von bin/supportdata einbaut, kann ich im Moment eigentlich nicht gebrauchen. Andererseits ist ein nachträgliches Verriegeln durch ein Firmware-Update auch nicht mehr tragisch, wenn erst einmal genug Daten von mehreren Providern zum Vergleich vorliegen. Andere Provider sind aber wohl auch nicht so paranoid (beim Einschränken des GUI) wie KDG, bei KDG färbt das dann auch auf Kunden wie mich ab.

Daß aber auch AVM nicht jeden denkbaren Fall voraussehen kann (die KDG-Truppenteile offenbar schon gar nicht, die haben da meiner Meinung nach erst recht keinen Plan), merkt man spätestens dann, wenn mal eine FB6360 seitens des Providers ausgetauscht wird und man die unmittelbar vorher gesicherte Konfiguration wieder in die neue Box einspielen will. Insofern ist auch ein "Vergessen" der Support-Daten beim Verkrüppeln des UI nicht unwahrscheinlich.

Vielleicht OT, aber als Erklärung meiner Vermutung und als Erfahrungsbericht, ansonsten einfach weiter unten suchen:
Das Restore funktioniert natürlich erst dann, wenn man solange gewartet hat, bis das automatische Firmware-Update auf die aktuelle Version erfolgt ist. Die Sicherung vor dem Austausch läßt sich nur in eine Firmware vom selben (oder einem späteren) Stand wieder einspielen. Bei der telefonischen Aufforderung an KDG, ein Update über die Management-Schnittstelle zu forcieren, erntet man nur offene Münder und Nachfragen (für den Kunden heißt das dann Warteschleife) und am Schluß die Auskunft, man müsse eben warten, bis das von alleine stattfindet; der Support kann da gar nichts machen.
Im Angesicht der sicherlich alltäglichen Prozedur des Austauschs einer FB6360 beim Kunden ist der KDG-Support dann bei der Ansage: "Ich habe einfach nur meine alte Konfiguration wiederhergestellt." offenbar so richtig überrascht, daß überhaupt jemand auf die Idee kommt, nach einer (sagen wir mal 45-minütigen) Konfigurationsorgie seine eigenen Einstellungen sichern zu wollen und diese dann zu allem Überfluß auch noch einfach so wiederherzustellen. Daß genau dieses "Versprechen" beim Sichern der Konfiguration angezeigt wird, weiß offenbar niemand bei KDG (zumindest nicht im 1st-Level-Support).
Wie auch immer, offenbar werden beim Wiederherstellen auch die SIP-Accounts übernommen und da ist wohl irgendwie die ID (MAC-Adresse intern) der Box in den Kontodaten verwurstet. Jedenfalls funktionieren nach dem Wiederherstellen die SIP-Accounts nicht mehr und der Support weiß sich eben nicht anders zu helfen, als einfach immer wieder die Werkseinstellung wiederherzustellen und dann funktioniert die Autokonfiguration ja auch.
Damit geht dann die Telefonie wieder genau so lange, bis man seine eigenen Einstellungen wiederherstellt.
Auch wenn es sicherlich stur vom Kunden ist: Bei der Sicherung steht ausdrücklich folgendes:

Hier können Sie alle Einstellungen, die Sie in der FRITZ!Box vorgenommen haben, in einer Sicherungsdatei speichern.
Die Einstellungen können in dieser FRITZ!Box oder in einer FRITZ!Box des gleichen Typs vollständig wiederhergestellt werden. In eine FRITZ!Box anderen Typs können ausgewählte Einstellungen aus der Sicherungsdatei übernommen werden.

Zum Vergrößern anklicken....

Wenn dann der KDG-Support mir sagt, mit der Werkseinstellung funktioniert es ja und wenn ich meine eigene Konfiguration wiederherstelle bin ich schließlich selbst schuld, ist das meines Erachtens der pure Hohn. Ich könne ja auch meine Einstellungen einfach noch einmal einzeln vornehmen ...
Selbst wenn ich es könnte, sagen wir mal Oma Kasulske oder auch ein beliebiger Small Business-Kunde (z.B. meine Autowerkstatt) kann das nicht ohne weiteres und muß u.U. richtig in die Tasche greifen, um die Arbeiten zu bezahlen. Da sollte KDG, wenn sie schon dem Kunden alles haarklein selbst konfigurieren wollen, dann auch die denkbaren Fälle in die Überlegungen einbeziehen und so exotisch dürfte der Tausch einer FB6360 ja nun wirklich auch bei KDG nicht sein. Jedenfalls kann man mit einer eigenen Sicherungsdatei aus einer ausgetauschten FB6360 die ganze Autokonfiguration (und die diversen Verriegelungen in der Firmware) bei KDG herrlich ad absurdum führen.

Ende OT

Also, dann mal Klartext:
Der Abruf der Support-Daten erfolgt wie bei jedem anderen Modell ganz normal über fritz.box/support.lua - bitte alle Dateien aufheben, da einige Flash-Files (z.B. crash.log und panic) nach dem Auslesen gelöscht werden und erst beim nächsten Fehler wieder mit sinnvollen Daten gefüllt werden.

Auch mit direkten Aufrufen von query.lua (Anleitung am Anfang der Lua-Quelle - z.B. für 7390 - im Kommentar) lassen sich einer FB6360 weitere Informationen entlocken, die im UI entweder gar nicht vorgesehen sind (auch bei anderen Modellen nicht) oder von/für KDG (andere OEMs kenne ich nicht) entfernt wurden. Für mögliche Abfragen findet man im Fritz!Box-Wiki oder bei einer Internetsuche umfangreiche Tipps, die aber nicht alle auf der 6360 implementiert sind.

Für das Setzen von Einstellungen (das meinte ich oben mit "Abklopfen auf Lücken") habe ich noch keine allgemeine Lösung, um einen beliebigen cmtable-Eintrag zu basteln. Auf anderen Modellen ist das dank Telnet ja auch nicht notwendig, da gibt es ctlmgr_ctl.

Für spezielle Einstellungen (soweit es dafür keine "offizielle" Stelle in der eigenen 6360 gibt) kann man auch einfach mal eine Suche nach "cmtable.add_var" über die Lua-Sources (wieder von der 7390) laufen lassen. Findet man dann dort ein Script, das die gesuchte Einstellung setzen könnte, muß man einfach nachschauen, ob erstens das Script auf der 6360 überhaupt vorhanden ist und wenn das der Fall ist, ob auch überall ordentlich geprüft wird, ob diese Einstellung auf dieser Box auch gesetzt werden soll. Diese Prüfung findet definitiv nicht immer korrekt statt und dann kann man durch einen "händischen" Request versuchen, diese Einstellung zu manipulieren.

So sind durch "Basteln" einer eigenen URL z.B. die Seiten "/internet/docsis_stats.lua" (MSE-Grafik) und "/internet/docsis_log.lua" (was wohl, halt das DOCSIS-Log) erreichbar, obwohl sie offiziell im (KDG-)Interface ausgeblendet sind (gültige sid ist selbstverständlich).
Unter "/internet/lanbridges.lua" kann man LAN2-4 bridgen - zumindest merkt die Box sich die gesetzten Checkmarks, ob auch wirklich gebridged wird, habe ich nicht getestet.
Die Änderung von "var:allowSipName=disabled" auf "enabled" am Ende der URL für die Seite zum Editieren des Namens einer SIP-Nummer bringt zumindest auch bei KDG mal eine erweiterte Edit-Seite zur Anzeige, auch wenn mir dort das Ändern von Daten auf die Schnelle nicht gelungen ist.

So gibt es definitiv noch weitere Seiten in der Firmware, die durch einfache Änderung des Seitennamens oder durch Modifikation von Parametern auch jenseits der Verriegelung für KDG funktionieren.
Eigentlich müßte man sich mal die Zeit nehmen und das Fritz!Box-Wiki im Hinblick auf die 6360 ergänzen. Ein erster Schritt wäre ja z.B. das Feststellen OEM-spezifischer Besonderheiten. ;-)

Normalerweise sind das auch alles Binsenweisheiten und für andere Modelle sind diese Möglichkeiten lange bekannt. Die "verriegelten" Boxen stellen aber eben wieder eine Herausforderung dar (so wie frühere Modelle, als der Telnet-Zugang noch das "Pseudo-Update" erforderte) und da muß wohl vieles erneut getestet und die Erkenntnisse dann mühsam zusammengetragen werden.

Offensichtlich wurden auch gerade im Zuge der erweiterten Benutzerverwaltung (seit 05.50 auf der FB6360, wenn ich mich nicht irre) einige Stellen besser gesichert oder es ist mir vorher bloß nie aufgefallen, daß inzwischen sogar schon der ftpd im Kontext des angemeldeten FTP-Benutzers läuft, aber es gab ja vorher eigentlich auch nur den ftpuser.

Was in den Support-Daten alles enthalten ist oder sein könnte, kann man sich anhand des Scripts "/bin/supportdata" von einem anderen Modell (z.B. wieder der 7390, da ist eben die Labor-Version fast immer die neueste) zusammenreimen, da scheint AVM die Entwicklung nur einmal machen zu wollen.
Auch wenn der Abruf der kompletten Support-Daten natürlich Overkill ist, wenn man es ein einfaches "ps w" oder "netstat -a" auch tun würde, kann man doch support.lua als eine Art "Behelfskonsole" mit starren Befehlsablauf benutzen, wenn denn die auszuführenden Befehle irgendwo im Zuge der Verarbeitung von /bin/supportdata (oder der Erweiterungen) mit abgespult werden. Einen nachteiligen Effekt des Abrufs der Support-Daten (z.B. Restarts von Interfaces, o.ä.) habe ich bei mir nicht beobachten können.

In den 7390-Dateien findet man in capture.lua (ab Zeile 14, keine Ahnung, ob ich die hier zitieren dürfte) dann auch eine Sonderbehandlung für DOCSIS-Boxen, wenn der OEM=kdg ist. Damit dürfte auch klar sein, daß AVM um die Existenz des "DOCSIS management"-Interfaces weiß (denn das erhält dann noch einmal eine Sonderbehandlung) und dann würde ich die Urheberschaft für snmp_agent_cm auch eher den AVM-Leuten zutrauen.

Gerade auch die Ausgabe von capture.lua (also der HTML-Text, keine Capture-Dateien) auf DOCSIS-Boxen von UM und KBW wäre interessant, auf KDG-Boxen ist durch die o.a. Abfrage in der Lua-Source jedes Capture auf der WAN-Seite unterbunden. Meine Versuche, durch manipulierte Start-/Stop-Requests (s. Javascript in der Seite) für das Capture auch den Verkehr auf dem DOCSIS-Management-Interface einzufangen, waren bisher nicht von Erfolg gekrönt, da enthält das verwendete Binary (capture_notimeout) dann wohl doch eigene Tests.

Wenn bei UM oder KBW das Capture auf WAN-Seite möglich ist, freut mich das für alle Kunden dieser Provider. KDG-Kunden können so etwas aber ohnehin nicht gebrauchen. :-( Leider kann man sich den lokalen Kabelbetreiber nun mal nicht aussuchen ...

Wenn dann bei UM und KBW auch im JSON-Query-Log (im Source der HTML-Seite nach "logqueries" suchen) in der Liste der Interfaces das DOCSIS-Management nicht auftaucht (bei mir ist es das 17. Interface - minor=3000, type=30), dann existiert es wohl auf diesen Boxen wirklich nicht, da nach meinen Erfahrungen der aktuelle Status des Interfaces für die Aufnahme in die Liste keine Rolle spielt (es sind ja auch alle möglichen WLAN-Interfaces aufgeführt, die können nicht gleichzeitig aktiv sein). Wenn es doch auftaucht, wird es wahrscheinlich nur nicht verwendet.

Das DOCSIS-Management-Interface sieht in JSON bei mir so aus:

Wichtig: Es kann natürlich jeder seine eigenen Support-Daten auslesen. Bei mir fallen dabei aber regelmäßig mind. 250 KByte an (je nach uptime) und ich hoffe mal, daß niemand auf die Idee kommt, seine Datei dann hier komplett zu posten. Auch deshalb (ich würde fast wetten, es passiert trotz meines Hinweises ) wollte ich eigentlich PN oder besser noch E-Mail nutzen. Auch wenn man die Datei als Anhang hochlädt: Wer nicht weiß, wo er Daten maskieren sollte, gibt schnell mehr preis, als er eigentlich wollte.

Besser ist es also, wirklich immer nur 3-4 Zeilen vor und hinter einer interessanten Stelle hier mit einzubeziehen; außer man weiß genau, welche Daten zusammengehören und für den Kontext benötigt werden.

Bei KBW-Kunden wäre es im Moment sehr interessant zu erfahren, ob außer in diesen Zeilen
der Begriff "SNMP" (Groß-/Kleinschreibung egal) noch an anderen Stellen in den Support-Daten auftaucht. Bei KDG-Boxen (da taucht SNMP mehrfach auf) stellt sich dann natürlich die Frage, was verbirgt sich hinter den Indizes 0-2 (SNMP fängt meines Wissens immer mit 0 als Index an) und wie weit gehen die Indizes jenseits des Upstream-Interfaces ?

Zu meinen Versuchen, den SNMP-Agent aus dem LAN zu erreichen ... wenn es wirklich jemanden interessiert:
Der SNMP-Agent hat offenbar ein ähnliches Problem wie der ctlmgr, er kann die Interfaces wohl nicht richtig auseinanderhalten, wenn er auf eine unerwartete Konfiguration (z.B. die DOCSIS-Management-IP auf dem LAN-Interface, was vielleicht nur bei KDG funktioniert) trifft.

Allerdings kommen dann auch noch einige andere Programme durcheinander und die Box ist LAN-seitig nur noch unter der IP 169.254.1.1 zu erreichen. Internet und Telefonie (also der DHCP-Client) funktioniert aber offenbar genauso weiter und auch das Routing, wenn man denn die Box unter 169.254.1.1 anspricht.

Achtung: Da es an der 6360 aber keinen Reset-Taster mehr gibt, kann das dann auch schnell ein Fall für den Kundendienst werden, denn der SNMP-Zugriff von der KDG-Seite funktioniert wahrscheinlich nicht mehr.

Wenn das jetzt einige Leute probieren und sich hinterher beim AVM-Support ausheulen, werden die sicherlich in der nächsten offiziellen Release bei der LAN-Konfiguration besser aufpassen, also bitte nicht nachmachen ! Vielleicht liest AVM ja doch nicht mit hier bzw. nicht gerade diesen Thread.

Ob das KDG-SNMP-Management noch funktioniert ist ja schwer definitiv festzustellen, ich kann schlecht beim Support anrufen und fragen, ob sie meine Box noch sehen.

In jedem Falle sollte man vor Experimenten mit der LAN-Adresse wissen, wie man an die LL-Adresse kommt und seine Box LAN-seitig wieder einnordet oder notfalls auf Werkseinstellungen setzt.

Die bei der o.a. Konfiguration teilweise ausgelesenen Support-Daten lassen aber darauf schließen, daß das später startende DOCSIS-Interface einerseits die Management-Adresse nicht mehr setzen kann (doppelt) und andererseits auch die notwendige Route für 10.x dann nicht mehr angenommen wird. Dadurch findet die Box zumindest die Autokonfigurationsserver nicht mehr (die liegen wohl auch im 10.x-Netz), so steht es dann jedenfalls im Event-Log.

Ich habe bisher leider auch nur eine unvollständige Support-Datei einer "ausgeblendeten" FB6360, im Moment brauche ich den KDG-Zugang - auch für den KDG-Support, selbst wenn die sich nur immer wieder mit einem Werksreset zu helfen wissen - und kann nicht weiter mit der Box herumspielen.
Andererseits ist am WE sicherlich nicht mit einer Reaktion des 3rd-Level-Supports zu rechnen und ich probiere vieleicht doch noch ein wenig herum, schau'n wir mal.

Schönen Samstag (falls das hier wirklich noch jemand liest)

Hi,

Chatty schrieb:

Ich würde gern eigene Programme [...] auf der FB laufen lassen

Zum Vergrößern anklicken....

Bei allem Verständnis für diesen Wunsch: Ich bin mir sicher, daß es jedem interessierten Kunden möglich war, sich vor dem Abschluß eines Vertrags über die Miete einer FB6360 darüber kundig zu machen, daß eine Modifikation der Software der Box nicht vorgesehen ist. Das wäre auch eine Veränderung der Mietsache, die dem Mieter nicht erlaubt ist. Ebensowenig, wie dem Vermieter (solange vertraglich nichts anderes vereinbart wurde) die Veränderung des Mietgegenstandes während er vermietet ist gestattet werden muß (Stichwort Firmware-Update und/oder Werksreset).

Bei Deinem Problem mußt Du wohl die zusätzlichen Programme auf Deiner 7270 laufen lassen müssen. Eine derartige Modifikation der Firmware einer FB6360 wäre m.E. auch nicht sinnvoll (siehe hier, das kann man nur unterstreichen).

den neuen Repeatermodus nutzen können

Zum Vergrößern anklicken....

Sagt mir nichts, was ist der "neue" Repeatermodus ?

Bei mir wurde bisher kein unabgesprochener Werksreset durchgeführt [...]

Zum Vergrößern anklicken....

Ich bin mir nicht einmal sicher, ob UM diese Möglichkeit überhaupt hat und/oder nutzt.

Mir wurde vom KDG-Support einer als "erster Schritt" vorgeschlagen, den ich heftig abgelehnt habe.
Dieser Vorschlag führte (am 08.07.) aber auch bei mir erst zu der klaren Erkenntnis, daß mein Provider ohne mein Einverständnis Daten auch jenseits der DOCSIS-Schnittstelle auslesen kann und - wenn ihm danach ist - auch Einstellungen oder Betriebszustände ändern kann. Daraufhin habe ich ihm das per Fax ausdrücklich (mit umfangreicher Begründung) untersagt.
Das hat - nach dem Austausch der inzwischen dann doch als defekt angenommenen alten Box - ihn trotzdem nicht davon abhalten können, mir bisher dreimal die neue Box aus der Ferne ohne mein Einverständnis (ja sogar gegen den bei jedem Kontakt - telefonisch oder schriftlich - ausdrücklich bekräftigten Willen) komplett zurückzusetzen.

Beim ersten Rücksetzen war ich nicht einmal anwesend (das war erst 4,5 Stunden nach meinem Anruf beim Support) und habe den Schaden erst festgestellt, als die Amok laufende 6360 mein Netz schon 7 Stunden durcheinander gewirbelt hatte.

Ich habe daraus zwar gelernt und sie besser abgeschottet, aber das konnte KDG nicht wissen und so sehe ich die nächsten zwei Resets (wieder Werkseinstellung, obwohl erneut telefonisch abgelehnt) schon als ernstes Problem. Ich wünsche mir inzwischen eher wieder ein Kabel-Modem und meine eigene FB7390 (war vorher eine 7270v1, die war etwas zu schwachbrüstig) dahinter, da wußte ich wenigstens, wer darauf zugreifen darf.

lohnt es, dafür Zeit zu investieren?

Zum Vergrößern anklicken....

Meine Position: Eindeutig ja.

Wenn man sich einmal vor Augen führt, was bei einer Standard-Konfiguration einer 6360 für Lücken in ein gesichertes Netzwerk gerissen werden oder was dem Kunden dabei an Aufwand aufgebürdet wird, versteht man diesen Standpunkt vielleicht.

1. In Standardkonfiguration ist das Web-Interface der Box vollkommen offen, der erste Aufrufer kann alle Einstellungen vornehmen.

2. WLAN ist (in meinen Augen unnötigerweise) aktiviert, obwohl der einrichtende Benutzer durch einfaches Drücken des WLAN-Knopfes das auch erst bei Bedarf zuschalten könnte.

3. Zu allem Überfluß wird auch noch der komplette Verkehr zwischen den 4 LAN-Anschlüssen und dem WLAN gebrückt (Bridge), damit steht einem erfolgreichen Angreifer über das WLAN auch das gesamte LAN offen. Für die erste Konfiguration wäre diese Bridge nicht notwendig.

4. Für die Sicherheit des Standard-WLAN-PSK übernimmt auch AVM keine Gewähr, man wird sogar ausdrücklich aufgefordert, ein eigenes sicheres WLAN-Kennwort zu vergeben. Das wird beim Reset auch gelöscht.

5. Geräte, die per WLAN mit der vom Kunden selbst vergebene SSID kommunizieren sollen (Smartphones, Tablets, etc. - meine haben jedenfalls keinen Ethernet-Anschluß), finden das WLAN nicht mehr und sind damit abgeschnitten.

6. Absprachen mit den Nachbarn über die Aufteilung der verfügbaren WLAN-Kanäle werden nicht berücksichtigt (Wie sollte die Box davon auch wissen ?) und der Ärger ist vorprogrammiert (das kann auch ein "Sicherheitsproblem" sein ).

7. Die Box behauptet in der Standard-Konfiguration tollkühn, der "authoritative" DHCP-Server für das Netzwerk zu sein und liefert - bei mir sinnfreie - IP-Einstellungen an die Clients aus. Mir ist kein aktuelles (gebräuchliches) BS bekannt, das für eine Erstkonfiguration der FB eine Vergabe von Adressen per DHCP erforderlich macht. Heutzutage ist Zeroconf oder APIPA oder wie man es auch immer nennen will, erst recht bei (notfalls vorläufiger) Verwendung von IPv6 auf der LAN-Seite der Box (da ist die Autokonfiguration noch ausgefeilter), vollkommen ausreichend. Ich würde sogar behaupten, daß jede aktuelle Fritz!OS-Version die Adresse 169.254.1.1 (leider meines Wissens aber ohne Prüfung auf Kollisionen, das macht bei 2 Boxen dann richtig Spaß, die richtige zu erwischen, da hilft nur ein ARP-Eintrag) auf der LAN-Seite fest verdrahtet hat.

8. Dank dieser DHCP-Einstellungen wird die Box dann als DNS-Server und Standard-Gateway auf den Clients registriert, damit erhält sie (und auch der Provider über den Zwangs-DNS) Kenntnis von internen Informationen wie z.B. DNS-Abfragen und es wird auch der Internet-Verkehr, der eigentlich auf anderem Wege oder auch über den KDG-Anschluß, dann aber in einem OpenVPN- oder IPSec-Tunnel, geleitet werden sollte, im Klartext über das KDG-Netz übertragen. Damit sind praktisch alle Benutzernamen/Kennwörter "verbrannt", wenn davon z.B. auch ein administrativer Benutzer betroffen ist, der auf den noch unverschlüsselten Verkehr im LAN zugreifen darf.

9. Rufumleitungen, -sperren, Anrufbeantworter, usw. - eigentlich alles außer den "Eigenen Rufnummern" im Telefonie-Bereich wird ignoriert.

10. Die angeschlossenen USB-Datenträger sind per FTP ohne Zugriffbeschränkungen, glücklicherweise nur im LAN, zugänglich. Warum der FTP-Server überhaupt laufen muß, ist mir vollkommen unklar.

11. Vom Benutzer konfigurierte Einstellungen für den Push-Service (um selbst ein lückenloses Protokoll zu haben, falls man mal in Beweisnot gerät) werden beim Rücksetzen durch KDG ohne Not ignoriert, ein Versand einer Push-Mail mit dem Hinweis auf das ausgelöste Rücksetzen und den üblichen Angaben seit der letzten Mail, ist meines Erachtens das Mindeste, was man erwarten darf.

12. Dank falscher LAN-Adressen (192.168.178.x) spielte mein IPS auch verrückt (eigentlich machte es aber nur seinen Job) und nahm den Rest des Netzes Stück für Stück durch Herunterfahren aus der Schußlinie, damit aber leider auch außer Betrieb.

Mir fallen sicherlich noch weitere Punkte ein, aber ich denke, es ist auch so deutlich geworden, daß die - sicherlich von einer Mehrheit der Kunden begrüßte - Möglichkeit des Eingriffs (nicht vertraglich vereinbart, das habe ich vorher geprüft, ich lese AGB bei solchen Verträgen wirklich) durch den Provider nicht immer gewünscht ist und dann muß auch ein solcher Fall in den Support-Richtlinien berücksichtigt werden.

Abgesehen davon werde ich nun einmal "wild", wenn mir einfach jemand in mein Netzwerk hineinpfuscht ... auch ohne PRISM und andere "Neuigkeiten" sichere ich meine Infrastruktur schon lange im Rahmen meiner Möglichkeiten.
Neben rein privaten Zwecken benutze ich mein Netz eben auch geschäftlich (daher auch T-DSL-Business) und da habe ich leider durch KDG wieder einmal lernen müssen, daß Murphy's Gesetz immer noch gilt.

Beim derzeitigen Stand der Dinge ist jedenfalls der (nicht zusätzlich abgeschottete) Einbau einer FB6360 in ein auch geschäftlich genutztes Netzwerk so ziemlich das Dümmste, was man machen kann. Daher ist das Angebot von KDG für "Internet & Telefon Business 32 / 100" "inkl. HomeBox Fritz!Box 6360" gratis in meinen Augen die reine Veralberung/Täuschung der Kunden. :verdaech:

Selbst wenn man KDG keine Absicht unterstellt (ich glaube, die sind sich des Problems gar nicht bewußt), ist ein derartiger Umgang mit der (Daten-)Sicherheit von Kunden - egal ob Privat- oder Business-Kunden - meines Erachtens nicht zu tolerieren. Alle Welt regt sich völlig zu Recht über die Geheimdienste auf ... wenn aber der eigene Provider im lokalen Netz faktisch alles machen könnte (ich finde meinen Denkfehler hier immer noch nicht), sollte man auf den Hrn. Friedrich hören :-( - explizit nur in dieser eng begrenzten Frage - und sich auch selbst um die eigene Datensicherheit kümmern.

Just my 2 cents ...

Da das jetzt aber immer mehr OT ist, sollten wir den Thread vielleicht doch umbenennen ([sarkasmus]dann aber bitte auch gleich reißerisch genug, so nach dem Motto "Backdoor in der Firmware für die Fritz!Box 6360 bei Kunden von Kabel Deutschland ?!" [/sarkasmus]) und ihn ggf. in ein anderes Unterforum verschieben lassen. Ich kann leider meist bei diesem Thema nicht an mich halten und kurz ist schon gar nicht möglich. Sorry.

Nachtrag zum eigentlichen Thema (Was geht bei FB6360 ?):

Auf meiner KDG-Box (s.u.) ist die Seite

http://fritz.box/internet/providerservices.lua?sid=(gültige sid hier einfügen)

vorhanden.
Selbst wenn die dort vorgenommenen Einstellungen ignoriert werden, ist über "Automatisches einrichten" (so steht es auf dem Button) die Lösung meines Problems "Erneuern der KDG-SIP-Konfiguration nach Restore meiner eigenen Einstellungen" möglich geworden.
Die Box hat sich nach einem Neustart - mit Beibehalten meiner eigenen Einstellungen - beim Provider die neuen SIP-Einstellungen per TR069 abgeholt und die falschen Einstellungen damit überschrieben.
Damit ist dieses Problem erledigt; warum der KDG-Support da nicht helfen konnte, ist mir immer noch ein Rätsel.

Es ist dann auch gleich noch möglich, die vom Provider angebotenen (um nicht zu sagen: festgelegten) DNS-Server gegen einen oder zwei eigene Server auszutauschen.
Sei es wegen einer DNS-Sperre oder weil man wie ich der Meinung ist, daß sich die Schlapphüte die Daten gefälligst aus dem kompletten Verkehr ausfiltern sollen (wenn der nicht verschlüsselt ist) und daß ich meinem Provider die Hinweise auf kontaktierte Internet-Adressen - heutzutage sagt man wohl "Metadaten" dazu - nicht auch noch auf dem berühmten Silbertablett servieren muß.
Unter

http://fritz.box/internet/dns_server_enh.lua?sid=(s.o.)

kann man seine eigenen Server zu setzen. Bei mir haben diese Einstellungen auch den Restart der FB6360 überlebt und wurden durch das Provider-seitige DHCP nicht überschrieben. Ob irgendwann im Laufe des Betriebs die KDG-Server wieder eingetragen werden, kann ich mangels vergangener Zeit seit meiner Aktion noch nicht sagen. Mir fällt aber auch kein Grund ein, wieso das ohne Not geschehen sollte.

informerex schrieb:

alle bisherigen Links sind bei mir auch so über die WebGUI erreichbar (also nicht versteckt).

Zum Vergrößern anklicken....

Daraus - und aus Deiner Signatur - schließe ich dann glatt, daß Du nicht Kunde bei Kabel Deutschland bist. Ich habe nur meine bei KDG gemietete Box zum Testen (und die Experten-Ansicht ist eingeschaltet ! ;-) ), daher auch mein Aufruf. Inzwischen würde ich auch davon ausgehen, daß das UI bei KDG am heftigsten eingeschränkt wird.

Da Du der erste KBW-Kunde hier im Thread bist, stelle ich Dir einfach noch einmal die Frage nach dem "SNMP" in den Supportdaten. Wäre schön, wenn Du dazu etwas sagen könntest ...

Inzwischen ist mir aber auch bekannt, daß selbst bei KDG-Boxen der "offizielle" Zugang zu den Support-Daten - über "Inhalt" unten auf der Startseite und dann "FRITZ!Box Support" unten links - vorhanden ist (ich würde schwören, daß das in früheren Fritz!OS-Versionen auch leichter zu finden war) und damit die Theorie vom "vergessenen" Zugang wohl doch nur meinem Mißtrauen (das sich eigentlich gegen KDG und nicht gegen AVM richtet) zugeschrieben werden muß.

informerex schrieb:

neben SNMP-Pfaden/Dateien kommt nachstehendes:

Zum Vergrößern anklicken....

Danke, ich war wohl nicht präzise genug und hatte vergessen, daß es in der voip.cfg (auch wenn man seine Einstellungen sichert) pro SIP-Nummer einen Eintrag "snmp_instance = x;" gibt (x ist m.W. immer 0).
Die anderen Zeilen mit "SNMP" (SNMP-Index 3 für Downstream-If und 4 für Upstream) sind ja die schon von mir zitierten.

Läuft auf KBW-Boxen auch ein Prozess "snmp_agent_cm" der, wie z.B. hier:


auf einem WAN-seitigen Interface auf Abfragen / Befehle wartet ?

Gibt es dort auch einen Prozess "eventmgr_cm" an "UDP 0.0.0.0:3000" ? Bei UM ist er wohl vorhanden.

Bei KDG eigentlich auch, da ist er aber nicht an einen UDP-Port gebunden, nur an einen Unix-Socket.

Meine Interpretation wäre da, daß bei UM/KBW das Event-Log auch per Zugriff auf Port 3000 (z.B. mit 'echo "irgendeine Nachricht" | nc -u fritz.box 3000' ... nc.exe gibt es auch für Windows, wird aber oft von AV-Software zu Unrecht beschimpft/verdächtigt) möglich sein könnte. Bei KDG hingegen (wie bei UM/KBW wahrscheinlich auch zusätzlich) ist es über den Socket zugänglich, bei UM soll der Socket jedenfalls auch vorhanden sein. Wird aber ein spezielles Binärformat für die UDP-Datagramme seitens eventmgr_cm erwartet, ist sicherlich auch ein Schreiben mit netcat nicht erfolgreich.

So langsam nimmt das in meinen Augen doch Form an ...
Nach Internetsuche ist bei Fritz!Boxen der Prozess 'eventmgr_cm' nur bei den DOCSIS-Modellen vorhanden.
Allerdings gibt es wohl einen Prozess gleichen Namens auch auf anderen DOCSIS-Geräten, insofern kann er auch zum Software-Umfang des Puma5 von TI gehören.
Dann wäre es aber gerade interessant herauszufinden, was denn dort (abseits von dem, was in docsis_info.lua angezeigt wird) so protokolliert wird.
Gut möglich, daß die komplette Protokollierung bei AVM-DOCSIS-Boxen dann eben über die zum Puma5 gehörende Software läuft (das was sonst .ar7events, eventadd, eventsdump, usw. erledigen).

Ich denke inzwischen, daß da doch sehr weite Teile des Referenz-Designs von AVM übernommen wurden, so wohl auch der SNMP-Stack, das Event-Handling, uam. Dank "closed source" bleibt das zwar Spekulation, aber ...

Nicht patentgeschützte Teile des Puma5-Referenzdesigns von TI wurden als OSS freigegeben und einige Hersteller haben ihre Sourcen dann auch veröffentlicht. => http://gpl.back2roots.org/source/puma5/ - die 6360 ist da mit Version 4.91 auch dabei.
Dann werde ich mir die Quellen bei AVM gerade unter dem Gesichtspunkt SNMP wohl doch morgen noch einmal ansehen müssen, bei meinem ersten Versuch wußte ich noch nicht so genau, wonach ich suchte ... und beim simplen Browsen kann man sich da schnell verzetteln.

Findet sich eigentlich auch ein Hinweis auf zusätzliche Forward-Rules für den UDP-Port 161 (bzw. 162) in den Support-Daten oder in der ar7.cfg ? Ist da bei KBW/UM vielleicht Port 3000 von außen (also über 10.x) zugänglich ?

Autsch ...
Wenn ich gerade einmal die KBW-AGB hier überfliege (Abschnitt A, 1.3, 1.4, 1.6) ist das bei KBW aber ohnehin ausdrücklich geregelt, was der Provider mit der FB6360 so alles machen darf. Egal wie man dazu steht, das ist wenigstens klar festgelegt.

Aus 1.3 würde ich sogar (die Preislisten durchsuche ich jetzt nicht) darauf schließen, daß KBW die Fritz!Box unentgeltlich für die Dauer des Vertrags zur Verfügung stellt.

Das ist etwas anders bei KDG, da wird die Box gegen 5,00€/Monat vermietet.

Also angesichts der AGB beneide ich damit KBW-Kunden (auch wenn die Box freizügiger zu konfigurieren ist als bei KDG) nicht mehr. Auch wenn sie wissen konnten, worauf sie sich einlassen ...

Selbst wenn man davon ausgeht, daß KBW vielleicht nicht absichtlich "Mist baut", wenn sie von dem eingeräumten Recht "dort vorhandene Software/Firmware oder darauf gespeicherte Daten zu ergänzen oder zu ändern" Gebrauch machen => wenn es mal hart auf hart geht und Dein Internet-Zugang mißbraucht wird, dürfte es schwer sein, die Verantwortung dafür auch an KBW zu delegieren, selbst wenn die vielleicht mit einer Einstellung wirklich daran Schuld tragen sollten.

Und ich vermute nicht (ich sehe jetzt aber auch nicht extra nach), daß KBW den Kunden an dieser Stelle aus der - bestimmt in den AGB vereinbarten - Haftung entläßt.

Ein neugieriger oder meinetwegen auch gelangweilter Mitarbeiter bei KBW (z.B. wenn nachts im Support mal nichts los ist) kann auch nur durch klar definierte Zugangsrechte und entsprechende Dokumentation mit automatischer Protokollierung aller Zugriffe daran gehindert werden, auf Deiner Box "einfach mal so" herumzuspielen - auch wenn es eigentlich immer ein anderer ist, dem so etwas passiert.

Solange nicht geklärt ist, wie die Leute auf die Box kommen und was sie da wirklich so alles machen können, würde ich mich nicht einmal auf das WLAN verlassen (meins ist in der FB6360 aber ohnehin aus).

Anders als Kennwörter für die Benutzer auf der Box (die können als Hash gespeichert werden) liegen WLAN-PSK, Zugangsdaten zum Online-Speicher, zu My!Fritz, usw. mit hoher Wahrscheinlichkeit auch auf DOCSIS-Boxen in reversibler Verschlüsselung vor und damit können sie auch ausgelesen werden. Wenn dann Dein WLAN oder Online-Speicher für illegales File-Sharing herhalten muß (auch wenn Du selbst da vielleicht nur Deine eigene Musik oder Fotos auf einem Onlinespeicher ablegen wolltest), erkläre das mal plausibel einem ermittelnden StA oder seinen Hilfstruppen. Schwer, wenn die bei einer Durchsuchung der Wohnung den Kaffeeautomaten schon nicht von einem Computer unterscheiden können und erst einmal anstandslos alles mit einem Stecker einpacken. Nein, ich habe das nicht selbst erleben müssen ... der Rest ist Schweigen.

Wenn man dann noch überlegt, wie das mit den Rechten und Protokollen z.B. bei der NSA gehandhabt wurde (ja, schon wieder dieses Thema, sorry), stellt sich mir immer die Frage, warum das bei einem (ich sag mal ruhig: kleineren) deutschen Kabel-Betreiber so viel besser geregelt sein sollte. Und auch dann bräuchte es eine Kontrolle der Einhaltung solcher Regeln und das kostet dann den Anbieter eigentlich wieder nur und bringt ihm keine Vorteile bzw. keine zusätzlichen Kunden. 8)

Noch mehr OT (und keine ernsthafte Frage): Kann man auf IPPF eigentlich seinen Nickname ändern ? Ich würde gerne "Paranoiker" werden oder ist der schon vergeben ? Jemand einen Tipp ?

informerex schrieb:

hier die weiteren Auszüge:

Zum Vergrößern anklicken....

Danke.

Ich fasse mal die bisherigen Feststellungen - oder meinetwegen auch nur Vermutungen - zusammen:

1. In der Firmware für die FB6360 gibt es einen, wahrscheinlich zur Puma5-Software gehörenden, SNMP-Agent, der auf dem Interface wan0 an den Ports 161 und 162 auf eingehenden Datenverkehr wartet. Zur prinzipiellen Funktion des SNMP-Protokolls kann man eine Einführung hier nachlesen. Die Existenz dieses SNMP-Agents wird weder auf der AVM-Webpräsenz noch bei einem der drei Kabel-Anbieter erwähnt oder derartige Fundstellen sind über die jeweilige Suchfunktion nicht zugänglich.

2. Über diesen Zugang ist dem jeweiligen BK-Netzbetreiber ein Zugriff auf Informationen zu aktuellen Betriebszuständen der FB6360 möglich, diese Informationen beschränken sich nicht nur auf die Daten des DOCSIS-Interfaces der Box.

3. Auch eine Veränderung des Betriebszustands (Reset) und eine Veränderung der Konfiguration (mindestens ein Reset auf Werkseinstellung) ist über den SNMP-Agent möglich.

[vermutlich OT, bitte trotzdem stehen lassen, wenn möglich]

Selbst wenn es hier ursprünglich nicht um die rechtlichen Grundlagen derartiger Zugriffsmöglichkeiten für den Anbieter gehen sollte:

Diese Zugriffe sind bei KabelBW und Unitymedia ausdrücklich in den (wohl weitgehend identischen) "Besonderen Geschäftsbedingungen Internet und Telefonie" im Abschnitt A unter den Ziffern 1.3, 1.4 und 1.6 insgesamt vereinbart, hier exemplarisch diese BesGB von KabelBW. KabelBW/Unitymedia beziehen die Endgeräte (ausdrücklich auch die Fritz!Box) in ihr Netz mit ein und legen den NTP vertraglich auf das komplette Endgerät fest. Damit beginnt das Netz des Kunden dort erst im WLAN oder an den LAN-Buchsen der FB. Die Möglichkeit des Kundenzugriffs auf das FB-GUI ist reine Höflichkeit und auch wenn sie komplett entfallen sollte, wäre das wohl kein Mangel, sofern nicht doch noch irgendwo im speziellen Vertrag etwas anderes schriftlich zugesagt/vereinbart wurde.

Bei Kabel Deutschland (AGB hier) ist diese Regelung nicht getroffen, ein Zugriff ohne ausdrücklichen Auftrag (und damit eine Einwilligung) des Kunden wird dort nicht vereinbart. Ohnehin sind die AGB von KDG - in meinen Augen - wesentlich liberaler, ganz im Gegensatz zum weiter eingeschränkten GUI der FB6360.

Ich sehe für Kunden von KabelBW und Unitymedia (abseits von einem vitalen Interesse, wie groß der Umfang der übermittelten Informationen wirklich ist) keinen Grund, ihrem Anbieter dabei irgendetwas vorzuwerfen ... allerdings kann von Transparenz der Angaben des Betreibers auch bei diesen Anbietern wohl nicht die Rede sein.
Bei Kunden von KabelBW und Unitymedia sind dafür dann eben wieder die Einstellmöglichkeiten im Web-UI der FB6360 weitreichender als für die Kunden von Kabel Deutschland.

[Ende OT]

Für Kunden von KabelBW und Unitymedia dürften sich auch aus der legalen Untersuchung der Firmware keine zusätzlichen - sonst "versteckten" - Einstellmöglichkeiten ergeben, diese Einstellungen stehen offenbar ohnehin im UI zur Verfügung.

Ich werde trotzdem meinerseits weiterhin versuchen, den "Leistungsumfang" des SNMP-Agents zu ermitteln. Auf der WAN-Seite ist beim derzeitigen Stand der Dinge (http://heise.de/-1886889) wohl nichts gegen die Kontrolle des Providers einzuwenden (in BK-Netz war der NTP schon immer etwas näher beim Kunden), aber den rechtmäßig erworbenen Besitz (nicht das Eigentum) für einen gemieteten Router muß der Kunde ohne Regelung nicht dem Anbieter (aka Vermieter/Eigentümer) überlassen.
Ein Haus-/Wohnungseigentümer als Vermieter kann ja auch nicht so ohne weiteres einfach den Inhalt des mitvermieteten Briefkastens inspizieren, weder die Zeitung noch die Werbung - Post (egal ob Brief oder Karte) schon überhaupt nicht, aber aus anderen Gründen.

Und das ist ja (s. erstes Posting) auch der eigentliche Grund für meine Suche ... wenn KDG behaupten sollte, sie machen jenseits von DOCSIS auch nichts oder "haben noch nie von derartigen Programmen gehört" (das scheint im Moment ja Mode zu sein), will ich Gegenbeweise oder zumindest plausible Gegenargumente vorlegen können.

Insofern hiermit mein Dank an SaschaBr und informerex für ihre Informationen ... damit wurde für mich erst klar, daß dieser SNMP-Agent wohl in der originalen AVM-Firmware für alle Anbieter enthalten ist und wonach ich in den von AVM bereitgestellten Quellen jetzt suchen muß.

Definitiv OT (gehört sicherlich eher hier hinein, Antworten also besser dort oder per PN):
Darf eigentlich ein KabelBW-Internet-Kunde unter Einhaltung der oben verlinkten BesGB (Abschnitt B, Zf. 3.1) einem volljährigen Freund/Bekannten über seinen KBW-Internet-Anschluß eine E-Mail schicken, in der er ihn darüber informiert, daß es auch Computer-Spiele ab 18 Jahren - wie z.B. Call of Duty oder Battlefield - gibt und sogar so etwas wie erotische "Erwachsenenunterhaltung" - auch hier keine gesetzwidrigen Inhalte - existiert ? Und zwar unabhängig davon, ob es sich dabei um Online- oder Offline-Inhalte handelt ? Ich behaupte: Nein, darf er nicht.

KunterBunter schrieb:

Im übrigen behaupte ich, dass ein Reboot oder Werksreset der Fritzbox auch per TR-069 über den ACS möglich sind. Ein SNMP-Zugriff ist dafür nicht nötig.

Zum Vergrößern anklicken....

Das halte ich für unwahrscheinlich - nicht die Möglichkeit per TR069 generell, sondern in der Fritz!Box und in meinem Falle. Es besteht ja keine dauerhafte Verbindung, um da irgendetwas zu triggern.

Der TR069-Client wird (behaupte ich jetzt mal in Analogie zu anderen Modellen) nur beim Start ohne vorherige Provisionierung oder auch bei ausdrücklicher Aufforderung übers UI (providerservices.lua) gestartet. Selbst wenn er anschließend noch periodisch den ACS abfragen sollte, der Eingriff durch KDG erfolgt nach meinen Erfahrungen ziemlich unmittelbar und da kann ich mir ein Polling nicht vorstellen.

Und die schon beschriebenen Probleme mit den SIP-Accounts bei mir liegen genau daran, daß der TR069-Client bei vorher erfolgter Provisionierung (evtl. aus nicht leerem tr069:settings/provcode abgeleitet) die Einstellungen eben nicht selbst erneut lädt, weil er meines Erachtens nur gestartet wird (ich behaupte sogar nur nach einem Neustart), wenn es etwas für ihn zu tun gibt.
Das kann ich durch neues Laden meiner (alten) Einstellungen gut nachvollziehen. Solange ich nicht selbst die neue Provisionierung anstoße, macht die Box auch nach Neustarts nichts in der Richtung und protokolliert auch über 5 Tage hinweg alle 30 Minuten "Anmeldung der Internetrufnummer XXX war nicht erfolgreich. Gegenstelle meldet Ursache 400" für alle drei Nummern.

[...] Rahmen von Maßnahmen, [...], auch bei nach Ziffer 3.2.2. überlassenen Geräten (Kaufgeräten) berechtigt, die [...]

Zum Vergrößern anklicken....

Es besteht IMHO schon ein Unterschied, der durch ein nicht vorhandenes Komma entsteht. Bei

[...] überlassenen Geräten (Kaufgeräten), berechtigt, die [...]

Zum Vergrößern anklicken....

stimme ich Dir sofort zu, daß da ein (zumindest ähnliches) Zugriffsrecht vereinbart wäre - aber eben auch nur auf ausdrückliches Verlangen (das kann selbstverständlich ein Auftrag beim Support sein) des Kunden, was bei den beiden anderen überhaupt nicht erforderlich ist.

Die Lesart, daß bei Geräten im Eigentum des Kunden seitens KDG für den Fall der Fälle besondere Vereinbarungen getroffen werden sollten, was mit dem von Dir zitierten Punkt 3.2.6. geregelt wird, ist m.E. ebenso logisch. Ansonsten wäre die explizite Bezugnahme auf Ziffer 3.2.2. unnötig, wenn dort einfach "bei allen überlassenen Geräten" o.ä. formuliert wäre.

Ich gehe eher davon aus, daß KDG aus ihrem Eigentumsrecht auch automatisch die Zugriffsrechte für die FB6360 ableiten will und da bin ich aber ganz anderer Meinung.

KunterBunter schrieb:

das Polling im Abstand von 45 Minuten.

Zum Vergrößern anklicken....

Ok, ich korrigiere mich dahingehend, daß auch bei den DOCSIS-Boxen ja irgendwann mal die Prüfung auf neue Firmware erfolgen muß.

Das wird dann ordentlich in den Konfigurationsdaten unter
eingetragen und nach meiner Interpretation alle 7 Tage (7x24=168) neu gestartet. Wenn dann auf Anhieb keine Verbindung möglich ist, wird halt immer wieder versucht, das nachzuholen.

Beim Start der Box wurde es - jedenfalls nach meinem Austausch - nicht automatisch ausgeführt oder hat (was ich nicht geprüft habe) trotz vorhandenem Update das dann selbst irgendwann in die Nacht verlegt. Keine Ahnung, wann das Update wirklich stattfand ... die neue Box hatte ja nicht meine eigenen LAN-Einstellungen, damit habe ich für diese Zeit auch keine automatisch gespeicherten Protokolle. Die Box war um 16:00 Uhr schon getauscht, das Update um 00:30 Uhr aber noch nicht durchgeführt.

Bei mir liegen für die FB6360 (2 Boxen nacheinander) folgende Zeitpunkte in gespeicherten Konfigurationsdateien vor:

Meiner Meinung nach ist das derselbe Mechanismus (hinsichtlich des Triggerns, bei der 7390 wahrscheinlich irgendwo in Kernel-Module kdsldmod.ko), der auf anderen Boxen (per HTTP-Request an "http://www.avm.de/fritzbox-firmware-update.php?[...]") überprüft, ob bei AVM eine neue Firmware vorliegt.

Die DOCSIS-Boxen fragen dann eben den Provider per TR069 ab (und starten das Update vermutlich auch gleich, wenn es vorliegt), wo das dann getriggert wird, wäre genauso spekulativ, wie alles andere auch.

Vielleicht ist die Angabe unter "check_interval" falsch oder wird schlicht ignoriert und es sind nicht 7 Tage. Aber an ein viel extensiveres Polling nach einem FW-Update glaube ich genauso wenig wie an eine regelmäßige TR069-Abfrage. Bei einer ausreichend großen Anzahl an Boxen kommt es dann bei zu kleinen Intervallen recht schnell zu Engpässen beim ACS.
Die Verteilung der einzelnen Clients über den Zeitraum eines kompletten Intervals per Ansage seitens des ACS wäre etwas kompliziert zu planen und wenn dann mal zwischenzeitlich der ACS doch ungeplant nicht erreichbar war und viele Boxen in kürzeren Abständen (s. Dein Link) nachhaken, schiebt sich das zusammen und es kommt zum Stau.
Dabei würde mich schon einmal interessieren, wie lange so eine komplette ACS-Kommunikation für eine Provisionierung dann wirklich dauert. Das Sammeln von Daten (in der Kundendatei, den Management-DBs für das Netz, usw.) dürfte bei einer ausreichend großen Anzahl von Kunden den Durchsatz des ACS schon begrenzen und wenn die DB zu langsam ist, nutzt auch der potenteste Frontend-Server nichts.