firewalld block TCP-FIN

[Marco Moock]

Hallo!

Ich habe firewalld eingerichtet und bemerke im Log, dass Pakete
abgelehnt werden, die eigentlich nicht abgelehnt werden sollen.

STATE_INVALID_DROP: IN=eno1 OUT= MAC=x
SRC=2001:07d0:829c:4f00:4f6d:89be:9fc7:c6a0
DST=2001:mein-PC LEN=140 TC=0 HOPLIMIT=51
FLOWLBL=204023 PROTO=TCP SPT=1 DPT=39809 WINDOW=488 RES=0x00 ACK PSH
FIN URGP=0

Das sind die Pakete, die beim Schließen der TCP-Verbindung von der
Gegenseite gesendet werden.

Was ist da faul?
Ich würde jetzt mal davon ausgehen, dass sowas nicht der Standard sein
sollte, oder?

m@ryz:~$ sudo firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eno1
sources:
services: bittorrent-lsd dhcpv6-client ssh
ports: 51413/tcp 51413/udp 6771/udp 39315/udp
protocols: icmp ipv6-icmp
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
m@ryz:~$

Bitte Follow-Up2 beachten!

--
Gruß
Marco

[Tim Ritberg]

Am 18.09.23 um 12:12 schrieb Marco Moock:

> Hallo!
>
> Ich habe firewalld eingerichtet und bemerke im Log, dass Pakete
> abgelehnt werden, die eigentlich nicht abgelehnt werden sollen.

Local oder Router?

> STATE_INVALID_DROP: IN=eno1 OUT= MAC=x
> SRC=2001:07d0:829c:4f00:4f6d:89be:9fc7:c6a0
> DST=2001:mein-PC LEN=140 TC=0 HOPLIMIT=51
> FLOWLBL=204023 PROTO=TCP SPT=1 DPT=39809 WINDOW=488 RES=0x00 ACK PSH
> FIN URGP=0

Ist die Logline echt?
SPT=1 und DPT=39809???

Whois:
inet6num: 2001:7d0:8280::/42
netname: EE-ESTPAK
descr: Dynamic Links

> Das sind die Pakete, die beim Schließen der TCP-Verbindung von der
> Gegenseite gesendet werden.

Auch, und:
https://kb.mazebolt.com/knowledgebase/ack-psh-fin-flood/

>
> Was ist da faul?
> Ich würde jetzt mal davon ausgehen, dass sowas nicht der Standard sein
> sollte, oder?

Wohl ein Scan und wird sicher als nicht zugehörig zu ESTABLISHED gesehen.

Tim

--
Xubuntu 23.04 64 bit, Kernel 6.2 (native)
ASRock x470 Taichi, 64 GB RAM, Ryzen 7 3700X

Eine Firewall ist kein Konzept! RTFM: RFC 2979

[Marco Moock]

Am 18.09.2023 um 12:38:48 Uhr schrieb Tim Ritberg:

> Am 18.09.23 um 12:12 schrieb Marco Moock:

> > Ich habe firewalld eingerichtet und bemerke im Log, dass Pakete
> > abgelehnt werden, die eigentlich nicht abgelehnt werden sollen.
> Local oder Router?

Lokal unter Debian mit nftables.

> > STATE_INVALID_DROP: IN=eno1 OUT= MAC=x
> > SRC=2001:07d0:829c:4f00:4f6d:89be:9fc7:c6a0
> > DST=2001:mein-PC LEN=140 TC=0 HOPLIMIT=51
> > FLOWLBL=204023 PROTO=TCP SPT=1 DPT=39809 WINDOW=488 RES=0x00 ACK PSH
> > FIN URGP=0
> Ist die Logline echt?
> SPT=1 und DPT=39809???

Ja.
Drin im ICMP-Paket ist BitTorrent (Torrent-Client läuft).
Sieht für mich nach legitimem Traffic aus.
Port 1 ist zwar sehr, sehr komisch auf der Gegenseite, wäre aber
technisch möglich.

> Whois:
> inet6num: 2001:7d0:8280::/42
> netname: EE-ESTPAK
> descr: Dynamic Links

Passt, Peers aus Estland habe ich gesehen.

