Windows agent doesn't synchronize agent.conf

[Ricardo Galossi]

Hi guys,

I'd like to ask for some help here..

My windows agents are not synchronizing shared/agent.conf, within C:\Program Files (x86)\ossec-agent\shared direrectory there is no agent.conf even after restarting windows agent. Follow my agent.cong below:

<agent_config>

    <syscheck>

        <directories realtime="yes" check_all="yes">C:\labtest</directories>

    </syscheck>

</agent_config>

In the agent log file I receive the following message:

ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf': XMLERR: File 'shared/agent.conf' not found. (line 147).

If I create the file agent.conf manually the configuration works (what proof that the configuration is ok), but also doesn't synchronize if i try to change it.

Am I making some mistake? Please, help me!!

[Jesus Linares]

Hi

ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf': XMLERR: File 'shared/agent.conf' not found. (line 147).

what is in the line 147?.

More information about the agent.conf and the process to synchronize it: https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html 

I hope it helps.

Regards.

[Victor Fernandez]

Hi,

it is strange that the log indicates line 147 when it was not able to read it. Maybe the agent.conf file is not arriving to the agent or it is being discarded due to a checksum error.

First, please remove file merged.mg from folder shared in the agent and the manager. Then enable debugging log in order to know where the problem is.

• On the manager: 

/var/ossec/bin/ossec-control enable debug

/var/ossec/bin/ossec-control restart

• On the agent, add this line to file local_internal_options.conf:

windows.debug=1

and restart the agent. When it gets connected, the manager should log a message like:

ossec-remoted: Sending file 'merged.mg' to agent.

and that file should appear immediately in the agent (folder shared). After few seconds, when the file is completely delivered, it should be unmerged into every file that exists in the manager's shared folder.

A common issue is that the file doesn't arrive properly (e.g. some packets were lost or corrupted) the file merged.mg will disappear suddenly and the Windows agent should log:

ossec-agent: Failed md5 for: merged.mg -- deleting.

In this case, the manager will retry to send the file every 10 minutes.

But as I mentioned before, an error message about reading file that indicates a line different from 0 has no sense. However I hope this help you.

Best regards.

--

---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Victor M. Fernandez-Castro

IT Security Engineer

Wazuh Inc.

[Ricardo Galossi]

Hi Victor,

Thanks for your reply. I did everything you told me, but the error persist. I continuous receiving many logs as below:

ossec-agentd: Failed md5 for: shared/merged.mg -- deleting. 

A new thing that I realized is that the file ar.conf is not present in windows agent installation directory too, I tried to restart the agent remotely and saw it. After I enable debug on the windows agent I was able to see this log:

ossec-agent: DEBUG: Sending keep alive: #!-Microsoft Windows Server 2012 Datacenter Edition (full)  (Build 9200) - OSSEC HIDS v2.9.0 / e204e0200d4f36c5c80b071e2e1ef79b

x merged.mg 

The point is, this checksum is not the same of agent.conf or merged.mg on ossec server. I kinda gave up about this and tried to do everything manually, I created agent.conf in blank within C:\Program Files (x86)\ossec-agent\shared directory and restart the agent, in the log file the error (ERROR: Error reading XML file 'shared/agent.conf': XMLERR: File 'shared/agent.conf' not found) isn't being shown anymore, but the agent.conf doesn't synchronize, it remains in blank. 

I don't know what to do anymore, reinstalled the agent and the server, tried in different windows installations and tried with ossec 2.8.3, but the problem remains. The funny point is that it only happens on Windows agents, on Linux agents everything works perfectly.

If I copy the content of agent.conf from the server to the windows agent, everything works. But I don't know if it can bring me some problem in the future.

To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Victor Fernandez]

Hi Ricardo,

in this case it's probable that the Windows agent is dropping UDP packages from the manager due to overflow. The default UDP buffer size in Linux is 212992 (208 KiB) but I think that in Windows it is only 8 KiB. OSSEC resizes the buffer to 6 KiB (the maximum message length) when the default size is less than 6 KiB.

File ar.conf comes in the merged.mg. Try to send a very little shared file (remove every file in the manager's /var/ossec/etc/shared except ar.conf), restart the manager and then restart the agent.

You may also try to increase the network buffer size in Windows. This may help you: http://smallvoid.com/article/winnt-winsock-buffer.html.

Best regards.

To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Crow]

can this be changed to use TCP instead of UDP? i have the same issue but i dont think changing the default buffer size is a good idea

[Nathan Buuck]

This issue has been documented in https://github.com/ossec/ossec-hids/issues/1205 and resolved in PR https://github.com/ossec/ossec-hids/pull/1207. You can fetch the latest from the repo, compile, and distribute on your own or wait for a subsequent release of the Windows agent installer.

[dan (ddp)]

On Wed, Aug 2, 2017 at 7:19 AM, Stephen Crow <stephe...@gmail.com> wrote:
> can this be changed to use TCP instead of UDP? i have the same issue but i
> dont think changing the default buffer size is a good idea
>

Yes, just add tcp support to agentd and remoted.
Wazuh may already have this, I'm not positive.

[Victor Fernandez]

Hi all,

I think that the issue you referred is not the cause of this problem: it will write the merged.mg as a binary file but this shouldn't matter because OSSEC and Wazuh performs the shared file (merged.mg) MD5 as a text file, so the hash should match.

As I said before IMHO the issue affects to Windows and UNIX agents but it's more common in Windows because the default buffer is shorter. We had this problem with a Windows agent on a private VirtualBox network: the shared file didn't arrive. With debugging enabled, we saw the message:

ossec-agent: Failed md5 for: merged.mg -- deleting.

So we did this test: we modified the source code to prevent file from being deleted although it was corrupted, and compared the received file with the original one: some chunks of the file were indeed lost, it was not a line ending issue.

Shared file chunks may be lost due to the UDP protocol, as well as any other agent event or control message. In fact using TCP seems to be a good solution for this problem. We implemented TCP communication in Wazuh a year ago from version 1.1 and we reached some advantages:

• No event losing. Communication is reliable for events, control messages and Active response requests.
• Agents detect that a manager is down immediately, so they are able to "lock" the transmission in order to prevent events from being dropped.

Agents with TCP connection are working properly in many systems using Linux, Windows, OpenBSD, macOS, AIX, etc.

Best regards.