Groups | Search | Server Info | Login | Register


Groups > de.comp.security.firewall > #304

Re: firewalld block TCP-FIN

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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