Netzwerkattacke oder FritzBox defekt?

[mat6937]

Code: Alles auswählen

root@DEB-SRV01:~# tcpdump -c 400 -vvveni any port 443
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:08:02.827395  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 6012, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.57646 > 10.0.0.252.443: Flags [S], cksum 0x2ad2 (correct), seq 1090246107, win 29200, options [mss 1460,sackOK,TS val 1506601962 ecr 0,nop,wscale 7], length 0
11:08:02.827513 Out 00:08:9b:e5:ff:e2 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 21376, offset 0, flags [DF], proto TCP (6), length 40)
    10.0.0.252.443 > 37.24.59.146.57646: Flags [R.], cksum 0x4a69 (correct), seq 0, ack 1090246108, win 0, length 0

Der Server (Port 443) antwortet auf jeden Versuch, von außen eine Verbindung zu ihm aufzubauen (1.-weg-Handschlag mit dem dem syn-flag) mit einem reset+ack-Flag (statt mit dem syn+ack-Flag als 2.-weg-Handschlag). Das könnte auch an der Server-Konfiguration liegen.

[mat6937]

bei UM mache ich das jetzt umgekehrt?
Die wollen IP und reverse DNS Namen

also
meine IP und web.domain.de
meine IP und cloud.domain.de usw?

Ja. Wirst ja sehen ob man auch mehrere hostnamen(+domain) auf eine einzige statische öffentliche IPv4-Adresse, bei Unitymedia als Reverse-DNS-Eintrag einrichten kann.

[Rubberduck]

Code: Alles auswählen

root@DEB-SRV01:~# tcpdump -c 400 -vvveni any port 443
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:08:02.827395  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 6012, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.57646 > 10.0.0.252.443: Flags [S], cksum 0x2ad2 (correct), seq 1090246107, win 29200, options [mss 1460,sackOK,TS val 1506601962 ecr 0,nop,wscale 7], length 0
11:08:02.827513 Out 00:08:9b:e5:ff:e2 ethertype IPv4 (0x0800), length 56: (tos 0x0, ttl 64, id 21376, offset 0, flags [DF], proto TCP (6), length 40)
    10.0.0.252.443 > 37.24.59.146.57646: Flags [R.], cksum 0x4a69 (correct), seq 0, ack 1090246108, win 0, length 0

Der Server (Port 443) antwortet auf jeden Versuch, von außen eine Verbindung zu ihm aufzubauen (1.-weg-Handschlag mit dem dem syn-flag) mit einem reset+ack-Flag (statt mit dem syn+ack-Flag als 2.-weg-Handschlag). Das könnte auch an der Server-Konfiguration liegen.

JA, mag sein und ich unke ja ungern, aber wieder bei jeder physikalischen Maschine und bei jeder VM?
höchst unwahrscheinlich und jede Wette, wenn ich den A Record gleich entferne und nichts aus dem INet zu mir zeigt, läuft wieder alles gut...

[Rubberduck]

So wie ich es voraus gesagt habe.
Ich habe die A Records cloud und web.domain gelöscht.

Ist jetzt gerade aktiv geworden.
Weiterleitung des Ports verursacht keine Probleme mehr.

Das soll einer verstehen...

[Rubberduck]

Also ich weiß ja nicht, ob hier noch jemand mit liest, aber....

mittlerweile habe ich andere A Records für meine Weiterleitung und damit gibt es keine Probleme.

Was ich da hatte mit der Konfiguration, war glaube ich ....verrand in irgendwas, da zuviel parallel probiert und falsch geschlussfolgert.

Abschließend bin ich mit ziemlich sicher über:

1 Der A Record cloud.mydomain.de war entweder seitens meines Providers ....irgendwie defekt oder
ich wurde permanent darauf beschossen. Defekt ist natürlich schwachsinn, das ist nur ne Tabelle mit namen | IPs, ich wolte nur eine
andere Möglichkeit einräumen.
Ich weiß dass sich das unrealistisch anhören mag, aber seit ich neue A Records benutze und die alten gelöscht habe, läuft alles tutti.

Das spricht einfach gegen irgendeinen Defekt auf meiner FB und auch gegen einen Fehler in irgendeinem System von mir.

Wenn das jetzt so bleibt, mach ich den Thread hier zu.
Vielen Dank nochmal.

