Hi Kpex
The Wazuh agent doesn’t depend on the user, it depends only on the machine. If the user is disconnected and the end-point is still on and with an available connection to the manager, no events are lost.
The behavior of the Wazuh agent, when the agent is disconnected from the manager for modules like FIM is to block the process until the agent is connected again to the manager. If this happens, in the log file you can find these logs when the agent is disconnected:
2021/02/19 11:24:38 ossec-agentd: INFO: Trying to connect to server (10.2.0.13:1514/tcp).
2021/02/19 11:24:38 ossec-agentd: ERROR: (1216): Unable to connect to '10.2.0.13:1514/tcp': 'Connection refused'.
2021/02/19 11:24:43 ossec-syscheckd: WARNING: Process locked due to agent is offline. Waiting for connection...
And these logs when the agent has connected again:
2021/02/19 11:27:08 ossec-agentd: INFO: Server responded. Releasing lock.
2021/02/19 11:27:13 ossec-syscheckd: INFO: Agent is now online. Process unlocked, continuing...
The purpose of the leaky bucket is to handle the output throughput in order to not overflow the manager. So if the agent disconnects, the bucket retains the events that weren’t sent, but no events will be appended to this bucket if the agent is not connected. These events will be sent when the agent reconnects to the manager.
The Wazuh agent was developed considering the need to monitor a wide variety of different endpoints without impacting their performance, so the agent itself only sends the information to the manager. With this in mind, buffering events that are generated when the agent is disconnected would impact the resources it uses (either memory or disk), and go against this philosophy.
You can find more information in the following links: