Gathering some info from Firewall Logs is hard

[sec-con]

First of all, I do not pay a lot of attention to logs. They just gather too much information in many cases and ways of limiting them to show actually dangerous activity seems to be hard and require code.

The time is 12:15 and my log has

Total number of firewall hits for December 21, 2023: 24423

So just for a bit of fun, I thought I would make an export and sort out items labeled as

DROP_HOSTILE
only that.

So I click on Export and get a text based page with 24665 lines but zero entries labelled as DROP_HOSTILE . Ok?

Me no understand. I don’t speak “firewall”.

[bbitsch (Bernhard Bitsch)]

You are right.
Doing an examination through the WUI ( firewall logs, export ) doesn’t output the cause.
This is a case for bugzilla.

Alternatively you could try a search in /var/log/messages on the command line ( search tool is grep ).

[sec-con]

Do you bug or do I bug ?

My bug account works.

[jon]

I get LOTS of DROP HOSTILEs. Please post a screenshot of your Firewall Options page.

Here is mine:

[jon]

I think I see what you are saying. All the log names (e.g., DROP_xxxxxx) are missing.

Yes, please add this bug to bugzilla. That will help make sure the Development team reviews this information.

Login using your IPFire email address and your IPFire password.

Information to add a bug report in IPFire Bugzilla:

• IPFire Bugzilla
  • https://bugzilla.ipfire.org
• Bugzilla info in IPFire Wiki
  • wiki.ipfire.org - Bugzilla

---

EDIT:
but they do appear in the message log:

[root@ipfire ~] # cat /var/log/messages | head -30
Dec 17 00:01:00 ipfire syslogd 1.5.1: restart (remote recep
Dec 17 00:01:01 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:02 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:05 ipfire dhcpd: CRE-Commit:  ClientIP: 192.16
Dec 17 00:01:05 ipfire dhcpd: execute_statement argv[0] = /
Dec 17 00:01:05 ipfire dhcpd: execute_statement argv[1] = c
Dec 17 00:01:05 ipfire dhcpd: execute_statement argv[2] = 1
Dec 17 00:01:05 ipfire dhcpd: execute_statement argv[3] = i
Dec 17 00:01:05 ipfire dhcpEvent: testing --> /root/dhcpdco
Dec 17 00:01:06 ipfire dhcpEvent: commit: same -> iPhone-W0
Dec 17 00:01:06 ipfire dhcpEvent: commit: same hostname & s
Dec 17 00:01:06 ipfire dhcpEvent: commit: finished
Dec 17 00:01:06 ipfire dhcpd: DHCPREQUEST for 192.168.65.11
Dec 17 00:01:06 ipfire dhcpd: DHCPACK on 192.168.65.110 to 
Dec 17 00:01:06 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:07 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:07 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:09 ipfire unbound: [7526:0] info: validation f
Dec 17 00:01:12 ipfire unbound: [7526:0] info: rpz: applied
Dec 17 00:01:14 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:15 ipfire unbound: [7526:0] info: rpz: applied
Dec 17 00:01:15 ipfire unbound: [7526:0] info: rpz: applied
Dec 17 00:01:16 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:16 ipfire unbound: [7526:0] info: rpz: applied
Dec 17 00:01:27 ipfire kernel: DROP_FORWARD IN=blue0 OUT=gr
Dec 17 00:01:27 ipfire kernel: BLKLST_CIARMY IN=red0 OUT= M
Dec 17 00:01:28 ipfire rsnapshot[7436]: /usr/bin/rsnapshot 
Dec 17 00:01:28 ipfire rsnapshot[7594]: /usr/bin/rsnapshot 
Dec 17 00:01:29 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA
Dec 17 00:01:32 ipfire kernel: DROP_HOSTILE IN=red0 OUT= MA

[hvacguy (Shaun HVAC)]

Wow @jon thats hard core.
Firewall policy Defaults all BLOCKED.
Very cool.

[jon]

my set-up? No, not as blocked as I would like…

[sec-con]

As per request by the non-expert…

I will spam GodZilla a bit later. When the sun is up…

[sec-con]

13492 done

[bonnietwin (Adolf Belka)]

Patch with the fix has been submitted.

[sec-con]

seen it, commented, that was fast…

[bonnietwin (Adolf Belka)]

Well i wasn’t doing anything else when i was reading this thread so i had a look at the code and the fix turned out to be quite simple. Glad to have been able to help.