[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[PeterPawn]

warum stellst Du nicht bei Deinem modfs gleich noch ein passendes pseudoimage bereit?

Weil es ein weiterer Schritt in eine von mir eigentlich nicht gewollte Richtung wäre. Ich tue mich schon schwer, beim modfs Binärdateien mit auszuliefern (nicht umsonst steht bei mir immer dabei, daß man das lieber selbst lesen und kontrollieren sollte, wer weiß denn schon, was mein böser Zwilling da ansonsten jemandem unterjubeln will) und da wäre der Schritt zu einem Pseudo-Image (wo dann garantiert niemand mehr hineinsieht) genau der falsche.

Andererseits ist mir schon bewußt, daß das dem "leichten Modifizieren" auch entgegensteht ... aber die richtige Lösung könnte es dann wohl nur sein, wenn man solche "Binärpakete" in signierter Form irgendwo von mind. zwei (besser mehr) Leuten unabhängig voneinander kontrollieren und veröffentlichen läßt. Dazu fehlt aber die Infrastruktur ... und ich bringe es auch nicht "über's Herz", jemandem zu empfehlen, sich auf einen einzelnen Anderen so weit zu verlassen. Das widerspricht einfach meinen Überzeugungen zum Thema "Open Source" und zum "Vier-Augen-Prinzip" (das können auch gerne vier Einäugige sein, das macht es sogar noch besser). Das heißt auch nicht, daß ich Repositories für Teufelswerk halte, aber es fehlt eben die Grundlage für eine "chain of trust" bei FRITZ!Box-Software.

Solche Sachen wie ruKernelTool oder JFritz, wo man nur raten kann, was hinter den Kulissen vorgeht, sind einfach nichts für mich ... das ist auch nicht unbedingt Mißtrauen gegenüber den jeweiligen Autoren (ich habe ruKT auch schon in einer VM benutzt/getestet), es ist eine Sache des Prinzips. Ich stamme eben noch aus der "Ringkernspeicher-Zeit" und da kannte man jedes Bit noch mit Namen ... ich will immer noch wissen, was auf meinen Geräten genau passiert (wenigstens annähernd oder zumindest in meiner Einbildung) oder sie kommen (per Default) ins Exil (aka Sandbox/DMZ).

Bei mir haben eben nicht einmal die FRITZ!Boxen Zugriff auf das LAN, da ist noch eine Firewall dazwischen ... daher weiß ich auch genau, daß AVM mit so einer Konstellation nicht rechnet (anderes NAT im LAN der FRITZ!Box), denn bei einem einzigen ungültigen Login-Versuch fliegen bei mir immer alle Logins auf den FRITZ!Boxen heraus, denn die sieht natürlich für all diese Logins immer nur die Adresse des NAT-Gateways. Das macht besonders dann Spaß, wenn da zwei automatische Prozesse sich immer gegenseitig abschießen, weil jeder der Meinung ist, er hätte gültige Credentials und das ist gerade nicht der Fall, weil der andere das seinerseits auch denkt ... nach einem FRITZ!Box-Neustart bei mir keine Seltenheit, daß sich das so "aufschaukelt".

Ok, der Rest ist schon wieder OT, aber sei's drum ... es zeigt mir immer wieder, daß auch so eine FRITZ!Box nur für ganz fest umrissene Szenarien gedacht ist und die eierlegende Wollmilchsau eben auch ihre Grenzen hat.

 

[koyaanisqatsi]

Moins

OMG

So eine Pseudoimagedatei ist doch keine Raketenwissenschafft.
Es ist ein simples TAR Archiv, welches auf *.image umbenannt wurde.
Genauso kann es wieder in *.tar umbenannt, mit 7zip entpackt, geändert und wieder gepackt und in *.image umbenannt werden.
Bei der install ist nur darauf zu achten: UTF-8 ohne BOM mit UNIX Zeilenende
...aber ich fürchte das mit der Textdatei überfordert die Meisten schon wieder. :silly:

 

[PeterPawn]

Ich bin ja ernsthaft am Überlegen, ob es nicht - trotz Binärdateien - fast sinnvoller wäre, ein modscript für den Einbau von ShellInABox mit dem FRITZ!Box-eigenen Zertifikat und zwangsweisem TLS zu stricken, anstatt einfach wieder den Telnet-Zugang zu etablieren. Ich habe AVM ja sogar den Vorschlag unterbreitet, den Telnet-Daemon zu streichen (ja, ich gebe das offen zu, weil ich es für die FRITZ!Box beim "normalen User" immer noch für zu unsicher halte, wie das umgesetzt ist und wie einfach es sich auch ohne Wissen des Nutzers aktivieren (und dann mißbrauchen) läßt) ... da sind nun diese gegenläufigen Bestrebungen schon etwas schizophren.

ShellInABox hätte eben den gewaltigen Vorteil (wie wir wissen, verwendet(e) AVM es ja ebenfalls - auch mit einem eigenen Patch für das Box-Zertifikat), daß man auch im LAN eine gesicherte Kommunikation hätte (eben HTTPS) und doch nicht unbedingt einen passenden Client (wie beim SSH) braucht, der (im Moment, für Windows 10 und PowerShell soll da ja was mit OpenSSH in Planung sein) bei einem Windows-PC z.B. nicht "out of the box" dabei ist (Telnet ja normalerweise schon, läßt sich zumindest leicht nachinstallieren).

Wenn dann jemand weitere Dienste (egal ob SSH oder Telnet) nachinstallieren will, ist das immer noch eine andere Sache ... im Moment habe ich fast so etwas wie ein schlechtes Gewissen, daß ich AVM (und meinen eigenen Vorschlag, auch wenn der sicherlich nicht den Ausschlag gegeben hat) so "torpediere". Ich tröste mich eigentlich nur damit, daß es noch andere Wege gibt, an das Kennwort eines Admins zu gelangen und daß AVM die noch nicht alle gestopft hat. Andererseits ist das genau die Argumentation, die mich in solchen Fragen immer zur Weißglut treibt ... denn dann würde sich vermutlich nie etwas verändern/verbessern, weil es eben "auf einen Schlag" nur sehr schwer zu realisieren ist. Aber der Argumentation: "Wenn wir das fixen, geht es ja so und so immer noch, also lassen wir es gleich." begegnet man durchaus öfter und da reichen zwei - sich gegenseitig stützende - Lücken dann eben aus, damit das nie in Angriff genommen wird.

 

[koyaanisqatsi]

Klar mach doch.
Obwohl ich noch eine busybox dazulegen würde, wegen den zusätzlichen benötigten Shellskriptkommandos.
...und dropbear, für Diejenigen denen eine Shell im Webbrowser zu langsam ist.
Die Boxen haben den Speicher, jetzt wirds auch mal Zeit den zu nutzen.
...und sei es auch nur: Pseudo

 

[KingTutt]

... da wäre der Schritt zu einem Pseudo-Image (wo dann garantiert niemand mehr hineinsieht) genau der falsche.

OK, ich habe bisher noch in jedes Pseudo-Image reingeschaut und es auch nachvollzogen.

Daher weiß ich auch, dass

So eine Pseudoimagedatei ist doch keine Raketenwissenschafft.

ist. Allerdings lässt es die zeit nicht immer zu, bei Tippfehlern oder neuen FW Versionen sich vorab mit allen erdenklichen Randbedingungen auseinander zu setzten. Die sind zwar meist auch hier im Forum irgendwo dokumentiert, aber da ist es dann halt komfortabler, wenn sich eh schon mal jemand die Mühe gemacht hat alles nachzuprüfen, ein fertiges Skript zu nehmen wo man nur kurz reinschauen muss, um sicher zu stellen, dass es auch das macht, was man erwartet. Außerdem geht es hierbei ja auch nur um kleine leichte Änderungen durch den Nutzer. Wenn ich mehr will baue ich mir eh mein eigenes Freetz Image zusammen. So habe ich das schließlich damals auch als Pionier mit der 6840 gemacht.

Spätestens wenn AVM anfängt, nur noch die Installation von signierter FW zu erlauben, kommen wir dann da an, wo der große Apfel schon heute ist. Jailbreaks für Fritz!Boxen... ein Katze und Mausspiel zwischen Nutzern und Hersteller, was keine hilft und für beide Seite nur Ärger bringt. Das gegenseitige respektvolle Miteinander war schon immer der beste Ansatz, aber jetzt wird es wieder OT.

Ich habe AVM ja sogar den Vorschlag unterbreitet, den Telnet-Daemon zu streichen (ja, ich gebe das offen zu, weil ich es für die FRITZ!Box beim "normalen User" immer noch für zu unsicher halte, wie das umgesetzt ist und wie einfach es sich auch ohne Wissen des Nutzers aktivieren (und dann mißbrauchen) läßt) ... da sind nun diese gegenläufigen Bestrebungen schon etwas schizophren.

IMHO interessiert das Telnet den normalen Nutzer eh nicht und ich würde darauf wetten, dass 90% der normalen FRITZ!Box User nicht einmal wissen, dass es so etwas überhaupt gab. Von daher finde ich es sehr bedauerlich, dass dieses Zusatz für die "extended User" nun deaktiviert wird.

 

[PeterPawn]

Obwohl ich noch eine busybox dazulegen würden, wegen den zusätzlichen benötigten Shellskriptkommandos.[
...und dropbear, für diejenigen denen eine Shell im Webbrowser zu langsam ist.

Ich vermute mal, da verstehen wir uns eben genau nicht (falls das kein Sarkasmus gewesen sein sollte) ... wenn man das konsequent bis zum Ende denkt, ist das am Schluß ein "Konkurrenz-Image" (und zwar sowohl zu AVM als auch zu Freetz) und das macht nur dann Sinn, wenn man dort andere (vorzugsweise neue) Wege beschreitet.

Da einfach ein weiteres Image anzubieten ist (für mein Verständnis jedenfalls) Unsinn - daß das noch mehr dem sparsamen Einsatz von (fremden) Binärdateien zuwider läuft, ist Dir ja sicherlich auch nicht entgangen. Solange man da nicht nach dem Motto: "Jetzt ist ohnehin alles schon egal ..." vorgehen will, paßt das ja deutlich nicht zu dem vorher von mir Geschriebenen. Die Überlegung, SIAB noch als zusätzliches (statisch gelinktes) Binary anzubieten, hat ja bestimmte Gründe (und da paßt ein "alles was reingeht und gebraucht werden könnte" irgendwie nicht ins Bild).

Wenn man da einen Mechanismus implementiert, der das Nachinstallieren von Programmen ermöglicht, ist das schon wieder etwas anderes, das wäre dann nämlich wirklich eine andere Qualität (und nicht nur Quantität bei der angebotenen Software).

Aber das ist eben keine Sache, die man als Einzelkämpfer so ohne weiteres in Angriff nehmen kann (wo das landet, sieht man am "Phoenix-Mod") und bei den Freetz-Developern war da wenig Gegenliebe für einen solchen Vorschlag zu spüren, weil es a) auf älteren und kleineren Modellen mit einiger Sicherheit nicht mehr funktioniert und man die damit abschneiden würde und b) es schon lange kein "Freetz-Release" mehr als "stable version" gab und das erst einmal Vorrang haben soll.

