Habe ich nicht anders geschrieben ... das war der Versuch der Erklärung, warum ein eRouter vom Beginn an keine gute Idee in einem Netz mit sensiblen Informationen ist.
Ansonsten verstehe ich nicht, was da "hinter dem eRouter" aus Deiner Sicht noch zu konfigurieren wäre ... der wird vom Provider eingeschaltet (Abschnitt 6 in der Spezifikation) und ist dann selbst dafür zuständig, die IPv4- und/oder IPv6-Konfiguration per DHCP zu machen (die nachfolgenden Abschnitte der Spezifikation).
Meine Frage an @scuros bezog sich darauf, wie gut AVM da die neue Einstellung "SNMP für den Anbieter abschalten" und "TR-069 für den Anbieter abschalten" (die ist schon älter, trotzdem wissen wir ja, daß das nicht immer auch wirklich "aus" hieß, Stichwort "litemode" bei 1&1) umgesetzt hat und ob weitere Besonderheiten des DOCSIS-Standards nicht doch dazu führen könnten, daß der Provider über die eCM-Konfiguration entweder TR-069 unabhängig von den Einstellungen des Besitzers einschalten kann (oder den ACS neu setzen, usw.) oder den eRouter aus der Ferne auch bei ausgeschaltetem SNMP-Zugriff noch neu starten kann ... da das Auswirkungen auf das LAN haben kann, wenn da die Box nicht als DHCP-Server reagiert und derweil ein anderer DHCP-Server dann falsche Informationen verbreiten könnte.
Nur als Beispiel könnte man so den Verkehr eines Clients an sich selbst als Gateway umleiten und damit zumindest das mitlesen, was nicht mit Ende-zu-Ende-Verschlüsselung gesichert ist - geht bei "normalen DNS-Abfragen" los und man könnte per DHCP natürlich solche Abfragen auch gleich direkt umleiten.
Das gilt eben auch für WLAN-Netze (wenn so ein Client zwar automatisch "umspringt", aber nicht wieder zurückschaltet) und es gibt noch genug fehlerhafte Implementierungen in Clients, wo das recht unsicher erfolgt. Selbst wenn so ein Client nur eine Kombination aus MAC-Adresse des AP und der SSID eines "bekannten Netzes" speichert ... wenn ich z.B. weiß, daß jemand mit einem offenen Netz in einem Café kommuniziert hat und ich die MAC-Adresse dieses AP kenne, dann kann ich auch an anderen Orten versuchen, durch das "Vorspiegeln" dieses AP (MAC-Adresse und SSID passend senden) das verwendete Gerät wieder auf meinen simulierten AP zu locken, wenn ich ein höher priorisiertes Netz irgendwie abschalten kann.
Das funktioniert natürlich bei einem aufmerksamen Benutzer nicht und ein solcher würde schon gar kein Netz ohne WPA2 benutzen, solange da aber auch beim WPA2 ein PSK verwendet wird, der auch anderen bekannt ist (das ist praktisch bei jeder FRITZ!Box so, die kann ja kein RADIUS), da kann dann auch nur noch ein passend gesichertes Gerät zwischen den verschiedenen Vertrauensstufen so einer WPA2-gesicherten WLAN-Verbindung unterscheiden und manchmal reicht es eben schon, eine POP3- oder IMAP4-Anmeldung so eines Clients mal "live mitzuschneiden" über den gefaketen AP, damit man den Rest des Postfachs auch noch auslesen kann - nicht umsonst haben viele größere Anbieter inzwischen eine Zwei-Faktor-Authentifizierung und eine Benachrichtigung beim Zugriff von unbekannten Geräten auf so ein Postfach. Nur ein Beispiel von vielen denkbaren Angriffen ...
Und genau weil es für einen solchen Angriff eben hilfreich ist, wenn man ein eigentlich sendendes WLAN mal kurzerhand außer Betrieb gehen lassen kann, sind solche Möglichkeiten in den Händen eines Fremden (der Provider ist hier ein solcher) eine potentielle Gefahr. Das muß nicht heißen, daß der die überhaupt nutzen kann und will und es mag sogar viel einfachere Wege geben. Wenn man dann diese einfacheren Wege aber irgendwann mal schließt und sich dabei der anderen Möglichkeiten gar nicht bewußt ist, hat man "die Kosten" für einen Angreifer nur unwesentlich erhöht.
- - - Aktualisiert - - -
Generell ist ein DOCSIS-Router schon darauf angewiesen, daß der Provider dort auch "mitspielt".
Ich glaube nicht, daß es bei einem Kundengerät (jenseits des guten Willens des Providers und seines Credos "don't be evil") eine "Sperre" gibt, die einen Neustart verschiedener Teile des Gerätes durch den Provider verhindert bzw. daß AVM es bei der 6490 tatsächlich für die Retail-Firmware alles so geändert hat, daß es sich nun anders verhält als bei der Provider-Firmware.
Wenn dann so ein "Teilstart" das gesamte Gerät neu starten läßt (auch hier gab es bisher wenige Gründe, das zu trennen), dann hat es der Provider weiterhin in der Hand, die FRITZ!Box 6490 beim Kunden neu zu starten ... daher ja die Bitte an @scuros, das zu testen und das geht eben nur dann, wenn man selbst "Provider" spielen kann.
Für ein "soft reset" gibt es ja ein gesondertes Skript (/bin/edocsis_softreset), das auch nur per "msgsend" den "multid" informiert - das ist bei vielen anderen DOCSIS-Ereignissen aber auch so, die werden per "msgsend" an den "ctlmgr" weitergereicht (in /bin/edocsis_state_changed). Die Frage ist halt, welche Auswirkungen das auf die Dienste hat.
Ein Beispiel für so einen Neustart, wo die Frage wäre, ob der nun partiell ist (also nur das eCM betrifft) oder das gesamte Gerät neu startet, wäre folgendes SNMP-Objekt (aus
http://mibs.cablelabs.com/MIBs/DOCSIS/DOCS-IF3-MIB-2016-08-04.txt):
Code:
docsIf3CmMdCfgIpProvModeResetOnChange OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This attribute determines if the CM is to automatically
reset upon change of the IpProvMode attribute. The attribute has a
default value of 'false' (2) which means that the CM does not reset
upon change to IpProvMode attribute. When this attribute is set to
'true' (1), the CM resets upon a change to the IpProvMode attribute."
REFERENCE
"DOCSIS 3.0 MAC and Upper Layer Protocols Interface
Specification CM-SP-MULPIv3.0-I14-101008, IP Initialization
Parameters TLV section."
DEFVAL { false }
::= { docsIf3CmMdCfgEntry 2 }
Dazu gibt es dann noch eine einstellbare Verzögerung so eines Resets und mit dem Wert "true" für die oben gezeigte Einstellung würde eine Änderung der SNMP-Variablen "docsIf3CmMdCfgIpProvMode" mit einem SNMP-SET-Kommando zumindest schon mal das (e)CM neu starten lassen ... die Frage ist halt, wie weit sich das auf die anderen Funktionen des Gerätes (und das meint nur die lokalen und ggf. auch nur interne DECT-Telefonie, daß die Internet-Verbindung dann weg wäre, ist logisch) auswirken wird.
Der nächste Punkt wäre sogar "docsDevResetNow" (OID 1.3.6.1.2.1.69.1.1.3 - RFC 4639) - auch darüber wäre (zumindest in der Theorie) ein Reset des Gerätes durch den Provider denkbar ... das sind alles deutliche Unterschiede zu den DSL-Modellen, wo die Eingriffsmöglichkeiten des Anbieters mit dem Abschalten von TR-069 dann auch erst einmal "weg" sind - da beschränkt sich das auf die Unterbrechung der Internet-Verbindung, was aber keine direkten Auswirkungen auf die Funktion des Gerätes als LAN-Zentrale hat.
Bei einer 6490 kommt dann m.W. auch noch hinzu, daß die AHA unterstützt ... wenn die dann als Zentrale dafür zuständig ist, daß irgendwelche Schaltaktionen rechtzeitig oder koordiniert ausgeführt werden (keine Ahnung, wie weit die Aktoren da autonom reagieren und ob da "Ketten" von Ereignissen umzusetzen sind in der AVM-Firmware), dann ist so ein (potentieller) Neustart durch einen Dritten zum unpassenden Zeitpunkt schon mal mehr als "annoying".
Das sind sicherlich alles keine weltbewegenden Möglichkeiten ... wenn man aber als Anbieter solche Geräte auch für "Business-Anschlüsse" vertreibt und darunter sind dann auch "Berufsgeheimnisträger", ist die mangelhafte "Aufklärung" der Kunden schon wieder anders zu bewerten in meinen Augen.
Wenn hier die nachträgliche Feststellung, daß die DECT!200-Teile ein (nicht in der Gerätebeschreibung dokumentiertes) Mikro enthalten, zu Skepsis bei einigen führt, kann ich das nachvollziehen ... bei wichtigen Besprechungen liegt auch bei mir kein MT-F direkt daneben (für das Smartphone haben es einige ja inzwischen begriffen) - das ist am Ende auch nur eine Frage der Software, was da im Zustand "aufgelegt" auf so einem Gerät wirklich läuft und es muß ja nicht einmal der Hersteller des Gerätes sein, der da eine veränderte Software eingespielt hat.
Hat AVM irgendwo die MIBs für den SNMP-Stack der 6490 veröffentlicht? Bei Arris-Modems gibt es z.B. die Einstellung:
Code:
arrisCmDoc30ResetFactoryDefaults OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Reset a number of settings to their default factory values.
This includes clearing the modem's frequency cache and
restoring a number of NVM parameters to their original values."
::= { arrisCmDoc30Base 6 }
Eine Entity in einer MIB nach RFCs wird es dafür vermutlich nicht geben (sonst bräuchte es die herstellerspezifischen ja nicht) ... die Frage wäre, ob AVM eine derartige herstellerspezifische MIB auch implementiert hat. Sie haben sicherlich (einige andere Einstellungen sind ja auch AVM-spezifisch) ... die Frage bleibt, was da zu steuern ist und hier rede ich nicht von irgendwelchen SNMP-Interfaces auf dem eRouter, die vielleicht abgeschaltet werden können über "Anbieterdienste", hier meine ich herstellerspezifischen Einstellungen für das eCM. Gibt es eine analoge Einstellung für "factory reset" bei AVM auf dem eCM und die wirkt nicht nur auf das eCM selbst, sondern auf das gesamte Gerät, wäre das schon wieder ein ziemliches Problem. Der Kunde könnte kaum zwischen einem solchen Reset und dem "plötzlichen Verlust" seiner Einstellungen unterscheiden (und das auch nie richtig nachweisen, weil ja selbst Protokolle gelöscht wären).
Da eine Trennung bisher nicht notwendig/möglich war, auch wenn große Teile der DOCSIS-Konfiguration ja in /nvram liegen und die AVM-Konfiguration normalerweise in /var/flash, gibt es wohl (zumindest bisher, ich lasse mich gerne eines Besseren belehren) keine gesonderte Möglichkeit, die DOCSIS-Einstellungen getrennt von den AVM-Einstellungen zu löschen.
Das dafür zuständige Skript "/bin/docsisfactorydefaults" (das löscht die Einstellungen in /nvram) wird jedenfalls (zumindest offensichtlich, d.h. irgendwelche "versteckten" Aufrufe, die erst zusammengebaut werden müssen, sind hier nicht berücksichtigt) nur aus der /etc/init.d/S01-head aufgerufen und auch das nur dann, wenn zuvor für den normalen AVM-Teil die Werkseinstellungen geladen wurden. Zumindest sagt das ein "grep" über die Firmware für den ARM-Core in der Version 06.62 ... bliebe die Frage, wie AVM denn ein selektives Löschen realisiert hätte, wenn es ein solches gäbe.
Aber schon bei der Frage, ob der herstellerspezifische Stack überhaupt ein solches Reset erlaubt oder das nur über TR-069 erfolgen kann (was machte dann bisher der KNB, der keinen ACS verwendete und ausschließlich über SNMP steuerte?), ist die Informationslage ja ausgesprochen dünn - daher muß man eben auch mal spekulieren, was natürlich immer die Gefahr birgt, daß man auch mal heftig danebenliegt.
Aber irgendeine Einstellung muß ja auch dafür sorgen, daß die Datei /var/tmp/avmfeature.conf erstellt wird, wenn bei den Provider-Firmwares darüber die Konfiguration von Gerätefunktionen machbar ist (boxfeaturedisable - was ja beim TV eher ein "enable" ist, außer man sieht es unter dem Aspekt "disable lock").
Bei den DOCSIS-Boxen ist jedenfalls eine neue Runde des Lernens angesagt und selbst wenn man nicht alle Erkenntnisse von anderen Modellen über Bo(a)rd werfen muß, sind einige Sachen eben doch schon ganz wesentlich anders realisiert. Da muß man dann eben ein wenig experimentieren und suchen ... wenn hier einer ein altes CMTS wegwerfen und die Entsorgungskosten sparen will: Ich nehme es.
), damit man dem eCM "Befehle" geben kann.