> > Das sind die Pakete, die beim Schließen der TCP-Verbindung von der
> > Gegenseite gesendet werden.
> Auch, und:
> https://kb.mazebolt.com/knowledgebase/ack-psh-fin-flood/
> >
> > Was ist da faul?
> > Ich würde jetzt mal davon ausgehen, dass sowas nicht der Standard
> > sein sollte, oder?
> Wohl ein Scan und wird sicher als nicht zugehörig zu ESTABLISHED
> gesehen.

Vermute ich eher nicht, siehe oben.
Eher noch ein gezielter Angriff auf BitTorrent.

[Günter Frenz]

Am Mon, 18 Sep 2023 12:56:09 +0200 schrieb Marco Moock:

> Am 18.09.2023 um 12:38:48 Uhr schrieb Tim Ritberg:
>
> > Am 18.09.23 um 12:12 schrieb Marco Moock:
> > > Ich habe firewalld eingerichtet und bemerke im Log, dass Pakete
> > > abgelehnt werden, die eigentlich nicht abgelehnt werden sollen.
> > >
> > Local oder Router?
>
> Lokal unter Debian mit nftables.
>
> > > STATE_INVALID_DROP: IN=eno1 OUT= MAC=x
> > > SRC=2001:07d0:829c:4f00:4f6d:89be:9fc7:c6a0
> > > DST=2001:mein-PC LEN=140 TC=0 HOPLIMIT=51
> > > FLOWLBL=204023 PROTO=TCP SPT=1 DPT=39809 WINDOW=488 RES=0x00 ACK
> > > PSH FIN URGP=0
> > Ist die Logline echt?
> > SPT=1 und DPT=39809???
>
> Ja.
> Drin im ICMP-Paket ist BitTorrent (Torrent-Client läuft).

Das Log sagt TCP, nicht ICMP...

> Sieht für mich nach legitimem Traffic aus.
> Port 1 ist zwar sehr, sehr komisch auf der Gegenseite, wäre aber
> technisch möglich.

Bei einem BitTorrent-Client wohl eher nicht...

>
> > Whois:
> > inet6num: 2001:7d0:8280::/42
> > netname: EE-ESTPAK
> > descr: Dynamic Links
>
> Passt, Peers aus Estland habe ich gesehen.

Nur weil du auch estnische BitTorrent-Partner hast, heißt das nicht
automatisch, dass alles aus Estland kommende dazu gehört. Wenn die
Firewall das Paket als STATE_INVALID einstuft, kann sie es keinem
bekannten Datenstrom zuordnen.

>
> > > Das sind die Pakete, die beim Schließen der TCP-Verbindung von der
> > > Gegenseite gesendet werden.
> > Auch, und:
> > https://kb.mazebolt.com/knowledgebase/ack-psh-fin-flood/
> > >
> > > Was ist da faul?
> > > Ich würde jetzt mal davon ausgehen, dass sowas nicht der Standard
> > > sein sollte, oder?
> > Wohl ein Scan und wird sicher als nicht zugehörig zu ESTABLISHED
> > gesehen.

Davon gehe ich auch aus.

Günter

[Marco Moock]

Am 18.09.2023 um 18:24:06 Uhr schrieb Günter Frenz:

> Am Mon, 18 Sep 2023 12:56:09 +0200 schrieb Marco Moock:

> > Sieht für mich nach legitimem Traffic aus.
> > Port 1 ist zwar sehr, sehr komisch auf der Gegenseite, wäre aber
> > technisch möglich.
>
> Bei einem BitTorrent-Client wohl eher nicht...

Wenn der als root läuft schon, das wäre aber sehr, sehr ungewöhnlich.

> >
> > > Whois:
> > > inet6num: 2001:7d0:8280::/42
> > > netname: EE-ESTPAK
> > > descr: Dynamic Links
> >
> > Passt, Peers aus Estland habe ich gesehen.
>
> Nur weil du auch estnische BitTorrent-Partner hast, heißt das nicht
> automatisch, dass alles aus Estland kommende dazu gehört. Wenn die
> Firewall das Paket als STATE_INVALID einstuft, kann sie es keinem
> bekannten Datenstrom zuordnen.

Das könnte aber natürlich auch eine fehlerhafte Konfiguration sein.

