wazuh-logcollector don't work in wazuh-docker

[abigael Do santos]

Hello everybody

I'm using wazuh docker and wazuh-logcollector doesn't work. It fails to collect logs.

Thank you for your help

[Raul Del Pozo Moreno]

Hello abigaeldosantos,

This error usually appears when these files are not present in the system where they are being monitored, can you verify that they exits? As you can see in the log, after starting logcollector, it tries to analyze said file, since it is not available, it reports an error, and ignores it for future analysis.

Could you tell me the Wazuh version that you are using? I will wait your answer.

Regards, Raúl. 

[abigael Do santos]

I found that it tries to read the logs in docker system folders instead of reading it on wazuh agents.

I am using version 4.2.5.

How to make the collection and analysis of agent logs wazuh?

[Raul Del Pozo Moreno]

Hello abigaeldosantos, if you want to monitor an agent file, then you must apply this configuration in the agent, for this you have several options:

1. You configure that specific agent from its ossec.conf
2. From the manager, you apply this configuration in a shared way

In the first case you would only have to put in the ossec.conf of the agent the <localfiles> directives that you have put in the manager (and remove them from the manager if you don't want them)

In the second case you can use the shared configuration tool: https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html

As indicated in the documentation, the steps to be carried out would be:

In the agent: 

   - Edit /var/ossec/etc/local_internal_options.conf
   - Add/modify wazuh_command.remote_commands=1

In the manager:  

   - Create and grant permissions to /var/ossec/etc/shared/default/agent.conf (if it doesn't exist)
   - Edit the file /var/ossec/etc/shared/default/agent.conf
   - Add the desired configuration to the file agent.conf file

Here you can differentiate between specific agent (by name), systems (linux/windows/etc) or profile, an example would be:

<agent_config name="agent_name">
    <localfile>
        <location>/var/log/my.log</location>
        <log_format>syslog</log_format>
    </localfile>
</agent_config>  

    - Once applied in the agent.conf file, verify that the configuration is correct with /var/ossec/bin/verify-agent-conf

[root@centos7 vagrant]# /var/ossec/bin/verify-agent-conf

verify-agent-conf: Verifying [etc/shared/default/agent.conf]
verify-agent-conf: OK  

   - Restart the manager, the configuration is shared with each keepalive (every 10 seconds), once it is shared, it is not shared again if it is present, restarting the manager ensures that it is shared

   - Confirm that the agent has received it running these commands in the manager (By default, user and password are wazuh:wazuh):       

       -  TOKEN=$(curl -u <user>:<password> -k -X GET "https://localhost:55000/security/user/authenticate?raw=true")
       - curl -k -X GET "https://localhost:55000/agents/id/group/is_sync?pretty=true" -H  "Authorization: Bearer $TOKEN"
       - /var/ossec/bin/agent_groups -S -i id  

   - The output should be (my agent id is 001):

[root@centos7 vagrant]# curl -k -X GET "https://localhost:55000/agents/001/group/is_sync?pretty=true" -H "Authorization: Bearer $TOKEN"
{
   "data": {
      "affected_items": [
         {
            "id": "001",
            "synced": true
         }
      ],
      "total_affected_items": 1,
      "total_failed_items": 0,
      "failed_items": []
   },
   "message": "Sync info was returned for all selected agents",
   "error": 0

[root@centos7 vagrant]# /var/ossec/bin/agent_groups -S -i 001
Agent '001' is synchronized.  

   - Restart the agent, at this point, if you check the /var/ossec/etc/shared/agent.conf file in the agent, it should contain the configuration you have applied from the manager

In this way you can make multiple agents have a configuration without having to go one by one, but you must also take into account the configuration preference order, the ossec.conf file is read before the agent.conf, so the configuration that agent.conf has, will override the configuration in ossec.conf.

I hope I have been able to help you with this explanation and if you have any questions about the process, do not hesitate to ask me.

Regards, Raúl.

[abigael Do santos]

Thanks !!! It's work