How to Monitor Services with Wazuh

Wazuh is a great open source tool that allows us to integrate many security features under one manager. Let’s add another task to wazuh’s impressive capabilities. We will monitor services with wazuh using remote commands.

Enabling remote commands on wazuh agents

Before we can monitor services with wazuh , we must enable remote commands on the wazuh agents. This needs to be done on each individual agent.

We need to change the value of logcollector.remote_commands=0 to logcollector.remote_commands=1

This setting is located here /var/ossec/etc/internal_options.conf

We can manually change the file using nano

nano /var/ossec/etc/internal_options.conf

Or we script the change using sed

sed -i '/logcollector.remote/c\logcollector.remote_commands=1' /var/ossec/etc/internal_options.conf 

Add rules on wazuh manger to monitor services with wazuh

Creating a new rules file

Wazuh comes out of the box with a custom rules file you can use to make a few edits. The wazuh documentation recommends that if you are going to extensively leverage rules, create your own rule files. I like to create my own rule either way because it is easier to manage.

Create a rule file to monitor services with wazuh

You can find out which services you would like to monitor by using systemctl on linux distros that support it. Most major distros do use systemctl

systemctl status 

After running that command, I have decided I want to monitor auditd , apparmor , and suricata. In a production environment, you will likely be monitoring more services, but for the sake of this lab I will be monitoring these services

(Part 1 ) Create your XML Rules file to monitor services with wazuh

nano /var/ossec/etc/rules/service_monitoring_rules_02-99.xml


Copy and paste this into your new xml file. I will explain what everything means so you can tweak yours to your liking.

<!-- ################################### -->
<!-- # Service Monitoring Rules        #  --> 
<!-- ################################### -->

<!-- ################################### -->
<!-- # Rule numbers 2 - 99             #  --> 
<!-- ################################### -->


<group name="service_monitor,">

<rule id="100002" level="10">
  <if_sid>530</if_sid>
  <match>ossec: output: 'sudo systemctl show -p ActiveState --value auditd'</match>
  <regex>inactive</regex>
  <description>The service auditd is no longer running on  host</description>
  <group>service_monitor,</group>
</rule>


<rule id="100003" level="10">
  <if_sid>530</if_sid>
  <match>ossec: output: 'sudo systemctl show -p ActiveState --value apparmor'</match>
  <regex>inactive</regex>
  <description>The service apparmor is no longer running on host</description>
  <group>service_monitor,</group>
</rule>

<rule id="100004" level="10">
  <if_sid>530</if_sid>
  <match>ossec: output: 'sudo systemctl show -p ActiveState --value suricata'</match>
  <regex>inactive</regex>
  <description>The service suricata is no longer running on host</description>
  <group>service_monitor,</group>
</rule>

<rule id="100005" level="10">
  <if_sid>530</if_sid>
  <match>ossec: output: 'sudo systemctl show -p ActiveState --value suricata'</match>
  <regex>failed</regex>
  <description>The service suricata has failed on host</description>
  <group>service_monitor,</group>
</rule>



</group>

Let’s break down the XML file

group name

<group name="service_monitor,">

This is the name of the group that will be displayed in ELK. In this particular instance we are creating a new category. You can call this whatever you’d like. Just make sure to update <group> under the description on the XML file as well if you make any changes.


rule id

<rule id="100002" level="10">

The Rule ID field must be unique. The custom rules file that wazuh gives you out of the box starts at 100001. So we started our first custom rule at 100002. You will also noticed that we included rule numbers in file name as well so it is easy to remember what number to use for rules within this custom rules set.

if_sid

<if_sid>530</if_sid>

Rule 530 is a default Wazuh rule for command monitoring. When using the remote commands we will always point to this rule.

match

<match>ossec: output: 'sudo systemctl show -p ActiveState --value auditd'</match>

Our command that is being run to show the state of the auditd service

regex

<regex>inactive</regex>

The outcome of the command that makes an alert trigger. In this case, we want inactive as this means the service is no longer running.

description

<description>The service auditd is no longer running on  host</description>

This is the description of the alert we want to display in ELK

(Part 2 ) Edit your agent.conf file on wazuh server

You can use /var/ossec/etc/shared/default/agent.conf to configure centralized updates to configuration files on agents.

nano /var/ossec/etc/shared/default/agent.conf

We want our file to look like this when done:

<agent_config>

<!-- ################################### -->
<!-- # Service Monitoring Commands     #  --> 
<!-- ################################### -->


<localfile>
  <log_format>command</log_format>
  <command>sudo systemctl show -p SubState --value auditd</command>
  <frequency>120</frequency>
</localfile>

<localfile>
  <log_format>command</log_format>
  <command>sudo systemctl show -p ActiveState --value apparmor</command>
  <frequency>120</frequency>
</localfile>

<localfile>
  <log_format>command</log_format>
  <command>sudo systemctl show -p ActiveState --value suricata</command>
  <frequency>120</frequency>
</localfile>


</agent_config>

Let’s look at agent.conf in more detail

Log_format

<log_format>command</log_format>

This is the type of log. Since we are executing a command, it will be set to command

Command

<command>sudo systemctl show -p ActiveState --value auditd</command>

This is the actual command we are using to check status for auditd

Frequency

<frequency>120</frequency>

Frequency in which the command is run in seconds

Restart wazuh manager and wazuh agent

Restart Wazuh Manager

systemctl restart wazuh-manager

Restart all of wazuh agents from wazuh manager server

/var/ossec/bin/agent_control -R -a

Test

Now login to any of your wazuh agents and manually stop a service

systemctl stop auditd

You should now receive on alert on your ELK stack

For more information on this subject see the command monitoring documentation by wazuh Here.

For more information about wazuh check out the rest of my blog Here.

0 Points


Leave a Reply

Your email address will not be published. Required fields are marked *