Netzwerkattacke oder FritzBox defekt?

[mat6937]

ok, sag mal wie kann ich hier Bilder posten?

Bilder sind hier nicht erwünscht. Nur Text in code blocks.

[Rubberduck]

ok, sag mal wie kann ich hier Bilder posten?

Bilder sind hier nicht erwünscht. Nur Text in code blocks.

alright

[Rubberduck]

Oder willst du wieder nur was testen?

Ja, ist nur zum testen.

puhhh das alles zwischen VMware nach Hyper-V Migration...gib mir mal ein paar minuten, sonst schieß ich mir den Standort ab.

Ok also im Green Mode keine Änderung

Code: Alles auswählen

64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3529 ttl=245 time=15.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3530 ttl=245 time=17.2 ms   # normal
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3531 ttl=245 time=21.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3532 ttl=245 time=19.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3533 ttl=245 time=22.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3534 ttl=245 time=26.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3535 ttl=245 time=1333 ms  # forwarding an
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3536 ttl=245 time=2421 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3539 ttl=245 time=7151 ms # gateway weg
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3549 ttl=245 time=18.9 ms  # VM pause
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3550 ttl=245 time=17.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3551 ttl=245 time=16.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3552 ttl=245 time=14.7 ms

[mat6937]

... im Green Mode keine Änderung

OK. Jetzt noch mit der abweisenden Route für die multicast Adressen versuchen/testen?

Ist deine Maschine direkt per Kabel mit deiner FritzBox verbunden oder evtl. über einen Switch? Ist an der FritzBox das WLAN aktiviert? Wenn ja, hast Du Smartphones, Tablets permanent im WLAN der FritzBox? Dürfen die WLAN-Geräte untereinander und mit den kabelverbundenen Geräten kommunizieren?

[Rubberduck]

... im Green Mode keine Änderung

OK. Jetzt noch mit der abweisenden Route für die multicast Adressen versuchen/testen?

Ist deine Maschine direkt per Kabel mit deiner FritzBox verbunden oder evtl. über einen Switch? Ist an der FritzBox das WLAN aktiviert? Wenn ja, hast Du Smartphones, Tablets permanent im WLAN der FritzBox? Dürfen die WLAN-Geräte untereinander und mit den kabelverbundenen Geräten kommunizieren?

Ja, ist nur zum testen.

puhhh das alles zwischen VMware nach Hyper-V Migration...gib mir mal ein paar minuten, sonst schieß ich mir den Standort ab.

Ok also im Green Mode keine Änderung

Code: Alles auswählen

64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3529 ttl=245 time=15.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3530 ttl=245 time=17.2 ms   # normal
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3531 ttl=245 time=21.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3532 ttl=245 time=19.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3533 ttl=245 time=22.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3534 ttl=245 time=26.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3535 ttl=245 time=1333 ms  # forwarding an
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3536 ttl=245 time=2421 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3539 ttl=245 time=7151 ms # gateway weg
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3549 ttl=245 time=18.9 ms  # VM pause
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3550 ttl=245 time=17.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3551 ttl=245 time=16.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3552 ttl=245 time=14.7 ms

route add kennt mein System nicht.

Code: Alles auswählen

[manjaro tom]# [manjaro tom]# ip route add -net 224.0.0.0 netmask 240.0.0.0 reject
Error: any valid prefix is expected rather than "-net".
[manjaro tom]# ip route add net 224.0.0.0 netmask 240.0.0.0 reject
Error: any valid prefix is expected rather than "net".
[manjaro tom]# route add net 224.0.0.0 netmask 240.0.0.0 reject
bash: route: Kommando nicht gefunden.
[manjaro tom]# 
hab ich gerade ein Brett vorm Kopf?
.

[Rubberduck]

ich guck das grad mal nach für Archlinux..bin damit noch nicht soo lange unterwegs

[mat6937]

route add kennt mein System nicht.

Code: Alles auswählen