> > > Wohl ein Scan und wird sicher als nicht zugehörig zu ESTABLISHED
> > > gesehen.
>
> Davon gehe ich auch aus.

Wobei der dann wissen muss, dass ein BT-Client läuft (kann er
rausfinden, ist ja öffentlich).
Zudem muss der die IPv6 kennen, mit raten wird es eher schwer.
Ich vermute also, dass das ein BT-Client ist, der da scannt, sollte es
ein Angriff sein.

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

Das Log ist voll damit, völlig unterschiedliche IPs aus
unterschiedlichen Netzen und Ländern. Ich vermute da eher fehlerhafte
Torrent-Clients.

Bei TCP kann ich ja auf die Flags filtern und da gibt es massenhaft
welche mit SYN und Zielport=1.
Da lauscht aber bei mir nix, ergo kann das nichts sein, für das es bei
mir eine dynamische Regel gibt.

[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?

[Günter Frenz]

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

[Marco Moock]

Am 20.09.2023 um 19:23:16 Uhr schrieb Günter Frenz:

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

Wo kann man in dem Fall diese Zeiten auslesen?

[Marc Haber]

Marco Moock <mm+use...@dorfdsl.de> wrote:
>Ist das ein Problem beim Connection-Tracking?

TCP ist ein hochkomplexes, unterspezifiziertes Monster, dessen
Spezifikation auf Drölfzig RFCs verteilt ist, so schlimm, dass es ein
eigenes RFC als Wegweiser durch die TCP-RFCs gibt.

Für stateful handling auf dem Netzwerkweg, sei es Paketfilterung oder
Connection Tracking, muss man die TCP State Machine im Wesentlichen
komplett nachimplementieren. Linux Netfilter hat dabei den Ruf, dies
nicht so ganz vollständig getan zu haben, besonders in den Bereichen,
wo Security und Standardkonformität nicht so ganz in sync zueinander
sind. Das beobachte ich durchaus bevorzugt beim Verbindungsabbau, da
fällt das nämlich nicht auf wenn nicht detailliert loggt oder die Logs
nicht genau genug anschaut.

Ich habe keine Ahnung ob sich das in den letzten zehn Jahren geändert
hat, aber gefühlt bewegt sich die Codequalität von Netfilter in dieser
Zeit eher rückwärts. So ist z.B. meine Telefonie-Fritzbox seit zwei
Jahren nicht mehr hinter der Linux-Firewall weil das SIP ständig
rumgezickt hat.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Günter Frenz]

Bei der Software im Quellcode, bei TCP in den RFCs...

[Marco Moock]

Am 20.09.2023 um 22:36:34 Uhr schrieb Marc Haber:

> Für stateful handling auf dem Netzwerkweg, sei es Paketfilterung oder
> Connection Tracking, muss man die TCP State Machine im Wesentlichen
> komplett nachimplementieren. Linux Netfilter hat dabei den Ruf, dies
> nicht so ganz vollständig getan zu haben, besonders in den Bereichen,
> wo Security und Standardkonformität nicht so ganz in sync zueinander
> sind.

Was ist da denn die bessere Alterantive?

Bei iptables wird gemunkelt, dass das irgendwann rausfliegt.
Bei firewalld ist das schon als deprecated markiert.

[Marc Haber]

Marco Moock <mm+use...@dorfdsl.de> wrote:
>Am 20.09.2023 um 22:36:34 Uhr schrieb Marc Haber:
>> Für stateful handling auf dem Netzwerkweg, sei es Paketfilterung oder
>> Connection Tracking, muss man die TCP State Machine im Wesentlichen
>> komplett nachimplementieren. Linux Netfilter hat dabei den Ruf, dies
>> nicht so ganz vollständig getan zu haben, besonders in den Bereichen,
>> wo Security und Standardkonformität nicht so ganz in sync zueinander
>> sind.
>
>Was ist da denn die bessere Alterantive?

Warum willst Du das ändern wenn es doch funktioniert?

Man sagt, die BSDs hätten da besseres. Das kann ich aber nicht
beurteilen, es gibt in der BSD-Welt zu viel anderes was mich nervt.

>Bei iptables wird gemunkelt, dass das irgendwann rausfliegt.
>Bei firewalld ist das schon als deprecated markiert.