[spiralnebelverdreher]

Also ich weiß ja nicht, ob hier noch jemand mit liest, aber....

mittlerweile habe ich andere A Records für meine Weiterleitung und damit gibt es keine Probleme.

Was ich da hatte mit der Konfiguration, war glaube ich ....verrand in irgendwas, da zuviel parallel probiert und falsch geschlussfolgert.

Abschließend bin ich mit ziemlich sicher über:

1 Der A Record cloud.mydomain.de war entweder seitens meines Providers ....irgendwie defekt oder
ich wurde permanent darauf beschossen. Defekt ist natürlich schwachsinn, das ist nur ne Tabelle mit namen | IPs, ich wolte nur eine
andere Möglichkeit einräumen.
Ich weiß dass sich das unrealistisch anhören mag, aber seit ich neue A Records benutze und die alten gelöscht habe, läuft alles tutti.

Das spricht einfach gegen irgendeinen Defekt auf meiner FB und auch gegen einen Fehler in irgendeinem System von mir.

Wenn das jetzt so bleibt, mach ich den Thread hier zu.
Vielen Dank nochmal.

Du hattest vor einigen Tagen folgendes berichtet:

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. ...

Irgendwie fehlt mir das Verständnis, wie das zusammen hängt. Wieso hat heute die Änderung des A-Records hat und das Laden einer alten Konfiguration in der FritzBox vor einigen Tagen die gleichen Auswirkungen? Ich verstehe gut, dass du froh bist die Probleme los zu haben. Aber was war denn nun Ursache und was nicht?

[Rubberduck]

Hi,

ehrlich gesagt, kann ich es dir nicht so richtig erklären.
Zu dem Zeitpunkt als ich getestet hatte, habe ich so vieles gleichzeitig getestet, dass ich wohl nicht mehr richtig im Überblick hatte,
wann ich denn bei DomainFactory mit den A Records rumgespielt hatte ( das dauert ja auch immer eine Stunde oder mehr bis das aktiv ist) und wann ich
die alte Konfiguration in die neue FritzBox importiert habe.
In diese Moment sah es für mich so aus, als wenn mit dem Import der alten Konfiguration, das Problem sozusagen mit importiert wurde,
wahrscheinlich hat aber einfach mein "An-Ausschalten" der A Records bei DomainFactory gegriffen, so dass ich dachte es wäre so.

Fakt ist aber definitiv, dass wenn ich den Eintrag cloud.mydomain.de bei DomainFactory aktiviere, und an meiner FB den Port 443 auf eine aktive Maschine weiterleite, die besagten Probleme auftreten. Nach wie vor.
Mit allen anderen Records eben nicht.

Für mich - auch wenn es noch so unrealistisch erscheint - sieht es wie eine Art Angriff aus.
Eventuell sowas https://www.searchsecurity.de/definitio ... er-Angriff

In den nächsten Tagen nimmt sich ein Kollege ne andere alte FritzBox mit, dann werde ich den Eintrag nochmal erstellen und auf seine IP umleiten.
Ich kann dir einfach keine bessere Erklärung geben.

Gruß

[mat6937]

Für mich - auch wenn es noch so unrealistisch erscheint - sieht es wie eine Art Angriff aus.
Eventuell sowas https://www.searchsecurity.de/definitio ... er-Angriff

Ich denke nicht, dass es ein Angriff auf dein Gerät (tcp Port 443) ist.

Aber syn flood Angriffe kannst Du z. B. mit tcpdump und dem entsprechenden Filter, auf dem Endgerät anzeigen lassen:

Code: Alles auswählen

tcpdump -c 300 -vvveni any tcp dst port 443 and 'tcp[tcpflags] & (tcp-syn) != 0'

[Rubberduck]

Für mich - auch wenn es noch so unrealistisch erscheint - sieht es wie eine Art Angriff aus.
Eventuell sowas https://www.searchsecurity.de/definitio ... er-Angriff

Ich denke nicht, dass es ein Angriff auf dein Gerät (tcp Port 443) ist.

Aber syn flood Angriffe kannst Du z. B. mit tcpdump und dem entsprechenden Filter, auf dem Endgerät anzeigen lassen:

Code: Alles auswählen

tcpdump -c 300 -vvveni any tcp dst port 443 and 'tcp[tcpflags] & (tcp-syn) != 0'