[manjaro tom]# route add net 224.0.0.0 netmask 240.0.0.0 reject
bash: route: Kommando nicht gefunden.
.

Versuch mal mit:

Code: Alles auswählen

ip route add prohibit 224.0.0.0/4

[Rubberduck]

route add kennt mein System nicht.

Code: Alles auswählen

[manjaro tom]# route add net 224.0.0.0 netmask 240.0.0.0 reject
bash: route: Kommando nicht gefunden.
.

Versuch mal mit:

Code: Alles auswählen

ip route add prohibit 224.0.0.0/4

egal..debian gebootet .

Analyse brauch ich nicht mehr machen denke ich..guckst du

Code: Alles auswählen

root@debianZFS:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
224.0.0.0       -               240.0.0.0       !     0      -        0 -
root@debianZFS:~# ping heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=245 time=24.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=245 time=14.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=245 time=24.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=245 time=16.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=245 time=15.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=6 ttl=245 time=16.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=245 time=17.2 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=8 ttl=245 time=72.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=9 ttl=245 time=1761 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=10 ttl=245 time=3330 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=13 ttl=245 time=3510 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=14 ttl=245 time=3581 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=20 ttl=245 time=17.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=21 ttl=245 time=18.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=22 ttl=245 time=23.1 ms

[mat6937]

Analyse brauch ich nicht mehr machen denke ich..guckst du

OK, versuch mal ein anderes Protokoll. statt icmp. Einen download nach /dev/null, mit und ohne forwarding:

Code: Alles auswählen

wget -4 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/1000mb.bin

EDIT:

Folgende Fragen hast Du noch nicht beantwortet:

Ist deine Maschine direkt per Kabel mit deiner FritzBox verbunden oder evtl. über einen Switch? Ist an der FritzBox das WLAN aktiviert? Wenn ja, hast Du Smartphones, Tablets permanent im WLAN der FritzBox? Dürfen die WLAN-Geräte untereinander und mit den kabelverbundenen Geräten kommunizieren?

[Rubberduck]

Analyse brauch ich nicht mehr machen denke ich..guckst du

OK, versuch mal ein anderes Protokoll. statt icmp. Einen download nach /dev/null, mit und ohne forwarding:

Code: Alles auswählen

wget -4 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/1000mb.bin

nee. du echt...jetzt hab ich erstmal kein Bock mehr auf mach mal das und mach mal dies..das nimmt ja kein Ende und das Ende ist das selbe...
Vor allem was soll denn ein Download von egal-woher, wenn das Gateway weg ist, gibt es keinen download....

[mat6937]

Vor allem was soll denn ein Download von egal-woher, wenn das Gateway weg ist, gibt es keinen download....

Das gateway ist nicht (ganz) weg, denn ein echo reply vom >/= 3. hop ist doch noch angekommen. Mit dem download (tcp-Protokoll) vergewissert man sich, ob das so ist. tcp-Datenpakete werden evtl. mit einer anderen "Priorität" geroutet, als icmp-Datenpakete (request/reply).

[Rubberduck]

Vor allem was soll denn ein Download von egal-woher, wenn das Gateway weg ist, gibt es keinen download....

Das gateway ist nicht (ganz) weg, denn ein echo reply vom >/= 3. hop ist doch noch angekommen. Mit dem download (tcp-Protokoll) vergewissert man sich, ob das so ist. tcp-Datenpakete werden evtl. mit einer anderen "Priorität" geroutet, als icmp-Datenpakete (request/reply).

JA ok , aber in letzter Konsequenz. was bringt uns das?

[mat6937]

JA ok , aber in letzter Konsequenz. was bringt uns das?

Das sind zusätzliche Erkenntnisse für evtl. Gespräche mit AVM bzw. mit Unitymedia.

Was ich gerade getestet habe ist, dass der tcp-Port 8089 deiner FritzBox, aus dem Internet per tcp-Ping erreichbar ist.

