Skip to main content

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.ip[0] in cidr %Trusted_Jump_Servers” ? Even so that feels nasty.

That is strange and I can’t replicate it personally but is your IPV6 going into principal.asset.ip? If not then you could use that potentially.. If it is going there then I would be interested to see how this can be handled

Yes, its like this:

principal.ip = "172.44.555.55"
principal.ip = "fe80::d1b0:953c:1111:xyz”

the ipv4 is in the whitelist, but the alert is firing anyway, and i can only assume it’s because it’s checking the 2nd entry against the whitelist as well or instead which is causing the “not” condition to succeed.

Yes, the IPv6 IP is being enriched into both principal.ip and principal.asset.ip. I’ve learned this was because IPv6 was enabled on the windows server in the TCP/IP settings. The actual connections and the log itself all only refer to IPv4 addresses.

However, it’s very confusing doing a negative check against a field that normally has 1 value but can have multiple values. This is a real danger with enrichment that isn’t clearly differentiated from the actual log data. To my knowledge there is no way to specify “the IP that was actually in the log” and use that for checks, apart from doing a parser modification and putting the true IP into a named additional field or other nonsense.

I’ve raised a support case on this, but so far the proposed solution (using any/all modifiers) is not compatible with my use of reference lists.

I am wondering if there is a way I can extract the IPv4 into a variable and then use that for the test instead, but not sure if there is syntax to do that that would work under all variations of the principal.ip field.

I did at least get a solid answer on why the search and detection rule logic gave different results:
 

In Chronicle Search, this filter only checks the base event's IP address against your Jump Server IPs, not the entire enriched IP array. This may lead to no search results being returned.

However, in Detection rules, the same condition is applied to each element within the enriched IP array. Therefore, if any IP address (including enriched IPv6 addresses) within the array does not match your whitelist, the rule triggers, potentially resulting in false positives. 

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.