Core: Filterlog: Rule Number May Change - need tracker ID for log collectors

[gauthig]

Issue
When using a log collector and analyzer, (ELK, SPLUNK...) you cannot match the block/pass reason to a rule as the rule number may change if you reorder or make any changes to it. This makes analysis hard.

Enhancement Request
Follow same enhancement from pfSense - create a tracker id for each rule including system and default firewall rules. /etc/inc/filter.inc
Or
Use the calculated rule hash and expose it in the syslog

1. Create fix ID for each filterlog rule that does not change with rule ordering or changes to the rule.
2. All system default rules get a static tracker id
3. Tracker id must not be reused if rule deleted
4. add tracker id to the filterlog and ensure it is sent for log forwarding
5. Have the rule tracker id displayed with the pfctl -sr command along with rule description

[AdSchellevis]

we're not planning to add non standard kernel patches, but you might be able to use the same method we use for parsing the logs inline using syslog-ng. our approach can be found here https://github.com/opnsense/core/blob/master/src/opnsense/scripts/filter/read_log.py

[gauthig]

Thanks @AdSchellevis, I would agree with the approach of not using kernel extensions and utilizing the syslog-ng. Looking at the output of pfctl -sr there is a static label for each rule that does not change like rule numbers do. Here is an example:

pfctl -sr | grep sand
pass in

log quick on vmx1 reply-to (vmx1 47.180.18.1) inet proto tcp from any to port = 3400 flags S/SA keep state label "61190f4fceaef6abb48e072638de49b9"

So recommending the enhancement request be changed to:
1 - Pass the rule label to the log output if the syslog target level is set to NOTICE
2 - Pass the rule description to the log output if syslog target level is set to INFO

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.