Groups | Search | Server Info | Login | Register
Groups > de.comp.security.firewall > #304
| From | Günter Frenz <usenet-01@guefz.de> |
|---|---|
| Newsgroups | de.comp.security.firewall |
| Subject | Re: firewalld block TCP-FIN |
| Date | 2023-09-20 19:23 +0200 |
| Organization | news.netcologne.de |
| Message-ID | <20230920192316.5d6f90ca@corinnis.midgard> (permalink) |
| References | <ue97q6$1nagj$1@dont-email.me> <ue99bo$a735$1@tota-refugium.de> <ueegp2$2slju$1@dont-email.me> |
Am Wed, 20 Sep 2023 12:16:02 +0200 schrieb Marco Moock: > Am 18.09.2023 um 12:38:48 Uhr schrieb Tim Ritberg: > > > Wohl ein Scan und wird sicher als nicht zugehörig zu ESTABLISHED > > gesehen. > > [813898.534972] STATE_INVALID_DROP: IN=enp1s0 OUT= > MAC=xxxx > SRC=2001:0470:xxxx #mein PC > DST=2a01:0170:#Mein IMAP-Server LEN=72 TC=0 HOPLIMIT=55 > FLOWLBL=746672 PROTO=TCP SPT=56758 DPT=993 WINDOW=1552 RES=0x00 ACK > FIN URGP=0 > > Das kam definitiv von meinem Rechner, wurde aber von firewalld > verworfen. Was ist da der Grund? > > Ist das ein Problem beim Connection-Tracking? Solange man nicht weiß, wann das andere FIN-Paket gelaufen ist, ist das Kaffesatzleserei. Der TCP-Verbindungsabbau ist mit 4 Paketen definiert, damit Server und Client ihren jeweiligen Teil der Verbindung zeitversetzt und unabhängig voneinander beenden können. Ich weiß den maximal zulässigen Abstand der der beiden FIN-Pakete nicht auswendig, aber wenn zu lange keine Pakete laufen, wird die Verbindung als abgebrochen betrachtet. Das Connection-Tracking sollte in diesem Fall die gleichen Zeiten verwenden wie das normale Betriebssystem. Ob das in diesem Fall so ist, kann man aus deinen Daten nicht herauslesen... Günter
Back to de.comp.security.firewall | Previous | Next — Previous in thread | Next in thread | Find similar
firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-18 12:12 +0200
Re: firewalld block TCP-FIN Tim Ritberg <tim@server.invalid> - 2023-09-18 12:38 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-18 12:56 +0200
Re: firewalld block TCP-FIN Günter Frenz <usenet-01@guefz.de> - 2023-09-18 18:24 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-18 20:22 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-19 09:05 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-20 12:16 +0200
Re: firewalld block TCP-FIN Günter Frenz <usenet-01@guefz.de> - 2023-09-20 19:23 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-20 20:20 +0200
Re: firewalld block TCP-FIN Günter Frenz <usenet-01@guefz.de> - 2023-09-20 23:27 +0200
Re: firewalld block TCP-FIN Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-09-20 22:36 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-21 07:50 +0200
Re: firewalld block TCP-FIN Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-09-21 17:33 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-21 18:16 +0200
Re: firewalld block TCP-FIN Paul Muster <exp-311223@news.muster.net> - 2023-09-22 18:23 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-22 19:03 +0200
Re: firewalld block TCP-FIN Paul Muster <exp-311223@news.muster.net> - 2023-09-22 20:16 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-22 20:34 +0200
Re: firewalld block TCP-FIN Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-09-25 17:04 +0200
Re: firewalld block TCP-FIN Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-09-25 21:00 +0200
Re: firewalld block TCP-FIN Günter Frenz <usenet-01@guefz.de> - 2023-09-25 21:14 +0200
csiph-web