Was glaubst du denn WAS es ist ?

[Rubberduck]

Für mich - auch wenn es noch so unrealistisch erscheint - sieht es wie eine Art Angriff aus.
Eventuell sowas https://www.searchsecurity.de/definitio ... er-Angriff

Ich denke nicht, dass es ein Angriff auf dein Gerät (tcp Port 443) ist.

Aber syn flood Angriffe kannst Du z. B. mit tcpdump und dem entsprechenden Filter, auf dem Endgerät anzeigen lassen:

Code: Alles auswählen

tcpdump -c 300 -vvveni any tcp dst port 443 and 'tcp[tcpflags] & (tcp-syn) != 0'

Was glaubst du denn WAS es ist ?

ÜBrigens grad mal durchgeführt

Code: Alles auswählen

37.24.59.146.52294 > 10.0.0.252.443: Flags [SEW], cksum 0xa255 (correct), seq 137527334, win 29200, options [mss 1460,sackOK,TS val 1959525390 ecr 0,nop,wscale 7], length 0
00:57:02.475857  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 18018, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.52296 > 10.0.0.252.443: Flags [SEW], cksum 0x74a2 (correct), seq 912883613, win 29200, options [mss 1460,sackOK,TS val 1959525393 ecr 0,nop,wscale 7], length 0
300 packets captured
302 packets received by filter
0 packets dropped by kernel

[mat6937]

Was glaubst du denn WAS es ist ?

ÜBrigens grad mal durchgeführt

Code: Alles auswählen

37.24.59.146.52294 > 10.0.0.252.443: Flags [SEW], cksum 0xa255 (correct), seq 137527334, win 29200, options [mss 1460,sackOK,TS val 1959525390 ecr 0,nop,wscale 7], length 0
00:57:02.475857  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 18018, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.52296 > 10.0.0.252.443: Flags [SEW], cksum 0x74a2 (correct), seq 912883613, win 29200, options [mss 1460,sackOK,TS val 1959525393 ecr 0,nop,wscale 7], length 0
300 packets captured
302 packets received by filter
0 packets dropped by kernel

Ich denke, dass es was mit der Konfiguration deiner Konstellation zu tun hat.

Sind die "300 packets captured", alles SEW-Datenpakete von der IP-Adresse 37.24.59.146 zur internen IP-Adresse 10.0.0.252 (Port 443)?

37.24.59.146 ist doch einer deiner externen (statischen) IP-Adressen?

[spiralnebelverdreher]

ÜBrigens grad mal durchgeführt

Code: Alles auswählen

37.24.59.146.52294 > 10.0.0.252.443: Flags [SEW], cksum 0xa255 (correct), seq 137527334, win 29200, options [mss 1460,sackOK,TS val 1959525390 ecr 0,nop,wscale 7], length 0
00:57:02.475857  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 18018, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.52296 > 10.0.0.252.443: Flags [SEW], cksum 0x74a2 (correct), seq 912883613, win 29200, options [mss 1460,sackOK,TS val 1959525393 ecr 0,nop,wscale 7], length 0
300 packets captured
302 packets received by filter
0 packets dropped by kernel

Wie lange etwa lief tcpdump im obigen Fall durch, d.h. in wievielen Sekunden hast du die 300 Pakete aufgesammelt?

[Rubberduck]

Was glaubst du denn WAS es ist ?

ÜBrigens grad mal durchgeführt

Code: Alles auswählen

37.24.59.146.52294 > 10.0.0.252.443: Flags [SEW], cksum 0xa255 (correct), seq 137527334, win 29200, options [mss 1460,sackOK,TS val 1959525390 ecr 0,nop,wscale 7], length 0
00:57:02.475857  In 44:4e:6d:82:9e:32 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 62, id 18018, offset 0, flags [DF], proto TCP (6), length 60)
    37.24.59.146.52296 > 10.0.0.252.443: Flags [SEW], cksum 0x74a2 (correct), seq 912883613, win 29200, options [mss 1460,sackOK,TS val 1959525393 ecr 0,nop,wscale 7], length 0
300 packets captured
302 packets received by filter
0 packets dropped by kernel

Ich denke, dass es was mit der Konfiguration deiner Konstellation zu tun hat.

