Error when creating Sigma rule with integer field

[stormdosertao]

Version

2.4.10

Installation Method

Network installation on Red Hat derivative like Oracle, Rocky, Alma, etc.

Description

other (please provide detail below)

Installation Type

Distributed

Location

cloud

Hardware Specs

Exceeds minimum requirements

CPU

4

RAM

32

Storage for /

200

Storage for /nsm

600

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

Hello Team, good afternoon!

We are facing a problem when creating a sigma rule through the graphical interface when the rule has an integer field.

We did not receive any errors converting or creating the rule. However, the rule only does not execute and consequently does not generate alerts. When we make a troubleshooting via so-elastialert-test, we received the following error:

Error running your filter:
RequestError(400, 'verification_exception', {'error': {'root_cause': [{'type': 'verification_exception', 'reason': 'Found 1 problem\nline 1:12: first argument of [:] must be [string], found value [destination.port] type [long]; consider using [==] instead'}], 'type': 'verification_exception', 'reason': 'Found 1 problem\nline 1:12: first argument of [:] must be [string], found value [destination.port] type [long]; consider using [==] instead'}, 'status': 400})

Would have written the following documents to writeback index (default is elastalert_status):

elastalert_error - {'message': "Error running query: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1:12: first argument of [:] must be [string], found value [destination.port] type [long]; consider using [==] instead')", 'traceback': ['Traceback (most recent call last):', ' File "/usr/local/lib/python3.11/site-packages/elastalert/elastalert.py", line 373, in get_hits', ' res = self.thread_data.current_es.search(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/client/utils.py", line 152, in _wrapped', ' return func(*args, params=params, headers=headers, **kwargs)', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elastalert/init.py", line 147, in search', ' results = self.transport.perform_request(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/transport.py", line 392, in perform_request', ' raise e', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/transport.py", line 358, in perform_request', ' status, headers_response, data = connection.perform_request(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/connection/http_requests.py", line 199, in perform_request', ' self._raise_error(response.status_code, raw_data)', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/connection/base.py", line 315, in _raise_error', ' raise HTTP_EXCEPTIONS.get(status_code, TransportError)(', "elasticsearch.exceptions.RequestError: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1:12: first argument of [:] must be [string], found value [destination.port] type [long]; consider using [==] instead')"], 'data': {'rule': 'Test rule - aed45a787', 'query': {'query': {'bool': {'filter': {'bool': {'must': [{'range': {'@timestamp': {'gt': '2024-04-02T19:04:15.027348Z', 'lte': '2024-04-02T19:14:15.027348Z'}}}, {'eql': 'any where (destination.port : "7023")\n'}]}}}}, 'sort': [{'@timestamp': {'order': 'asc'}}]}}}

When we adjust the .yml file as recommended, the rule works. However, we would not like to have to do this every time we create a new rule with integer field , because we do not know what will happen if we apply new updates or this rule is updated via the graphical interface it returns to the original configuration, losing what was done via the line command. Is it really a problem or can we do something to solve it?

Rule:

title: Test rule
id: 65354b83-a2ea-4ea6-8414-3ab38be0d409
status: test
description: Test rule
references:

https://github.com/oooo
author: Teste
date: 2024/04/03
modified: 2024/04/03
tags:

• attack.initial_access
• attack.t1189
  logsource:
  category: teste
  detection:
  select_method:
  destination.port : 7023
  condition: select_method
  fields:
• client_ip
• vhost
• url
• response
  falsepositives:
• JavaScripts,CSS Files and PNG files
• User searches in search boxes of the respective website
• Internal vulnerability scanners can cause some serious FPs when used, if you experience
  a lot of FPs due to this think of adding more filters such as "User Agent" strings
  and more response codes
  level: high

Thank you!

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[stormdosertao]

up

[defensivedepth]

If you wrap 7023 in single or double quotes within the Sigma rule itself, ie '7023', does that work?

[stormdosertao]

Hello Defensivedepth,

Thank you for responding."

It's not works, I've tried with single quotes, double quotes, without quotes, and trying with escape, whenever it creates the rule by sigma in WEB in the OS it creates with double quotes. And it gives the error that when using :, it should be a field to type string or replace it with ==, however when replacing : with == via Sigma on the WEB after the rule is created, the configuration is not replicated to the S.O. So far, the only way to make it work was to directly change the rule via vim in the OS.

Sigma Rule by Web:

title: CheckPoint - regra de teste
status: experimental
description: CheckPoint - regra de teste
author: Guilherme P. Ausechi
logsource:
product: Check Point
service: VPN Remote Access
detection:
socfieldsstatusCode:
soc.fields.statusCode:

• '200'
  condition: socfieldsstatusCode
  falsepositives:

teste
level: medium
File in linux:

[root@lab-so-standalone-01 playbook]# pwd
/opt/so/rules/elastalert/playbook
[root@lab-so-standalone-01 playbook]#
[root@lab-so-standalone-01 playbook]# cat a2bb8a61e.yaml
alert:

"modules.so.playbook-es.PlaybookESAlerter"
elasticsearch_host: "10.0.250.4:9200"
play_title: "CheckPoint - regra de teste"
play_id: "a2bb8a61e"
event.module: "playbook"
event.dataset: "playbook.alert"
event.severity: 2
rule.category: ""
play_url: "https://10.0.250.4/playbook/issues/3305"
kibana_pivot: "https://10.0.250.4/kibana/app/kibana#/discover?_g=()&_a=(columns:!(_source),interval:auto,query:(language:lucene,query:'_id:{[_id]}'),sort:!('@timestamp',desc))"
soc_pivot: "https://10.0.250.4/#/hunt"
sigma_level: "medium"

index: '.ds-logs-*'
name: "CheckPoint - regra de teste - a2bb8a61e"
priority: 3
realert:
minutes: 0
type: any
filter:

eql: >
any where soc.fields.statusCode : "200"
Error to try run:

[root@lab-so-standalone-01 playbook]# so-elastalert-test

This script will allow you to test an Elastalert rule.

Below is a list of available Elastalert rules:

playbook/a2bb8a61e.yaml

Choose a rule to test from the list above (must be typed exactly as shown above): playbook/a2bb8a61e.yam l
The results can be rather long. Would you like to write the results to a file? (y/N) N

Error running your filter:
RequestError(400, 'verification_exception', {'error': {'root_cause': [{'type': 'verification_exception', 'reason': 'Found 1 problem\nline 1:11: first argument of [:] must be [string], found value [soc.fields. statusCode] type [long]; consider using [==] instead'}], 'type': 'verification_exception', 'reason': 'Found 1 problem\nline 1:11: first argument of [:] must be [string], found value [soc.fields.statusCode] type [long]; consider using [==] instead'}, 'status': 400})

Would have written the following documents to writeback index (default is elastalert_status):

elastalert_error - {'message': "Error running query: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1:11: first argument of [:] must be [string], found value [soc.fields.statusCode] type [long]; consider using [==] instead')", 'traceback': ['Traceback (most recent call last):', ' File "/us r/local/lib/python3.11/site-packages/elastalert/elastalert.py", line 373, in get_hits', ' res = self. thread_data.current_es.search(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/client/utils.py", line 152, in _wrapped', ' return func(*arg s, params=params, headers=headers, **kwargs)', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ , ' File "/usr/local/lib/python3.11/site-packages/elastalert/init.py", line 147, in search ', ' results = self.transport.perform_request(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^', 'File "/usr/local/lib/python3.11/site-packages/elasticsearch/transport.py", line 392, in perform_request' 'raise e', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/transport.py", line 358, in perform_request', ' status, headers_response, data = connection.perform_request(', ' ^^^^^^^^^^^^^^^^^^^^^^^^^^^', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/connection/http_requests.py", line 199, in perform_request', ' self._raise_error(response.status_code, raw_data)', ' File "/usr/local/lib/python3.11/site-packages/elasticsearch/connection/bas e.py", line 315, in _raise_error', ' raise HTTP_EXCEPTIONS.get(status_code, TransportError)(', "elasticsearch.exceptions.RequestError: RequestError(400, 'verification_exception', 'Found 1 problem\nline 1: 11: first argument of [:] must be [string], found value [soc.fields.statusCode] type [long]; consider using [==] instead')"], 'data': {'rule': 'CheckPoint - regra de teste - a2bb8a61e', 'query': {'query': {'b ool': {'filter': {'bool': {'must': [{'range': {'@timestamp': {'gt': '2024-04-16T15:27:48.686464Z', 'lte' : '2024-04-16T15:37:48.686464Z'}}}, {'eql': 'any where soc.fields.statusCode : "200"\n'}]}}}}, 'sort': [ {'@timestamp': {'order': 'asc'}}]}}}

Test completed successfully!

Could you help me?

Thank you

[stormdosertao]

Hello @defensivedepth,

do you think this is some limitation in this moment?

Thank you

[defensivedepth]

@guiausechi With 2.4.70 released yesterday, we have added a new module called Detections that unifies NIDS+YARA+Sigma into one interface. As part of that update, we moved to the latest sigma backend and there is now a way to specify if a field is a number or string.

That should solve this problem longterm.