# Indicator Match Rule Fails with too\_many\_nested\_clauses **URL:** \ **Category:** SIEM\ **Tags:** elastic-stack-alerting\ **Created:** [July 8, 2022, 10:30pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233 "2022-07-08T22:30:10Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![codewriterguy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/codewriterguy/32/113440_2.png) [@codewriterguy](https://discuss.elastic.co/u/codewriterguy)\ **Post date:** [July 8, 2022, 10:30pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/1 "2022-07-08T22:30:10Z")
Hi, I created an indicator match rule using intel from the Recorded Future integration package v1.0.1 I am getting the following failure when the rule runs: ```auto Bulk Indexing of signals failed: ResponseError: search_phase_execution_exception: [too_many_nested_clauses] Reason: Query contains too many nested clauses; maxClauseCount is set to 37449 name: "URL detections from Recorded Future" id: "7078a5c0-fe4b-11ec-a2d8-071a4b73939e" rule id: "f010fb0e-77e2-4fbd-bc46-6aeac58bbc0c" execution id: "b2362ee5-b44e-4823-b5c3-131a64933d37" space ID: "default" ``` The rule succeeds occasionally, but also does not find matches when I know matches exist. Here is the rule logic, and the same indicator showing in both my index and the `logs-ti_*` datastream: ![Screen Shot 2022-07-08 at 4.26.35 PM](https://us1.discourse-cdn.com/elastic/original/3X/2/e/2e7c04c90a1822287f7e1c2ad9d4558ff2eba9df.png) ![Screen Shot 2022-07-08 at 4.29.39 PM](https://us1.discourse-cdn.com/elastic/original/3X/1/e/1e8ebb7f42d1c4d19451c8417d443db4503212d9.png) ![Screen Shot 2022-07-08 at 4.29.51 PM](https://us1.discourse-cdn.com/elastic/original/3X/e/f/efc03afe917bf365c3d02088e6a3df23b2eb57c3.png) ---
**Author:** ![Nikita\_Khristinin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nikita_khristinin/32/102092_2.png) [@Nikita\_Khristinin](https://discuss.elastic.co/u/Nikita_Khristinin)\ **Post date:** [July 11, 2022, 4:28pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/2 "2022-07-11T16:28:48Z")
Hey, what version of Kibana do you have? Can I also see mapping for demo\_url? url.full in particular About that, you don't have alerts: In your indicator index query you have `@timestamp \>= "now-30d/d". Does this URL from logs-ti\_\* fit this time query? ---
**Author:** ![codewriterguy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/codewriterguy/32/113440_2.png) [@codewriterguy](https://discuss.elastic.co/u/codewriterguy)\ **Post date:** [July 11, 2022, 8:56pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/3 "2022-07-11T20:56:41Z")
Hey Nikita, Kibana v8.1.2 `url.full` mapping: ```auto "url" : { "properties" : { "full" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } } ``` > About that, you don't have alerts: > In your indicator index query you have `@timestamp \>= "now-30d/d". Does this URL from logs-ti\_\* fit this time query? The timeframe `"now-30d/d"` gets a lot of documents from `logs-ti_*`, was hoping if I used more -\> more chance to make alert. I think this was pre-populated creating the indicator match rule. I could change it if that is better. I only need the most recent intel, the `demo_url` index intentionally has a lot of same indicators as `logs-ti_*` Over 10k hits on this query (I added the `url` tag in integration settings): ```auto GET /logs-ti_*/_search { "query": { "bool": { "must": [ {"range": {"@timestamp": {"gte": "now-30d/d"}}}, {"term": {"tags": {"value": "url"}}} ] } } } ``` `demo_url` full mapping: ```auto "demo_url" : { "aliases" : { }, "mappings" : { "properties" : { "@timestamp" : { "type" : "date" }, "@version" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "event" : { "properties" : { "original" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } }, "host" : { "properties" : { "name" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } }, "http_request_method" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "http_response_status_code" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "log" : { "properties" : { "file" : { "properties" : { "path" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } } } }, "message" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "mime_content_type" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "reply_size_include_header" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "response_time" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "server_ip" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "source_ip" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "squid_hierarchy_status" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "squid_request_status" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "tags" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "timestamp" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "url" : { "properties" : { "full" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } }, "user" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } } ``` ---
**Author:** ![Nikita\_Khristinin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nikita_khristinin/32/102092_2.png) [@Nikita\_Khristinin](https://discuss.elastic.co/u/Nikita_Khristinin)\ **Post date:** [July 12, 2022, 6:24am UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/4 "2022-07-12T06:24:44Z")
I believe one of the reasons you have an error in the first place is because there` url.full` has a mapping `text`. It performs a full-text search then and creates queries with too many clauses. What you can do, it's change the Indicator mapping in the rule from `url.full` to `url.full.keyword`, disable and enable the rule again. I hope the error will go and you can see some alerts If after that, you don't have the error, but also don't have alerts, maybe it's because the match doesn't happen. You can try to change Indicator index query maybe to a bigger interval. But remember that Indicator Match rule has some performance [limitation](https://www.elastic.co/guide/en/security/master/detection-engine-overview.html#support-indicator-rules), this is why we have this query by default. (you can also upgrade to 8.3 it's has some improvements in the performance) ---
**Author:** ![codewriterguy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/codewriterguy/32/113440_2.png) [@codewriterguy](https://discuss.elastic.co/u/codewriterguy)\ **Post date:** [July 12, 2022, 9:46pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/5 "2022-07-12T21:46:03Z")
Thank you @Nikita_Khristinin - I am using `url.full.keyword` now and the alert rule runs are succeeding now. I think we can close this now. I am looking into the lack of matches further and I believe that part is just my data ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 9, 2022, 9:46pm UTC](https://discuss.elastic.co/t/indicator-match-rule-fails-with-too-many-nested-clauses/309233/6 "2022-08-09T21:46:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.