Monitoring services on wazuh
-
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
tologcollector.remote_commands=1
This setting is located here
/var/ossec/etc/internal_options.conf
We can either manually change using
nano
or automate usingsed
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
, andsuricata
. 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