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 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
    32f91d78-5f04-4b82-b622-ed2996b4a819-image.png

    8af3f7e4-992d-4276-b0ac-a7981811701d-image.png