Die Box ist aus (über Nacht Stecker gezogen).
Das ist ja durchaus eine vollkommen neue Information. Das Problem tritt also nur beim
ersten Start nach einer längeren ausgeschalteten Periode auf.
Auch wenn Du es vielleicht nicht glauben willst, ändert sich das "Blinkverhalten" einer FRITZ!Box in Abhängigkeit vom Modell und der verwendeten Firmware, für das Blinken direkt beim Start ist z.B. der Bootloader zuständig. Daher fehlt - so unnütz das in Deinen Augen auch sein mag - einfach noch einiges an Informationen zur Box und zur eingesetzten Firmware. Auch die Konfiguration "Zugang über LAN1" erwähnst Du mehr oder weniger nur am Rande, in diesem Modus gibt es jedoch ebenfalls verschiedene Kombinationen, die wurden schon mehrfach im IPPF durchgekaut und ich werde keine weitere Auflistung liefern. Auch die Konfiguration beeinflußt die Signalisierungsfunktion der Power-LED, da damit auch DSL-Zustände signalisiert werden. Was die LED gerade signalisiert, ergibt sich aus dem Blinkrhythmus - auch da fehlt die konkrete Info. Ein "2s ein, 1s aus"-Blinken steht für eine andere Information als ein "1s ein, 2s aus"-Blinken. Solltest Du das nicht glauben wollen, probiere es einfach mit "led-ctrl" und den verschiedenen dort möglichen Signalen aus.
So blinkt eine 7390 mit Bootloader-Version 1.1939 nicht wie von Dir beschrieben, sie setzt die zwei möglichen Farben gezielt zur Übermittlung von Informationen ein. Während in den ersten 5 Sekunden nach der ersten Aktivierung der Netzwerk-Ports ein FTP-Login in EVA möglich ist, sind alle grünen LEDs aus und nur die Info-LED blinkt rot (3x, mit
2 1 Hz symmetrisch, also 0,5s ein, 0,5s aus), bevor die Power-LED (nach dem anfänglichen Initialisieren der GIO-PINs, bei dem erst einmal alle LEDs ganz kurz (< 0,3s) an waren, bei den zweifarbig hinterlegten Sichtschlitzen sogar die beiden dort möglichen Farben,was in Richtung orange geht) beginnt zu blinken, während das "finale" Linux in der Box geladen wird (also die eigentliche "Betriebs"-Firmware). Spätestens beim Beginn einer DSL-Synchronisierung ändert sich dann der Blinkrhythmus, in aller Regel bereits vorher.
Andere Bootloader-Versionen (und andere FRITZ!Box-Modelle) blinken während der "FTP-Bereitschaft von EVA" tatsächlich mit der Power-LED, die Pause danach ergibt sich dort dann aus der Zeit, die für das Laden des Kernels bis zum Initialisieren des dort enthaltenen LED-Status-Modules (led_modul_Fritz_Box_
irgendwas.ko) benötigt wird. Wenn da die EVA mit der LED "durchblinkt", tritt das eigentlich nur dann auf, wenn tatsächlich jemand ein FTP-Login in die EVA ausführt, dann blinkt die LED während der gesamten Sitzung nämlich dauerhaft. Das kennt man vom Recovery-Programm, da blinkt die Power-LED ebenfalls durch - soweit ich mich richtig erinnere, ich habe in der Test-7390 eben einen anderen Loader und momentan auch absolut keine Lust, ein Recovery auf einer anderen Box nur zum Test zu machen - nicht mal für ein Reboot mit FTP-Login reicht das Interesse an einer nochmaligen Prüfung, bevor ich so etwas hier behaupte ... sollte ich mich tatsächlich irren, wird das schon jemand korrigieren.
Ob die Frequenz konstant ist bei allen Modellen, weiß ich nicht mehr (geht mir auch nicht so nahe, daß ich dafür eine Box "opfere" zum Testen). Bei der o.a. 7390 blinkt jedenfalls während der gesamten Dauer der FTP-Sitzung die Info-LED in rot, mit dem bereits erwähnten Schema (3x mit
2 1 Hz sym., gefolgt von 3s Pause).
Wenn also die LED tatsächlich wegen einer (EVA-)FTP-Sitzung permanent blinken sollte, könnte es durchaus sein, daß irgendeine Software im kabelgestützten Netzwerk (was natürlich ausfällt, wenn da gar keine Kabel dran stecken, was bei LAN1-Verbindung zwar komisch wäre, aber auch da fehlt einfach die notwendige Information) versucht, sich in den Bootloader der FRITZ!Box einzuloggen. Das wäre dann (wenn es sich um eine gezielte Aktion handelt) tatsächlich ein recht gefährliches Stück Software, da die FRITZ!Box zu diesem Zeitpunkt praktisch "nackt" ist. Ein Angreifer kann zu diesem Zeitpunkt schon einmal mind. das Urlader-Environment auslesen (mit dem WLAN-Key und der maca-Adresse, mit denen man dann einen Dump der Konfigurationsdateien der Box entschlüsseln kann) und - wieder vom Bootloader abhängig - auch einen Dump der Partitionen mit den Konfigurationseinstellungen (MTD3/MTD4) machen. Das ist aber pure Spekulation (auch wenn ich einen solchen theoretisch möglichen Angriff schon früher irgendwo hier beschrieben habe - ich glaube im Oktober 2014), solange man nicht wirklich weiß,
wo die Box beim Booten hängenbleibt. Das muß auf der anderen Seite nicht einmal eine Schadsoftware gezielt für die FRITZ!Box sein, das FTP-Prinzip ist ja "geerbt" von TI und es gibt viele Geräte, die auf diese Art und Weise (inkl. Antwort auf UDP-Broadcasts zum Auffinden der Box) arbeiten.
Nehmen wir aber mal an, es findet erst nach EVA (früher hieß der Bootloader ja "ADAM", daher auch das Login) etwas Merkwürdiges statt und überlegen weiter ...
Bemerkenswert ist ja tatsächlich, daß bei einer nicht für DSL-Zugang konfigurierten Box spätestens beim Start des "dsld" die Power-LED auf "dauerhaft ein" geschaltet werden sollte. Ob das aber tatsächlich an einem so frühen Hängenbleiben der Box liegt, daß gar kein Zugriff mehr möglich wäre, kann man anhand der LED-Signale einfach nicht feststellen. Ob die Box die LAN-Schnittstellen initialisiert hat und (nach dem Start des "telefon"-Daemons) ein Telnet-Login zur näheren Untersuchung möglich wäre, sieht man nur bei Modellen mit LAN-LEDs. Da hilft es unheimlich, wenn man einfach mal vom kabelgebundenen Netzwerk aus versucht, mit der Box Kontakt aufzunehmen und zwar noch jenseits des Web-GUI, da dieses nur dann verfügbar ist, wenn "ctlmgr" läuft. Auf ein "ping" würde sie tatsächlich schon vorher reagieren, je nach Zustand des sonstigen Systems u.U. auch auf ein Telnet-Connect. Das ist aber tatsächlich alles wieder von der Box abhängig und über welches Modell (und welche Firmware) wir hier reden, steht ja bedauerlicherweise nur auf Deiner Box daheim und nicht hier im Forum.
Die nächste Frage, die sich dann stellt ... die Box startet nicht etwa nach ca. 4-5 Minuten von selbst noch einmal? Eigentlich läuft während der Initialisierung des Betriebssystems ein Watchdog mit, der nach 240 Sekunden die Box neu starten sollte, wenn bis dahin das System nicht "Start abgeschlossen" signalisiert hat. In diesem Falle müßte die Box also entweder vor dem Initialisieren dieses Watchdogs bereits hängenbleiben oder nachdem sie der Meinung ist, der Startvorgang (das ist erst einmal etwas anderes als "alle Dienste laufen auch tatsächlich") wäre abgeschlossen. Je nach Modell ist das Blinken der LEDs auch nicht "in Hardware" umgesetzt, das würde dann bei blinkender LED heißen, daß rudimentäre Funktionen (Timer-Behandlung im LED-Treiber) tatsächlich noch funktionieren und der Prozessor nicht einfach nur stehen geblieben ist.
Ich hoffe, ich konnte meine Neugier "rechtfertigen" und Dir verdeutlichen, was die tatsächlich wichtigen Informationen in diesem Zusammenhang wären und wie Du - neben der Feststellung: "startet nicht" - das Phänomen etwas anschaulicher beschreiben könntest. Im Extremfall gehört dazu tatsächlich eine "Zeitleiste" mit dem jeweiligen "LED-Blinken" inkl. des Rhythmus. Selbst der zeitliche Abstand eines Blinkens zum "Einschalten" der Stromversorgung kann von Interesse sein, weil man aus der Beobachtung anderer Geräte desselben Modells dann auf die dort zu einem bestimmten Zeitpunkt normalerweise stattfindenden Vorgänge schließen kann. Wenn es sich bei Dir nicht um einen DSL-Anschluß handelt (die dort stattfindende Synchronisation ist tatsächlich nicht-deterministisch und damit nicht - im Rahmen von Fertigungstoleranzen - vergleichbar), ist das sogar eine recht gute Möglichkeit, wenn man eine Vorstellung davon kriegen will, wie weit die Box tatsächlich beim Starten kommt.
Andererseits ist es ja bei Dir offensichtlich tatsächlich ein Frage falscher Einstellungen ... ob daran am Ende die FRITZ!Box-Firmware wegen mangelhafter Plausibilitätsprüfung die Schuld trägt oder ob es nicht doch nur ein simpler "Anwenderfehler" ist, kann man sicherlich erst beurteilen, wenn man dann weiß, woran es tatsächlich scheitert.
Ab hier wieder OT, also ggf. nicht weiterlesen ... aus irgendwelchen Gründen verspür(t)e ich Druck, meine "unangebrachte Neugier", wo Dein Problem tatsächlich liegen könnte, zu verteidigen.
Wenn es sich tatsächlich um eine EVA-Sitzung handeln sollte (die kann zum Zeitpunkt des Bootens ja auch über LAN1 reinkommen, da die abweichende Funktion dieses LAN-Ports ja erst mit der Konfiguration durch "dsld"/"ctlmgr" wirksam wird), dann würde mich die Software, die diese Sitzung startet, tatsächlich brennend interessieren, da es das erste Auftreten einer bisher nur theoretisch beschriebenen Angriffsmöglichkeit auf eine FRITZ!Box mit kabelgebundenem Zugriff beim Starten der FRITZ!Box wäre. Ob es sich um eine EVA-Sitzung handelt, kriegt man mit einem Packetdump heraus, auch ein Start ohne jedes LAN-Kabel sollte dann eigentlich selbst beim erstem Mal funktionieren. Das unterschiedliche Verhalten bei "unkonfigurierter" Box nach einem Werksreset (wo andererseits noch nichts auszulesen wäre) und konfigurierter Box wäre damit zwar auch noch nicht abschließend erklärt, aber es sind ohnehin noch viel zu viele Fragen offen, bevor man tatsächlich ernsthaft auf einen "Angriff" auf den Bootloader und eine Schadsoftware tippen kann - das ist also meinerseits keine Aussage: "Das ist bestimmt eine solcher Angriff.", es ist nur das Aufzeigen einer solchen Möglichkeit. Daß es beim zweiten Start dann funktioniert, wäre aber tatsächlich auch zu erklären, wenn eine solche "Angriffssoftware" nicht auf mehrere Geräte eingerichtet wäre und ihrerseits in einer (wg. der Umsetzung einzigen zeitgleich möglichen) FTP-Sitzung so lange verweilt, bis die Box beim zweiten Start schon wieder über die Wartezeit in der EVA hinweg ist.
Aber es wäre auch ein Ansatz für einen (perfiden) "DoS-Angriff" auf eine FRITZ!Box (der setzt aber natürlich beim Booten der Box ein LAN-Kabel dorthin voraus), wenn man einfach immer wieder eine FRITZ!Box beim Start im EVA-FTP-Login anhält. Jedes Recovery nach "AVM-Vorschrift" (nur eine direkte Kabelverbindung zwischen Windows-PC und FRITZ!Box) würde reibungslos funktionieren und keine Besonderheiten aufzeigen. Schließt man dann die Box später wieder an den Rest des LANs an und dort lauert beim nächsten Start der Box wieder dieser Daemon, der erneut die EVA anhält, kann man einen Besitzer einer FRITZ!Box sicherlich in den Wahnsinn treiben, denn das gibt vollkommen sinnlos erscheinende Fehlerbilder, wo in 99,9% der Fälle jeder Experte erst einmal mit dem Austausch aller möglichen Netzwerkkomponenten von Kabeln bis Switches beginnt, was natürlich nur wenig helfen würde, solange das Gerät mit dem "DoS-Daemon" an der Box steckt beim Booten.
Das wird zwar vermutlich alles bei Dir eher nicht zutreffen, aber es ist auch nicht nur eine Fabel oder Sage ... es ist tatsächlich möglich, eine Box auf diese Weise aus dem LAN anzugreifen.
AVM hat mit geringfügigen Änderungen am Bootloader aber durchaus Möglichkeiten, dem - auch bei der derzeitigen Architektur der Boxen - entgegen zu wirken ... was dem am Ende entgegensteht (außer einer zusätzlich notwendigen Interaktion des Benutzers vor Ort durch rechtzeitiges Drücken irgendwelcher Buttons an der Box), weiß nur AVM alleine. Ob man dem "normalen Benutzer" das nicht zutraut oder ob der am Ende tatsächlich zu blöd wäre, bei Recovery auch noch der Ansage im Fenster des Recovery-Programms "Drücken Sie innerhalb von 2 Sekunden nach dem Einschalten den WLAN-Knopf an der Box für mind. 2 Sekunden." zu folgen, wenn er das mit dem "Stecker raus, Stecker rein" schon begriffen hat, kann und will ich nicht einschätzen (es gibt Geräte mit komplizierterer Recovery-Prozedur), aber es würde ein nicht gewünschtes FTP-Login in den Bootloader ziemlich wirksam verhindern. Die Reaktion "Danke für Ihren Vorschlag ... wir haben ihn weitergeleitet." war/ist absehbar, damit können einige wahrscheinlich Wände tapezieren.
Wahrscheinlich wird sich erst dann etwas tun, wenn entsprechende Schadsoftware tatsächlich "in the wild" auftaucht. Angesichts der Verbreitung der FRITZ!Boxen in Deutschland und unter Berücksichtigung des modellübergreifend (weitgehend) einheitlichen Vorgehens ist das in absehbarer Zeit ein durchaus lohnendes Angriffsziel (vor der webcm-Lücke hätte ja auch jeder abgewunken mit der Begründung, daß sich ein speziell auf FRITZ!Boxen zugeschnittener Angriff nicht lohnen würde). Daß sich solche Angriffe aber tatsächlich immer mehr von einzelnen Geräten auf die zentralen Komponenten im Heim-Netz verlagern, ist erstens verständlich (ein Router ist eben immer an und in der Regel auch immer anwesend, anders als ein Handy oder Tablet oder Notebook) und zweitens ja eine nicht nur von mir konstatierte (und seit 2013 prognostizierte) Entwicklung. Wenn schon heise.de Angriffe auf Router zum Anlaß nimmt, in der c't (die ja nun keine Computer-Bild ist und in aller Regel fachkundige Leserschaft hat) einige Artikel zum Thema "Routersicherheit" zu publizieren, dann sicherlich nicht, weil das Thema "keine Sau interessiert". Es trifft auch nicht nur AVM-Router, aus dem LAN sind viele dieser Geräte überraschend leicht angreifbar, weil man zum Zeitpunkt der Entwicklung der meisten dort eingesetzten Firmware-Versionen das LAN eben immer als "safe harbor" angesehen hat und heutzutage eben z.B. mit Angriffen auf die WebView-Komponente in älteren Android-Versionen mit Lücken in Geräten im LAN konfrontiert ist, die man einfach nicht berücksichtigt hat.
Damit ist das LAN für einen Router heute in aller Regel genauso gefährlich, wie das WAN ... mit dem großen Unterschied, daß nach innen eigentlich kein Consumer-Gerät die simpelsten Sicherheitsvorkehrungen (z.B. den ausschließlichen TLS-Zugriff auf das Konfigurationsinterface) berücksichtigt.
Wenn sich Angreifer tatsächlich nur auf die "Profi-Geräte" konzentrieren würden (die solche Fehler in aller Regel nicht enthalten, weil Administratoren/Einkäufer entsprechende Anforderungen stellen) bzw. wenn tatsächlich auch in Firmen (und sei es im Home-Office von Mitarbeitern) immer solche Profi-Geräte anstelle von den dann doch "schon vorhandenen Consumer-Geräten" zum Einsatz kämen, dann wäre die Welt wahrscheinlich auch noch in Ordnung.
Aber erstens überwiegen wohl die Consumer-Anschlüsse (zunehmend All-IP-Anschlüsse mit IADs, wo sich aus einem erfolgreichen Angriff dann mit einiger Wahrscheinlichkeit auch wieder Kapital schlagen läßt, selbst gegen die Vorwarn-Systeme der Provider, wenn man es nicht übertreibt mit dem Aufbau von kostenpflichtigen Verbindungen) und zweitens wird sich wohl kaum eine Firma von einem Erpressungs-Trojaner o.ä. beeindrucken lassen (solange der nur droht und nicht tatsächlich verschlüsselt hat, dann bricht auch in Firmen die pure Verzweiflung aus).
Aber ein Consumer-Router als Bestandteil eines Bot-Netzes (auch das hatten wir für OpenWRT-Geräte ja schon, das geht prinzipiell natürlich auch mit FRITZ!Boxen) ist eben auch nicht zu verachten, mit einem 10 MBit/s-Upload an einen (voll funktionsfähigen) VDSL50-Anschluß kann man eben schon ganz schön Betrieb machen. Davon reichen schon 10 Stück (selbst wenn die danach vielleicht "verbrannt" sind) für einen DDoS-Angriff auf eine 100 MBit/s-Anbindung eines Servers (wenn dort keine Maßnahmen dagegen getroffen werden) und selbst für eine 1 GBit/s-Anbindung braucht man nur 100 davon. Wenn man sich dann die Größe ausgehobener Botnetze ansieht (die letzte diesbezügliche Meldung bei heise.de betraf 170.000 Bots, wenn ich mich richtig erinnere, auch wenn das natürlich nicht alles in D und VDSL50 ist), dann merkt man schnell, daß es bei einem Botnetz eben die Masse macht und da nimmt man selbst den ADSL2+-basierten 16.000-Anschluß mit 1 MBit/s im Upload gerne.
Selbst die (gezielte) Identifikation solcher potentiellen Angriffsziele (wenn man nicht gleich mit "brute force" auf alle FRITZ!Boxen losgehen will, die man anhand von SIP-Responses leicht identifizieren kann, auch ohne freigeschalteten FTP-Server oder Fernwartung, aber dann fehlt einem ohnehin noch der Zusammenhang zu einem Konto für einen Login-Versuch und ein Mißbrauch eines solchen Routers wäre nur wieder über eine Sicherheitslücke möglich, die sich von extern ausnutzen läßt) ist ja nicht allzu schwer. Schon die Information, daß ein Google-Konto aus dem Play-Store eine FRITZ!irgendwas-App von AVM geladen hat, ist ja ein deutliches Zeichen, daß da wohl irgendwo noch eine FRITZ!Box zu finden sein müßte ... bliebe noch ein Test, ob an einem solchen Google-Konto (i.d.R. ja eine E-Mail-Adresse als "Benutzername") vielleicht auch noch ein MyFRITZ!-Konto hängt. Die beiden Ausgangsinformationen (FRITZ!-App vorhanden, Google-Play-Konto) dürfte so ziemlich jede Android-App von "ihrem" Gerät schon sammeln können, die WebView-Lücke ist bekannt und wird wohl nicht geschlossen werden.