Jetzt wäre m. E. auch nützlich zu wissen, ob das auch dann der Fall ist, wenn Du das forwarding aktiviert hast. Denn bisher haben wir ja nur aus der Richtung von deinem (W)LAN ins Internet getestet. Das wäre jetzt aus der anderen Richtung (... aus dem Internet via gateway zu deiner FritzBox).

[spiralnebelverdreher]

Da ich heute im Homeoffice sitze, habe ich gedacht, was solls, testest du es eben heute noch.
Kurz nochmal geprüft, 443 Freigabe auf meinen Server oder eine andere aktive VM hat keine Auswirkung mit der neuen BOX und der manuellen Konfiguration.

• Neue FB Konfiguration abgespeichert.
  Alte FB Konfiguration geladen.
  Nach dem Neustart, das selbe Problem
  OK, liegt also an der Konfguration, schön das ich eine Sicherung der NEUEN Konfiguration der NEUEN Box hab.
  Wiederherstellung der neuen Konfiguration.

Was soll ich euch sagen, jetzt habe ich das Problem auch mit der neuen Fritzbox und der neuen Konfiguration.
Ich habe mehrfach die Konfigdatei geprüft, zumahl sie auch ein unterschiedliches Kennwort hat und die Einstellungen anders sind usw.

• Ok, Werkseinstellungen laden.
  Manuelle Konfiguration ( nur Wlan, alles andere so gelassen)
  443 Weiterleitung auf VM eingerichtet.
  Abgewandeltes Problem. Ich bekomme extreme Antwortzeiten, Time out ins Internet.

Ich hab den Ping von einer anxderen Maschine zu dem Zeitpunkt kopiert.
Man sieht richtig den
Normalzustand
Dann Aktivierung des Portforwardings
Dann Pause der Virtuellen Maschine und wieder alles normal.
Wie kann das nach dem Zurückstellen auf Werkseinstellungen der Fall sein? Erschließt sich mir nicht. man man man

Wenn Du das Problem jetzt (auch) auf der neuen Fritzbox hast, läßt das den Schluss zu dass es nicht an der FritzBox-HW liegt. Es wird auch kein externer Angriff sein. (Damit ist eiegntlich auch IMHO die Überschrift des Threads inzwischen nicht mehr passend). Weiterhin liegt nahe, dass es nicht an Parametern liegt, die in der Konfig gespeichert werden. Wenn dann zusätzlich ein Zurücksetzen der FB auf Werkseinstellungen auch keine Änderungen bewirkt, dann muss es entweder in der FB einen Speicherplatz geben, der weder durch Werkseinstellungsreset noch durch Konfig beeinflussbar ist. Das halte ich für nicht ausgeschlossen, aber unwahrscheinlich.

Wo also dann? Bleibt nur noch: Auf der WAN-Seite beim ISP? Oder auf der LAN-Seite im Host oder Gast (VM) deines Zielrechners? Gibt es im LAN noch weitere Teile wie Switche, die man resetten kann?

[Rubberduck]

JA ok , aber in letzter Konsequenz. was bringt uns das?

Das sind zusätzliche Erkenntnisse für evtl. Gespräche mit AVM bzw. mit Unitymedia.

Was ich gerade getestet habe ist, dass der tcp-Port 8089 deiner FritzBox, aus dem Internet per tcp-Ping erreichbar ist.

Jetzt wäre m. E. auch nützlich zu wissen, ob das auch dann der Fall ist, wenn Du das forwarding aktiviert hast. Denn bisher haben wir ja nur aus der Richtung von deinem (W)LAN ins Internet getestet. Das wäre jetzt aus der anderen Richtung (... aus dem Internet via gateway zu deiner FritzBox).

Ich denke dass dieser Port UnityMedia als Refernz dient um zu sehen was mit der Büchse los ist.
Die können darüber in ihrem Portal auch irgendwelche Werte sehen, das hat mir der Techniker vorgestern erzählt ( also jetzt nicht genau den Port. sondern dass die das grundsätzlich können)

