Elasticsearch Version
8.15.2
Installed Plugins
No response
Java Version
bundled
OS Version
Darwin Thumper.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:11 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6020 arm64
Problem Description
The bug happens when making EQL queries (via anything: api, Kibana timelines, or detection rules) involving comparisons to the same IP-mapped field connected with an or. For example, the following works:
network where destination.ip=="69.42.98.86"
but the following does not work
network where destination.ip=="69.42.98.86" or destination.ip=="89.185.234.145"
it results in the following error:
planning_exception Root causes: planning_exception: Found 4 problems line 1:15: Unresolved expression line 1:15: Unresolved expression line... (repeated)
Here destination.ip is an IP-mapped field, but if I use a keyword-mapped field with the exact same queries both work, e.g.
network where destination.address=="69.42.98.86" or destination.address =="89.185.234.145"
And when the IP fields are different on either side of the or it also works
network where destination.ip=="69.42.98.86" or source.ip=="89.185.234.145"
The lookup operators available in EQL (field in ("val1", "val2"), field like ("val1*", "val2*")) that would normally be used in a situation where you're comparing the same field to multiple values logically connected by or don't apply to IP-type fields, only keywords.
The problem also can't be fixed by any manner of adding parentheses, for example, these also don't work
network where (destination.ip=="69.42.98.86") or (destination.ip=="89.185.234.145")
network where (destination.ip=="69.42.98.86" or destination.ip=="89.185.234.145")
Adding some more nuance to the interplay of keyword and IP combinations, the following doesn't work
network where (destination.address=="69.42.98.86" or destination.ip=="69.42.98.86") or ( destination.address=="89.185.234.145" or destination.ip=="89.185.234.145")
but this does work
network where (destination.address=="69.42.98.86" or destination.ip=="69.42.98.86") and ( destination.address=="89.185.234.145" or destination.ip=="89.185.234.145")
Steps to Reproduce
A single IP-mapped field is all you need, but having a keyword field too helps to see what the behavior should be.
PUT index-pattern/_mapping
{
"properties": {
"ip_field": {
"type": "ip"
},
"keyword_field": {
"type": "keyword"
}
}
}
Then one EQL query:
any where ip_field=="0.0.0.0" or ip_field=="1.1.1.1"
With the full API query
GET /index-pattern*/_eql/search
{
"query": """
any where ip_field=="0.0.0.0" or ip_field=="1.1.1.1"
"""
}
will fail with the following error
planning_exception Root causes: planning_exception: Found 4 problems line 1:15: Unresolved expression line 1:15: Unresolved expression line... (repeated)
while the following query using keyword fields won't fail
any where keyword_field=="0.0.0.0" or keyword_field =="1.1.1.1"
Logs (if relevant)
No response
Elasticsearch Version
8.15.2
Installed Plugins
No response
Java Version
bundled
OS Version
Darwin Thumper.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:11 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6020 arm64
Problem Description
The bug happens when making EQL queries (via anything: api, Kibana timelines, or detection rules) involving comparisons to the same IP-mapped field connected with an
or. For example, the following works:but the following does not work
it results in the following error:
Here
destination.ipis an IP-mapped field, but if I use a keyword-mapped field with the exact same queries both work, e.g.And when the IP fields are different on either side of the
orit also worksThe lookup operators available in EQL (
field in ("val1", "val2"),field like ("val1*", "val2*")) that would normally be used in a situation where you're comparing the same field to multiple values logically connected byordon't apply to IP-type fields, only keywords.The problem also can't be fixed by any manner of adding parentheses, for example, these also don't work
Adding some more nuance to the interplay of keyword and IP combinations, the following doesn't work
but this does work
Steps to Reproduce
A single IP-mapped field is all you need, but having a keyword field too helps to see what the behavior should be.
Then one EQL query:
With the full API query
will fail with the following error
while the following query using keyword fields won't fail
Logs (if relevant)
No response