FB 7490 Backup vereinfachen

"OMG" zeigt schon das Problem.
Das bezog sich auf die Aussage:
Bis zur Firmware 6.24 eine prima Firma, danach Security vor Usability, so ein quatsch
und es ist Dir selbstverständlich unbenommen, diesen Standpunkt zu vertreten. Trotzdem habe ich (spontan und in vollkommen ungewohnter Kürze) das Erste niedergeschrieben, was mir zu diesem Satz (zweites Zitat hier drüber) durch den Kopf schoß. Und obwohl AVM auch noch das eine oder andere Problem in der Firmware hat, ist die Firmware inzwischen (glücklicherweise - das ist nun mal mein Standpunkt) eine der sichersten für einen SOHO-Router. Das ist so ein gewaltiger Fortschritt, daß AVM hoffentlich auf die vereinzelten Kunden, die sich durch die Security-Enhancements "gegängelt" fühlen, auch ohne Probleme verzichten kann - meine Erfahrung besagt nämlich auf der anderen Seite auch, daß es gerade diese Leute sind, die am lautesten schreien oder endloses Tamtam machen, wenn dann doch mal etwas passiert.

AVM ist zu blöd meine Daten unter Lisp mitzunehmen
Da ist schon das nächste Problem, denn das Locator/ID Separation Protocol wird als LISP abgekürzt. "Lisp" ist eine Programmiersprache oder eine halbe Sprachstörung - je nach Kontext.

Da die Sicherung dann nicht verschlüsselt wird halt grober Unfug.
Das ist nur als Aussage tatsächlich ebenfalls "grober Unfug" ... wenn Du etwas genauer hinsiehst, sind alle Daten in bestimmten Feldern (das sind dann die, die wirklich schützenswert sind und da gehören Deine WLAN-Kanäle sicherlich nicht dazu - aber andere durchaus und auch bei den LISP-Einstellungen sollte das Kennwort für den LISP-Provider verschlüsselt sein) durchaus nicht lesbar. Wenn Du die Theorie dahinter tatsächlich verstehen willst, empfehle ich Dir diesen Thread: [Info] Wie funktioniert eigentlich die AVM-Verschlüsselung für die Einstellungen? - anschließend kannst Du dann ja entscheiden, ob Du einige der - definitiv falschen - Behauptungen aus diesem Thread nicht doch revidieren möchtest.

Ansonsten hat AVM nirgendwo (ich lasse mich aber gerne mit einer Quellenangabe (die man auch selbst nachlesen kann) eines Besseren belehren) erklärt, daß man ALLE Einstellungen von einem FRITZ!Box-Modell auf ein anderes übertragen kann. Möglich, daß das bei den LISP-Einstellungen tatsächlich nicht funktioniert (ich habe es nie probiert) ... aber angesichts der sonstigen "Ungenauigkeiten" in Deinen Behauptungen, sollte das Fehlen der LISP-Einstellungen nach dem (kompletten) Import vielleicht auch noch einmal überprüft werden. Ich habe schon länger keine Einstellungen mehr von einem Modell auf ein anderes übertragen ... aber ich weiß auch definitiv, daß da noch viel mehr Einstellungen nicht auf eine andere Box übertragen werden - das geht schon beim Namen der FRITZ!Box los. Gleichzeitig war es bisher eigentlich immer so, daß ein "kompletter Import" noch mehr Einstellungen umfaßte, als ein "Selbst auswählen, welche Einstellungen wiederhergestellt werden sollen", auch wenn man dort dann alle Punkte ausgewählt hatte.

Und die Möglichkeit, eine Export-Datei OHNE ein Kennwort zu erstellen, funktioniert schon seit mehreren Jahren nicht mehr - jedenfalls nicht über das GUI von AVM. Einen tatsächlich vollkommen unverschlüsselten Export gab es bei AVM in den letzten sechs Jahren definitiv nie - seit dem "webcm"-Bug war (ab dem nächsten Release) nicht mal das Entschlüsseln der intern verschlüsselt gespeicherten Einstellungen (was zuvor mit "allcfgconv" möglich war) weiterhin machbar. Wenn also irgendjemand tatsächlich eine Export-Datei mit unverschlüsselten Credentials haben sollte, dann hat er die selbst entschlüsseln lassen. Selbst wenn man beim Export (in den alten Versionen) kein Kennwort angab, wurden dafür die gerätespezifischen Einstellungen (maca, WLAN-PSK) verwendet und die Datei war aus genau diesem Grund nur auf demselben Gerät wieder zu importieren und auch das nur dann, wenn man zwischenzeitlich nicht am Urlader-Environment herumgespielt hatte.

