Hi,

I’ve got a rule logic that has been working great for a while, but recently some of my hosts have been tagged with IPv6 addresses in the context/metadata. This may or may not be accurate (not sure where it’s come from yet) but it’s broken my alert rule logic, but not the search logic. this inconsistent behaviour is really confusing.

Here is my (slightly redacted rule logic)

    $e.metadata.log_type = "NIX_SYSTEM"

    $e.metadata.event_type = "USER_LOGIN"

    $e.network.application_protocol = "SSH"  

    $e.security_result.description = "Accepted password"

    $e.target.user.userid in %Privileged_Accounts

    not $e.principal.ip in cidr %Trusted_Jump_Servers

In the Search field this produces no results. But the same logic with no other qualifiers in the detection engine has ~10,000 hits so far today.

The issue appears to be the final  “not $e.principal.ip in cidr %Trusted_Jump_Servers” which ignores SSH connections that originate from trusted sources (which is the point of the rule, to find connections from Untrusted sources).

Now that some of my jump servers have been enriched with an IPv6 address, my guess is the detection engine is checking that and when it doesnt match the IPv4 address in the log, it thinks it’s an untrusted server.

How can it tell the rule to ignore the enriched field? Can i guaranteed that the original value will always be the first in the array and specify something like     “not $e.principal.ipe0] in cidr %Trusted_Jump_Servers” ? Even so that feels nasty.