Triggering Agentless alerts to show in security events

200 views
Skip to first unread message

Ryan Felim

unread,
Mar 30, 2023, 2:17:20 AM3/30/23
to Wazuh mailing list
Hey Community,

I just deployed and manage to connect and monitor my linux endpoint by using the agentless method. I want to test if it is actually receiving syslog. Can anyone tell me or give me some tips to trigger the alerts.json file so that it will appear in the dashboard. 

Please help.

Juan Carlos Tello

unread,
Mar 30, 2023, 4:07:40 AM3/30/23
to Ryan Felim, Wazuh mailing list
Hi Ryan,

Wazuh has three methods of monitoring an asset without an agent:
  • Agentless monitoring: In which the manager periodically logs into an endpoint via SSH and executes commands to detect differences in their output, this also has a basic FIM capability to determine changes in the filesystem.
  • Remote syslog: In which you configure the manager to listen in via syslog and the asset to forward syslog messages. This is the most commonly used method for monitoring network devices.
  • Cloud security: Through the use of Wazuh modules (also known as wodles) Wazuh can securely log to external APIs and retrieve security relevant information for analysis.
In order to determine if it is receiving syslog messages you may temporarily enable <logall_json> and monitor the /var/ossec/logs/archives/archives.json file for messages from the monitored source.

Alternatively you may use tools like ss (formerly netstat) and tcpdump to determine if the port is open and if messages are coming through, for example ss -nap | grep ':514'  will show if port 514 is actively listened to and tcpdump -i any port 514 -AA will show all syslog messages detected in transit on this port.

If you don't see the port open then you should verify the configuration and restart the Wazuh manager service. If you don't see any messages with tcpdump then you should verify the endpoint's syslog output configuration and if there's any network restriction.

Note that tcpdump will still show messages that are being blocked by the OS firewall, so if you see messages with tcpdump but not on the archives.json file then you should verify your firewall settings.

Finally, if messages are observed in the archives.json but not on the dashboard then you should create rules to match these events, since the default behavior in Wazuh is to only log events it identifies to be security relevant. More information on creating custom rules and decoders can be found here: https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

Best regards,
Juan C. Tello

--
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/283e6ff2-ec90-43cb-90d2-c14680b399b8n%40googlegroups.com.
Message has been deleted
Message has been deleted

Juan Carlos Tello

unread,
Mar 31, 2023, 4:34:33 AM3/31/23
to Ryan Felim, Wazuh mailing list
Hi Ryan,
I see there are two new messages but they have been deleted.
Since this can happen either due to faulty automated moderation or your personal choice I wanted to know if you still have a question related to this topic.
Best Regards,
Juan C. Tello

Ryan Felim

unread,
Mar 31, 2023, 4:36:40 AM3/31/23
to Wazuh mailing list
Actually, I still have questions. 

Ryan Felim

unread,
Mar 31, 2023, 4:50:31 AM3/31/23
to Wazuh mailing list
Hey Juan, 

Thanks for the heads up. I am quite aware of the deployment methods. Currently I am using the agentless monitoring method on my linux endpoint via SSH. It is successfully deployed and I received alerts from the agent id 000 in the wazuh dashboard which is I'm also aware. But the alerts that I am receiving are just successful boot alerts or opened sessions etc. But, when I try to do actions like "sudo", "touch", "rm", etc, I am not receiving any alerts. This could be that, I still haven't enabled or generate the log regarding those commands, direct my ossec.conf to actively monitor that log directory, or there could be no ruleset that match the actions that I mentioned. Is there a reference for me to tweak my wazuh so that I can configure it the way I wanted?  

Regarding this message:

"In order to determine if it is receiving syslog messages you may temporarily enable <logall_json> and monitor the /var/ossec/logs/archives/archives.json file for messages from the monitored source."

- Is it recommended to enable <logall_json>? Is this file directory /var/ossec/logs/archives/archives.json is where the alerts is generated that will appear in the wazuh dashboard?

Regarding this message:

"Alternatively you may use tools like ss (formerly netstat) and tcpdump to determine if the port is open and if messages are coming through, for example ss -nap | grep ':514'  will show if port 514 is actively listened to and tcpdump -i any port 514 -AA will show all syslog messages detected in transit on this port.
If you don't see the port open then you should verify the configuration and restart the Wazuh manager service. If you don't see any messages with tcpdump then you should verify the endpoint's syslog output configuration and if there's any network restriction."

- Yes, I have tried this method and currently wazuh remote is listening through this port, mine is 1514.

Thanks for the follow up.
Regards, 
Ryan.

Juan Carlos Tello

unread,
Mar 31, 2023, 5:22:28 AM3/31/23
to Ryan Felim, Wazuh mailing list
Hi Ryan,
The visibility you get with agentless monitoring depends on the configuration of agentless used for which you have 4 options:
  • ssh_integrity_check_bsd
  • ssh_integrity_check_linux
  • ssh_generic_diff
  • ssh_pixconfig_diff
Which allow you to either alert for changes to files within directories and their subfolders (integrity check) or to alert when a command outputs a different value (diff).

In order to use this to detect actions such as commands being run then you could monitor a log of commands executed on the machine (making sure not to read the commands you add yourself when looking for these actions). For example:

<agentless>
  <type>ssh_generic_diff</type>
  <frequency>20000</frequency>
  <host>ro...@test.com</host>
  <state>periodic_diff</state>
  <arguments>history | grep -P 'sudo|touch|rm' | grep -v history</arguments>
</agentless>

As for <logall_json>, enabling it is recommended if you wish to troubleshoot event collection. The alerts that appear on the Wazuh dashboard by default are in /var/ossec/logs/alerts/alerts.json and this file is populated whenever <jsonout_output> is set to yes. If you wish to have the events from the archives.json on the dashboard you must edit /etc/filebeat/filebeat.yml to enable the Wazuh archives module, restart the filebeat service and then create an index pattern to be able to visualize these indices.

Port 1514 is usually reserved for the secure communications from the Wazuh agent and not syslog, it is ok to have both types of connections.

Let us know if you have more questions and we'll be glad to help.
Best regards,
Juan C. Tello


Ryan Felim

unread,
Mar 31, 2023, 5:34:25 AM3/31/23
to Wazuh mailing list
Hey Juan,

Thank you for the information. This is very informative and helpful. I will run some test and see if it works out for me.

Thanks again.
Regards,
Ryan 
Reply all
Reply to author
Forward
0 new messages