Eine Komplettverschlüsselung der Export-Datei (wo also jeder Text zu Binärbrei verwurstet wird) widerspricht dann auch wieder der "Forderung", AVM solle doch die Leute, die sich genauer damit befassen wollen, einfach "machen lassen" ... dann haben sich nämlich Tools wie der FBEditor (u.a.) auch erst einmal erledigt, solange man denen dann die Entschlüsselung nicht auch noch beibringt.

Und wer sich "gegängelt" fühlt von der verbesserten Sicherheit der AVM-Firmware, der kann ja mal einen Blick in den Katalog des BSI werfen: https://www.bsi.bund.de/SharedDocs/...R03148/TR03148.pdf?__blob=publicationFile&v=2 - darin finden sich auch noch genug Punkte (zumindest optionale), die von der AVM-Firmware bisher nicht erfüllt werden.

Nun kann man natürlich auch auf dem Standpunkt stehen, die Spacken vom BSI hätten ohnehin keine Ahnung von der Materie ... aber da haben eben auch andere mitgewirkt, u.a. auch der CCC. Einige der Forderungen haben es zwar nicht in die Richtlinie geschafft (u.a. die Pflicht, die Installation von Fremdsoftware zuzulassen, wenn der Hersteller nicht länger Updates liefert), aber die dort angeführten Punkte machen eben aus Security-Sicht durchaus Sinn und man darf nun mal nicht vergessen/unterschätzen, daß der eigene Router tatsächlich DAS zentrale Element im Heimnetzwerk ist (jedenfalls bei den meisten FRITZ!Box-Besitzern und diese Geräte sind eben genau für die "blinden Massen" erdacht/gemacht) und wenn der erst mal kompromittiert ist, dann ist auch der Schaden entsprechend groß.

Ich weiß nicht genau, wer sich noch an den Mirai-Angriff auf die Telekom-Router am Anfang Dezember 2016 erinnern kann ... da hatte es dann innerhalb kürzester Zeit 1,25 Mio. Speedport-Router aus dem Netz gefegt und dabei war dieser Angriff damals noch nicht einmal in der Lage, tatsächlich in die Firmware der Geräte einzudringen und sich dort festzusetzen. Jetzt kann ja jeder mal überlegen, wie das wohl bei den FRITZ!Boxen in D wäre (es wird ja immer noch behauptet, daß diese mind. 60% der in D installierten SOHO-Router bilden), wenn man da auf Sicherheit zugunsten irgendeiner "Usability" (unter der auch wieder jeder etwas anderes versteht, abhängig vom eigenen Ausbildungsstand) verzichten würde.

Es gibt heute für so ziemlich jeden Quatsch "irgendeine App" ... wenn sich diese dem Router von der LAN-Seite aus ungehindert nähern kann und z.B. mit einer mitgeschnittenen Session-ID einen Download der Einstellungsdatei laden kann, dann ist eben der Router vollständig kompromittiert - da ist es eine sehr sinnvolle, zusätzliche Sicherung, wenn man mind. zwei Faktoren für eine Authentifizierung braucht und nichts anderes ist auch die 2FA bei AVM. Wer darin einen "Verlust an Usability" sehen will, der muß sich einfach mal selbst fragen, wie oft er wohl einen solchen Export der Einstellungen ausführt ... wenn derjenige dann auch noch der Ansicht ist, er will diese Datei möglichst unverschlüsselt haben, ist das ähnlich wie das "Schlüsselversteck" im gefaketen Findling neben der Haustür.
 
  • Like
Reaktionen: schwester
JETZT, vermutlich seit 7.11, geht das tatsächlich nicht mehr.
In Anlehnung an Beitrag #18 und #20 (edit: und nun auch in Ergänzung zu #21), das geht mindestens schon seit FRITZ!OS 6.80 nicht mehr. Hier bspw. eine 7390 mit FRITZ!OS 6.85:
Export_7390_06.85_01.png

Ab FRITZ!OS 7.0x gab es jedoch noch weitere Anforderungen an das PW, hier bspw. eine 7490 mit FRITZ!OS 7.01 beim Versuch der Sicherung mit dem Passwort "abcd12":
Export_7490_07.01_01.png

Bei FRITZ!OS 6.8x konnte man bspw. "1234" oder "abcd12" noch als PW verwenden, bei FRITZ!OS 7 nicht mehr. Mit FRITZ!OS 7.10 oder 7.11 gab es dagegen imo keine weiteren Änderungen mehr diesbezüglich.


