Netzwerkattacke oder FritzBox defekt?

[Rubberduck]

Vor allem, das Phänoment tritt ja seit einem bestimmten Abend auf.
Bis dahin hat sich an meiner Konstellation nichts geändert.

Das ist natürlich ein gutes Argument.
Dennoch: Hast du wirklich ganz genau geprüft, dass im fraglichen Zeitraum auch keine Pakete aktualisiert wurden (zB durch unattended-upgrades)? Ansonsten bleibt dann nur noch die Frage von mat6937 als mögliche Erklärung für des geänderte Verhalten.

Anyway, ich würde mir die Mühe machen, mit wireshark mal im Detail nachzuschauen, was da genau abgeht sobald erstens dein Server angeht und dann zweites das Forwarding aktiviert wird.

Also es hat sich Netzwerk technisch nichts bei mir geändert.
In der Tat ist es aber so, dass ich das Phänomen festgestellt hatte, als ich meinen Debian Docker Host auf ZFS umgestellt habe und dabei war meine Webseiten und Owncloud wieder zu aktivieren. Bei der Inbetriebnahme der Webseiten habe ich dann das erklärte Phänomen zum ersten mal festgestellt.
Natürlich wurde dabei einiges neu installiert und ich habe erste den Server abgeschaltet, dann bei UnityMedia angerufen, die haben mir dann berichtet, dass aktuell in Bonn ( da wohne ich ) wartungsarbeiten durchgeführt wurden usw. usw.. man kommt ja dann von höckchen auf stöckchen.
Habe ich aber erst nicht berichtet, da ich keinen falschen Fokus setzen wollte.
Es liegt nicht an einer Installation von mir, das konnte ich durch mehrfaches Prüfen herausfinden und vor allem - wie ich schon berichtete - auch mit virtuellen Maschinen nachstellen.

Bevor wir uns verrennen, nochmal kurz:
Portforwarding 443 ( und scheinbar nur bei 443, getestet habe ich auch 80 und 22 ) auf einen aktiven Rechner in meinem Netz ( egal ob VM oder der besagte neue Server ). Gateway für alle sofort weg, Fritzbox nach 10 Sekunden nicht mehr erreichbar.
Aktive Maschine ausgeschaltet, alles sofort wieder gut.

[Rubberduck]

Ich habe - genau wegen der DS-Lite Geschichte - damals meinen Anschluss von normal auf Business umgestellt.
Ich habe demnach einen 150MBit/down und 10Mbit/up Vertrag, der auch genau so in meiner FB angezeigt wird.

OK, dann starte mal auf deinem Server und auf einem anderen geeigneten Gerät in dem (W)LAN deiner FritzBox:

Code: Alles auswählen

tcpdump -c 300 -vvveni any arp or icmp or broadcast or multicast

, bevor "Server an + Forwarding an" und beobachte was tcpdump zusätzlich anzeigt, wenn das Forwarding (Portweiterleitung) in deiner FritzBox aktiviert wird.

Vielen Dank für eure Hilfe, ich werde das heute Abend spät testen, jetzt muss ich wieder den Kopf in die Arbeit stecken.
Grüße

[mat6937]

Server an + Forwarding an = GW tot
Server aus + Forwarding an = GW ok

Hast Du schon getestet, wenn "Server an + Forwarding an" und auf dem Server die iptables-Regeln:

Code: Alles auswählen

iptables -t raw -I PREROUTING 1 -p tcp --dport 443 -j DROP
iptables -t raw -I PREROUTING 2 -p udp --dport 443 -j DROP

aktiv sind?

[Rubberduck]

Server an + Forwarding an = GW tot
Server aus + Forwarding an = GW ok

Hast Du schon getestet, wenn "Server an + Forwarding an" und auf dem Server die iptables-Regeln:

Code: Alles auswählen

iptables -t raw -I PREROUTING 1 -p tcp --dport 443 -j DROP
iptables -t raw -I PREROUTING 2 -p udp --dport 443 -j DROP

aktiv sind?

Nein, was würde ich damit testen?

[mat6937]

Nein, was würde ich damit testen?

Na ob das blockieren der Datenpakete in Richtung destination-Port 443, evtl. gleichwertig ist mit dem Zustand "Server aus".

[mat6937]

Gateway für alle sofort weg, Fritzbox nach 10 Sekunden nicht mehr erreichbar.

Teste auch mal von einem Gerät, das per Kabel (LAN-Port) mit der FritzBox schon vorher verbunden war bzw. noch ist (siehe auch die Ausgabe von "ip n s"), ob in diesem Zustand die FritzBox-cable evtl. noch per arp-Protokoll (statt icmp/tcp/udp/...) erreichbar ist (mit arping aus dem package iputils-arping):