Sind die "300 packets captured", alles SEW-Datenpakete von der IP-Adresse 37.24.59.146 zur internen IP-Adresse 10.0.0.252 (Port 443)?

37.24.59.146 ist doch einer deiner externen (statischen) IP-Adressen?

Was sind SEW Pakete?
Aber ja, die 37.. ist meine externe öffentliche und der Server mit den Webseiten usw. 10.0.0.252.

###########################

Gestern Abend habe folgendes ernüchterndes festgestellt. In sofern glaube ich dass du vielleicht doch recht hast mit der falschen Konfig...
( ich könnte bald mal ein Buch darüber anfangen )

Nachdem jetzt alles wieder läuft und docker meinen ssl-proxy sowie meine Webseite und Cloud ins Netz hängt,
wollte ich die Konstellation inklusive der Container sichern.
Das mache ich über ein Skript, dass mittels docker-compose alles stoppt, mit tar alles wegsichert und docker wieder startet.

Nach ca. 3 Minuten ( nachdem die Container gestoppt waren und somit 443 auch nicht mehr von meinen ssl-proxy-docker-container (10.0.0.252) weitergeleitet wurde )
hatte ich wieder das selbe Problem.

Netzwerk in Richtung der WAN Strecke mit sehr großen Verzögerungen bis hin zu kompletten Aussetzern ( time > 10000 ).
Fritz box weg, nicht mehr aufrufbar. ( Übrigens sehe ich genau DANN etwas in dem tcpdump )

Ich schnell das Backup Skript abgebrochen, die Container wieder neu gestartet, zack Netzwerk wieder da.

---
Und wenn ich jetzt mal überlege, wie alles angefangen hat..

Ich wollte auf meinem Debian Server meinen ganzen Docker Kram auf ZFS umstellen.
Dafür habe ich natürlich alles runtergefahren, Server neu installiert, ZFS aktiviert... und DANN irgendwann abends hatte ich das Problem.

Meiner Analyse nach hat es sich dann irgendwann natürlich so 'angefühlt', als wenn immer wenn ich 443 weiterleite und jemand an nimmt, das WAN wegfliegt.
Scheinbar ist das aber die GANZE Zeit so und hat sich wohl auch nicht geändert, NUR hat bis zu meinem Umbau, Docker alles angenommen und dadurch ist es nicht aufgefallen.
(Ich kann es grad technisch nicht logischer erklären)

Ich hab das also gestern Abend noch mehrfach durchgespielt, wenn ich docker stoppe und somit 443 DIREKT auf dem Server ankommt und nicht von Docker entgegen genommen wird,
Dann habe ich die Ausfälle. Starte ich meine Docker Webseite und Cloud wieder und ist das auch wieder aus dem Internet zu erreichen, gibt es kein Problem.


Argss ist das verwirrend...ich komm nicht mehr ganz mit...ihr?

[mat6937]

Was sind SEW Pakete?

Das sind syn-Datenpakete mit gesetztem ecn-bit (Explicit Congestion Notification) und gesetztem cwr-bit (Congestion Window Reduced). Macht man in Linux mit z. B.:

Code: Alles auswählen

net.ipv4.tcp_ecn = 1

in der sysctl.conf

https://tools.ietf.org/html/rfc3168

EDIT:

... zum testen auch mit nping:

Code: Alles auswählen

nping -c 2 --tcp --flags=syn,ecn,cwr --delay=1s -g 11223 -p 443 37.24.59.146

und mit iptables kann man (!) ecn auch benutzen. Z. B.:

Code: Alles auswählen

iptables -I INPUT 1 -i <input-Interface> -p tcp --dport 443 --tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr -m state --state NEW -j DROP

[Rubberduck]

Was sind SEW Pakete?

Das sind syn-Datenpakete mit gesetztem ecn-bit (Explicit Congestion Notification) und gesetztem cwr-bit (Congestion Window Reduced). Macht man in Linux mit z. B.:

Code: Alles auswählen

net.ipv4.tcp_ecn = 1

in der sysctl.conf

https://tools.ietf.org/html/rfc3168

EDIT:

... zum testen auch mit nping:

Code: Alles auswählen

nping -c 2 --tcp --flags=syn,ecn,cwr --delay=1s -g 11223 -p 443 37.24.59.146

und mit iptables kann man (!) ecn auch benutzen. Z. B.:

Code: Alles auswählen

