2.27 cu 164 Testing release - Hostile & CTInvalid logging

Running 2.27 cu 164 Testing release and have enabled Drop packets from and to hostile networks.
I have the majority of countries blocked to my firewall (as don’t host any services), but am getting many DROP_HOSTILE logs from blocked countries and a few DROP_CTINVALID from blocked countries.

Is it possible for you to move the hostile network checking and CT Invalid checking logic to after Location Block logic?

This would reduce logging for countries that should be getting ignored by the Location Block matches.

Hi,

thanks for your testing feedback.

Indeed, both the “hostile networks” stuff and the connection tracking happen before the location block. For the latter, this cannot be changed due to technical reasons, so you can at best disable logging of DROP_CTINVALID packets completely.

Actually, I have long suspected conntrack to sometimes drop packets it actually should not have dropped. But since we never logged them, I was unable of the extend of the problem (actually, I am not quite sure if it is a problem at all). In theory at least, such drops should not occur, so it is good to have them logged - which is also why we decide to log these by default, since we hope that makes debugging previously unexplained network errors easier.

Regarding the location block, I really think we need to clarify the wiki page for it, and explain better what it does and what it doesn’t.

Since you do not run any services on your IPFire machine, you might as well disable the location block completely - incoming packets will be dropped later anyways, so there is no security implication in enabling or disabling the location block.

Actually, the intended purpose of the location block was to reduce the amount of log messages on installations running on extremely cheap flash storage. However, this feature turned out to be misunderstood frequently, and I think a firewall should always log if it interfered with the traffic for transparency reasons. The location block precisely does the opposite.

To cut it short: The only solution I can offer is to disable the “drop hostile” filter, and create a firewall rule for outgoing traffic to the country code XD, dropping and logging it. That will have the same effect, since incoming traffic cannot cause any harm in your scenario.

Also, and for the records, I am really unhappy with the location block, and I think it would be good if we replaced it by a better and less misunderstanding-prone solution.

Thanks, and best regards,
Peter Müller

1 Like

I like the fact that Location Block silently drops packets and does not fill the Firewall Logs.
Regardless of storage, it’s enough trawling through hundreds of log entries, rather than thousands.
Looking for a needle in a haystack and all that.

Maybe Location Block logs should be to their own file and accessed via own menu or an entry in the System Logs, like Intrusion Prevention does?

2 Likes

These entries have appeared in the Firewall Log:

10.254.0.1 is my Ip Green of IPFire.
10.254.0.89 is my Pc with W11.

Apparently it is port 800 of Squid.

Bye.

Interesting,
When I block ALL countries with Location block,
I still see 2-3 entries in “Firewall log” mostly from CHINA

In the “IPS log” I see 2000-3000 entries from around the world, even though all the countries are blocked with Location block.

Hi,

yes, we have long suspected conntrack may drop some packets it should not have dropped in the first place, but there was never any proof for that.

Thanks to the logging enabled, we can now investigate on these - apparently, a decent amount of them are FIN-ACKs sent very late by the peer (especially observed in conjunction with Cloudflare and Akamai - perhaps they run their own customised network stack?). Having these logged is ugly, but not a thing to worry about.

At the moment, I would really like to release Core Update 164 with this logging enabled. We should get deeper into this issue, presumed it actually is an issue.

Thanks, and best regards,
Peter Müller

2 Likes

Hi Trish,

is that a new issue appeared only after upgrading to Core Update 164?

If not, please open a new thread for it, so we can keep this one focused. :slight_smile:

Thanks, and best regards,
Peter Müller

2 Likes

hi
i have same message in log
i have clean instal Core Update 164
ty

Hi,

what log message are you referring to?

Thanks, and best regards,
Peter Müller

the Firewall Log

Hi,

And what in there precisely? DROP_CTINVALID, DROP_HOSTILE, or something else?

In doubt, please post the complete log message here, and elaborate why you think it is a problem.

Thanks and best regards,
Peter Müller

the same message that [trish] and [Roberto Peña]
i have this version 2022-02-22 11:38:15 +0000-ad9d6bf5/ in my apu
ty

no problem just a return

Thank you for the reply. I will open a new thread

1 Like

For me the ongoing Drop_Ctinvalid log entries appear after upgrade to 164. It’s restricted to DHCP clients on blue (WLan connected mobile phones, WLan connected IOS tablets) where WhatsApp is active. It seems to drop outgoing traffic as well as incomming traffic to/from port 443, sometimes 993. Anyway the connect to WhatsApp and the Mail-Server works. Whatever here is dropped.
Mainly I’m seeing blocked outgoing traffic to 142.251.36.170, which is google llc.
Which is by-the-way a strange situation since outgoing traffic up to now was never blocked nor logged.

Hi @guenni

Welcome to the IPFire community.

Drop_ctinvalid was always dropped by connection tracker but was never known about because it was not logged. The devs had suspicions about stuff being dropped and so from CU164 logging of these messages has been turned on to help see what is happening and to help with debugging why it is happening.

2 Likes

Hi,

hm, I am getting the feeling we should be more distinctive about network traffic in IPFire. Especially since we never really clarified that, for example, the firewall log shows packets, not connections.

This appears to be a bit confusing when it comes to the source and destination IP address displayed there, since it is not obvious that an external source IP address not necessarily implies the corresponding connection was also established from the outside, too.

Displaying the flags of the packet in question might help skilled users, but I think including them might be a bit of an overkill for the rest…

Just my thoughts on this.

Thanks, and best regards,
Peter Müller

3 Likes