[Info] FRITZ!Box 7490 Labor-Firmware Version 6.10-28178 vom 13.06.2014
- Ersteller Wotan-Box
- Erstellt am
DickS
Aktives Mitglied
- Mitglied seit
- 22 Feb 2005
- Beiträge
- 2,285
- Punkte für Reaktionen
- 132
- Punkte
- 63
Die LEDs kann man über eine versteckte Seite komplett abschalten. Sufu nutzen und ruhe ist im Schlafzimmer...
Hier gehts nicht um Ruhe, sondern um Dunkelheit... Lies einfach die vorangehenden Beiträge... :-Ö
DickS
Aktives Mitglied
- Mitglied seit
- 22 Feb 2005
- Beiträge
- 2,285
- Punkte für Reaktionen
- 132
- Punkte
- 63
Ähm, willst du alle LEDs ausschalten? Wenn ja gibt es eine Seite dafür im Adminbereich wo du das machen kannst. Früher war die Seite mal im menü, aber schon länger nicht mehr. Damit kannst du alle LEDs dauerhaft ausschalten. Vielleicht habe ich etwas nicht verstanden 
?
?Wenn du die Beiträge gelesen hast, hast du nix verstanden, ich vermute aber, du hast nicht gelesen...
Alufolie ... is klar .
Das Problem an der versteckten Seite, um die LED's abzuschalten ist ja die Tatsache, dass sie seit einigen Labor's wieder versteckt ist ... AVM, bringt sie wieder "in's Licht" *bettel* .
.Das Problem an der versteckten Seite, um die LED's abzuschalten ist ja die Tatsache, dass sie seit einigen Labor's wieder versteckt ist ... AVM, bringt sie wieder "in's Licht" *bettel*
.Ok, die Centbeträge werde ich bei meiner Stromrechnung verkraften. Wegen der Helligkeit habe ich beim Erwerb der Fritzbox diese direkt in die Diele verschoben. Mein alter Router hatte blaue LEDs und die haben das Schlafzimmer schon ganz schön erhellt. Nun ist es bei mir stockeduster und es schläft sich besser.
IPTV friert nach etwa 5 Sekunden ein
Hallo zusammen.
Ich habe gestern das Update auf von der 6.10.28067 auf die 6.10.28178 gemacht.
Soweit hat auch alles ohne Probleme funktioniert.
Leider funktioniert seit dem Update mein IPTV (T-Entertain) nicht mehr.
Wenn ich am MR303 den Sender wechsle, wird für etwa 5 Sekunden Bild und Ton angezeigt.
Danach friert das Bild und der Ton ein. Bei einem weiteren Senderwechsel ist dies ebenso.
Der MR303 ist wie folgt mit der FBF7390 verwunden:
FBF7390 (LAN2 / 1000MBit) --- Devolo 500Mbit --- Devolo AVtriple500Mbis --- MR303
Danach habe ich folgendes ohne Erfolg versucht:
- Recovery of 6.03
- Update auf 6.10.28067
Jetzt hat die FBF7390 zwar wieder die 6.10.28067, aber das Problem mit IPTV besteht weiterhin.
Woran kann dies liegen und wie kann ich dieses Problem wieder beheben?
Danke + viele Grüße
Nachtrag #1:
Kann bitte jemand den Thread in den 7390er Zweig der FW schieben?
Nachtrag #2:
Reboot des MR303 hat leider auch nichts gebracht :-(
Hallo zusammen.
Ich habe gestern das Update auf von der 6.10.28067 auf die 6.10.28178 gemacht.
Soweit hat auch alles ohne Probleme funktioniert.
Leider funktioniert seit dem Update mein IPTV (T-Entertain) nicht mehr.
Wenn ich am MR303 den Sender wechsle, wird für etwa 5 Sekunden Bild und Ton angezeigt.
Danach friert das Bild und der Ton ein. Bei einem weiteren Senderwechsel ist dies ebenso.
Der MR303 ist wie folgt mit der FBF7390 verwunden:
FBF7390 (LAN2 / 1000MBit) --- Devolo 500Mbit --- Devolo AVtriple500Mbis --- MR303
Danach habe ich folgendes ohne Erfolg versucht:
- Recovery of 6.03
- Update auf 6.10.28067
Jetzt hat die FBF7390 zwar wieder die 6.10.28067, aber das Problem mit IPTV besteht weiterhin.
Woran kann dies liegen und wie kann ich dieses Problem wieder beheben?
Danke + viele Grüße
Nachtrag #1:
Kann bitte jemand den Thread in den 7390er Zweig der FW schieben?
Nachtrag #2:
Reboot des MR303 hat leider auch nichts gebracht :-(
Zuletzt bearbeitet:
Gulaschsuppe
Neuer User
- Mitglied seit
- 17 Jul 2008
- Beiträge
- 130
- Punkte für Reaktionen
- 0
- Punkte
- 16
@ IT-ler
Mach mal einen Fallback auf die Version "FW fritzbox-labor-7490-27948". Habe ein ähnliches Problem mit einer WLAN-Bridge und die FW behebt das Problem erstmal wieder.
Siehe auch Beitrag #30
Nachtrag.....
ähhh, sorry...... redest du von der 7390? Da hatte ich nich drauf geachtet..... ich rede von der 7490 in diesem Thread......
Mach mal einen Fallback auf die Version "FW fritzbox-labor-7490-27948". Habe ein ähnliches Problem mit einer WLAN-Bridge und die FW behebt das Problem erstmal wieder.
Siehe auch Beitrag #30
Nachtrag.....
ähhh, sorry...... redest du von der 7390? Da hatte ich nich drauf geachtet..... ich rede von der 7490 in diesem Thread......
Zuletzt bearbeitet:
@IT-ler: Sorry, ich kann Dir nicht direkt helfen, nur soviel, bei mir läuft die fast gleiche Konstellation (statt FB7390 die FB7490, statt Devolo AVM Powerline 520E) einwandfrei. Ich empfehle den MR303 zu rebooten, denn der zickt schon mal rum.
Gruß Famagusta
PS: Irgendwie bist Du im falschen Thread gelandet ?! Hier geht´s um die Labor zur FB7490
Gruß Famagusta
PS: Irgendwie bist Du im falschen Thread gelandet ?! Hier geht´s um die Labor zur FB7490
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Eine gute Nachricht für Nutzer eines "benutzerdefinierten Dynamic DNS-Anbieters":
Die Kombination aus <ip6addr> oder <dualstack> mit <b64> für die Base64-Kodierung in einer Update-URL funktioniert jetzt endlich. Früher entstand bei der gemeinsamen Nutzung dieser Variablen mit Base64-Kodierung immer eine URL, die offensichtlich aus einer ungeplanten Schleife bis zum kompletten Füllen (oder event. sogar Überlaufen) des dafür vorgesehenen Buffers resultierte.
Die Kombination aus <ip6addr> oder <dualstack> mit <b64> für die Base64-Kodierung in einer Update-URL funktioniert jetzt endlich. Früher entstand bei der gemeinsamen Nutzung dieser Variablen mit Base64-Kodierung immer eine URL, die offensichtlich aus einer ungeplanten Schleife bis zum kompletten Füllen (oder event. sogar Überlaufen) des dafür vorgesehenen Buffers resultierte.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Und die weniger guten Nachrichten hinterher ...
Trotz erstarktem Sicherheitsbewußtsein bei AVM (das darf man sicherlich zu Recht vermuten), bleiben einige potentielle Sicherheitslücken weiterhin erhalten. Die Aufzählung erhebt weder einen Anspruch auf Vollständigkeit noch stellt die Reihenfolge irgendeine Bewertung der Schwere des Problems dar. Allen aufgezählten Punkten ist nur gemeinsam, daß sie mit sehr geringem bis gar keinem Aufwand geschlossen werden könnten und eigentlich unnötig wären.
1. AVM verläßt sich beim VPN immer noch darauf, daß Pakete an VPN-Gegenstellen in jedem Falle über die "default route" auch an "dev dsl" gehen ... was sich problemlos über das GUI anders einstellen läßt. Das ist allerdings vorwiegend nur ärgerlich und auch nur unter einigermaßen konstruierten Umständen wirklich ein Sicherheitsproblem. Aber das Einrichten einer entsprechenden Route beim Etablieren einer IPSec-SA ist ja nun wirkliche keine zusätzliche Belastung, braucht allerdings eine Änderung in einem AVM-Binary.
2. Die 169.254.1.1 als fester Anker einer Fritz!Box im LAN bleibt immer noch ewig aktiv. Da es ohnehin schon eine Stelle gibt, wo nach 10 Minuten Uptime einige Kommandos ausgeführt werden (in diesem Falle das Ermitteln des Speicherverbrauchs dynamisch geladener Kernel-Module), sollte es für AVM kein Problem sein, diese Adresse (egal ob man das nun Zeroconf oder APIPA nennt) auch einfach abzuschalten. Ein Password-Reset funktioniert auch nur eine begrenzte Zeit nach einem Neustart, warum muß das mit dieser "Notfall"-Adresse anders sein ? Die potentielle Gefahr, die davon ausgeht, sieht man bei AVM offenbar immer noch nicht allzu verbissen. Es kostet eine oder meinetwegen auch zwei Zeilen Shell-Code, diese Adresse nach 10 Minuten einfach zu deaktivieren.
3. Ein per USB angeschlossener Speicher wird auch bei einer vollkommen unkonfigurierten Box bereits per FTP (und zwar ohne jeglichen Zugriffsschutz durch Benutzerkonten) im LAN zugänglich gemacht. Das ist bei "normalen" Boxen vielleicht nur eine Randnotiz wert. Bei einer Box, die vom Provider aus der Ferne auf Werkseinstellungen zurückgesetzt werden kann, unterläuft es jedoch so ziemlich jede Vorkehrung, die der Besitzer/Benutzer der Box getroffen haben könnte ... vom Einrichten einer Berechtigungsstruktur bis zur Fixierung eines USB-Sticks per Sekunden- oder Heißkleber genau an dieser - vermeintlich - sicher konfigurierten Fritz!Box. Um den Start des FTP-Servers im unkonfigurierten Zustand zu verhindern, reichen wenige Zeilen (ich sag mal < 5) Skript-Code.
4. Das mit der Aktivierung im unkonfigurierten Zustand gilt auch für den WLAN-Zugang. Selbst wenn man davon ausgehen will, daß eine Fritz!Box automatisch immer über WLAN konfiguriert wird, ist das zusätzliche einmalige Drücken des WLAN-Buttons am Gerät für die Aktivierung des WLANs sicherlich keine zu große Hürde. Ich behaupte auch, 19 von 20 Fritz!Box-Besitzern müßten beim Zurücksetzen auf Werkseinstellungen für das Konfigurieren per WLAN die Box ohnehin erst einmal von der Wand reißen, um den hinten aufgebrachten Standard-Key für den WLAN-Zugang abzulesen. Um den Standardwert für diese WLAN-Aktivierung zu ändern, reicht eine einzelne Einstellung in den Default-Files aus (bei Dual-WLAN dann eben zwei).
5. Auch wenn der standardmäßige WLAN-Name nicht wirklich ein Sicherheitsrisiko darstellt (der Typ des AP ließe sich ja auch anhand der MAC-Adresse ermitteln), bringt es in dichter besiedelten Gebieten doch ab und an Probleme. Wenn AVM bei der Konfiguration vor der Einrichtung des Internetzugangs erst einmal einen Assistenten zur Einrichtung (bzw. bei fehlenden Clients auch zur Deaktivierung) des WLANs anbieten würde, hießen sicherlich wesentlich weniger 1&1-Homeserver "FRITZ!Box Fon WLAN xxxx" und deren Besitzer würden u.U. einiges an Strom sparen sowie die Nachbarn weniger stören. Auch wenn das für viele trivial klingen mag, es gibt genug Leute, die nach dem 1&1-Prinzip ihren Anschluß in Betrieb genommen haben und daran noch einen uralten PC ohne WLAN als einzigen Client betreiben. Diese haben - aus reiner Unkenntnis - dann eben trotzdem ihr WLAN ... und zwar mit dem hinten draufstehenden Standard-Key und dem Box-Typ direkt in der SSID.
6. Die automatische Provisionierung einer Fritz!Box nach dem Rücksetzen auf Werkseinstellung seitens des Providers ermöglicht den "verdeckten" Zugriff des Providers. Nach einem vom Nutzer initiierten Reset mag der Automatismus Sinn machen (auch wenn viele sicherlich eine Sicherung einspielen werden) ... wenn er aber auch nach einem providerseitigen Reset greift, kann der Provider zurücksetzen, in diesem Zustand eigentlich nicht vorgesehene Zugriffe ausführen und anschließend einfach wieder neu zurücksetzen. Der Benutzer kriegt von den zwischen dem ersten und zweiten Rücksetzen ausgeführten Aktionen nichts mit, eine entsprechende Protokollierung gibt es nicht. Wenn man hier die neue Provisionierung z.B. erst nach dem Drücken einer/beider Tasten zuläßt - nur wenn das Reset providerseitig war -, schiebt man dieser Möglichkeit einen Riegel vor.
7. Der FTP-Server "verrät" bei aktiviertem externen Zugriff, ob die Fritz!Box im LAN ohne Anmeldung arbeitet. Ein Zugriff ist allerdings nicht möglich. Insofern kann ein Angreifer daraus nur die Information: "Bist Du erst einmal im LAN, bist Du automatisch in der Fritz!Box." ziehen. Auch wenn AVM den Betrieb ohne Anmeldung ausdrücklich nicht empfiehlt, verhindert man ihn jedoch nicht und damit ist das "information disclosure".
8. Was den automatisch aktivierten DHCP-Server angeht, kann man sicherlich unterschiedlicher Meinung sein. Wer allerdings schon einmal eine Fritz!Box als "vagabundierenden" DHCP-Server in seinem Netz hatte, wird mir sicherlich zustimmen, daß es gar nicht lustig ist, wenn dieser irgendwelche LAN-Clients "einfängt" und dann direkt ins Internet verbindet. Auch hier sollte (gerade bei providerseitig auslösbarem Reset) der DHCP-Server erst im "Erstkonfigurationsmodus" gestartet werden.
Die Verbesserung des SSL-Handlings hat AVM ja inzwischen in Angriff genommen, das Ergebnis kann man erst in der finalen Version beurteilen.
Die aufgeführten Probleme sind sicherlich allesamt kein Grund, gleich wieder "Skandal" zu schreien ... aber im Zuge eines neuen Sicherheitsbewußtseins bei AVM würde ich zumindest für einige eine Lösung erwarten.
Trotz erstarktem Sicherheitsbewußtsein bei AVM (das darf man sicherlich zu Recht vermuten), bleiben einige potentielle Sicherheitslücken weiterhin erhalten. Die Aufzählung erhebt weder einen Anspruch auf Vollständigkeit noch stellt die Reihenfolge irgendeine Bewertung der Schwere des Problems dar. Allen aufgezählten Punkten ist nur gemeinsam, daß sie mit sehr geringem bis gar keinem Aufwand geschlossen werden könnten und eigentlich unnötig wären.
1. AVM verläßt sich beim VPN immer noch darauf, daß Pakete an VPN-Gegenstellen in jedem Falle über die "default route" auch an "dev dsl" gehen ... was sich problemlos über das GUI anders einstellen läßt. Das ist allerdings vorwiegend nur ärgerlich und auch nur unter einigermaßen konstruierten Umständen wirklich ein Sicherheitsproblem. Aber das Einrichten einer entsprechenden Route beim Etablieren einer IPSec-SA ist ja nun wirkliche keine zusätzliche Belastung, braucht allerdings eine Änderung in einem AVM-Binary.
2. Die 169.254.1.1 als fester Anker einer Fritz!Box im LAN bleibt immer noch ewig aktiv. Da es ohnehin schon eine Stelle gibt, wo nach 10 Minuten Uptime einige Kommandos ausgeführt werden (in diesem Falle das Ermitteln des Speicherverbrauchs dynamisch geladener Kernel-Module), sollte es für AVM kein Problem sein, diese Adresse (egal ob man das nun Zeroconf oder APIPA nennt) auch einfach abzuschalten. Ein Password-Reset funktioniert auch nur eine begrenzte Zeit nach einem Neustart, warum muß das mit dieser "Notfall"-Adresse anders sein ? Die potentielle Gefahr, die davon ausgeht, sieht man bei AVM offenbar immer noch nicht allzu verbissen. Es kostet eine oder meinetwegen auch zwei Zeilen Shell-Code, diese Adresse nach 10 Minuten einfach zu deaktivieren.
3. Ein per USB angeschlossener Speicher wird auch bei einer vollkommen unkonfigurierten Box bereits per FTP (und zwar ohne jeglichen Zugriffsschutz durch Benutzerkonten) im LAN zugänglich gemacht. Das ist bei "normalen" Boxen vielleicht nur eine Randnotiz wert. Bei einer Box, die vom Provider aus der Ferne auf Werkseinstellungen zurückgesetzt werden kann, unterläuft es jedoch so ziemlich jede Vorkehrung, die der Besitzer/Benutzer der Box getroffen haben könnte ... vom Einrichten einer Berechtigungsstruktur bis zur Fixierung eines USB-Sticks per Sekunden- oder Heißkleber genau an dieser - vermeintlich - sicher konfigurierten Fritz!Box. Um den Start des FTP-Servers im unkonfigurierten Zustand zu verhindern, reichen wenige Zeilen (ich sag mal < 5) Skript-Code.
4. Das mit der Aktivierung im unkonfigurierten Zustand gilt auch für den WLAN-Zugang. Selbst wenn man davon ausgehen will, daß eine Fritz!Box automatisch immer über WLAN konfiguriert wird, ist das zusätzliche einmalige Drücken des WLAN-Buttons am Gerät für die Aktivierung des WLANs sicherlich keine zu große Hürde. Ich behaupte auch, 19 von 20 Fritz!Box-Besitzern müßten beim Zurücksetzen auf Werkseinstellungen für das Konfigurieren per WLAN die Box ohnehin erst einmal von der Wand reißen, um den hinten aufgebrachten Standard-Key für den WLAN-Zugang abzulesen. Um den Standardwert für diese WLAN-Aktivierung zu ändern, reicht eine einzelne Einstellung in den Default-Files aus (bei Dual-WLAN dann eben zwei).
5. Auch wenn der standardmäßige WLAN-Name nicht wirklich ein Sicherheitsrisiko darstellt (der Typ des AP ließe sich ja auch anhand der MAC-Adresse ermitteln), bringt es in dichter besiedelten Gebieten doch ab und an Probleme. Wenn AVM bei der Konfiguration vor der Einrichtung des Internetzugangs erst einmal einen Assistenten zur Einrichtung (bzw. bei fehlenden Clients auch zur Deaktivierung) des WLANs anbieten würde, hießen sicherlich wesentlich weniger 1&1-Homeserver "FRITZ!Box Fon WLAN xxxx" und deren Besitzer würden u.U. einiges an Strom sparen sowie die Nachbarn weniger stören. Auch wenn das für viele trivial klingen mag, es gibt genug Leute, die nach dem 1&1-Prinzip ihren Anschluß in Betrieb genommen haben und daran noch einen uralten PC ohne WLAN als einzigen Client betreiben. Diese haben - aus reiner Unkenntnis - dann eben trotzdem ihr WLAN ... und zwar mit dem hinten draufstehenden Standard-Key und dem Box-Typ direkt in der SSID.
6. Die automatische Provisionierung einer Fritz!Box nach dem Rücksetzen auf Werkseinstellung seitens des Providers ermöglicht den "verdeckten" Zugriff des Providers. Nach einem vom Nutzer initiierten Reset mag der Automatismus Sinn machen (auch wenn viele sicherlich eine Sicherung einspielen werden) ... wenn er aber auch nach einem providerseitigen Reset greift, kann der Provider zurücksetzen, in diesem Zustand eigentlich nicht vorgesehene Zugriffe ausführen und anschließend einfach wieder neu zurücksetzen. Der Benutzer kriegt von den zwischen dem ersten und zweiten Rücksetzen ausgeführten Aktionen nichts mit, eine entsprechende Protokollierung gibt es nicht. Wenn man hier die neue Provisionierung z.B. erst nach dem Drücken einer/beider Tasten zuläßt - nur wenn das Reset providerseitig war -, schiebt man dieser Möglichkeit einen Riegel vor.
7. Der FTP-Server "verrät" bei aktiviertem externen Zugriff, ob die Fritz!Box im LAN ohne Anmeldung arbeitet. Ein Zugriff ist allerdings nicht möglich. Insofern kann ein Angreifer daraus nur die Information: "Bist Du erst einmal im LAN, bist Du automatisch in der Fritz!Box." ziehen. Auch wenn AVM den Betrieb ohne Anmeldung ausdrücklich nicht empfiehlt, verhindert man ihn jedoch nicht und damit ist das "information disclosure".
8. Was den automatisch aktivierten DHCP-Server angeht, kann man sicherlich unterschiedlicher Meinung sein. Wer allerdings schon einmal eine Fritz!Box als "vagabundierenden" DHCP-Server in seinem Netz hatte, wird mir sicherlich zustimmen, daß es gar nicht lustig ist, wenn dieser irgendwelche LAN-Clients "einfängt" und dann direkt ins Internet verbindet. Auch hier sollte (gerade bei providerseitig auslösbarem Reset) der DHCP-Server erst im "Erstkonfigurationsmodus" gestartet werden.
Die Verbesserung des SSL-Handlings hat AVM ja inzwischen in Angriff genommen, das Ergebnis kann man erst in der finalen Version beurteilen.
Die aufgeführten Probleme sind sicherlich allesamt kein Grund, gleich wieder "Skandal" zu schreien ... aber im Zuge eines neuen Sicherheitsbewußtseins bei AVM würde ich zumindest für einige eine Lösung erwarten.
@PeterPawn:
Du musst bedenken, dass ist eine Consumer Box. Also so Sachen wie WLAN order DHCP per default aus werden nie kommen und machen absolut keinen Sinn. Das ist auch nicht im Sinne der Großkunden (wie 1&1 oder UnityMedia), weil das mit erhöhtem Support-Aufwand verbunden ist. Außerdem sind viele weitere deiner Forderungen Snake-Oil, da sie nur Sicherheit vortäuschen.
Ich gehe mal auf die Punkte ein:
1. Hat nicht wirklich Priorität, Fix würde aber Sinn machen.
2. Würde den Supportaufwand bei Problemen erhöhen und ein Entfall bietet keine wirklichen Sicherheitsgewinn. Adressen in LAN kann man scannen. Das WebInterface wird mal also auf unter eine geänderten Standard IP finden.
3. Paranoid und verkompliziert die Benutzung für den Ahnungslosen User
4. Die meisten Anwenden benutzen Heute WLAN. Es macht also Sinn dass das eingeschaltet ist. Supportaufwand, wenn nicht
5. Schwachsinn/Pseudosicherheit. Genauso könntest du verlangen die SSID per default zu verstecken. Allerdings wären eindeutige Namen per default sinnvoll.
6. Support Aufwand
7. Nicht relevant. Die Sicherheit würde dadurch nicht nennenswert erhöht, wenn das Passwort ausreichend stark ist.
8. Völlig impraktikabel dem Privatanwender einen Router nicht ausgeschalteten DHCP zuzumuten.
Du musst bedenken, dass ist eine Consumer Box. Also so Sachen wie WLAN order DHCP per default aus werden nie kommen und machen absolut keinen Sinn. Das ist auch nicht im Sinne der Großkunden (wie 1&1 oder UnityMedia), weil das mit erhöhtem Support-Aufwand verbunden ist. Außerdem sind viele weitere deiner Forderungen Snake-Oil, da sie nur Sicherheit vortäuschen.
Ich gehe mal auf die Punkte ein:
1. Hat nicht wirklich Priorität, Fix würde aber Sinn machen.
2. Würde den Supportaufwand bei Problemen erhöhen und ein Entfall bietet keine wirklichen Sicherheitsgewinn. Adressen in LAN kann man scannen. Das WebInterface wird mal also auf unter eine geänderten Standard IP finden.
3. Paranoid und verkompliziert die Benutzung für den Ahnungslosen User
4. Die meisten Anwenden benutzen Heute WLAN. Es macht also Sinn dass das eingeschaltet ist. Supportaufwand, wenn nicht
5. Schwachsinn/Pseudosicherheit. Genauso könntest du verlangen die SSID per default zu verstecken. Allerdings wären eindeutige Namen per default sinnvoll.
6. Support Aufwand
7. Nicht relevant. Die Sicherheit würde dadurch nicht nennenswert erhöht, wenn das Passwort ausreichend stark ist.
8. Völlig impraktikabel dem Privatanwender einen Router nicht ausgeschalteten DHCP zuzumuten.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
@megakeule:
Und warum z.B. ein nicht aktivierter FTP-Server - im Vergleich zu einem aktivierten - "Schlangenöl" sein soll, müßtest Du vielleicht begründen. Ist der Server aus, ist er aus ... fertig, da wird nichts vorgetäuscht.
Das mit dem höheren Supportaufwand bezeichne ich nun meinerseits mal als Schwachsinn (Du hast damit angefangen) ... die erste Aktion so ziemlich jeder Support-Hotline ist mal die Frage: "Haben Sie das Gerät denn schon mal neu gestartet?". Über die dabei immer wieder erfolgende "Vernichtung" von sinnvollen Informationen zur Fehlersuche rede ich erst gar nicht.
Und nun mal ehrlich ... Adressen im LAN kann man scannen ? Wirklich ? :blonk:
Und nur weil ich vielleicht paranoid bin, ist das skizzierte Szenario ja noch lange nicht unmöglich ... gerade bei diesem Punkt sind die Voraussetzungen gleich null.
Wenn man das Argument mit "die meisten benutzen es eh" ernst nimmt, hätte man gleich den Button weglassen sollen. Ich möchte nicht wissen, wie oft irgendwo in D die Dame des Hauses schon beim Staubwischen das WLAN gekillt hat ... das nenne ich dann erhöhten Supportaufwand.
[Sarkasmus]
Wenn man dem Nutzer nicht einmal das Drücken irgendwelcher Tasten zutraut, warum gibt es dann noch so komplizierte Mechanismen wie einen Startcode ? Einfacher wäre es dann doch, die Boxen gleich fertig konfiguriert auszuliefern ... ah, ich weiß, der Aufwand ist zu hoch.
[/Sarkasmus]
Das mit dem "Privatanwender" kann ich - ehrlich gesagt - auch nicht mehr lesen ... die lautstarken Proteste von AVM, daß die Kabelbetreiber die Boxen auch für SOHO (oder SMB oder wie auch immer man es nennen will) anbieten, obwohl sie doch nur für Privatanwender gedacht sind, habe ich wahrscheinlich nur überhört.
Ich sage ja nicht, daß das alles ein Skandal ist, aber nur mit dem Argument "Support-Aufwand" kann man das auch nicht alles begründen.
Das muß ja noch nicht heißen, daß sich ein Angriff auf diese Geräte (gerade bei der oft behaupteten Marktdurchdringung der Boxen) nicht lohnen würde.
Sehe ich anders, die möglichen Angriffsflächen werden doch tatsächlich verkleinert. Wo liegt da die Täuschung ?
Und warum z.B. ein nicht aktivierter FTP-Server - im Vergleich zu einem aktivierten - "Schlangenöl" sein soll, müßtest Du vielleicht begründen. Ist der Server aus, ist er aus ... fertig, da wird nichts vorgetäuscht.
Ernsthaft ? Es ist ein gewaltiger Unterschied, ob ich für einen CSRF-Angriff ein LAN scannen muß (was vom Browser aus schwer bis unmöglich ist) oder ob ich eine fixe Adresse angreifen kann, hinter der sich dann mit einiger Wahrscheinlichkeit auch noch eine Fritz!Box verbirgt. Und diese Adresse ist nun mal der einzig unabänderliche Punkt einer Fritz!Box. Was spricht denn dagegen, das wie beim Passwort-Reset zu handhaben ?
Das mit dem höheren Supportaufwand bezeichne ich nun meinerseits mal als Schwachsinn (Du hast damit angefangen) ... die erste Aktion so ziemlich jeder Support-Hotline ist mal die Frage: "Haben Sie das Gerät denn schon mal neu gestartet?". Über die dabei immer wieder erfolgende "Vernichtung" von sinnvollen Informationen zur Fehlersuche rede ich erst gar nicht.
Und nun mal ehrlich ... Adressen im LAN kann man scannen ? Wirklich ? :blonk:
Wie ahnungslos muß bitte ein Nutzer sein, wenn er auf einer taufrischen, weil nicht konfigurierten, Box auf den FTP-Server zugreifen will ? Ist er ahnungslos, weiß er gar nicht, was ein FTP-Server ist. Nach der Erstkonfiguration der Box habe ich ja gar nichts dagegen, wenn er gestartet wird. Wenn die Box dann immer noch ohne Authentifizierung arbeitet und der Inhalt des USB-Speichers dadurch frei zugänglich ist, hat der Benutzer mindestens zwei diesbezügliche Warnungen bereits ignoriert.
Und nur weil ich vielleicht paranoid bin, ist das skizzierte Szenario ja noch lange nicht unmöglich ... gerade bei diesem Punkt sind die Voraussetzungen gleich null.
Ein Knopfdruck beim Einstecken des Netzteils ist zuviel des Guten ? Es eröffnet nun mal einen Angriffsvektor, den es nicht bräuchte. Auf der einen Seite wird jedem Nutzer empfohlen, ein eigenes starkes WLAN-Passwort einzustellen und auf der anderen Seite reicht ein Reset durch den Provider, wenn man gerade aus dem Haus ist, daß den ganzen Tag der Router mit seinem Standard-WLAN (selbst wenn das verschlüsselt ist) herumfunkt ? Das nur mit "Supportaufwand, wenn nicht" zu begründen ist genauso wenig fundiert, wie die früher oft von den Herstellern behaupteten Probleme, wenn man die Nutzer zur Verschlüsselung ihres WLANs auffordert. Und die meisten sind eben noch nicht alle ...
Wenn man das Argument mit "die meisten benutzen es eh" ernst nimmt, hätte man gleich den Button weglassen sollen. Ich möchte nicht wissen, wie oft irgendwo in D die Dame des Hauses schon beim Staubwischen das WLAN gekillt hat ... das nenne ich dann erhöhten Supportaufwand.
Erst Schwachsinn, dann allerdings ... wahrscheinlich haben wir uns hier mißverstanden. Ich erwarte von AVM auch für "Nichtfachleute" einen Einrichtungsassistenten, der ein ohnehin nicht benötigtes WLAN kurzerhand ausschaltet und so das Band und den Geldbeutel der Besitzer schont. Bei den Namen stimmst Du ja offenbar ohnehin zu, per default würde ich da aber nichts vorgeben. Es reicht schon, wenn man (kam ja irgendwann mal im Rahmen der Diagnose dazu) bei mehrfach in der Umgebung verwendeten SSIDs entsprechend zur Änderung zwingt (und am besten dabei den Standardnamen gar nicht mehr zuläßt, damit es gerecht bleibt). Zu "hidden SSIDs" äußere ich mich nicht mehr ...
Ist mir - ehrlich gesagt - Bummi ... wenn mein Provider meine Box (Miet- und kein Leihgerät, also bitte nicht nur nach dem Motto "Ist ja auch seine ...") remote zurücksetzen kann, anschließend irgendetwas (und ich habe da durchaus konkrete Möglichkeiten im Blick) anstellen und dann durch erneutes Rücksetzen alle Spuren tilgen kann, ist etwas grundsätzlich nicht in Ordnung. Wenn dann beim Provider nicht einmal protokolliert wird, wer wann zurückgesetzt hat, ist auch einem Mißbrauch Tür und Tor geöffnet.
Wenn Du nicht nur in der Nummerierung verrutscht bist, verstehe ich diese Antwort nun überhaupt nicht. Es geht hier darum, daß der FTP-Server bei aktiviertem externen Zugriff *ohne* Notwendigkeit verrät, daß intern ein Zugriff auf die Box ohne Authentifizierung möglich ist. Das heißt dann wieder, wenn es einem Angreifer gelingt, per CSRF irgendwie auf "fritz.box" zuzugreifen, steht ihm nichts weiter im Weg. Wenn das keine - vom Benutzer nicht gewünschte - Information ist, was wäre denn dann eine ? Und von welchem Passwort reden wir denn hier ? Es geht ja gerade um den Betrieb ohne Anmeldung ...
Entweder ich habe mich wirklich sehr unklar ausgedrückt oder Du hast die Idee des Starts der "Erstkonfiguration" durch einen oder beide Taster am Gerät nicht wirklich verstanden (der würde ja auch bei 3, 4, 6 und 8 eine Lösung sein). Ich will gar keine Fritz!Box ohne DHCP-Server ... ich will nur, daß die Box erst dann loslegt, wenn ich sie dazu auffordere.
[Sarkasmus]
Wenn man dem Nutzer nicht einmal das Drücken irgendwelcher Tasten zutraut, warum gibt es dann noch so komplizierte Mechanismen wie einen Startcode ? Einfacher wäre es dann doch, die Boxen gleich fertig konfiguriert auszuliefern ... ah, ich weiß, der Aufwand ist zu hoch.
[/Sarkasmus]
Das mit dem "Privatanwender" kann ich - ehrlich gesagt - auch nicht mehr lesen ... die lautstarken Proteste von AVM, daß die Kabelbetreiber die Boxen auch für SOHO (oder SMB oder wie auch immer man es nennen will) anbieten, obwohl sie doch nur für Privatanwender gedacht sind, habe ich wahrscheinlich nur überhört.
Ich sage ja nicht, daß das alles ein Skandal ist, aber nur mit dem Argument "Support-Aufwand" kann man das auch nicht alles begründen.
@PeterPawn Als denkender Mensch muss man dir, weil ein Großteil der Nutzer keine Ahnung hat, in allen Punkten zustimmen.
Gemacht wird es aber nicht, weil eben ein Großteil der Nutzer keine Ahnung hat.
Gemacht wird es aber nicht, weil eben ein Großteil der Nutzer keine Ahnung hat.
Danke,endlich sind die lichter aus.Die "inoffizielle" Seite http://fritz.box/system/led_display.lua funktioniert übrigens noch.
*edit* Yikes, das hier ist ja für die 7490 ... aber dort dürfte das Gleiche gelten, oder?
Stört doch sehr wenn der Router und das Bett im selben zimmer stehen,und dann die Fritzbox extrem hell leuchtet.
Gibt es davon noch mehr? Oder sonstige weitere Informationen in de Richtung?
Aber wenn ich den Text richtig interpretiere,leuchten die LED´s bei Updates,neustart u.s.w trozdem noch?
Wieso gibt es sowas in der GUI nicht offiziel?
wusel-09
Mitglied
- Mitglied seit
- 29 Mai 2009
- Beiträge
- 230
- Punkte für Reaktionen
- 3
- Punkte
- 18
Über den Sicherheitsgewinn kann man streiten – ich sehe ihn –; spätestens mit einer zweiten FB im Netz – ich habe 5 – wird die Nichtabschaltung der »Notfall-IP« zum Teil des Problems, statt Teil der Lösung zu sein. Denn es ist nicht deterministisch, welche meiner Boxen ich unter 169.254.1.1 erreiche; in Versuchen im normalen LAN war es nie die, die ich bearbeiten wollte/mußte. Gerade durch die Abschaltung der Notfall-IP nach Zeitablauf würde man Supportaufwände verringern — denn die ersten 10 Minuten nach dem Reboot ist selbst bei Murphy nur selten mehr als eine Box aktiv. Und der Trend geht aus meiner Sicht, auch wegen der Kabelbox-Problematik oder der ›ausbaufähigen‹ DECT-Performance, zur Zweit-FB. IMHO, YMMV.
Ich würde sogar soweit gehen und eine unkonfigurierte Box nur mit jener IP zu betreiben (und ohne DHCP-Server). Das würde nämlich verhindern, daß der Anschluß einer zweiten jungfräulichen – also auf 192.168.178.1 und als DHCP-Server laufenden – Box für Otto Normaluser zum Desaster wird. Ich jedenfalls fand es nicht lustig, als ich, in Berlin die 7170 faul auf 192.168.178.1 belassen, dort die 7570 zwecks Konfiguration für den kommenden VDSL-Anschluß anklemmte ... und kein Internet mehr hatte. Und keinen Zugriff auf die »Internet-FB«.
Ferner: durch die Pflicht zur Wahl des 192.168er Subnetzes – alternativ: pseudo-zufällig ausgewähltes 3. Oktett – wird später die Einrichtung eines VPNs erleichtert, denn die Chance, daß beide Seiten auf dem gleichen Netz sind, ist deutlich geringer.
In jedem Fall: Die Festlegung auf 192.168.178.0/24 halte ich für eine ... damals gut erscheinende, heute nicht mehr zeitgemäße und problematische, und daher zu revidierende, Designentscheidung; ein zufälliger Bereich bringt zwar, solange fritz.box entsprechend auflöst, keinen Sicherheitsgewinn — wohl aber weniger Konflikt- und damit Supportbedarfspotential.
Jau, die NSA findet durchgehende, qualitativ hochwertige, Ende-zu-Ende-Verschlüsselung auch doof, macht Aufwand.
Lies: Ernsthaft? Ich betreibe keine Provider-Boxen an meinen Anschlüssen (die bei congstar gekaufte 7360 hängt am T-VDSL, die 7490 an congstar-VDSL stammt von Amazon, die schwarze 7570 an Alice stammt aus der Bucht und wurde ruKT't), habe also keine Angst davor, daß der jew. Anbieter Zugriff auf meine Box hätte (bei Zugriff griffen zudem Strafrechtsparagraphen; hier dann die Frage: loggt die FB Zugriffe über TR-069?). Aber bei Kabelanbietern oder Anbietern wie 1&1 finde ich den Einwand schon gerechtfertigt; fehlende Datenintegrität mit »Support Aufwand« wegzuwischen ist schon eigenwillig. Zumal bei 1&1 der Kunde Eigentümer der Box ist und als solcher vor unlauteren Aktionen per TR-069 auch zu schützen ist ... :kopfschuettel:
Zuletzt bearbeitet:
wusel-09
Mitglied
- Mitglied seit
- 29 Mai 2009
- Beiträge
- 230
- Punkte für Reaktionen
- 3
- Punkte
- 18
Würde ja gerne updaten – die 20 Sekunden Zwangspause, bis die FritzBox-Oberfläche geladen ist, geht mir grade massiv auf die Nüsse –, aber derzeit schmeißt www.avm.de SSL-Fehler:
Code:
$ wget -O - https://www.avm.de/
--2014-06-17 23:25:01-- https://www.avm.de/
Resolving www.avm.de... 212.42.244.122, 2001:bf0:244:1::80
Connecting to www.avm.de|212.42.244.122|:443... connected.
OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Unable to establish SSL connection.Neueste Beiträge
-
AVM Geofencing - Smart Home: Fragen
- Letzte: pens
-
[Sammlung] Fritz!Box 7690 Labor/INHAUS Zyklus Smart24P1FCS - Fw ab 7.90
- Letzte: frank.lennert20
-
[Frage] Kompletter Ausfall von DNS over TLS (DoT)
- Letzte: DerderkeineAhnunghat
-
Fritz Dect200: Temperaturabhängig plus manuelle Schaltung
- Letzte: Erforderlich
-
[Problem] 5690 wlan modul
- Letzte: Vivacala
