Open rohithmulka opened 1 week ago
Hi @rohithmulka,
thanks for bringing this up.
Yes, this is a known behavior of libmodsecurity3 (I read your message on Slack, this is why I know - but it would be good to fill the issue template with versions and other information).
I think we have to discuss here (with other libmodsecurity3 users) what would be the correct behavior. I think we can modify the code that if a rule does not have a severity
action then that field won't be in the log. But I don't know how users would be happy, eg. if someone uses an own parser which expects the field...
I feel like "no severity" should mean "default log level", which I assume would be DEBUG
.
I feel like "no severity" should mean "default log level", which I assume would be
DEBUG
.
I think there are more different aspects around the severity
rule value.
severity
action, then why the engines log it with any value?severity
, then how should we interpret that?
severity
value determines which rules must appear in the log. Eg. if the Nginx's log level is "lower" than info
then only rules will be logged which have CRITICAL
value (if I'm not wrong)
0
is there because Nginx needs to know to logging. I haven't inspected that yet.So we definitely have some works with this.
I'm encountering an issue where the severity in ModSecurity audit logs is shown as a numeric value (e.g., "severity": "2") instead of the string defined in the rules (e.g., "severity": "CRITICAL")
0: EMERGENCY 1: ALERT 2: CRITICAL 3: ERROR 4: WARNING 5: NOTICE 6: INFO 7: DEBUG
Issue: Rules like 949110 (blocking evaluation) do not have a defined severity, but in the logs, severity = 0 is being incorrectly mapped to "EMERGENCY", causing confusion.
audit_log.json