Wazuh 2.0 Windows Agent not picking up logs.

1,728 views
Skip to first unread message

InfoSec

unread,
May 8, 2017, 12:51:07 AM5/8/17
to Wazuh mailing list
Recently upgraded OSSEC 2.8.3 Windows agent to Wazuh 2.0 feeding into OSSEC 2.0 Server (untouched OVA image).

The same /var/ossec/etc/shared/agent.conf that has been working for months is not working anymore.

There does not seem to be an issue between agent and server. When I start the agent, the server spits an agent connected event. /var/ossec/bin/agent_control -l lists the agent as Active.

With the agent running in debug=2 mode, the agent log shows periodic keep-alives being sent to the server. But no events are picked up. Only syscheck events are forwarded.

This is my agent.conf (on server: "/var/ossec/etc/shared/agent.conf" and on agent: "C:\Program Files (x86)\ossec-agent\shared\agent.conf"):

\<agent_config name="Agent_Name">

  \<localfile>
    \<location>Microsoft-Windows-AppLocker/EXE and DLL</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-AppLocker/MSI and Script</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-AppLocker/Packaged app-Deployment</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-AppLocker/Packaged app-execution</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Windows PowerShell</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-WMI-Activity/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-Defender/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-WindowsUpdateClient/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-Windows Remote Management/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-DriverFrameworks-UserMode/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Setup</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-DNS-Client/Operational</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

  \<localfile>
    \<location>Microsoft-Windows-Windows Firewall With Advanced Security/Firewall</location>
    \<log_format>eventchannel</log_format>
  \</localfile>

\</agent_config>

Agent_Name in agent.conf is correct.

Am I missing a step or a configuration that is causing this behavior?

InfoSec

unread,
May 8, 2017, 1:45:32 AM5/8/17
to Wazuh mailing list
Ignore the backslashes.

/var/ossec/bin/verify-agent-conf -f /var/ossec/etc/shared/agent.conf

returns no errors.

Victor Fernandez

unread,
May 8, 2017, 5:43:38 AM5/8/17
to InfoSec, Wazuh mailing list
Hi,

I tested your file agent.conf, removing backslashes, in the next system:
  • Manager: Wazuh v2.0 (latest)
    • agent.conf format: Unix (LF)
  • Agent: Wazuh v2.0 (latest)
    • Agent name: windows
    • received agent.conf format: Windows (CRLF)
I followed the next steps:
  1. Write file /var/ossec/etc/shared/agent.conf with your content. File head is: <agent_config name="windows">
  2. Enable archives on manager: <logall>yes</logall>
  3. Restart manager to update file merged.mg (that contains agent.conf and will be sent to agents).
  4. Restart Windows agent (called "windows") and wait to synchronize agent.conf.
  5. Restart Windows agent again to reload new agent.conf.
  6. Open Windows PowerShell to generate some events.
At this point, the agent log (with debug disabled) was:

2017/05/08 02:03:20 ossec-agentd(4102): INFO: Connected to the server (192.168.12.34:1514).

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-AppLocker/EXE and DLL'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-AppLocker/MSI and Script'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-AppLocker/Packaged app-Deployment'.

2017/05/08 02:03:20 ossec-logcollector: ERROR: Could not EvtSubscribe() for (Microsoft-Windows-AppLocker/Packaged app-Deployment) which returned (15007)

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-AppLocker/Packaged app-execution'.

2017/05/08 02:03:20 ossec-logcollector: ERROR: Could not EvtSubscribe() for (Microsoft-Windows-AppLocker/Packaged app-execution) which returned (15007)

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Windows PowerShell'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-WMI-Activity/Operational'.

2017/05/08 02:03:20 ossec-logcollector: ERROR: Could not EvtSubscribe() for (Microsoft-Windows-WMI-Activity/Operational) which returned (15007)

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-Defender/Operational'.

2017/05/08 02:03:20 ossec-logcollector: ERROR: Could not EvtSubscribe() for (Microsoft-Windows-Defender/Operational) which returned (15007)

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-WindowsUpdateClient/Operational'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-Windows Remote Management/Operational'.

2017/05/08 02:03:20 ossec-logcollector: ERROR: Could not EvtSubscribe() for (Microsoft-Windows-Windows Remote Management/Operational) which returned (15007)

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-DriverFrameworks-UserMode/Operational'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Setup'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-DNS-Client/Operational'.

2017/05/08 02:03:20 ossec-logcollector(1951): INFO: Analyzing event log: 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall'.

2017/05/08 02:03:20 ossec-logcollector: INFO: Started (pid: 2612).

2017/05/08 02:03:49 ossec-syscheckd: INFO: Syscheck scan frequency: 43200 seconds

Some of the event logs were rejected, maybe because my Windows lab has not enabled those logs.

But back in the manager, it received PowerShell logs from the Windows agent successfully. This is an extract from the file archives.log:

2017 May 08 11:03:21 (windows) any->ossec ossec: Agent started: 'windows->any'.


2017 May 08 11:05:28 (windows) any->WinEvtLog 2017 May 08 02:05:27 WinEvtLog: Windows PowerShell: INFORMATION(600): PowerShell: (no user): no domain: WIN-2JIH7DS7L6N: Provider "WSMan" is Started.     Details:    ProviderName=WSMan  NewProviderState=Started   SequenceNumber=1   HostName=ConsoleHost  HostVersion=2.0  HostId=2d152bf5-fe7d-4b8e-846e-1dbb4300e0df  EngineVersion=  RunspaceId=  PipelineId=  CommandName=  CommandType=  ScriptName=  CommandPath=  CommandLine=


