In Log, is it very difficult to add a "rule name"

Continuing the discussion from Firewall Rule Name for logging:

Hello together,

I would support this for usability/ergonomic reasons.

Is it very difficult to implement, to additional log a „rule name“ and also if it‘s an ALLOW- or a DENY-rule which is hit!?

Kind regards
Alex

Hello again,

I‘m no experienced ipfire- or linux-user, but I just digged a little bit deeper and changed the log-prefix in /usr/lib/firewall/rules.pl in line 603.

I changed it from ‘$chain‘ to ‘$chain\_$key‘ and now I get the rule-number in the logging.

I checked the cgi‘s to not break anything, but haven‘t found anything yet.
Messages and also iptables -L seems well.

Can somebody of the developers confirm, that this ‚patch’ doesn‘t break anything important??

Thanks and kind regards
Alex

1 Like

Just being curious: since line 603 in /usr/lib/firewall/rules.pl (Core 174) is actually empty - which line(s) exactly did you change?

Best,
Matthias

2 Likes

Hello Matthias,

sorry - it could also be line 602 - i used vi (-:
Find a screenshot attached what was added and how it looks like in the logging…

(sure that’s not perfect, and I would wish some real integration, but at the moment it’s okay for me to find the rules, which has been hit …)

regards
alex


1 Like

maybe line 606.

I do like what you added!

1 Like

ah… yes - thanks @Jon
it’s 606

I didn’t get, that @mfischer linked to git…

the problem with this is, that everytime the rules change in order, the corresponding log-entry changes as well… so it’s not for history…

Adding a “Rule Name” and also “Rule Number” to the log - HowTo & Proposal:

It has been a while since, and I’m still wondering how you get through your ipfire logs, without a rule name or even having the rule number in the log.
Being not so routinized in reading the logs, I often have to search for the fw-rule which is being hit.

I have enhanced therefore the idea from april 23 a little bit and inserted in rules.pl the following:

my $ruleinfo = "$target\_$key\_" . (substr((split(/\s/, $$hash{$key}[16]))[0], 0, 5) =~ s/[\s\$'\"<>&?]//gr);  # BLOCK/ALLOW/REJECT_Rulecount_Comment5chars sanitized

This will form a String with the type of the rule target (BLOCK, ALLOW or REJECT), with the actual rule number and the first 5 chars of the rule description.
So it’s possible, to use this additional $ruleinfo in the iptables --logprefix
e.g.:

some definition of fw-rules for example:

In the log it will look like this - and is a little bit easier to see, what’s going on.

image

@mfischer or @ms : Could something like this be integrated in ipfire by default?

changed to some better sanitisation of the string:

my $ruleinfo = "$target\_$key\_" . substr((split(/\s/, $$hash{$key}[16]))[0], 0, 5);
$ruleinfo =~ s/[^\w().-]//g;  # BLOCK/ALLOW/REJECT_Rulecount_Comment5chars sanitized (just a-zA-Z0-9().-)

In theory yes, but the ID of the rule is not the same as the shown number. If you delete a rule in the middle, the numbers of the rules after the deleted rule will change.

And so there would even be some inconsistency in the logs. I like the idea, but I don’t think the numbers would be fool-proof.

i think instead we could use unique rule name which can be entered by the user or/and uuid, but log-prefix of iptables is limited to 29 char or something

Thanks Michael for reply - yes, you‘re absolutely right, the number (counting order) is not „persistant“ (if the order of the fw-rules change).

Perhaps you have better ideas for such an achievement - if the rules not changing too often, it‘s nevertheless quite handy. Also with adding the first few chars of the comment - i made some systematic for VOIP, CLOUD etc - it‘s easier to read the logs, what kind of rule gets hit.

Can you leverage firewall comments -m comment --comment "some comment here"? They don’t get logged, so I am not sure it would help but you get up to 256 characters to play with.

Thanks Nick - for me it‘s totally fine to have the (actual) order number and the first 5 chars from the comment of the rule in the logging… nothing more needed.

I think @ezyz just thought further about using GUIDs in logging which would be much longer and therefore exceed the —logprefix of iptables.

I just made the proposal/idea to implement something by default, „some better way“ to recognize the hitted rules in log.
(Since I‘m just randomly looking into the logs, I‘m not so used to the rules etc. and it‘s sometimes difficult to get the root cause of blockings - therefore the patch)

Maybe just add a “Prefix” field after the Log Rule checkbox which allows you to override the default Log Prefix

3 Likes