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

[Jai H. <jai...@mu...>]

Responses interspersed below:

On Fri, Mar 22, 2019 at 8:34 PM Felipe Costa <FC...@tr...> wrote:

> 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.
>

In 3.0.2, I believe the callback was always invoked when a rule was
triggered. With 3.0.3, it is not invoked for a disruptive action. My
calling code was expecting the callback to always be invoked because that
is the only way we know that a rule has triggered. You state that for a
disruptive action, "the logging message is delivered via the disruptive
structure in text format". Where is this done? How is it delivered? How can
the calling code inspect this disruptive structure? And, does the
disruptive structure contain all the details which were provided by the
callback (eg ip address, api, ruleId, rule tags, etc)?


>
>
> 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.
>

The "error log" one is the one I am talking about, as well.


>
>
> 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?
>

The requirement is for the calling code to be able to determine if a rule
was triggered, regardless of whether the rule was disruptive or not. And,
if triggered, the calling code should be provided details about the
trigger.



I may have found a workaround for 3.0.3. Details below.

For 3.0.2, I have code such as the following inside of logCallback():

   * const modsecurity::RuleMessage * lRuleMessage =*
*        reinterpret_cast<const modsecurity::RuleMessage *>(aRuleMessage);*
*    ruleId = lRuleMessage->m_ruleId;*
*    logMsg << "clientIp:" << m_clientIpAddress *
*    << "clientPort:" << m_clientPort*

    . . .

We have a class, ModSecTransaction, which inherits from
modsecurity::Transaction. In 3.0.3, I have moved the above code into the
ModSecTransaction dtor:

*ModSecTransaction::~ModSecTransaction() noexcept*
*{*
*    for (modsecurity::RuleMessage& lRuleMessage : m_rulesMessages)*
*    {*
*      ruleId = lRuleMessage->m_ruleId;*
*      logMsg << . . .*
*      . . .*
*    }*
*    . . .*
*}*

With 3.0.3, I also iterate through m_ruleMessages to determine if any rules
have triggered after each call to processRequestHeaders(),
processRequestBody().

*bool*
*ModSecTransaction::shouldEscalateAnyTriggeredRule() noexcept*
*{*
*    bool lRetVal = false;*

*    // Iterate through all triggered rules*
*    for (modsecurity::RuleMessage& lRuleMessage : m_rulesMessages)*
*    {*
*        // Check if triggered rule should be escalated*
*        if (m_Origins.shouldEscalate(lRuleMessage.m_ruleId))*
*        {*
*            lRetVal = true;*
*            break;*
*        }*
*    }*

*    return lRetVal;*
*}*

So far, this approach in 3.0.3 is working. *Is it okay to use this approach
in ModSec 3.0.3? Will it always work? Are there cases in which
modsecurity::Transaction.m_rulesMessages will not be populated?*

Thanks,
Jai

>