Re: Netzwerkattacke oder FritzBox defekt?
Verfasst: 09.08.2018 14:01:03
Bilder sind hier nicht erwünscht. Nur Text in code blocks.
die deutschsprachige Supportwebseite rund um das Debian-Projekt
https://debianforum.de/forum/
Bilder sind hier nicht erwünscht. Nur Text in code blocks.
alrightmat6937 hat geschrieben:09.08.2018 14:01:03Bilder sind hier nicht erwünscht. Nur Text in code blocks.
Ok also im Green Mode keine ÄnderungRubberduck hat geschrieben:09.08.2018 13:45:31puhhh das alles zwischen VMware nach Hyper-V Migration...gib mir mal ein paar minuten, sonst schieß ich mir den Standort ab.
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
OK. Jetzt noch mit der abweisenden Route für die multicast Adressen versuchen/testen?
mat6937 hat geschrieben:09.08.2018 14:14:28OK. 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 hat geschrieben:09.08.2018 14:09:08Ok also im Green Mode keine ÄnderungRubberduck hat geschrieben:09.08.2018 13:45:31puhhh das alles zwischen VMware nach Hyper-V Migration...gib mir mal ein paar minuten, sonst schieß ich mir den Standort ab.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
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?
.
Versuch mal mit:Rubberduck hat geschrieben:09.08.2018 14:17:04
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. .
Code: Alles auswählen
ip route add prohibit 224.0.0.0/4
egal..debian gebootet .mat6937 hat geschrieben:09.08.2018 14:28:59Versuch mal mit:Rubberduck hat geschrieben:09.08.2018 14:17:04
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. .
Code: Alles auswählen
ip route add prohibit 224.0.0.0/4
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
OK, versuch mal ein anderes Protokoll. statt icmp. Einen download nach /dev/null, mit und ohne forwarding:Rubberduck hat geschrieben:09.08.2018 14:32:58
Analyse brauch ich nicht mehr machen denke ich..guckst du
Code: Alles auswählen
wget -4 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/1000mb.bin
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?
mat6937 hat geschrieben:09.08.2018 14:37:22OK, versuch mal ein anderes Protokoll. statt icmp. Einen download nach /dev/null, mit und ohne forwarding:Rubberduck hat geschrieben:09.08.2018 14:32:58
Analyse brauch ich nicht mehr machen denke ich..guckst duCode: Alles auswählen
wget -4 -c -O /dev/null http://mirror.de.leaseweb.net/speedtest/1000mb.bin
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 hat geschrieben:09.08.2018 14:38:33Vor allem was soll denn ein Download von egal-woher, wenn das Gateway weg ist, gibt es keinen download....
JA ok , aber in letzter Konsequenz. was bringt uns das?mat6937 hat geschrieben:09.08.2018 15:56:01Das 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 hat geschrieben:09.08.2018 14:38:33Vor allem was soll denn ein Download von egal-woher, wenn das Gateway weg ist, gibt es keinen download....
Das sind zusätzliche Erkenntnisse für evtl. Gespräche mit AVM bzw. mit Unitymedia.Rubberduck hat geschrieben:09.08.2018 15:57:17JA ok , aber in letzter Konsequenz. was bringt uns das?
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.Rubberduck hat geschrieben:09.08.2018 10:12:49Da 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.
Was soll ich euch sagen, jetzt habe ich das Problem auch mit der neuen Fritzbox und der neuen 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.
Ich habe mehrfach die Konfigdatei geprüft, zumahl sie auch ein unterschiedliches Kennwort hat und die Einstellungen anders sind usw.
Ich hab den Ping von einer anxderen Maschine zu dem Zeitpunkt kopiert.
- 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.
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
Ich denke dass dieser Port UnityMedia als Refernz dient um zu sehen was mit der Büchse los ist.mat6937 hat geschrieben:09.08.2018 16:07:52Das sind zusätzliche Erkenntnisse für evtl. Gespräche mit AVM bzw. mit Unitymedia.Rubberduck hat geschrieben:09.08.2018 15:57:17JA ok , aber in letzter Konsequenz. was bringt uns das?
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 hat geschrieben:09.08.2018 16:12:33Wenn 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.Rubberduck hat geschrieben:09.08.2018 10:12:49Da 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.
Was soll ich euch sagen, jetzt habe ich das Problem auch mit der neuen Fritzbox und der neuen 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.
Ich habe mehrfach die Konfigdatei geprüft, zumahl sie auch ein unterschiedliches Kennwort hat und die Einstellungen anders sind usw.
Ich hab den Ping von einer anxderen Maschine zu dem Zeitpunkt kopiert.
- 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.
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
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?
Das kann der TE z. Zt. mit seinem Business-Tarif (... ohne zusätzliche statische externe IPv4-Adresse) bei Unitymedia nicht machen.
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 hat geschrieben:09.08.2018 16:53:08
..., aber es ist definitv genau erst nach dem Import der Konfig Datei gewesen.
Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.Jana66 hat geschrieben:09.08.2018 16:57:42Wü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.)
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).Rubberduck hat geschrieben:09.08.2018 17:16:36Techniker sagten mir, dass auch neue Updates für die Fritzbox gepushed werden sollten ( habe ich nicht überprüft ob das wirlich durchgeführt wurde)
Ja; da ist was dran.Rubberduck hat geschrieben:09.08.2018 17:16:36Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.
Ä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.Rubberduck hat geschrieben:09.08.2018 17:16:36Einen Tag nachdem ich das Problem gemeldet habe, war meine FB neu gestartet und alle meine Portforwardings waren gelöscht, was sehr sehr ärgerlich war.
Da bin ich völlig bei dir. Ich habe ja schon früher gesagt, dass ich einen Angriff unrealistisch finde.spiralnebelverdreher hat geschrieben:09.08.2018 17:37:12Ja; da ist was dran.Rubberduck hat geschrieben:09.08.2018 17:16:36Ich brauch keinen Denksport. Es kann nicht alles falsch konfiguriert sein und auch nicht 'plötzlich' und auch nicht nach dem Import einer Datei.
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?