Bug 12778 - IPFire 164 Dev Build - Empty entries in FW log
Summary: IPFire 164 Dev Build - Empty entries in FW log
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: - Unknown - Balancing
Assignee: Peter Müller
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-17 17:26 UTC by Alex Neth
Modified: 2022-03-16 20:40 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Neth 2022-02-17 17:26:52 UTC
Please see my post in forum:

https://community.ipfire.org/t/ipfire-164-dev-build-empty-entries-in-fw-log/7255


Since the IPFire 164 Dev Build update, I can see quite some empty “Chain column” entries in the FW log.

https://community.ipfire.org/uploads/default/original/2X/7/78805188768af971c864f3d3a322a21aeae22ec4.png

Most of them are outgoing connections from green0
Here a few examples of the target IPs in those empty entries:

142.250.186.42
157.240.27.35
184.51.7.202
Here an example of an incoming connection with an empty entry:

https://community.ipfire.org/uploads/default/original/2X/e/ea578a2b96a043cb3177c7a0411d7680404caf9d.png

(Incoming IP: 2.19.244.28)

My firewall options are the following:

https://community.ipfire.org/uploads/default/original/2X/6/63d8f2d77f06793572afc8b257e6b2632c3583a8.png


At first I was thinking that the empty entries are a result of the new “hostile network” feature (Nice feature - Many thanks for that!). However I can find “DROP_HOSTILE” entries on incoming ppp0 connections; so logging is working in general - I guess.

I also do not have other Firewall rules:

https://community.ipfire.org/uploads/default/optimized/2X/a/ae7589b2fd43cf0684c1a178df4ab3cddaba07de_2_690x411.png

Question:

Where do these empty “Chain column” entries come from?
Why are they blocked? (or are they blocked?)


Thanks for checking & Cheers!
Comment 1 Peter Müller 2022-02-17 19:13:53 UTC
Hi,

this was accidentally introduced in commit 0e7bfb1343d28069acfbaacb957cd199f8ead099.

While fixing this should not be a difficult task in technical term, two aspects prevent me from doing that:

1. Right now, LOG_DROP only logs things without any prefix. But since we don't know the direction of a packet conntrack marked as INVALID, we cannot easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it is wise to introduce _another_ log prefix - we have (too ?) many of these already.

2. It would be interesting to see why conntrack decided to flag these packets as INVALID. It is good to get such events _logged_, and I think that might clarify some firewall malfunctions we never figured out before. However, I cannot get rid of the feeling something is off at conntrack.

Any opinions, especially to (1)?

Thanks, and best regards,
Peter Müller
Comment 2 Michael Tremer 2022-02-17 19:24:10 UTC
(In reply to Peter Müller from comment #1)
> 1. Right now, LOG_DROP only logs things without any prefix. But since we
> don't know the direction of a packet conntrack marked as INVALID, we cannot
> easily use DROP_{INPUT,OUTPUT,FORWARD}. On the other hand, I don't think it
> is wise to introduce _another_ log prefix - we have (too ?) many of these
> already.

Why not? If you want to know why something got dropped, you will have to log it.
Comment 3 Peter Müller 2022-02-17 19:33:47 UTC
Certainly, and I think it is good to have these packets logged.

But what log prefix should we use? DROP_CONNTRACK?
Comment 4 Michael Tremer 2022-02-17 19:40:33 UTC
(In reply to Peter Müller from comment #3)
> But what log prefix should we use? DROP_CONNTRACK?

Why not DROP_INVALID?
Comment 5 Peter Müller 2022-02-17 19:47:57 UTC
> Why not DROP_INVALID?

Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP stuff?
In a way, they can all be considered "invalid"...
Comment 6 Michael Tremer 2022-02-17 19:48:52 UTC
(In reply to Peter Müller from comment #5)
> > Why not DROP_INVALID?
> 
> Hm, wouldn't this lead to confusions with DROP_NEWNOTSYN and the BADTCP
> stuff?
> In a way, they can all be considered "invalid"...

Yes they would, but I wouldn't have mixed those things together.

To be entirely clear you could go with DROP_CTINVALID
Comment 7 Peter Müller 2022-02-17 20:16:52 UTC
> To be entirely clear you could go with DROP_CTINVALID

I like it. Patch sent: https://patchwork.ipfire.org/project/ipfire/patch/c9cdec8e-bec6-1793-2b8e-7a83e6f7d2d8@ipfire.org/
Comment 8 Alex Neth 2022-02-17 21:24:38 UTC
Nice! That’s what I call efficient :-D
Comment 9 Peter Müller 2022-02-18 22:14:29 UTC
Arne asked me to provide a switch to disable logging for such events anyway. It seems as conntrack drops a lot of (at the first glance legitimate) packets, which bloats the logs and makes more serious log events harder to spot.

While I don't think logging for this should ever be disabled in production, his argumentation made sense to me. Therefore, I will apply the aforementioned patch to "next", add another one for toggling logging, and will request both patches to be cherry-picked into "master" when I'm done.
Comment 13 Christof Misch 2022-02-21 11:00:52 UTC
Hi,

I just upgraded to Core Update 164 Development Build: master/3b45d956
My Log gets flooded with DROP_CTINVALID
May be because of this change?


Not a topic to this bug report...
I just wanted to report that the upgrade to this version on XEN HVM client was successfull! (As Peter asked for testing on XEN.)
have two findings:
grep FATAL update-core-upgrade-164.log
modprobe: FATAL: Module nf_log_ipv4 not found in directory /lib/modules/5.15.6-ipfire
I think thats not Problem but may be resolved somehow.

Console output during boot
Creating Squid swap directories...                                     [  OK  ]
Starting Squid Proxy Server...
Unable to continue: /usr/sbin/squid is running                         [ WARN ]

BUT Squid is down!
I have this Problem for a long time ...
maybe same as  https://bugzilla.ipfire.org/show_bug.cgi?id=12623

Sorry for writing the update check outcome to this Bug report too ...