Code: Alles auswählen

arping -c 4 -I <lan-Interface-PC> -s <IP-Adresse-lan-Interface-PC> <IP-Adresse-FritzBox-cable>

[Rubberduck]

Nein, was würde ich damit testen?

Na ob das blockieren der Datenpakete in Richtung destination-Port 443, evtl. gleichwertig ist mit dem Zustand "Server aus".

Nein klar, was die Regel verursacht|bedeutet war mir klar, aber was bringt uns das?
Letztenendes kann ich diese Regel ja nicht anwenden, denn ich benötige ja den port 443 im Ziel und wir bekommen dann immer noch nicht den Grund heraus.
Aber wenn das vielleicht dem allgemeinen Verstehen näher bringt, mach ich das natürlich..
Wie gesagt heute abend.

[Rubberduck]

Gateway für alle sofort weg, Fritzbox nach 10 Sekunden nicht mehr erreichbar.

Teste auch mal von einem Gerät, das per Kabel (LAN-Port) mit der FritzBox schon vorher verbunden war bzw. noch ist (siehe auch die Ausgabe von "ip n s"), ob in diesem Zustand die FritzBox-cable evtl. noch per arp-Protokoll (statt icmp/tcp/udp/...) erreichbar ist (mit arping aus dem package iputils-arping):

Code: Alles auswählen

arping -c 4 -I <lan-Interface-PC> -s <IP-Adresse-lan-Interface-PC> <IP-Adresse-FritzBox-cable>

Auch das kann ich machen ( Hey, direkt mit Angabe des Pakets, perfekt)

[mat6937]

..., aber was bringt uns das?
...
Aber wenn das vielleicht dem allgemeinen Verstehen näher bringt, mach ich das natürlich..

Ja, es geht nur um das allgemeine Verstehen. Es werden ja, nur die tcp-/udp-Datenpakete geblockt und der Rest kann durch.

EDIT:

Teste auch, ob Du deine FritzBox-cable an LAN1, mit der IP-Adresse 192.168.100.1 (in beiden Fällen) erreichen kannst:

Code: Alles auswählen

nc -zv 192.168.100.1 443 80
snmpwalk -c public -v 1 192.168.100.1

[Rubberduck]

..., aber was bringt uns das?
...
Aber wenn das vielleicht dem allgemeinen Verstehen näher bringt, mach ich das natürlich..

Ja, es geht nur um das allgemeine Verstehen. Es werden ja, nur die tcp-/udp-Datenpakete geblockt und der Rest kann durch.

EDIT:

Teste auch, ob Du deine FritzBox-cable an LAN1, mit der IP-Adresse 192.168.100.1 (in beiden Fällen) erreichen kannst:

Code: Alles auswählen

nc -zv 192.168.100.1 443 80
snmpwalk -c public -v 1 192.168.100.1

Tu mir bitte mal den Gefallen und sag mir was du damit versuchst in Erfahrung zu bringen und was du davon ableiten möchtest.
Ich weiß Hilfe immer sehr zu schätzen, aber dieses hundertfache "klick mal hier" und "mach mal da" ohne weitere Infos macht mich konfus.
Vielleicht sagst du auch direkt dabei, was du im Falle von Ergebnis A oder B machen möchtest oder erwartest.
:=) Ich bin eben sonst nicht Befehlsempfänger...

[mat6937]

... sag mir was du damit versuchst in Erfahrung zu bringen und was du davon ableiten möchtest.

Es geht darum festzustellen, unter welchen Bedingungen und mit welchen tools deine FritzBox-cable noch erreichbar ist.

[Rubberduck]

... sag mir was du damit versuchst in Erfahrung zu bringen und was du davon ableiten möchtest.

Es geht darum festzustellen, unter welchen Bedingungen und mit welchen tools deine FritzBox-cable noch erreichbar ist.

Du das versteh ich natürlich, aber über die Details lässt du mich im unklaren.

Was ist denn bspw. wenn sie auf der IP in beiden Fällen erreichbar ist und was ist wenn nicht. Was leitest du dann davon ab?
Somit könnte ich deine Gedanke mit durch denken, verstehst du?
Wenn du mir das aber nicht sagst, kann ich das nur ausführen, dir das Ergebnis präsentieren und wieder auf neue "Anweisung" warten.
Eventuell könnte ich dir in dem Moment vielleicht auch sagen, du das habe ich schon anderweitig probiert...blabla..dieses Ergebnis..

Daß das alles irgendwie dienlich ist um irgendwie das große Ganze zu verstehen ist klar.

[Rubberduck]