Das ist ein Standpunkt, den man akzeptieren muß ... aber man muß ihn auch nicht teilen und für mich - nicht das erste Mal, daß ich diese These auch hier im IPPF äußere - ist Freetz (was das fertige Image angeht, nicht das Build-System!) ein Dinosaurier - die leben heute auch nur noch auf einer fernen Insel (oder war es in einem tapferen gallischen Dorf?).

So ein Thema - nicht gegen das "komplette" Freetz, aber eben gegen den "mod" - ins Auge zu fassen, erfordert aber ein paar aktive Mitstreiter und auch wenn ich mich bei solchen Aktionen ab und an mal traue "querzudenken", kann ich die dazu notwendigen Anstrengungen gut genug einschätzen, um mich im Moment auf einzelne kleine Bausteine zu beschränken. Das Machbare (u.a. eben auch das "paketweise" Update durch Speicherung im yaffs2) wird sicherlich demnächst auch mal als modscript kommen (ich habe es teilweise schon so im Einsatz) ... aber es ist im Moment eben so, daß da an allen Ecken Baustellen auftauchen, die erst einmal behoben werden müssen, bevor man sich Gedanken über weitere Anwendungsfälle macht.

Wenn es jemand mal selbst probieren (und dann weiterdenken) will, was man mit solchen "dynamischen" Änderungen an der Firmware noch alles anstellen kann (außer die Box darüber anzugreifen, das geht natürlich auch), dann kann er sich ja mal mit