iptables -I INPUT 1 -i <input-Interface> -p tcp --dport 443 --tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr -m state --state NEW -j DROP

Ich versteh leider nicht was das bedeutet.
:=) Du hast SEW Pakete mit "Syn Datenbpakete mit ecn bit" erklärt. Das macht es für mich nicht verständlicher.
Was sagst du zu meiner "Geschichte" oben, seltsam alles oder?

[mat6937]

Ich versteh leider nicht was das bedeutet.

Siehe z. B.: https://de.wikipedia.org/wiki/Explicit_ ... tification

Was sagst du zu meiner "Geschichte" oben, seltsam alles oder?

Naja, so seltsam ist das nicht. M. E. bist Du ja auf dem richtigen Weg, die Ursache zu finden.

[Rubberduck]

Ich versteh leider nicht was das bedeutet.

Siehe z. B.: https://de.wikipedia.org/wiki/Explicit_ ... tification

Was sagst du zu meiner "Geschichte" oben, seltsam alles oder?

Naja, so seltsam ist das nicht. M. E. bist Du ja auf dem richtigen Weg, die Ursache zu finden.

Ok, was ich verstanden habe ist, dass das eine Methode ist, bei der nicht mehr so viele Paket wegen Überlastung verworfen werden.

Was ich grundsätzlich nicht verstehe ist, warum gibt es das Problem der Überlast?

Meine Freundin hat eine kleine 3-Mann Firma, denen habe ich genau das selbe Konstrukt gebaut wie mir.
Auf deren Hyper-V läuft ein Debian mit docker mit einem SSL Proxy einer Webseite und Owncloud.
Über zwei A Records und über die 443 Weiterleitung der selben (!) FritzBox 6390 Cable landen die auf der Maschine.

Einem Freund von mir habe ich auch genau das selbe eingerichtet, der hat eine Synology mit Debian drauf und dem selben Konstrukt.
Darüber hinaus, ist das ja eine total simple Geschichte, die QNAP bspw auch mit eigener Software und ddns Client anbietet.

Nie hab ich von solchen Problemen gehört.

Gruß

[Rubberduck]

Ich werde wohl heute Abend nicht mehr dazu kommen, das zu testen, da ich morgen früh für eine Woche in den Urlaub fahre.
Danach melde ich mich aber wieder.

[mat6937]

Ok, was ich verstanden habe ist, dass das eine Methode ist, bei der nicht mehr so viele Paket wegen Überlastung verworfen werden.

Was ich grundsätzlich nicht verstehe ist, warum gibt es das Problem der Überlast?

Ich denke nicht, dass das ein Problem der Überlast ist. Das ecn-Bit wird hier evtl. mehr oder weniger zufällig gesetzt sein, und hat mit deinem Problem dann nichts zu tun. Aber wenn Du das genau wissen willst, solltest Du schauen, wo bzw. auf welchem Gerät das ecn-Bit gesetzt wird:

Code: Alles auswählen

sysctl net.ipv4.tcp_ecn
sysctl net.ipv4.tcp_ecn_fallback

Was etwas merkwürdig ist, ist dass tcpdump als source IP-Adresse deine externe IP-Adresse (37.24.59.146) anzeigt.

Denn auch wenn im Router eine Portweiterleitung gemacht wird, muss auf dem Endgerät die tatsächliche source-IP-Adresse angezeigt werden. Oder Du hast tatsächlich nur aus deiner Konstellation (und nicht von einem fremden Internetanschluss) getestet.

EDIT:

Z. B. wenn ich in meiner FB6360-cable (Unitymedia) eine Portweiterleitung 443 auf das Gerät mit der internen IP-Adresse 192.168.178.22 konfiguriere und dann aus dem Internet (d. h. von einem fremden Internet-Anschluss) die externe/öffentliche IPv4-Adresse meiner FB6360-cable (als border device) auf dem Port 443 scanne, zeigt mir tcpdump als source-IP-Adresse nicht die externe IP-Adresse meiner FB6360-cable an, sondern die externe IP-Adresse (5.xx.68.xxx) des fremden Internet-Anschlusses:

Code: Alles auswählen

# tcpdump -vvveni eth0 port 443
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:32:12.924539 c0:25:06:##:##:## > ##:##:##:17:62:b4, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 54, id 54409, offset 0, flags [DF], proto TCP (6), length 52)
    5.xx.68.xxx.42102 > 192.168.178.22.443: Flags [S], cksum 0xd149 (correct), seq 64286421, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