iptables wird uns noch eine ganze Weile erhalten bleiben, docker
benutzt es, nahezu alle anderen Virtualisierungs- und
Containertechniken benutzen es, hinter der Wand benutzt es sowieso
nft, und nftables ist weit von fertig entfernt und das Ökosystem
drumrum ist vielleicht ein hundertstel von dem was es um iptables
herum gibt.

[Marco Moock]

Am 21.09.2023 um 17:33:26 Uhr schrieb Marc Haber:

> Warum willst Du das ändern wenn es doch funktioniert?

Wenn Pakete gedroppt werden, die nicht gedroppt werden sollten, würde
ich das nicht unter funktionieren einordnen.

[Paul Muster]

Gibt es denn irgendwelche spürbaren Probleme auf Applikationsebene? Oder
gar Logmeldungen über Probleme?


mfG Paul

[Marco Moock]

Am 22.09.2023 um 18:23:05 Uhr schrieb Paul Muster:

> Gibt es denn irgendwelche spürbaren Probleme auf Applikationsebene?
> Oder gar Logmeldungen über Probleme?

Nein, aber die Verbindungen sind weiter offen, was nicht sein müsste.
TCP baut die ordnungsgemäß ab, wenn die Firewall die Pakete mit ACK FIN
nicht droppen würde.

Das macht jetzt noch kein Problem, ist aber technisch eines, gerade
wenn viele Verbindungen aufgebaut werden.

[Paul Muster]

Ich denke, der Kernel löscht diese Sessions auch ohne sauberes FIN _nach
einer gewissen Zeit_ und gibt die belegten Ressourcen frei.

Solltest du Engpässe und/oder Fehlermeldungen feststellen, würde es sich
mMn lohnen, dem Thema tiefer nachzugehen. Wenn nicht, dann nicht.


mfG Paul

[Marco Moock]

Am 22.09.2023 um 20:16:46 Uhr schrieb Paul Muster:

> Ich denke, der Kernel löscht diese Sessions auch ohne sauberes FIN
> _nach einer gewissen Zeit_ und gibt die belegten Ressourcen frei.

Natürlich, aber das ist eigentlich nicht der vorgesehene weg.

> Solltest du Engpässe und/oder Fehlermeldungen feststellen, würde es
> sich mMn lohnen, dem Thema tiefer nachzugehen. Wenn nicht, dann nicht.

Ich werde mal versuchen, dem weiter nachzugehen.

[Marc Haber]

Marco Moock <mm+use...@dorfdsl.de> wrote:
>TCP baut die ordnungsgemäß ab, wenn die Firewall die Pakete mit ACK FIN
>nicht droppen würde.

Das tut sie nicht.

Denk daran, dass das ACK nicht das FIN bestätigt sondern die
enthaltenen Daten. In diesse Falle tippt man gerne.

[Marco Moock]

Am 25.09.2023 um 17:04:35 Uhr schrieb Marc Haber:

> Denk daran, dass das ACK nicht das FIN bestätigt sondern die
> enthaltenen Daten. In diesse Falle tippt man gerne.

Ist sowas denn technisch überhaupt vorgesehen oder müsste das getrennt
sein, sprich ACK für die Daten und dann ein FIN für das Trennen?

Wenn dem so ist, wäre die doch TCP-Implementierung auf der Gegenseite
die Problemstelle, oder?

[Günter Frenz]

Das FIN wird genauso wie das SYN mit einem ACK bestätigt. Das FIN kann
einerseits separat ohne Daten geschickt werden aber auch zusammen mit
den letzten Daten. Habe ich in Mitschnitten alles schon gesehen. Das
ACK-Flag sagt letztlich nur aus, dass das Segment eine gültige
ACK-Nummer enthält. Wenn ein FIN oder SYN bestätigt wird, wird die
ACK-Nummer um 1 hochgezählt. Kannst du in jedem vollständigen
Mitschnitt einer TCP-Verbindung nachvollziehen. Da wir nicht wissen, ob
das zweite FIN vor oder nach deinem Logeintrag gelaufen ist, ist eine
Schuldzuweisung an eine der beiden Seiten schwierig...

Bis denn
Günter