mist....ich hab die neue Fritzbox eingebaut und von UnityMedia eine neue IP bekommen.
Damit ist das Problem natürlich nicht mehr existent.
Gut aber irgendwie unbefriedigend.

Grundsätzlich kann man sich gar nicht dagegen schützen, oder?
Wenn so ein Irrer auf die Idee kommt Netzwerk Scans durchzuführen und anschließend offene Ports von seinem BOT Netzwerk bombardieren lässt, dann wars das.
Was soll ich sagen? Trotzdem erstmal vielen Dank für euren Gehirnschmalz dazu.

Grüße

[KBDCALLS]

Da hättste eventuell auch früher drauf kommen können. Die alte Box hat das bestimmt in ihren Logs vermerkt. Danach hatte ich ja gefragt, ob du dir die angesehen hast. Die kann man sich auch an sein Postfach schicken lassen. So das man die in Ruhe durchlesen kann.

[Rubberduck]

Da hättste eventuell auch früher drauf kommen können. Die alte Box hat das bestimmt in ihren Logs vermerkt. Danach hatte ich ja gefragt, ob du dir die angesehen hast. Die kann man sich auch an sein Postfach schicken lassen. So das man die in Ruhe durchlesen kann.

Worauf hätte ich früher kommen können. Das ich bei einer neuen IP das Problem nicht mehr habe?
Das war mir von Anfang an klar und ist auch logisch, aber das löst ja nicht das Problem.

Was hätte ich deiner Meinung nach in den Logs der Fritzbox sehen können? Da gab es unter System nur Verbindungsabbrüche, mehr nicht.
Hab ich mir natürlich überflogen.

[mat6937]

Wenn so ein Irrer auf die Idee kommt Netzwerk Scans durchzuführen und anschließend offene Ports von seinem BOT Netzwerk bombardieren lässt, dann wars das.

Und Du meinst, dass der weitergeleitete TCP-Port 443, mit deiner alten Box "bombardiert" worden ist? Warum hat tcpdump das dann nicht angezeigt?

[Rubberduck]

Wenn so ein Irrer auf die Idee kommt Netzwerk Scans durchzuführen und anschließend offene Ports von seinem BOT Netzwerk bombardieren lässt, dann wars das.

Und Du meinst, dass der weitergeleitete TCP-Port 443, mit deiner alten Box "bombardiert" worden ist? Warum hat tcpdump das dann nicht angezeigt?

Nein, weiß ich natürlich nicht und ehrlich gesagt, gehe ich auch nicht davon aus. Ich habe das nur eben für mich selber festgestellt, dass wenn es so wäre, man kaum was tun könnte, außer den Port dicht zu machen.

Ich gehe also davon aus, du denkst auch, die FB hatte irgendwas, ja? Bleibt ja eigentlich nichts anderes oder?

[mat6937]

..., die FB hatte irgendwas, ja? Bleibt ja eigentlich nichts anderes oder?

Könnte sein. Welche Firmware-Version hatte die alte FritzBox-cable und welche Firmware-Version die neue FritzBox-cable?
Wie hast Du die neue FritzBox konfiguriert? Manuell oder mit Hilfe einer _aktuellen_ Sicherungsdatei, die Du wann mit der alten FritzBox erstellt hast?

[KBDCALLS]

Unter Ereignisse Internetverindung hätte sowas eigentlich vermerkt werden müssen.

[Rubberduck]

..., die FB hatte irgendwas, ja? Bleibt ja eigentlich nichts anderes oder?

Könnte sein. Welche Firmware-Version hatte die alte FritzBox-cable und welche Firmware-Version die neue FritzBox-cable?
Wie hast Du die neue FritzBox konfiguriert? Manuell oder mit Hilfe einer _aktuellen_ Sicherungsdatei, die Du wann mit der alten FritzBox erstellt hast?

Die haben beide 6.52, die neue habe ich extra nicht über die Sicherungsdatei zurück geholt, ich wollte mir keinen Fehler reinholen, falls einer in der Konfig ist.

[mat6937]

..., die neue habe ich extra nicht über die Sicherungsdatei zurück geholt, ich wollte mir keinen Fehler reinholen, falls einer in der Konfig ist.

OK, d. h. die Konfiguration der neuen FB könnte jetzt auch anders, als die der alten FB sein? Wenn es jetzt einige Tage ohne Probleme funktioniert und Du eine aktuelle Sicherungsdatei von der alten FB hast, konntest die ja mal auf der neuen FB testen. Mit Hilfe der Werkseinstellung und manueller Konfiguration, kannst Du das immer rückgängig machen.

[Rubberduck]

..., die neue habe ich extra nicht über die Sicherungsdatei zurück geholt, ich wollte mir keinen Fehler reinholen, falls einer in der Konfig ist.