Wie willst du das testen? Zu einem bestimmten Zeitpunkt forwarding einschalten für X Minuten damit du das prüfen kannst?
Ich mein ich könnte natürlich auch einen Hotspot mit dem HAndy aufmachen usw..

[Rubberduck]

Da ich heute im Homeoffice sitze, habe ich gedacht, was solls, testest du es eben heute noch.
Kurz nochmal geprüft, 443 Freigabe auf meinen Server oder eine andere aktive VM hat keine Auswirkung mit der neuen BOX und der manuellen Konfiguration.

• Neue FB Konfiguration abgespeichert.
  Alte FB Konfiguration geladen.
  Nach dem Neustart, das selbe Problem
  OK, liegt also an der Konfguration, schön das ich eine Sicherung der NEUEN Konfiguration der NEUEN Box hab.
  Wiederherstellung der neuen Konfiguration.

Was soll ich euch sagen, jetzt habe ich das Problem auch mit der neuen Fritzbox und der neuen Konfiguration.
Ich habe mehrfach die Konfigdatei geprüft, zumahl sie auch ein unterschiedliches Kennwort hat und die Einstellungen anders sind usw.

• Ok, Werkseinstellungen laden.
  Manuelle Konfiguration ( nur Wlan, alles andere so gelassen)
  443 Weiterleitung auf VM eingerichtet.
  Abgewandeltes Problem. Ich bekomme extreme Antwortzeiten, Time out ins Internet.

Ich hab den Ping von einer anxderen Maschine zu dem Zeitpunkt kopiert.
Man sieht richtig den
Normalzustand
Dann Aktivierung des Portforwardings
Dann Pause der Virtuellen Maschine und wieder alles normal.
Wie kann das nach dem Zurückstellen auf Werkseinstellungen der Fall sein? Erschließt sich mir nicht. man man man

Wenn Du das Problem jetzt (auch) auf der neuen Fritzbox hast, läßt das den Schluss zu dass es nicht an der FritzBox-HW liegt. Es wird auch kein externer Angriff sein. (Damit ist eiegntlich auch IMHO die Überschrift des Threads inzwischen nicht mehr passend). Weiterhin liegt nahe, dass es nicht an Parametern liegt, die in der Konfig gespeichert werden. Wenn dann zusätzlich ein Zurücksetzen der FB auf Werkseinstellungen auch keine Änderungen bewirkt, dann muss es entweder in der FB einen Speicherplatz geben, der weder durch Werkseinstellungsreset noch durch Konfig beeinflussbar ist. Das halte ich für nicht ausgeschlossen, aber unwahrscheinlich.

Wo also dann? Bleibt nur noch: Auf der WAN-Seite beim ISP? Oder auf der LAN-Seite im Host oder Gast (VM) deines Zielrechners? Gibt es im LAN noch weitere Teile wie Switche, die man resetten kann?

Ich weiß dass das unrealistisch klingt, aber es ist definitv genau erst nach dem Import der Konfig Datei gewesen.
Ich weiß es so genau, weil ich gerade dabei bin meine Webseiten und Cloud wieder online zu bringen und das heute morgen früh alles wunderbar geklappt hat....bis jemand auf die wahnwitzige Idee kam, die alte Konfig mal wieder einzuspielen....grummel...:=)

Es gibt nichts weiter bei mir.
Vier Kabel die von der Fritzbox weggehen, Eins an die QNAP (debian server),Raspberry, PC, Laptop. fertig

[BenutzerGa4gooPh]

