Why System inventory data is not in wazuh log?

826 views
Skip to first unread message

lid...@gmail.com

unread,
Feb 26, 2021, 4:44:27 AM2/26/21
to Wazuh mailing list
Hi, there

I'm using wazuh version 3.13, and the ossec.conf System inventory function is enabled, but I can't search the info log in wazuh index. Use wazuh APP, when I click to  Agents->IP->inventory data,  I can see the server inventory info, but I also want to use the log data to mornitorning the server status. How to do it?


My ossec.conf    System inventory part is like below:

  <!-- System inventory -->
  <wodle name="syscollector">
    <disabled>no</disabled>
    <interval>1h</interval>
    <scan_on_start>yes</scan_on_start>
    <hardware>yes</hardware>
    <os>yes</os>
    <network>yes</network>
    <packages>yes</packages>
    <ports all="no">yes</ports>
    <processes>yes</processes>
  </wodle>

lid...@gmail.com

unread,
Feb 26, 2021, 5:03:25 AM2/26/21
to Wazuh mailing list
Yes, I found the info data in  $install_directory/queue/db/ path, but it need sqlit to open and read,  how I can ingest it into my splunk?

Only to see it on wazuh APP is not very convenient, I can't search and see many agent info at the same time.

Victor M Fernandez-Castro

unread,
Mar 4, 2021, 1:47:13 PM3/4/21
to lid...@gmail.com, Wazuh mailing list
Hi,

