Re: [Mod-security-developers] Finding triggered RuleIds

[Felipe C. <FC...@tr...>]

Just to make sure that we are talking about the same thing… when there Is a log to be shown the API is calling the callback. The only circumstance where the callback is not called is when the logging is a consequence of a disruptive action. In this last case the logging message is delivered via the disruptive structure in text format. So you guys want me to disable the logging for certain cases? If that is your request, there is a feature for that among the compilation flags to make ModSecurtiy mute.

There are three logs in v3: Debug, Msg/Error, Audit. I am talking about the “error log” one. It could be “displayed” as o consequence of the rules execution flow (log, auditlog action, etc) or consequence of a disruptive action. The first you retrieve via callback, the second via disruptive structure.

Jai, from your initial email I had the feeling that you would like to have the id in a data structure at the disruptive message or having the logging callback to replace the logging data inside the disruptive structure. It will be a pleasure to make the library more flexible, but, can you give us a brief explanation of your requirements?

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>


From: Jai Harpalani via mod-security-developers <mod...@li...>
Reply-To: "mod...@li..." <mod...@li...>
Date: Friday, March 22, 2019 at 5:16 PM
To: "mod-security-d." <mod...@li...>
Cc: Jai Harpalani <jai...@mu...>
Subject: Re: [Mod-security-developers] Finding triggered RuleIds

A 'SecLogAllRule' such as Ervin suggests would work well. Ideally, the log message would contain all of the information currently contained in the ruleMessage.

I may have found a workaround for this. Will send another email with the details.

On Fri, Mar 22, 2019 at 3:10 PM Ervin Hegedüs <ai...@gm...<mailto:ai...@gm...>> wrote:
hi,

On Fri, Mar 22, 2019 at 12:49:18PM +0000, Felipe Costa wrote:
> Hi Jai,
>
> For the current public supported connectors, the rule id altogether with logging text is enough. There is no data structure except for char pointer that point towards the logging string [for the logging attached to the disruptive events]. Is my understanding that it may be useful for your application,  to have an specific field that held to rule id (may other information regarding the rule as well). Having that in mind, we can change the API the make it more useful to your application. Sorry for the inconvenience. Lets discuss out-of-band the specific characteristics of your use case, so we can make the API suits you better.

I can imagine that there should be a new configuration directive,
which allows to log every triggered rule, not just when it
intervents.

The default value should be disable to do this, but if the
end-user wants to see that, then it can be use that.

eg.

SecLogAllRule 0|1



a.



_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://lists.sourceforge.net/lists/listinfo/mod-security-developers<https://scanmail.trustwave.com/?c=4062&d=qsKV3OL797AuHt0YIpZtf8wkheEsZv18XuZPrY4e8A&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers>
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php