Würde langsam auf fehlerhafte Virtualisierung (Netzwerkeinstellungen oder Webserver-VM) tippen.
Vorschlag:
zusätzliche VM mit PFSense, damit: "Reihenschaltung" von FB (im Modembetreb oder Exposed Host) - NW-Adapter Hostsystem - VM mit pfSense - VM mit Webserver zuschalten/abschalten. ping-Tests von jedem Host, jeder VM.
Dann das Gleiche mit FB im Routing-Betrieb, also 2 Router aktiv.
Evtl. noch pfSense-VM transparent / Layer 2.
Ziel: Sofort verfügbare, ausführliche Logs der pfSense-VM und Fehlerausschluss.
(Welche Fehler man in welcher Konstellation und mit aktiver/passiver Webserver-VM ausschließt, fällt unter Denksport.)

[mat6937]

... FB (im Modembetreb oder Exposed Host) - ...

Das kann der TE z. Zt. mit seinem Business-Tarif (... ohne zusätzliche statische externe IPv4-Adresse) bei Unitymedia nicht machen.

[BenutzerGa4gooPh]

Dann 2 Router oder pfSense transparent. 2 defekte Fritzboxen sind eh unwahrscheinlich.

[mat6937]

..., aber es ist definitv genau erst nach dem Import der Konfig Datei gewesen.

Diese Konfig-Datei, ist die mit bzw. aus einer Firmware-Version 6.52 entstanden oder schon mit bzw. aus einer früheren Firmware-Version (z. B. 6.50 oder kleiner)?

[Rubberduck]

Würde langsam auf fehlerhafte Virtualisierung (Netzwerkeinstellungen oder Webserver-VM) tippen.
Vorschlag:
zusätzliche VM mit PFSense, damit: "Reihenschaltung" von FB (im Modembetreb oder Exposed Host) - NW-Adapter Hostsystem - VM mit pfSense - VM mit Webserver zuschalten/abschalten. ping-Tests von jedem Host, jeder VM.
Dann das Gleiche mit FB im Routing-Betrieb, also 2 Router aktiv.
Evtl. noch pfSense-VM transparent / Layer 2.
Ziel: Sofort verfügbare, ausführliche Logs der pfSense-VM und Fehlerausschluss.
(Welche Fehler man in welcher Konstellation und mit aktiver/passiver Webserver-VM ausschließt, fällt unter Denksport.)

Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.
Getestete Portforwarding Regel 443 nach
Debian Server ( Phsyik )
PC ( Physik )
Laptop ( Physik)
Manajro VM
Debian VM
Windows VM
ÜBerall ausnahmslos das gleiche Ergebnis.

Alles ist an die Fritzbox angeschlossen.
Alles funktionierte genau so wie es sollte, schon seit sehr langer Zeit.
Webseiten werden über dnydns über port443 auf meinen Server geleitet.
Meine Kamera wird über dyndns auf mein Notebook geleitet.
VPN von außen auf meinen Server funktionierte wunderbar.
Bis zu dem einen Abend, von dem ich berichtete.
Da kann nicht alles falsch konfiguriert sein.

Ich weiß ganz sicher, dass die UnityMedia genau an dem und dem darauffolgenden Tag Wartungsarbeiten ( per Mail vorangekündigt ) durchgeführt haben.
Techniker sagten mir, dass auch neue Updates für die Fritzbox gepushed werden sollten ( habe ich nicht überprüft ob das wirlich durchgeführt wurde)
Einen Tag nachdem ich das Problem gemeldet habe, war meine FB neu gestartet und alle meine Portforwardings waren gelöscht, was sehr sehr ärgerlich war.
Bei mir ist alles ziemlich gut dokimentiert und ich glaube nicht an ein internes Problem ( auch wenn das vielleicht etwas überheblich klingt, ist aber so.)
Aber trotzdem danke für die Ideee

[mat6937]

Techniker sagten mir, dass auch neue Updates für die Fritzbox gepushed werden sollten ( habe ich nicht überprüft ob das wirlich durchgeführt wurde)

Als erste bekommen die Privatkunden-Anschlüsse das Update auf 6.88 für ihre FB6490-cable (als Zwangsbox) und danach erst die Business-Anschlüsse (... evtl. in der 2. Augusthälfte und später).