OK, d. h. die Konfiguration der neuen FB könnte jetzt auch anders, als die der alten FB sein? Wenn es jetzt einige Tage ohne Probleme funktioniert und Du eine aktuelle Sicherungsdatei von der alten FB hast, konntest die ja mal auf der neuen FB testen. Mit Hilfe der Werkseinstellung und manueller Konfiguration, kannst Du das immer rückgängig machen.

Stimmt, könnte ich mal ausprobieren.

Ich werde das am WE mal testen.
Aktuell will ich jetzt endlich meinen ganzen Docker Kram wieder aktivieren. Endlich auf zfs. Das war der eigentliche Grund für die Fummelei.

Ich geb Bescheid wenn ich das am WE getestet habe.
Danke

[Rubberduck]

Oh my God!

Ich könnte mich sowas von ärgern.-

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

Code: Alles auswählen

[root@PC01 tom]# 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=16.1 ms           # Normalzustand
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=245 time=15.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=245 time=14.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=245 time=18.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=245 time=16.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=6 ttl=245 time=25.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=7 ttl=245 time=23.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=8 ttl=245 time=17.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=9 ttl=245 time=21.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=10 ttl=245 time=21.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=11 ttl=245 time=19.2 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=12 ttl=245 time=17.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=13 ttl=245 time=36.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=14 ttl=245 time=370 ms             # Portforwarding eingeschaltet
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=15 ttl=245 time=3268 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=27 ttl=245 time=136 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=28 ttl=245 time=18.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=29 ttl=245 time=24.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=30 ttl=245 time=31.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=31 ttl=245 time=15.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=32 ttl=245 time=65.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=33 ttl=245 time=153 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=37 ttl=245 time=4665 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=43 ttl=245 time=3835 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=55 ttl=245 time=3368 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=61 ttl=245 time=2177 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=65 ttl=245 time=3444 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=66 ttl=245 time=2933 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=128 ttl=245 time=3705 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=135 ttl=245 time=3193 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=136 ttl=245 time=2340 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=144 ttl=245 time=2083 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=146 ttl=245 time=2200 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=148 ttl=245 time=2056 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=150 ttl=245 time=1134 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=152 ttl=245 time=148 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=153 ttl=245 time=1005 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=154 ttl=245 time=1984 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=161 ttl=245 time=2324 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=169 ttl=245 time=4538 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=170 ttl=245 time=4348 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=196 ttl=245 time=2965 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=197 ttl=245 time=2249 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=201 ttl=245 time=2697 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=203 ttl=245 time=3709 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=207 ttl=245 time=3502 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=211 ttl=245 time=1343 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=213 ttl=245 time=4717 ms                # Virtuelle Maschine Pause, oder Server aus.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=224 ttl=245 time=14.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=225 ttl=245 time=24.6 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=226 ttl=245 time=17.2 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=227 ttl=245 time=14.9 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=228 ttl=245 time=20.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=229 ttl=245 time=23.5 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=230 ttl=245 time=18.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=231 ttl=245 time=16.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=232 ttl=245 time=14.8 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=233 ttl=245 time=16.0 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=234 ttl=245 time=15.4 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=235 ttl=245 time=16.3 ms

[BenutzerGa4gooPh]

Normalzustand
Dann Aktivierung des Portforwardings [Anmerkung von mir: lange ping-Zeiten]
Dann Pause der Virtuellen Maschine und wieder alles normal.

Auslastung/Performance der Fritzbox, des eingebauten Modems, DSL, PPPoE?
MTU-Size etc? viewtopic.php?f=30&t=167021&hilit=mtu+size

Fritzbox mal in Modembetrieb nehmen oder/und exposed Host testen. Wenn funktioniert erfolgt damit Fehlerausschluss des "eigenen Geraffels".

[Rubberduck]

Normalzustand
Dann Aktivierung des Portforwardings [Anmerkung von mir: lange ping-Zeiten]
Dann Pause der Virtuellen Maschine und wieder alles normal.

Auslastung/Performance der Fritzbox, des eingebauten Modems, DSL, PPPoE?
MTU-Size etc? viewtopic.php?f=30&t=167021&hilit=mtu+size

Danke für deine Antwort aber könntest du mir etwas genauer sagen WAS du mir genau sagen möchtest ohne das ich mir 20 Seiten Text raussuchen muss um das selbe zu analysieren? :=)

Und, um nur die Schlagwörter aus der Überschrift zu nehmen, klar kann es mit DSL PPPoE oder eingebautem Modem zu tun haben,
faktisch hat es aber bis zum import der alten Konfiguration funktioniert, wieso sollte ich jetzt alles andere prüfen..?