The blocking logs of "HOSTILE_DROP_IN" and "HOSTILE_DROP_OUT" appear to be absent, although the chains mentioned, regularly block HOSTILE traficking

Security Firewall Rules
1

I have updated IPFire to CU 184.
I noticed that the Chain “HOSTILE_DROP” has been split into “HOSTILE_DROP_IN” and “HOSTILE_DROP_OUT”.
But in the Logs (both those visible in Web/GUI and those stored in my own SysLog server), I see no attempts to block the mentioned chains. I can confirm that “hostile packets passed through my IPFire and were blocked,” but from my logs, this does not show up.
Is this normal? In previous versions, all blocking attempts of the HOSTILE chain were visible.
I thank you in advance.

Attivato
Attivato1004×867 58.2 KB

2
  1. I have disabled and saved the two “HOSTILE” options that pertain to the logs, on the figure above.
  2. I restarted IPFire.
  3. I have reactivated and saved the two “HOSTILE” options involving logs, in the figure above.
  4. I restarted IPFire.
  5. It seems to be working now. :+1: :+1:
1 Like
3

Hi @casabenedetti

I had a look at my machine and also found no DROP_HOSTILE entries in the logs.

I just pressed the Save button leaving the logging entries enabled and then rebooted and that fixed the problem for me.

I missed this issue during the testing. I was concentrating more on the graphs of the DROP_HOSTILE split into in and out and maintaining the history in some form.

I will look to see what command needs to be run additionally in the update.sh script for the upgrade.

3 Likes
4

I have realised that I added the logging options into the WUI cgi page but in the upgrade.sh script I did not add the new logging entries into the
/var/ipfire/optionsfw/settings file . Pressing the Save button makes that happen but the two new options also need to be added to the settings file.

If they are missing from the file the code treats it the same as if the settings are set at Off.

Will do a patch submission to fix the Core Update 184 update.sh script.

2 Likes
5

I thank you for the valuable information. I was convinced it was something isolated in my machine. I’ll leave the post unresolved so anyone can add. I will follow the progress :+1: :+1: :+1: :wink:.

6

I have already submitted a patch to fix the problem.

Once that gets accepted, merged and built then any CU84 update will no longer have the problem.

A fresh install of CU184 will not have the problem as the fw options settings file is created with the default values.

The hostile entries are still dropped if you had that selected before, it is just that the logging is not enabled.

4 Likes