Syscollector is a system inventory module in the agent, which means that its main output is not an alert (as we can easily index) but a queriable state in a database. Indeed, the manager holds the agent inventory data in the database file you mentioned. However, I do not recommend accessing the database directly. Instead, I encourage you to use the API (https://documentation.wazuh.com/current/user-manual/api/reference.html#tag/Syscollector).

For instance, this is how we query the hardware inventory of the agent 002:

API_TOKEN=$(curl -u wazuh:wazuh -sk -X GET "https://localhost:55000/security/user/authenticate?raw=true")
curl -w\\n -sk -H "Authorization: Bearer $API_TOKEN" -X GET "https://localhost:55000/syscollector/002/hardware"
{
  "data": {
    "affected_items": [
      {
        "cpu": {
          "cores": 4,
          "mhz": 2592,
          "name": "Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz"
        },
        "ram": {
          "free": 1437008,
          "total": 2024012,
          "usage": 30
        },
        "scan": {
          "id": 1864538886,
          "time": "2021-03-04T18:10:10Z"
        },
        "board_serial": "0",
        "agent_id": "001"
      }
    ],
    "total_affected_items": 1,
    "total_failed_items": 0,
    "failed_items": []
  },
  "message": "All specified syscollector information was returned",
  "error": 0
}

If you need to index that data into Splunk and you have set up it to ingest alerts from Wazuh, maybe you want to enable the alerts matching data from Syscollector. Just increase the level of the rule 221 (0016-wazuh_rules.xml). Simply redefine it in /var/ossec/etc/rules/local_rules.xml:

<group name="local,wazuh,">
  <rule id="221" level="3" overwrite="yes">
    <category>ossec</category>
    <decoded_as>syscollector</decoded_as>
    <description>Syscollector event.</description>
  </rule>
</group>
This is a sample of a Syscollector alert about the process "wazuh-monitord":

{
  "timestamp": "2021-03-04T19:27:45.386+0100",
  "rule": {
    "level": 3,
    "description": "Syscollector event.",
    "id": "221",
    "firedtimes": 1340,
    "mail": false,
    "groups": [
      "local",
      "wazuh"
    ]
  },
  "agent": {
    "id": "000",
    "name": "groovy"
  },
  "manager": {
    "name": "groovy"
  },
  "id": "1614882465.2217230",
  "full_log": "{\"type\":\"process\",\"ID\":80620390,\"timestamp\":\"2021/03/04 19:27:43\",\"process\":{\"pid\":42915,\"name\":\"wazuh-modulesd\",\"state\":\"S\",\"ppid\":1,\"utime\":11,\"stime\":27,\"cmd\":\"/var/ossec/bin/wazuh-modulesd\",\"euser\":\"root\",\"ruser\":\"root\",\"suser\":\"root\",\"egroup\":\"ossec\",\"rgroup\":\"ossec\",\"sgroup\":\"ossec\",\"fgroup\":\"ossec\",\"priority\":20,\"nice\":0,\"size\":199605,\"vm_size\":798420,\"resident\":2255,\"share\":1013,\"start_time\":2805024,\"pgrp\":42914,\"session\":42914,\"nlwp\":13,\"tgid\":42915,\"tty\":0,\"processor\":0}}",
  "decoder": {
    "name": "syscollector"
  },
  "data": {
    "type": "process",
    "process": {
      "pid": "42915",
      "name": "wazuh-modulesd",
      "state": "S",
      "ppid": "1",
      "utime": "11",
      "stime": "27",
      "cmd": "/var/ossec/bin/wazuh-modulesd",
      "euser": "root",
      "ruser": "root",
      "suser": "root",
      "egroup": "ossec",
      "rgroup": "ossec",
      "sgroup": "ossec",
      "fgroup": "ossec",
      "priority": "20",
      "nice": "0",
      "size": "199605",
      "vm_size": "798420",
      "resident": "2255",
      "share": "1013",
      "start_time": "2805024",
      "pgrp": "42914",
      "session": "42914",
      "nlwp": "13",
      "tgid": "42915",
      "tty": "0",
      "processor": "0"
    }
  },
  "location": "syscollector"
}
We have an issue in our roadmap to produce alerts based on deltas (alert only when an item changed): #3940. The current implementation produces an alert per each item detected in every scan.

Hope this helps you.
Best regards,

Victor M. Fernandez-Castro 
Director of engineering | vic...@wazuh.com


--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/d6d50082-d381-4ff2-9862-4e23bd068b4cn%40googlegroups.com.

lid...@gmail.com

unread,
Mar 11, 2021, 10:53:29 PM3/11/21
to Wazuh mailing list
Hi, Victor 

I had added the config in my  local_rules.xml file ,but wazuh can't be start not.

the error info is :
[root@wazuh-manager rules]# systemctl start wazuh-manager
Job for wazuh-manager.service failed because the control process exited with error code. See "systemctl status wazuh-manager.service" and "journalctl -xe" for details.
[root@wazuh-manager rules]# systemctl status wazuh-manager.service
● wazuh-manager.service - Wazuh manager
   Loaded: loaded (/etc/systemd/system/wazuh-manager.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2021-03-12 11:46:40 CST; 18s ago
  Process: 32193 ExecStop=/usr/bin/env ${DIRECTORY}/bin/ossec-control stop (code=exited, status=0/SUCCESS)
  Process: 32448 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-control start (code=exited, status=1/FAILURE)

Mar 12 11:46:39 bj-m8-vm-sec-office-wazuh-manager systemd[1]: Starting Wazuh manager...
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager env[32448]: 2021/03/12 11:46:40 ossec-analysisd: ERROR: Invalid configuration. 'group' is not a valid element.
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager env[32448]: 2021/03/12 11:46:40 ossec-analysisd: CRITICAL: (1220): Error loading the rules: 'etc/rules/local...es.xml'.
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager env[32448]: ossec-analysisd: Configuration error. Exiting
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager systemd[1]: wazuh-manager.service: control process exited, code=exited status=1
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager systemd[1]: Failed to start Wazuh manager.
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager systemd[1]: Unit wazuh-manager.service entered failed state.
Mar 12 11:46:40 bj-m8-vm-sec-office-wazuh-manager systemd[1]: wazuh-manager.service failed.
Hint: Some lines were ellipsized, use -l to show in full.


in my   /var/ossec/etc/rules/  path ,I had only one  local_rules.xml file ,there is no file like   0016-wazuh_rules.xml

I add confg in the   local_rules.xml file.

<!-- Local rules -->

<!-- Modify it at your will. -->
<!-- Copyright (C) 2015-2020, Wazuh Inc. -->

<!-- Example -->
<group name="local,syslog,sshd,">

  <!--
  Dec 10 01:02:02 host sshd[1234]: Failed none for root from 1.1.1.1 port 1066 ssh2
  -->
  <rule id="100001" level="5">
    <if_sid>5716</if_sid>
    <srcip>1.1.1.1</srcip>
    <description>sshd: authentication failed from IP 1.1.1.1.</description>
    <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
  </rule>

<group name="local,wazuh,">
  <rule id="221" level="3" overwrite="yes">
    <category>ossec</category>
    <decoded_as>syscollector</decoded_as>
    <description>Syscollector event.</description>
  </rule>
</group>

</group>

Victor M Fernandez-Castro

unread,
Mar 12, 2021, 4:23:17 AM3/12/21
to lid...@gmail.com, Wazuh mailing list
Hi. The manager is complaining because there is a block <group> nested inside another <group>. Simply put the second <group> below the former.

Best regards.


Victor M. Fernandez-Castro 
Director of engineering | vic...@wazuh.com

lid...@gmail.com

unread,
Mar 15, 2021, 10:28:46 PM3/15/21
to Wazuh mailing list
Sorry, I don't know what's the meaning of <group>, can you help to explain and how to modify the configuration ?

Victor M Fernandez-Castro

unread,
Mar 17, 2021, 9:16:03 AM3/17/21
to lid...@gmail.com, Wazuh mailing list
Hi,

Each rule belongs to one o more groups, but we must put each <rule> block inside a <group> block. The syntax of the rules is something like this:

<group>
  <rule />
  <rule />
  <rule />
</group>

<group>
  <rule />
  <rule />
  <rule />
</group>
However, we cannot nest a <group> block inside another <group>:
<group>
  <group>
  </group>
</group>

Per your last message, I wonder if you added the code I suggested (<group name="local,wazuh,">) inside <group name="local,syslog,sshd,">.

As your file local_rules.xml contains only a sample rule, I suggest you clean the file and add this only:
<group name="local,wazuh,">
  <rule id="221" level="3" overwrite="yes">
    <category>ossec</category>
    <decoded_as>syscollector</decoded_as>
    <description>Syscollector event.</description>
  </rule>
</group>

Hope it helps.

Best regards.

Victor M. Fernandez-Castro 
Director of engineering | vic...@wazuh.com

lid...@gmail.com

unread,
Mar 18, 2021, 10:06:05 PM3/18/21
to Wazuh mailing list
Yes , I got it, thanks a lot, I will try to famillar with the logs.
Reply all
Reply to author
Forward
0 new messages