Eines zeigt mir das jedoch:
Dass das bis jetzt hier im IPPF kaum jemanden aufgefallen ist (auch wenn man @paulbaumann1 oder @PeterPawn dabei nicht berücksichtigt heißt das nicht niemanden), bedeutet das doch, dass die meisten (leider nicht alle, wie dieser Thread zeigt) hier im IPPF wohl schon lange verstanden haben, das eine Sicherungsdatei ohne selbst vergebenes Passwort nicht wirklich Sinn macht. Denn im Zweifel ist eine solche Sicherung ohne eigenes Passwort einfach mal wertlos (wenn man nicht noch zufälligerweise auch einen Auszug des Environment der betreffenden Box besitzt).
Und auch die Rücksicherung einer Export-Datei ohne eigenes Passwort auf der gleichen Box könnte ein Problem darstellen, wenn mittlerweile bestimmte Environment-Variablen der Box verändert hat (dazu gehören meiner Erinnerung nach bspw. die Variablen "tr069_passphrase", "webgui_pass" oder "wlan_key", auch wenn das bei neueren Modellen nicht mehr so einfach funktioniert, so doch bei einigen älteren durchaus).

Zudem hat das auch den Vorteil, dass man eine Sicherungsdatei (mit selbst vergebenen Passwort) im Fall des Falles auch mal einfacher entschlüsseln kann. Man braucht dazu ja nur dieses Passwort und muss nicht erst einige Environment-Variablen der ursprünglichen Box zusammensuchen (falls überhaupt noch möglich). Damit dann auch gleich der klitzekleine Hinweis: Das Passwort mit in den Dateinamen der Sicherungsdatei "einzubauen" ist u.U. auch nicht gerade ideal.

Kurzum, meiner Ansicht nach hat hier AVM keinen Fehler gemacht, den Nutzer zu einem Passwort zu zwingen. Seit dem haben bspw. auch die Nachfragen/Themen hier im Forum imo doch schon um einiges nachgelassen, wo Nutzer ihre Sicherung von einer anderen Box nicht mehr in die neue Box zurück sichern konnten (denn wer hatte die Hinweise dazu im Webinterface schon wirklich vollständig gelesen und erst genommen). Und im Zweifel steht der Nutzer nun auch nicht mehr mit einer wertlosen Sicherungsdatei im Regen, falls seine alte Box "abgeraucht" ist.


... und dann unverschlüsselten Daten in der Export-Datei ist allerdings merkwürdig. Wenn man, wie auch immer, an solch eine Export-Datei gerät, kann man daraus die Zugänge für Provider, Email- und VoIP-Accounts ableiten oder diese in eine eigene Export-Datei integrieren.
Jein. Also gänzlich unverschlüsselt ist die Export-Datei definitiv nicht. Die Benutzernamen und Passwörter für die hinterlegten Zugangsdaten bspw. zum PPPoE-Login, E-Mail-Account, SIP-Accounts, DDNS-Accounts usw. usf. sind darin verschlüsselt. Übrigens auch als man noch eine Sicherungsdatei ohne eigenes Passwort erstellen konnte. Allerdings wurden dann bestimmte Eigenschaften der Box für die Verschlüsselung herangezogen, weshalb diese Sicherung eben auch nur auf dieser Box wiederhergestellt werden konnte.
Allerdings gibt es dennoch noch genügend andere Informationen in der Sicherungsdatei, die weiterhin unverschlüsselt sind (weshalb diese u.U. weiterhin nicht ganz unkritisch ist). Aber komplett unverschlüsselt stimmt eben auch wieder nicht.

Ich glaube hier im Forum schonmal ein Thema bezüglich Manipulation der Export-Datei gesehen zu haben.
Das ist einerseits richtig, bezog sich aber andererseits nur auf den Fall, das die entsprechenden Zugangsdaten bekannt waren. Ein Beispiel hierzu war die Hinterlegung der richtigen PPPoE-Zugangsdaten in der Sicherungsdatei an L3-BSA Anschlüssen von 1und1 bei der Verwendung eines externen DSL-Modem.
 
Zuletzt bearbeitet:
Aber irgendwie widersprichst du dich. Einerseits ist es viel zu kompliziert wenn man nicht tief in der Materie drinsteckt, andererseits verfluchst du die Sicherheitsmassnahmen die AVM genau für solche User eingebaut hat.
Alles einfach und unverschlüsselt bringt dann im Endeffekt siehe weiter oben auf einmal Telefonrechnugnen über 1000 €.
Und dann ist wieder AVM schuld. Einfache Sicherheit ist ein antagonistischer Widerspruch
 
Recht hast Du.
Aber man kann Sicherheit und Usability durchaus zusammenbringen.
Beispiel: Wenn AVM Telnet so gefährlich scheint, warum nicht eine klare Warnung anzeigen das bei Benutzung sämtliche Gewähr erlischt anstatt das Feature zu sperren?
Antwort: Die Firma hat primär Interesse an Ihr Geschäftsmodell und da spielen Bastler nur eine untergeordnete Rolle. Da sperrt man lieber zuviel und ist auf der sicheren Seite. Das kann man prima finden und ja AVM hat einen gut abgesicherten Router.
Oder man hat da eine andere Meinung. Ich finde eben Entwicklungen wie OpenWrt besser wo ohne die Sicherheit zu vernachlässigen auch Flexibilität nicht eingeschränkt wird. Mein nächster Router wird das unterstützen. Sorry wenn ich da eine andere Meinung habe.
 