[spiralnebelverdreher]

Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.

Ja; da ist was dran.
Um den Denksport zu reduzieren ist es aber hilfreich, Optionen auszuschließen. Nach bisheriger Diskussion würde ich externen Angriff ausschließen. Siehst du das auch so?
Weiterhin würde ich einen simplen HW-Schaden in der Box ausschließen, einen in der FB enthaltenen systematischen Fehler (ob HW oder SW sei dahingestellt) aber nicht. ok?

[BenutzerGa4gooPh]

Einen Tag nachdem ich das Problem gemeldet habe, war meine FB neu gestartet und alle meine Portforwardings waren gelöscht, was sehr sehr ärgerlich war.

Ärgerlich - und leicht absehbar. Leistungsgrenzen und Adminhoheiten (Fernzugriff von wem und womit, offene Ports) sollten eindeutig sein, wenn man Betriebsicherheit braucht oder wichtige Dienste (dein Webserver?) anbieten will. Ein eigener Router anstelle des Providerrouters oder eben zusätzlich wäre hilfreich. So könnte man auch mal Downgrade probieren um Firmarefehler auszuschließen, Netzwerkfehler wären eindeutig zwischen dir und Provider abgegrenzt und testbar. Mit deinem Providerrouter kannst du dir nie sicher sein, der gehört eigentlich zur Sicherheitszone "Böses Internet", Unbekannte haben ja Zugriff.
https://www.heise.de/newsticker/meldung ... 99863.html
https://www.datenschutzbeauftragter-inf ... en-router/
Beschweren über Fernzugriff und Löschen deiner Konfig nach Updates kannst du dich auch nicht, ist ja nicht dein privater Router, (nicht jede Kundenkonfiguration kennende) Mitarbeiter des Providers tun nur ihre Arbeit. Wenn nicht upgedatet wird, Sicherheitslücken. Damit scheint dein Pivatnetz und angebotene, öffentliche Dienste weder wichtig (Betriebssicherheit) noch vertraulich/sicher zu sein. Providerrouter, insbesondere Fritzboxen nutzen Tante Emma und Firmen ohne Admin. Manche Provider stellen Geschäftskunden auch richtige Router (Cisco) mit mehreren konfigurierbaren Accounts, Hilfsadmins und entsprechenden Logs zu Accounts. Mit einem eigenen Router bestimmt man den Zeitpunkt von Updates und Umkonfigurationen selber.

[Rubberduck]

Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.

Ja; da ist was dran.
Um den Denksport zu reduzieren ist es aber hilfreich, Optionen auszuschließen. Nach bisheriger Diskussion würde ich externen Angriff ausschließen. Siehst du das auch so?
Weiterhin würde ich einen simplen HW-Schaden in der Box ausschließen, einen in der FB enthaltenen systematischen Fehler (ob HW oder SW sei dahingestellt) aber nicht. ok?

Da bin ich völlig bei dir. Ich habe ja schon früher gesagt, dass ich einen Angriff unrealistisch finde.
Ich kann grad den Titel nicht ändern, sollten wir uns nicht weiter drüber aufregen, ok?

Ich finde es ja irgendwie unrealistisch und würde bei meinem Kollegen in der Technik auch fragen..und was haste wieder gemacht und gebastelt.Ist ja klar.
Aber ich weiß sehr genau was ich mache und hab auch kein Problem damit zu zugeben, wenn ich es verursache. Aber bei so vielen Geräten und einer ziemlich einfachen Infrastruktur, gehe ich nicht davon aus. Egal wie unrealistisch der Defekt der FB ist ( hatte ich persönlich noch nie, auch nicht an unseren kleineren Standorten wo wir die bis 5 Mitarbeiter einsetzen, danach natürlich Cisco).

Hrmppf..hätt ich nicht ne Glatze würd ich mir die Haare raufen..