mount -o remount,rw /wrapper

den Schreibzugriff auf die betreffende NAND-Partition für das aktive System freischalten und dort (im Rahmen des Machbaren und unter Berücksichtigung, daß das beim übernächsten Firmware-Update überschrieben wird) eigene Sachen speichern. Der "bootmanager" macht das - nebenbei bemerkt - schon genauso, wenn er die Einstellungen des laufenden Systems in der yaffs2-Partition sichern soll.

Für die Verwaltung einer Paketliste und anderer eigener Einstellungen/Programme ist das allemal genug (ca. 20 MB umkomprimiert) ... wenn man darum weiß, kann man es sogar beim Update berücksichtigen und in das neue System übernehmen. Das ist jedenfalls (auch was den zur Verfügung stehenden Platz angeht, selbst bei Modellen mit 128 MB NAND-Flash gesamt) ein Quantensprung im Vergleich zum alten "NOR-Flash" im TFFS und funktioniert eben auch ohne USB-Speicher (was besonders bei frühen Eingriffen in den Startprozess ein gewaltiger Vorteil ist, weil da USB meist noch nicht zur Verfügung steht).

Wenn AVM dann noch den UBIFS-Treiber mit in den Kernel integriert und man anstelle von yaffs2 auch das (komprimierende) ubifs verwenden könnte (erfordert aber auch einen anderen "NAND-Scanner" bei der Suche nach Partitionen), dann wäre das ein richtig fetter Pluspunkt auf dem Weg zu einer "Paketverwaltung" auf der FRITZ!Box ... ein Punkt, den heute eigentlich jedes bessere Festplattengehäuse schon beherrscht, wenn es sich NAS nennen will. Solange muß man sich eben selbst um die effiziente Nutzung des zur Verfügung stehenden Speicherplatzes kümmern und ggf. etwas komprimieren, bevor man es dort ablegt.

