Monitoring services on wazuh

IRJ

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 either manually change using nano or automate using sed

nano /var/ossec/etc/internal_options.conf

or

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.

You can find out which services you want to monitor by using the following command:

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

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