Beispiel: Wenn AVM Telnet so gefährlich scheint, warum nicht eine klare Warnung anzeigen das bei Benutzung sämtliche Gewähr erlischt anstatt das Feature zu sperren?
Was genau würde es denn bringen, wenn der Angreifer bei der Verwendung von Telnet angezeigt bekäme, daß der FRITZ!Box-Besitzer nun nicht länger auf die Hilfe des Herstellers rechnen könne? Ich würde das (in der Rolle des Angreifers) ja eher als "gute Nachricht" empfinden.

Und meines Wissens reden/schreiben wir hier immer noch über eine 7490 ... da braucht die Aktivierung eines Shell-Zugangs praktisch nichts - nicht mal eigene Vorkenntnisse oder "spezielle Software" wie VMs (mal abgesehen vom PC mit Windows oder Linux oder MacOS).

Wer aber von Beginn an "Keine Lust/keine Zeit, mich damit zu befassen." konstatiert:
Die Zeit habe ich nicht, Punkt.
und das u.a. damit begründet, daß die Zeitangaben, wie lange man für die Umsetzung als "blutiger Anfänger" brauchen würde, nicht stimmen, der sollte - in meinen Augen und da auch gleich aus genau diesen beiden Gründen (keine Zeit + keine Ahnung ... oder wie wäre ein blutiger Anfänger sonst zu beschreiben?) - ohnehin die Finger davon lassen.

Was will man in so einem Falle eigentlich mit einem Shell-Zugang anfangen? Schon die Frage, welche Einstellungen man ggf. auf der Kommandozeile erreichen könnte, die man über das GUI nicht ändern kann, erfordert ja ein entsprechendes Befassen mit dem Thema. Wie geht das bei "keine Zeit/keine Lust" dann genau?

Wer mir einreden will, die Installation von OpenWRT auf irgendeinem x-beliebigen anderen Gerät, das nicht bereits vom Hersteller mit OpenWRT ausgeliefert wird (und so riesig bzw. gar aktuell ist da auch bei ALLNET bzw. Linksys die Auswahl nicht), wäre sooo viel einfacher als das Aktivieren eines Shell-Zugangs bei einer FRITZ!Box (gerade auch zu einer 7490), der hat ebenfalls "keine Ahnung".

Ich bin (an den richtigen Stellen) durchaus auch ein Fan von OpenWRT ... nur handelt es sich bei der FRITZ!Box eben (wie bei anderen Geräten, z.B. den Telekom-Speedports, auch) gar nicht mehr länger nur um einen simplen Router, der dann als Edge-Router zum Internet oder als WLAN-AP für das Heimnetz agieren kann.

Wer sich darauf beschränken will, findet viel preiswertere Hardware - die dann auch von OpenWRT unterstützt wird. Nur wird er da auf alles andere eben auch verzichten müssen (ebenso, wenn man OpenWRT auf einer FRITZ!Box einsetzt) ... da funktioniert dann nämlich weder DECT noch SmartHome oder VoIP richtig (letzteres zumindest nicht "out of the box") - wenn man Pech hat, nicht mal das WLAN in der FRITZ!Box (die dann sicherlich ohnehin "Horst" heißen sollte).

Wer mir jetzt einreden will, die Konfiguration eines OpenWRT-Devices mit VoIP-Funktionalität (also mit Asterisk i.d.R.) hätte irgendetwas mit der Konfiguration bei AVM (oder einem der anderen IADs) gemein, der kennt vermutlich ebenfalls mind. eines von beiden nicht wirklich.

Wieviele Speedport-Router werden eigentlich derzeit "von irgendeiner Community" unter den Gesichtspunkt, daß man da eigene Firmware bzw. eigene Erweiterungen installieren könnte, unterstützt? Am liebstem wären mir ja sogar die Links zu diesen ganzen Projekten ... ich stelle mich bei der Suche wohl zu blöd an - hier bietet sich die Chance, mir das mal so richtig zu zeigen. Oder sind diese Geräte am Ende eher ein Beispiel für tatsächlich "verrammelte" Systeme?

Es bringt aber am Ende eben nichts, wenn man Äpfel mit Pferdeäpfeln vergleicht ... beides hat seine Berechtigung und seine "Konsumenten". Wenn dann der eine beim anderen "nascht", ist die Enttäuschung (bis hin zur Empörung) vorprogrammiert.
 
Das möchte ich nicht bezweifeln.
Ich sagte ja schon Hut ab von Deiner Arbeit mit der man doch noch so Manches erreicht. (Ich habe aktuell von AVM jetzt eine 7590 und da hab ich kein Bock zum basteln weil doch nicht völlig trivial)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.