2017 May 08 11:05:28 (windows) any->WinEvtLog 2017 May 08 02:05:27 WinEvtLog: Windows PowerShell: INFORMATION(600): PowerShell: (no user): no domain: WIN-2JIH7DS7L6N: Provider "Alias" is Started.     Details:    ProviderName=Alias  NewProviderState=Started   SequenceNumber=2   HostName=ConsoleHost  HostVersion=2.0  HostId=2d152bf5-fe7d-4b8e-846e-1dbb4300e0df  EngineVersion=  RunspaceId=  PipelineId=  CommandName=  CommandType=  ScriptName=  CommandPath=  CommandLine=


2017 May 08 11:05:28 (windows) any->WinEvtLog 2017 May 08 02:05:27 WinEvtLog: Windows PowerShell: INFORMATION(600): PowerShell: (no user): no domain: WIN-2JIH7DS7L6N: Provider "Environment" is Started.     Details:    ProviderName=Environment  NewProviderState=Started   SequenceNumber=3   HostName=ConsoleHost  HostVersion=2.0  HostId=2d152bf5-fe7d-4b8e-846e-1dbb4300e0df  EngineVersion=  RunspaceId=  PipelineId=  CommandName=  CommandType=  ScriptName=  CommandPath=  CommandLine=


2017 May 08 11:05:28 (windows) any->WinEvtLog 2017 May 08 02:05:27 WinEvtLog: Windows PowerShell: INFORMATION(600): PowerShell: (no user): no domain: WIN-2JIH7DS7L6N: Provider "FileSystem" is Started.     Details:    ProviderName=FileSystem  NewProviderState=Started   SequenceNumber=4   HostName=ConsoleHost  HostVersion=2.0  HostId=2d152bf5-fe7d-4b8e-846e-1dbb4300e0df  EngineVersion=  RunspaceId=  PipelineId=  CommandName=  CommandType=  ScriptName=  CommandPath=  CommandLine=


I could not reproduce your issue. Please tell us the steps you followed with more detail so we could try it in our lab.

Regarding the agent name (at the agent.conf head) is not a regex. You should only use sregexes (aka matches) (https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html?highlight=sregex#sregex-os-match-syntax).

I hope it help.
Kind regards.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
 To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/a24e9f70-0317-4ba3-98c0-48c90a9a47fe%40googlegroups.com.

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



--
Victor M. Fernandez-Castro
IT Security Engineer
Wazuh Inc.

InfoSec

unread,
May 10, 2017, 3:37:16 AM5/10/17
to Wazuh mailing list
Hi Victor,

I had to uninstall the agent, clear rids on the server side, restart server, then point agent to server + enter key, and start agent. It is finally working.

Thank you for your assistance.

InfoSec

unread,
May 10, 2017, 8:11:42 AM5/10/17
to Wazuh mailing list
I upgraded the OSSEC Server from pre-2.0 to 2.0 (wazuh/wazuh:latest docker image, id: 0fdf4c934f81). Started with a clean data directory.

Everything seemed fine on the server side, but I am unable to get the wazuh-2.0 Windows client to connect to the server.

Stopped server and agent, deleted rids at both ends, and started server then agent. The issue persists.

Nothing in the logs on server side, even in debug mode.

It is not a connectivity issue. On the server, if I dump udp traffic with agent IP as a source and port 1514 as destination, I can clearly see a continuous stream of packets coming in from the agent.

$ sudo tcpdump -i eth0 -vvv -nn -p udp and src host <agent_ip> and dst port 1514
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:02:06.178192 IP (tos 0x0, ttl 128, id 27291, offset 0, flags [none], proto UDP (17), length 101)
    <agent_ip>.49700 > <server_ip>.1514: [udp sum ok] UDP, length 73
...

For every packet, the ossec.log on the agent spits:
2017/05/10 15:02:06 ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: '192.168.XX.XX'.
2017/05/10 15:02:07 ossec-agentd: INFO: Trying to connect to server (192.168.XX.XX:1514).

The agent key matches at both ends (client.keys on agent is identical to the same file on the server).

The file with agent ID is 0 bytes at both ends; sender_counter is 0 bytes on server, and contains: 0:350: on agent.

I am at loss as to what could be wrong.

Any hints or suggestions to help resolve the issue are welcome.

Victor Fernandez

unread,
May 10, 2017, 9:10:53 AM5/10/17
to Wazuh mailing list
Hi,

Do you see any package returning from manager to agent at tcpdump?

As you know, tcpdump utility captures traffic arriving to the network interface, not to the port 1514, I mean, it could be blocked by a firewall or SELinux.

Please make sure that neither Iptables nor SELinux are blocking this traffic.

Best regards.

InfoSec

unread,
May 11, 2017, 12:22:53 AM5/11/17
to Wazuh mailing list
Traffic was arriving from the agent to the server on udp port 1514. It was neither an SELinux nor a firewall issue.

Restarting the docker container did not help. Recreating the container from image did not either.

Restarted the docker host, and it worked. Don't ask me why!
Reply all
Reply to author
Forward
0 new messages