[spiralnebelverdreher]

Was ich grundsätzlich nicht verstehe ist, warum gibt es das Problem der Überlast?

Das macht mich auch stutzig. Die von dir oben aufgezeichneten 300 SYN Pakete sollten deine Fritzbox nicht in die Verzweiflung treiben solange sie nicht jede Sekunde eintreffen. Vielleicht kannst du dir die Mühe machen, mal mit wireshark gezielt nachzuschauen, ob es tatsächlich eine SYN Flood Attacke ist oder ob damit eigentlich legitime TCP Verbindungen aufgebaut werden, aber in viel zu großer Zahl die dann auch noch lange leben.

[Rubberduck]

Was ich grundsätzlich nicht verstehe ist, warum gibt es das Problem der Überlast?

Das macht mich auch stutzig. Die von dir oben aufgezeichneten 300 SYN Pakete sollten deine Fritzbox nicht in die Verzweiflung treiben solange sie nicht jede Sekunde eintreffen. Vielleicht kannst du dir die Mühe machen, mal mit wireshark gezielt nachzuschauen, ob es tatsächlich eine SYN Flood Attacke ist oder ob damit eigentlich legitime TCP Verbindungen aufgebaut werden, aber in viel zu großer Zahl die dann auch noch lange leben.

Das ist durchgerauscht in dem Moment wo mein GW wegfliegt.
Das ist nur ein Ausschnitt eines ganzen Bildschirms. Wenn ich die Docker Container wieder anschalte, kommt nichts durch.

[Rubberduck]

Ich denke nicht, dass das ein Problem der Überlast ist. Das ecn-Bit wird hier evtl. mehr oder weniger zufällig gesetzt sein, und hat mit deinem Problem dann nichts zu tun. Aber wenn Du das genau wissen willst, solltest Du schauen, wo bzw. auf welchem Gerät das ecn-Bit gesetzt wird:
CODE: ALLES AUSWÄHLEN

sysctl net.ipv4.tcp_ecn
sysctl net.ipv4.tcp_ecn_fallback

Da gibt es ja nicht so viele Geräte..

FritzBox --> Gerät ( was auch immer , physik, VM ( Linux, Windows) )

Auf der FB kann ich das nicht nachschauen, meines Wissens, auch nicht ändern.
Jedes Endgerät...hm und ..wenn dann? Immer ändern?

[mat6937]

Jedes Endgerät...hm und ..wenn dann? Immer ändern?

Immer ändern musst Du nicht. Wenn, dann nur einmal, in der sysctl.conf.

[Rubberduck]

Jedes Endgerät...hm und ..wenn dann? Immer ändern?

Immer ändern musst Du nicht. Wenn, dann nur einmal, in der sysctl.conf.

is schon klar :=)
Ich meine damit, ich müsste das immer machen wenn ich einen Port weiterleiten möchte.
Das kann ja auch nur ein Workaround sein.

Stell dir irgendwie vor, das würde in einer Firma passieren und du müsstest jedesmal bei allen Endanwendern was ändern...die würden dir was erzählen.

Also klar, wenn es jetzt darum geht bei der einen Maschine eine Lösung herbei zu führen, wäre das noch ok ( und ich betone nochmal, danke für das Engagement ), aber ich experimentiere so viel mit VMs, nested VMs, LXC, Docker usw..da müßte ich ja jedesmal was anpassen nur um ein Portforwarding zu ermöglichen, das KANN einfach nicht die Lösung sein, immer am Endpunkt rumzufummeln, zumal es ja mal funktioniert hat.

[mat6937]

..., das KANN einfach nicht die Lösung sein, immer am Endpunkt rumzufummeln, zumal es ja mal funktioniert hat.

Ja, ich stimme dir (bzgl. ecn-Bit) zu, denn ich habe weiter oben ja geschrieben:

Das ecn-Bit wird hier evtl. mehr oder weniger zufällig gesetzt sein, und hat mit deinem Problem dann nichts zu tun.

Evtl. weiter suchen, warum auf dem Endpunkt (... bei dem auf Port 443 gelauscht wird) deine externe IPv4-Adresse als source-IP-Adresse gesehen wird.