@full2000:
Exakt so ... anschließend einpacken, flashen, glücklich sein.
Bei 30593 funktioniert das jedenfalls problemlos und - an anderen Stellen mehrfach von mir erwähnt - sogar die Steuerung über die Telefon-Tastencodes funktioniert dann wieder für den Telnet-Daemon. Wie das in künftigen Versionen aussieht, weiß ich natürlich auch nicht ... aber ich gehe nicht davon aus, daß das hier in einen Wettlauf mit AVM ausartet. Wenn man die Aussagen von Urban Bastert akzeptiert, dann ist das Ziel ja eine Verbesserung der Sicherheit für den Großteil der Kunden und nicht das Verärgern der Bastler:
http://heise.de/-2696116 schrieb:
Wie AVM-Sprecher Urban Bastert gegenüber heise Netze erklärte, "war und ist Telnet kein Leistungsmerkmal der Fritzbox". Allerdings führte das versehentliche Aktivieren dieses Dienstes bei den Nutzern immer wieder zu Irritationen, denn ein einmal laufendes Telnet lässt sich nur durch ein Recovery der Firmware abschalten. Unabhängig davon verhindere das nicht, dass der Nutzer selbst erstellte Firmware auf einer Fritzbox installieren könne, wenn er es tatsächlich möchte. Solche Eigenentwicklungen und Beteiligungen unterstütze AVM außerdem durch sein Fritzbox-Labor, die ausführlichen Schnittstellenbeschreibungen und die Veröffentlichungen der GPL-Pakete des jeweiligen Firmware-Releases, erklärt Bastert abschließend.
Auch wenn die Aussage, daß sich Telnet nicht abschalten ließ/läßt, natürlich Bullshit ist, gehe ich einfach mal davon aus, er meinte die "modifizierte Firmware"-Anzeige in TFFS-Node 87 und wurde da von heise.de nur falsch interpretiert/zitiert. Und solange dieser Weg beim "normalen Kunden" das "versehentliche Aktivieren dieses Dienstes" (das passiert mir heute noch, daß ich einfach auf den Tasten eines Telefons herumdrücke, dabei #96*7* eingebe und damit dann versehentlich den Telnet-Daemon aktiviere*) verhindert, sollte es ja keinen Grund geben, weitere Änderungen an dieser Stelle vorzunehmen.
Das läßt dann auch darauf hoffen/vertrauen, daß die Bemühungen wirklich der Erhöhung der Sicherheit dienen und nicht in den erwähnten Wettlauf ausarten. Wie so etwas in der Regel ausgeht, kann man auch anhand anderer "Wettkämpfe" sehen ... was das iOS-Update auf 8.4 noch in der verbleibenden Zeit bis zur Veröffentlichung wieder schließen kann angesichts des Jailbreaks für 8.3, ist zwar spannend, aber das kostet Apple garantiert auch entsprechende Nerven und Anstrengungen und die Programmierabteilung dort dürfte um einiges größer sein als bei AVM. Damit wäre ja dann auch die Idee eines verriegelten Bootloaders oder das Blockieren unsignierter Firmware beim Update vom Tisch, zumindest für die bisher verfügbaren Modelle, wenn man die Glaubwürdigkeit nicht komplett verspielen will. Das Ansehen hat aufgrund nicht so glücklicher Aktionen in letzter Zeit ja ohnehin etwas gelitten, wie man auch hier immer wieder mal lesen kann ... wenn jetzt anstelle immer wieder neuer Funktionen auch mal eine Qualitätsoffensive gestartet wird, kann das ja für den Kunden und das Image des Herstellers nur gut sein.
Ich kann es mir aber wieder nicht verkneifen darauf hinzuweisen, daß Telnet wirklich nicht die erste Wahl sein sollte, wenn man auf der anderen Seite eine sichere(re) FRITZ!Box haben möchte. Die Telnet-Kommunikation ist komplett im Klartext, da geht also nicht nur bei der Authentifizierung das Kennwort 1:1 über die Leitung, auch jede weitere Ein- und Ausgabe ist (zumindest mit einer Kabelverbindung für den Lauscher) problemlos mitzuschneiden.
Wer ohnehin modifiziert und neu packen muß, kann auch gleich eine bessere Lösung in Betracht ziehen und z.B. ShellInABox mit TLS-Verbindung verwenden. Das ermöglicht die Benutzung der Shell auch direkt im Browser - aber eben verschlüsselt und für einen Lauscher damit wertlos - und mit ein paar weiteren Fingerübungen kann man sich sogar einen passenden Link in die AVM-Oberfläche integrieren, am besten am unteren Rand des Fensters. Wenn man auf den Permalink zum Newsletter-Bestellen verzichten kann und auch die AVM-Seite ohne Nachhilfe im Internet finden würde, ist am rechten Rand noch genug Platz für einen entsprechenden Link (da hat die CSU den rechten Rand entgegen dem Veto eines ehemaligen Vorsitzenden dann doch aus den Augen verloren und das ist jetzt tatsächlich eine nicht hierher gehörende Einlassung).
Dafür braucht es nur ein passend übersetztes ShellInABox-Paket und einige wenige zusätzliche Änderungen an Start-Skripten (wenn man nicht die debug.cfg ohnehin reaktiviert, dann kann man das auch dort starten) und ein oder zwei AVM-GUI-Files. Das kann man problemlos in einen Patch integrieren, den man dann einfach zwischen dem Aus- und Wiedereinpacken des AVM-Images ausführen läßt und dann kann man sogar auf die Installation eines PuTTY o.ä. verzichten, wenn man ohnehin einen Browser zur Verfügung hat (und nur Kommandos ausführen will).
Wer unbedingt von Linux aus per Kommandozeile zugreifen will (also ohne Browser, dafür taugt SIAB nicht), der installiert dann eben einen SSH-Server (die 7490 ist potent genug und wer sich ein wenig mit OpenSSH auskennt, verwendet dann ohnehin "connection sharing" und nimmt dem SSH-Server damit ständige Anmeldungen ab) und hat damit noch ganz andere Möglichkeiten, z.B. autofs mit sshfs für den Datenaustausch oder auch SSH-Tunnel zu irgendwelchen weiteren Diensten auf der Box, die sonst auch nur im Klartext kommunizieren würden bzw. wo der erfolgreiche Aufbau des Tunnel gleichzeitig als Authentifizierung/Autorisierung dient. Das geht natürlich mit PuTTY/KiTTY und Windows ebenfalls, es ist nur eine Frage der persönlichen Vorlieben.
Der entscheidende Punkt ist und bleibt die sichere Kommunikation zwischen der FRITZ!Box und deren "Manager" ... wer da wirklich Telnet verwendet und sich ansonsten aber Gedanken um die Sicherheit seines LANs macht, der übersieht diese generelle Schwachstelle genauso, wie die "Gefahr" der Benutzung des AVM-GUI ohne TLS - es geht ja auch mit, man muß nur die Disziplin dazu aufbringen.
Das sind jedenfalls alles Eingriffe, die weit unterhalb der "Schwelle" eines kompletten Freetz-Images möglich sind und die ursprüngliche Arbeitsweise und die korrekte Funktion des FRITZ!OS nur dann beeinträchtigen, wenn man dabei Fehler macht. Selbst das Nachrüsten einer LED-Anzeige für bestimmte Zustände (ich wünsche mir schon lange, daß man die INFO-LED auch für die Anzeige einer bestehenden VPN-Verbindung nutzen könnte) ist noch kein "wirklicher Eingriff".
Wer seine debug.cfg (oder wie auch immer er sie nennt) etwas ausgefeilter implementiert, der regelt einfach durch die An- oder Abwesenheit eines USB-Sticks oder irgendeine andere Semaphore (selbst die Abfrage, ob LAN-Kabel gesteckt sind oder ein bestimmter Client (per ARP) verfügbar ist (z.B. das eigene NAS), sind ja denkbare "Schalter" für den Notfall), ob die eigenen Modifikationen überhaupt gestartet werden sollen.
Wenn man die dann nicht startet und auch sonst keine Änderungen vornimmt, die sich in den Support-Daten niederschlagen, kann man mit so einer FRITZ!Box sogar die Support-Daten erzeugen und an AVM senden, ohne daß man dort etwas davon bemerkt - wobei man diese Möglichkeit natürlich in erster Linie dann verwenden sollte (also das "Stilllegen" der eigenen Modifikationen), wenn man ergründen will, ob ein Problem mit der originalen Firmware auch auftritt oder ob es doch auf eigene Änderungen zurückzuführen ist. Wobei dieser Test (auf NAND-Modellen mit "dual boot") natürlich auch mit einem eigenen und einem originalen System im Flash möglich ist ... aber eine Art "Not-Aus" ist nie falsch und merkwürdigerweise immer dann nicht vorhanden, wenn man es brauchen könnte - dann nimmt man sich in der Regel vor, das als nächstes umzusetzen und wundert sich beim nächsten Problem dann doch wieder, warum das noch niemand implementiert hat.
* Wenn mal wieder jemand
versehentlich den Telnet-Daemon über die erwähnte Tastenkombination aktiviert hat, hilft es auch gegen die berühmt-berüchtigte "nicht autorisierte Änderungen"-Meldung, wenn man sich einfach nicht über den Telnet-Daemon in der Box anmeldet und ihn wieder über #96*6* deaktiviert. Das Flag wird ja erst bei einem Login gesetzt (und zwar bei jedem, wenn man ar7login verwendet, wie es die AVM-Version nun mal macht, denn das ist im telefon-Daemon fest hinterlegt) ... die Möglichkeit, dieses Flag auch wieder zurückzusetzen, ist ja auch kein wirkliches Geheimnis, wenn man die zwei notwendigen Schritte zum Setzen des Flags (es geht hier nur um Telnet, nicht um die anderen Anzeigen in TFFS-Node 87) mal wieder versehentlich hintereinander in der richtigen Reihenfolge ausgeführt hat und nun so irritiert ist, daß man Recovery in Erwägung zieht, nur um diese unschöne Meldung wieder loszuwerden.
