Optimal fände ich den Mittelweg, es standardmäßig zu deaktivieren, aber in der erweiterten Ansicht eine Option zu bieten, das "Entwicklungsfeature" telnet wieder über Telefon aktivierbar zu machen.
Für die Masse wäre das doch auch ersteinmal ausreichend sicher gewesen. Quasi 2-Faktor-Authentifizierung.
Ich traue mich dann doch noch einmal zu widersprechen.
Praktisch alles, was der Besitzer im Webinterface einstellen kann, läßt sich auch ohne sein Wissen von einem Angreifer im LAN mißbrauchen, solange die Kommunikation eines berechtigten Benutzers nicht grundsätzich besser abgesichert ist (da bietet sich TLS halt an). Auch wenn die Authentifizierung natürlich beim GUI nicht im Klartext erfolgt, kann man doch mit einer gültigen SID und unter Zuhilfenahme von ARP-Spoofing (weil die SID an die IP-Adresse gebunden ist, was in einer "vom Standard abweichenden Konfiguration" wie meiner auch schon ins Leere läuft, da die FRITZ!Box grundsätzlich nur die IP-Adresse meines internen NAT-Servers sieht und den benutzen alle Clients im "internen Netz") so eine Sitzung übernehmen bzw. im Rahmen des Timeouts von ARP-Einträgen sogar mitten in so einer Sitzung eigene Requests absenden, wenn man nur die IP-Adresse und die SID irgendwie durch Lauschen in Erfahrung bringt. Abhilfe schafft hier nur das Binden der SID an die MAC-Adresse, das ist aber wieder ein tiefer gehender Eingriff, der auch nicht in jedem Falle hilfreich ist (Clients hinter einem zusätzlichen WLAN-AP (nicht hinter einem Repeater, da wird L2 getunnelt) kennt die FRITZ!Box eben nicht mit der MAC-Adresse des Endgeräts, sondern mit der des AP).
Solange es für einen Angreifer die Chance gibt, sich auf einem per LAN-Kabel mit dem Router verbundenen Gerät einzunisten, kann dieser Angreifer sogar noch vor der Erstkonfiguration durch den Besitzer alle möglichen Einstellungen vornehmen, wenn man nicht wieder vollkommen andere Gegenmaßnahmen trifft. Das geht ganz einfach durch den Export einer Sicherungsdatei, Änderung der dort hinterlegten Einstellungen und anschließendes Wiederherstellen dieser geänderten Einstellungen (natürlich automatisiert und dann dauert das inkl. Neustart max. 3 Minuten). Dabei läßt sich dann auch gleich noch der Telnet-Daemon aktivieren, obwohl es im Moment gar keine per Webinterface zu steuernde Einstellung dafür gibt. Wenn man das nur schnell genug nach dem Einschalten der FRITZ!Box erledigt, bekommt der "normale Benutzer", der in dieser Zeit erst einmal im Handbuch nachliest, was er jetzt bei der Ersteinrichtung eigentlich machen soll, das gar nicht mit und das bißchen zusätzliche Geflacker der LEDs an der Box kann er ohnehin nicht interpretieren, wenn er es überhaupt bemerkt.
Wenn die Einstellung zum Telnet-Daemon irgendwo in der Box gespeichert und dann auch beim Ex-/Import berücksichtigt wird, wird sich das o.a. Szenario auch nicht vermeiden lassen. Jede (mir einfallende, ich diskutiere aber gerne Abwehrmöglichkeiten) Gegenmaßnahme hat dann wieder entsprechende Konsequenzen an anderer Stelle und wenn man mich als Hersteller vor die Wahl stellen würde, die Bedienung für >95% meiner Kunden komplizierter zu gestalten (selbst wenn es nur zu ihrem Besten ist und ich sie damit schützen will) oder einfach auf ein Feature zu verzichten, was geschätzt 1% meiner Kunden benötigen könnte, dann ist die Entscheidung nicht schwer. Klar könnte man auch hingehen und in der Kombination des Zugangs zum GUI und zum Telefon eine Zwei-Faktor-Authentifizierung sehen ... aber es ist ja bekanntlich auch problemlos möglich, die Wählhilfe zur Aktivierung des Telnet-Daemons zu benutzen -> damit sind wir dann wieder bei nur einem Faktor. Will man das Problem (Wählhilfe) wieder in den Griff bekommen, trifft das auch alle anderen Funktionen, die über Telefoncodes gesteuert werden können.
Ich könnte mir als Ausweg aus so einem Dilemma nur vorstellen, daß man eine Handlung, die tatsächlich nur der Benutzer der FRITZ!Box physisch vornehmen kann, zu Voraussetzung für die Freischaltung von "Entwicklungsfeatures" macht. Das ist aber nicht so viel, was da in Frage käme ... eigentlich bleiben nur die Tasten und die Ethernet-Ports übrig. HP macht bei seinen Procurve-Switches z.B. ein "Werksreset" davon abhängig, daß der Bediener ein Patchkabel zwischen zwei LAN-Anschlüsse dieses Switches steckt und somit eine - im Normalbetrieb verbotene - Konfiguration herstellt, die auch nicht dauerhaft bestehen kann (eben weil sie den Wirkbetrieb verhindert). Aber selbst die Auswertung so einer "sicheren Anzeige", daß es wirklich der Wunsch des Benutzers ist, "erweiterte Funktionen" zu nutzen und das auf eigene Gefahr erfolgt, muß eben erst einmal programmiert werden und da stellt sich wieder die Frage nach dem Mehrwert für den Hersteller.
Wobei ich schon dabei bleibe, daß ich kein echtes Problem sehe. Solange der Upload von unsignierten Images noch möglich ist und damit auch die "Pseudo-Images", die ja im Wesentlichen nur aus der Abarbeitung des dort enthaltenen "install"-Skripts bestehen, weiterhin funktionieren, solange ist das Aktivieren des Telnet-Zugangs (wir reden hier von der 7490, bei NOR-Boxen wäre das etwas anderes) nur eine Sache von 10 Minuten und dafür braucht man nicht einmal eine eigene Freetz-Buildumgebung. Das gilt auch nur für die erstmalige Verwendung ... wenn man von diesem Punkt an bereit ist, das Update auch über Telnet zu machen, steht man nicht wieder vor dem Problem, selbst wenn man praktisch jede Laborversion mitnimmt (solange AVM nicht noch weitere Gegenmaßnahmen ergreift) und der zusätzliche Aufwand mit dem Pseudo-Image für die erste Aktivierung von Telnet fällt auch nur ein einziges Mal an. An diesem Punkt warte ich dann nur noch auf den Einwand, daß es ja viel zu kompliziert ist, ein Update über Telnet zu machen ... da muß man sich ja dann erst einmal damit befassen, wie so eine Telnet-Session funktioniert.
