How CDB Lists with IPs works?

[Kompromittiert]

Hello everyone,

I have a problem with using a CDB List. With a quick example, my problem should be explained:

This custom rule works perfect:

<rule id="10001" level="16">

    <if_sid>5700</if_sid>

    <srcip negate="yes">1.1.1.1</srcip>

    <srcip negate="yes"> 2.2.2.2  </srcip>

    <srcip negate="yes"> 3.3.3.3  </srcip>

    <srcip negate="yes">5.5.5.5</srcip>

    <srcip negate="yes">6.6.6.6</srcip>

    <description>SSH login outside from LAN.</description>

  </rule>

But the same rule with a CDB List won't work:

<rule id="10001" level="16">

    <if_sid>5700</if_sid>

    <list field="srcip" lookup="not_address_match_key">etc/lists/list-IP</list>

    <description>SSH login outside from LAN.</description>

  </rule>

my CDB List:

1.1.1.1:

2.2.2.2:

3.3.3.3:

Every try with wazuh-logtest will create an alert, no matter if the IP is in the list or not.

What causes this issue?

Best Regards

Kompromittiert

[Yana Zaeva]

Hi Kompromittiert,

First of all, thank you for using Wazuh. Regarding your query, I have been testing your scenario, and followed these steps:

- First of all, I have created a CDB list, called test2, using the Kibana UI. To do so, you will have to go to Management -> CDB lists -> Add new lists file (right top side of the screen). Set a name for your CDB list and add keys and values (optional). Remember that it is not possible to set two different keys. 

- Once I have done that, I restarted the Wazuh manager to apply the changes. Using this event: "Sep  4 23:58:33 junction sshd[9351]: Accepted password for root from 1.1.1.1 port 1066 ssh2", I started to test your rules. With the first one, everything worked as expected, but with the second one, I realized that, in fact, regardless of the srcip value, every pasted event was triggered as 10001. 

- After this, I came back to this guide to make sure that the rule syntax was correct and the CDB list was properly configured and realized that I had missed this step. Basically, is adding this new list to the ossec.conf configuration. Not sure if you have done this, but right after I included the missing lines and restarted the manager, the rule started to work as expected: 

root@pop-os:/var/ossec/etc/lists# /var/ossec/bin/wazuh-logtest

Starting wazuh-logtest v4.2.1

Type one log per line

Sep  4 23:58:33 junction sshd[9351]: Accepted password for root from 192.168.10.1 port 1066 ssh2

**Phase 1: Completed pre-decoding.

full event: 'Sep  4 23:58:33 junction sshd[9351]: Accepted password for root from 192.168.10.1 port 1066 ssh2'

timestamp: 'Sep  4 23:58:33'

hostname: 'junction'

program_name: 'sshd'

**Phase 2: Completed decoding.

name: 'sshd'

parent: 'sshd'

dstuser: 'root'

srcip: '192.168.10.1'

**Phase 3: Completed filtering (rules).

id: '10001'

level: '16'

description: 'SSH login outside from LAN.'

groups: '['local', 'syslog', 'sshd']'

firedtimes: '1'

mail: 'True'

**Alert to be generated.

Sep  4 23:58:33 junction sshd[9351]: Accepted password for root from 1.1.1.1 port 1066 ssh2

**Phase 1: Completed pre-decoding.

full event: 'Sep  4 23:58:33 junction sshd[9351]: Accepted password for root from 1.1.1.1 port 1066 ssh2'

timestamp: 'Sep  4 23:58:33'

hostname: 'junction'

program_name: 'sshd'

**Phase 2: Completed decoding.

name: 'sshd'

parent: 'sshd'

dstuser: 'root'

srcip: '1.1.1.1'

**Phase 3: Completed filtering (rules).

id: '5715'

level: '3'

description: 'sshd: authentication success.'

groups: '['syslog', 'sshd', 'authentication_success']'

firedtimes: '1'

gdpr: '['IV_32.2']'

gpg13: '['7.1', '7.2']'

hipaa: '['164.312.b']'

mail: 'False'

mitre.id: '['T1078', 'T1021']'

mitre.tactic: '['Defense Evasion', 'Initial Access', 'Persistence', 'Privilege Escalation', 'Lateral Movement']'

mitre.technique: '['Valid Accounts', 'Remote Services']'

nist_800_53: '['AU.14', 'AC.7']'

pci_dss: '['10.2.5']'

tsc: '['CC6.8', 'CC7.2', 'CC7.3']'

**Alert to be generated.

Check your /var/ossec/etc/ossec.conf file and let me know if you missed that section too. If you are going to make any changes, do not forget to restart the manager afterwards. 

If you already had that configuration, please, send me the exact log that you are using to do these tests, so I can go further in the investigation.

Hope this helps. Let me know if you need anything else.

Regards,

Yana.

[Kompromittiert]

Hello Yana,

thanks for investigate the problem.

Indeed, I did not add the list in the ossec.conf because as described in the documentation, I thought this is not needed any more:

New in version 3.11.0.

Since Wazuh v3.11.0, CDB lists are built and loaded automatically when the analysis engine is started. Therefore, when adding or modifying CDB lists just restart the manager.

I double-checked it and can confirm, that manual adding the list in the ossec.conf is still necessary.

Thanks for your time, Yana!

Best Regards

Kompromittiert

[Yana Zaeva]

Hello Kompromittiert,

New in version 3.11.0.

Since Wazuh v3.11.0, CDB lists are built and loaded automatically when the analysis engine is started. Therefore, when adding or modifying CDB lists just restart the manager.

This message makes reference to the list compilation every time they are modified. Before version 3.11.0, it was necessary to compile the lists every time they were modified, making use of the /var/ossec/bin/ossec-makelists tool. You can check more information about previous versions here. From version 3.11.0, these lists are compiled automatically when the analysis engine is started, so there is no need to run the previously mentioned binary, you can just restart the manager. Therefore, the configuration still has to be defined in the ossec.conf file.

Hope this was helpful. Let me know if you need anything else.

Regards,

Yana.