Auch sollte natürlich das "Problembewußtsein" für die beschränkte Lebensdauer des Flash-Speichers erhalten bleiben und niemand auf die Idee kommen, da doch einfach das Syslog o.ä. zu speichern. Das ginge zwar theoretisch auch, wäre aber der Lebensdauer eher abträglich, da so ein Flash eben keine Festplatte ist und - selbst wenn man immer nur dieselben 32, 64 oder 128 KB schreiben will - das eben technisch vollkommen anders gelöst ist. Das erhöht einerseits zwar die Lebensdauer des gesamten Flash-Speichers (durch "wear leveling"), führt aber eben auch zu einer Belastung des gesamten (verteilten) Speichers, wenn man da täglich 4-5 MB an Daten hineinschreibt (die Partition hat nur 48 MB, von denen i.d.R. knapp über 24 vom AVM-Image belegt sind).

@KingTutt:
Mein Vorschlag zur Abschaffung von Telnet beruhte auch nicht auf der Tatsache, daß es niemand braucht ... es ging nur darum, daß ich es auch auf einer fabrikneuen FRITZ!Box mit ein paar Tricks ohne das Wissen des Nutzers aktivieren kann und dann eine sehr bequeme Art des Zugriffs habe. Selbst bei einem absichtlich vom Nutzer aktivierten Telnet-Zugang fehlt eben jede Sicherung (Telnet hat nun mal kein PAM oder CRAM-MD5-Login) und damit gehen die Daten im Klartext durch das LAN. Dort mitzuschneiden, ist nur eine Fingerübung (ettercap macht's vor, ein "exploit" nutzt dieselben Techniken). Man kann schlecht auf der einen Seite den Vorschlag unterbreiten, auch das GUI nur noch TLS-verschlüsselt anzubieten (mit entsprechendem Redirect und STS-Header heute bei modernen Browsern problemlos machbar) und auf der anderen Seite auf der Verfügbarkeit eines Telnet-Zugangs bestehen. Da ich für das erstere bin, ist der Telnet-Zugang schon ein "Klotz am Bein".
EDIT: Apropos Klartext und Anmeldung mit Hash o.ä. ... ich brauche als MITM bei Telnet noch nicht einmal Kenntnis der Credentials, es reicht vollkommen, wenn ich mich in eine solche ungesicherte Verbindung einklinken, eigene Tastendrücke (heißt tatsächlich so) senden und die Ergebnisse ebenfalls wieder "filtern" kann, dann kriegt nicht einmal der Nutzer der Telnet-Session etwas davon mit.

 

[KingTutt]

Mein Vorschlag zur Abschaffung von Telnet beruhte auch nicht auf der Tatsache, daß es niemand braucht ... es ging nur darum, daß ich es auch auf einer fabrikneuen FRITZ!Box mit ein paar Tricks ohne das Wissen des Nutzers aktivieren kann und dann eine sehr bequeme Art des Zugriffs habe. Selbst bei einem absichtlich vom Nutzer aktivierten Telnet-Zugang fehlt eben jede Sicherung (Telnet hat nun mal kein PAM oder CRAM-MD5-Login) und damit gehen die Daten im Klartext durch das LAN. Dort mitzuschneiden, ist nur eine Fingerübung (ettercap macht's vor, ein "exploit" nutzt dieselben Techniken).

Ich sehe das etwas entspannter, das der Zugriff immer nur aus dem LAN gegeben ist (nicht WAN) und bei physischem Zugriff durch den Nutzer kann man eh absichern was man will... es gibt immer einen Weg. Außerdem gab es bei der Nutzung von Telnet den Hinweis in der GUI, so das der User Wissen darüber erlangen könnte. Sicherlich würde ich auch ssh mit den in der Fritz!Box hinterlegten credentials bevorzugen (bei vielen NAS Laufwerken geht das auch) aber lieber ein Telnet, als gar nichts...

 

[koyaanisqatsi]

Hallo?

fabrikneuen FRITZ!Box mit ein paar Tricks ohne das Wissen des Nutzers

Tricks?
Hochoffiziell dokumentiert im Internet (Handbuch/Onlinehilfe?) mit jedem an der Box angeschlossenen Telefon.
...nur SL Boxen ohne angeschlossene DECT/Analog/ISDN Telefone, also nur mit IP-Telefonen sind dagegen gefeit (gewesen).

Naja, wenigstens geht noch WLAN aus/an (#96*0*, #96*1*)
...da kommt Freude auf beim Pensionsportier.

Und das mit der busybox war nicht sarkastisch.
Ich denke du weisst ganz genau wie willkürlich/unberechenbar AVM mit dem Appletumfang der busybox umgeht.
...da kannste dich (bei unbekannter Firmware) einfach nicht drauf verlassen.
Es wäre ja auch nur ein: Installationstool (jetzt muss ich mir schon Wörter ausdenken :doktor: d. futurologischen Linguistik )
...link alle benötigten Applets da rein, dokumetier das und gut ist.

 

[PeterPawn]

@KingTutt: @koy:
Ihr mißversteht mich beide ... wenn ich schreibe "ohne Wissen des Nutzers" dann meine ich natürlich einen automatischen Angreifer, der einerseits (@koy) keine Telefone in die Hand nehmen und irgendwelche Nummern wählen kann (Telefonbuchzugriff und Wählhilfe sind schon wieder ein Grenzfall) und andererseits (@KingTutt) keinen physischen Zugang zur FRITZ!Box hat, sehr wohl aber ein anderes Gerät im LAN als Relay kontrolliert ... das kann vom Webradio bis zum Kühlschrank, vom Smart-TV über Tablets/Smartphones bis zum "HDMI-Stick" a la FireTV so ziemlich jedes Gerät sein. Lassen wir uns einfach überraschen, in welchem Gerät die nächste auszunutzende Lücke auftaucht. Und so ein "relay" kann natürlich - entsprechend präpariert - auch erst einmal unabhängig von einer Steuerung agieren und die Infektion vollziehen ... die Schlußfolgerung, daß ohne die FRITZ!Box ja keine Steuerung des Relays aus dem Internet möglich ist, habe ich auch schon angeboten bekommen. So simpel muß ein solcher "Angreifer" aber auch nicht gestrickt sein ...

Nur in diesem Kontext macht auch der Vergleich einer HTTP-Verbindung für das GUI der FRITZ!Box und einer Telnet-Verbindung unter Security-Aspekten Sinn. Wenn ich von einem physischen Angriff reden würde (wie das Abfangen von Cisco-Technik durch die NSA), wäre das ein vollkommen anderes Thema, das auch nichts mehr mit AVM und der Firmware zu tun hätte. Wenn ich physikalischen Zugang zu einer FRITZ!Box habe, kann ich die immer angreifen (notfalls über (E)JTAG, einfacher mit einem LAN-Kabel zwischen meinem eigenen Rechner und der FRITZ!Box) ... ich theoretisiere nur über Angriffe, die durch das Ausnutzen von Sicherheitslücken auf einer der beiden "Netzwerkseiten" (LAN/WAN, ggf. noch DECT) der FRITZ!Box möglich werden.

@koy:
Wo gibt es eigentlich eine "offizielle" Dokumentation des Telefoncodes zur Aktivierung des Telnet-Daemons?

@KingTutt:
Meine FRITZ!Boxen zeigen nie (zumindest nicht länger als 10 Sekunden) eine Warnung auf der Startseite an ... das ist ein einziges durchlaufendes Skript, das die entsprechende Einstellung ausliest und bei einer Änderung (die nur nach einem Telnet-Login auftaucht - ar7login ist dafür verantwortlich, das kann man sogar komplett rauspatchen, wenn man will) das gleich wieder zurücksetzt. Das ist nun wirklich nur "Kosmetik".

 

[koyaanisqatsi]

Nicht schon wieder diese Haarspaltereien.
Wie geht eine RUL per Tastencode?
Wie gehen verschiedene Arten von RULs per Tastencode?
Wie löscht man eine RUL per Tastencode?
Wie löscht man alle RULs per Tastencode?
...das steht hier im IPPF

Bei AVM findest du höchstens den für WLAN an/aus, im Suchergebnistext, nicht Artikel.
Suchfilter: Service Suchwort: tastencodes

 

[KingTutt]

Eine "offizielle" Dokumentation des Telefoncodes zur Aktivierung des Telnet-Daemons gibt es IMHO nicht. Alle offiziell unterstützten Tastencodes/Telefoncodes sind im Handbuch zur jeweiligen Fritz!Box beschrieben. WLAN, Umleitungen, Werksreset, etc. gehören dazu, Telnet nicht. AVM erwähnt den Begriff Telnet nur in der Hilfe im Zusammenhang mit "Vom Hersteller nicht unterstützte Änderungen". Deshalb kann AVM sich auch auf den Standpunkt stellen, dass Telnet nie offiziell beworben wurde.

@PeterPawn
Das man die Meldung komplett rauspatchen kann ist mir bewusst. Sie taucht übrigens nicht nur nach Telnet-Login auf, sondern z.B. auch, wenn man einen modifizierten Export mit "NoChecks=yes" importiert hat. Aber wenn ein User telnet aus Versehen aktiviert und benutzt haben sollte, steht das eben schon dauerhaft da. Das Argument, dass das versehentliche Aktivieren dieses Dienstes bei den Nutzern immer wieder zu Irritationen führte, lasse ich zumindest nicht gelten.

 

[PeterPawn]

Nicht schon wieder diese Haarspaltereien.
[...]
Bei AVM findest du höchstens den für WLAN an/aus, im Suchergebnistext, nicht Artikel.

Sorry, das ist Deine Ausdrucksweise gewesen:

Hochoffiziell dokumentiert im Internet (Handbuch/Onlinehilfe?) mit jedem an der Box angeschlossenen Telefon.

Da darf man doch dann mal nachfragen, oder?

@KingTutt:
Ja, ist mir doch auch alles klar, neben "TELNET" gibt es auch noch andere Werte für die "Flags" in Minor-ID 87 ... aber auch "NoChecks=yes" geht eben schon länger nicht mehr und die "Aussagekraft" dort hat auch stark nachgelassen, weil es eben bei einer manuellen Änderung an der Export-Datei gar nicht mehr erkannt wird, denn bei korrekter Prüfsumme braucht es ja kein "NoChecks" - was ohnehin nicht mehr funktioniert (zeitgleich mit der debug.cfg, wenn ich mich richtig erinnere).

Die Meldung an sich ist mir auch egal, meinetwegen soll das AVM mit einer "write once"-Zelle lösen, daß man es nicht zurücksetzen kann. Mir ging es nur darum, daß ich Dich so verstanden hatte, daß der berechtigte Nutzer es immer auch anhand dieser Meldung sehen könne oder sogar müsse, daß da jemand hinter seinem Rücken Telnet aktiviert hat (und es nutzt, ohne Login ohnehin keine Meldung) - und das ist eben genauso wenig der Fall, wie ein falscher Login-Versuch über FTP derzeit protokolliert wird. Wenn also ein Angreifer so blöd ist, das "Kennwortraten" über das Webinterface machen zu wollen, ist er selbst schuld, wenn das protokolliert wird. Glücklicherweise hält da eine Verzögerung einen Angreifer wenigstens etwas auf ... aber für einen schnellen Test, ob irgendwo erbeutete Credentials auch auf der FRITZ!Box funktionieren würden, reicht das schon aus ... vom "Mitschneiden" der Credential auch beim FTP-Login aus dem LAN will ich gar nicht erst wieder anfangen, keine Ahnung, ob "AUTH TLS" inzwischen auch aus dem LAN geht bzw. sich als "mandatory" einstellen läßt. Es ist zwar sehr nett, wenn das GUI nur mit einem Hash authentifiziert und dann die SID verwendet, solange weitere Dienste das im Klartext tun (mit denselben Credentials), ist das aber die gepanzerte Tür in der Rigips-Wand und die hilft eben gegen bestimmte Gefahren, aber längst nicht gegen alle. Das soll nicht heißen, daß man das im Webinterface nicht mit Hash und SID machen sollte ... das heißt, das man keine anderen Dienste mit Klartext-Authentifizierung anbieten sollte (und natürlich am besten das GUI auch nur noch verschlüsselt).

 

[BurningCrash]

- Pseudo-Image für den Telnet-Start unter 06.35 verwenden (vorher das modfs-Paket nach /var/media/ftp schieben, sonst wird es eng mit dem Laden aus dem Internet)

Das mit dem Pseudo-Image habe ich dann hier gefunden. Vielen Dank schonmal dafür.

Geht eigentlich durch einen Reboot irgendwas verloren nach der "Behandlung" mit modfs?

 

[PeterPawn]

Geht eigentlich durch einen Reboot irgendwas verloren nach der "Behandlung" mit modfs?

?
Die Frage verstehe ich nicht und so antworte ich vorsichtshalber wahlweise mit "Häh, wie jetzt?" oder der Feststellung: "Ja, die von AVM gewollte zusätzliche Sicherheit durch die fehlende debug.cfg und den nicht startenden Telnet-Daemon.".

Die Reaktivierung der debug.cfg erfolgt tatsächlich automatisch, das müßte man vorher entsprechend ändern, wenn man "nur Telnet" will. Ansonsten setzt der Telnet-Mod wirklich nichts weiter als den alten Symlink wieder ein, packt das Filesystem und macht das "Update" für Dich. Im Prinzip genau derselbe Ablauf, wie bei einem Update über's GUI, nur mit einmal Auspacken, Ändern, Einpacken zusätzlich.

Wenn Du keine weiteren Änderungen einbauen läßt (oder an der Stelle mit der "Pause" selbst einbaust), ändert sich praktisch nichts weiter.

Daß es für 06.35 auf 06.35 im Moment doch nicht geht, hast Du sicherlich gelesen ... mal sehen, was ich noch schaffe.

PS: Deine Signatur ist auch schon älter? Oder ist Rainer jetzt wieder zurück beim Würfel? Ne, kann er ja nicht, gibt es ja nicht mehr als Forum. Ich konnte nicht mal mehr den Account löschen ... :-(

 

[BurningCrash]

?
Die Frage verstehe ich nicht und so antworte ich vorsichtshalber wahlweise mit "Häh, wie jetzt?" oder der Feststellung: "Ja, die von AVM gewollte zusätzliche Sicherheit durch die fehlende debug.cfg und den nicht startenden Telnet-Daemon.".

Das die ggf. von AVM gewollte "Sicherheit" verloren geht durch das behandeln der FW mit deinem Skript ist mir klar.

Was ich meinte (sorry war echt etwas komisch gestellt die Frage).
Nach dem ich die Debug.cfg wieder enabled habe mit deinem script und die Box normal rebootet muss man aber nicht mehr machen. Oder muss ich nach einem Reboot der Box irgendwas beachten?

Bei mir geht es aktuell Primär um den reibungslosen Ablauf des LCR.

 

[PeterPawn]

Nach dem ich die Debug.cfg wieder enabled habe mit deinem script und die Box normal rebootet muss man aber nicht mehr machen. Oder muss ich nach einem Reboot der Box irgendwas beachten?

Nur das breite Lächeln(?) von Wilson Wilson jr. aufsetzen und natürlich die debug.cfg mit dem gewünschten Inhalt füllen.

Bei mir geht es aktuell Primär um den reibungslosen Ablauf des LCR.

Den kann ich Dir natürlich nicht garantieren. Ich weiß auch nicht, wie da die allcfgconv-Problematik seit der 06.2x gelöst wurde ... wenn das auch über webdavcfginfo lief/läuft (wie bei decode_passwords), gibt es eine weitere Baustelle, denn das funktioniert jetzt auch nicht mehr wie bei der 06.20-06.24 ...

 

[BurningCrash]

Nur das breite Lächeln(?) von Wilson Wilson jr. aufsetzen und natürlich die debug.cfg mit dem gewünschten Inhalt füllen.

:-D Sehr gut.

Den kann ich Dir natürlich nicht garantieren. Ich weiß auch nicht, wie da die allcfgconv-Problematik seit der 06.2x gelöst wurde ... wenn das auch über webdavcfginfo lief/läuft (wie bei decode_passwords), gibt es eine weitere Baustelle, denn das funktioniert jetzt auch nicht mehr wie bei der 06.20-06.24 ...

Klar kannst du das nicht garantieren. Das fällt dann eher in die Fähigkeiten/Zuständigkeiten von Harald Becker. Aber wenn die Debug.cfg wieder geht ist das schonmal die hälfte der Miete (nicht für für LCR sondern auch andere Skripte die diese debug.cfg benötigen).

Vielen Dank für dein Skript und deine Antworten um meine Unklarheiten zu klären ;-)

 

[scraemgo]

Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.24

Die Auswahl des 'update'-Modus erfordert eine neuere Firmware-Version vom
FTP-Server des Herstellers.

Ermitteln der neuesten Version durch Suche auf dem FTP-Server ..../modfs: line 1: head: not found
 Fehler
Die neueste Versionsnummer auf dem FTP-Server kann nicht ermittelt werden, Abbruch.#

Ich habe auf meiner 7490 aktuell FRITZ!OS 6.24 am laufen. Jetzt wollte ich das Skript das erste Mal benutzen und damit direkt das Update auf Version 6.30 zu fahren. Leider wird das Update nicht gefunden. Wo genau wird denn die neue Version gesucht, auf dem FTP liegt doch die neueste Version?!
ftp://ftp.avm.de/fritz.box/fritzbox.7490/firmware/deutsch/

 

[KunterBunter]

Das gleiche stand gestern schon in diesem Thread in #116, gerade mal eine Seite zurück.

 

[scraemgo]

Das habe ich schon gesehen, aber die Situation war eine andere. Der User war auf 06.29 und wollte auf die neue 6.35 Labor-Version. Da ist ja klar dass es nicht automatisch funktioniert. In meinem Fall sollte es das aber schon, weil ich ja von der stabilen Version 6.24 auf 6.30 möchte.