This is the documentation for Wazuh 3.9. Check out the docs for the latest version of Wazuh!

Security Configuration Assessment

This section attempts to introduce how this module can help us to secure our systems.

The configuration assessment scope

One of the most certain ways to avoid hosts being compromised is to secure them by reducing their surface of vulnerabilities. That process is commonly known as hardening, and the configuration assessment is the most effective way to determine where the hosts may have their hardening improved.

The SCA will perform scans using policy files as templates to discover the exposures or misconfiguration of the monitored hosts. For example it will determine if it is necessary to change default passwords, remove unnecessary software, unnecessary usernames or logins, and disable or remove of unnecessary services. The target of those policies can be an Operating System such as Debian or Windows, or a particular software like the SSH server.

Security compliance

Each policy check can contain an optional compliance field that is used to specify how the check is relevant to different Compliance Standards specifications. Many of the default policies available with Wazuh, especially CIS policies, already have the CIS and PCI-DSS controls mapped. Here we can see an example:

id: 6512
title: "Ensure noexec option set on removable media partitions"
description: "The noexec mount option specifies that the filesystem cannot contain executable binaries."
rationale: "Setting this option on a file system prevents users from executing programs from the removable media. This deters users from being able to introduce potentially malicious software on the system."
remediation: "Edit the /etc/fstab file and add noexec to the fourth field (mounting options) of all removable media partitions. Look for entries that have mount points that contain words such as floppy or cdrom."
compliance:
 - cis: "1.1.20"
 - cis_csc: "8"
 - pci_dss: "2.2.4"
condition: any
rules:
  - 'f:/etc/fstab -> NIN !r:^# && r:/media && r:noexec;'

SCA scan results

SCA scan results appear as alerts when a check has changed its status between scans. Only the events that are necessary to keep the global status of the scan updated are sent by agents, avoiding the flooding of unnecessary events in each scan.

An alert example can be seen here:

** Alert 1556643969.400529: - sca,gdpr_IV_35.7.d
2019 Apr 30 10:06:09 (centos) 192.168.0.97->sca
Rule: 19008 (level 3) -> 'CIS Benchmark for Red Hat Enterprise Linux 7: Ensure address space layout randomization (ASLR) is enabled'
{"type":"check","id":645241598,"policy":"CIS Benchmark for Red Hat Enterprise Linux 7","policy_id":"cis_rhel7","check":{"id":6523,"title":"Ensure address space layout randomization (ASLR) is enabled","description":"Address space layout randomization (ASLR) is an exploit mitigation technique which randomly arranges the address space of key data areas of a process.","rationale":"Randomly placing virtual memory regions will make it difficult to write memory page exploits as the memory placement will be consistently shifting.","remediation":"Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: kernel.randomize_va_space = 2 and set the active kernel parameter","compliance":{"cis":"1.5.3","cis_csc":"8.4"},"rules":["f:/proc/sys/kernel/randomize_va_space -> !r:^2$;"],"file":"/proc/sys/kernel/randomize_va_space","result":"passed"}}
sca.type: check
sca.scan_id: 645241598
sca.policy: CIS Benchmark for Red Hat Enterprise Linux 7
sca.check.id: 6523
sca.check.title: Ensure address space layout randomization (ASLR) is enabled
sca.check.description: Address space layout randomization (ASLR) is an exploit mitigation technique which randomly arranges the address space of key data areas of a process.
sca.check.rationale: Randomly placing virtual memory regions will make it difficult to write memory page exploits as the memory placement will be consistently shifting.
sca.check.remediation: Set the following parameter in /etc/sysctl.conf or a /etc/sysctl.d/* file: kernel.randomize_va_space = 2 and set the active kernel parameter
sca.check.compliance.cis: 1.5.3
sca.check.compliance.cis_csc: 8.4
sca.check.file: ["/proc/sys/kernel/randomize_va_space"]
sca.check.result: passed

On the Wazuh App, within the SCA tab we can see the result for each check of the scanned policies. In addition, each check can be expanded to view more detailed information about it.

Scanned policies overview

Every scanned policy should contain a header to provide its overview information. Here we can see a header example:

policy:
  id: "system_audit_ssh"
  file: "system_audit_ssh.yml"
  name: "System audit for SSH hardening"
  description: "Guidance for establishing a secure configuration for SSH service vulnerabilities."
  references:
    - https://www.ssh.com/ssh/

Fields like id are mandatory to identify and classify policies.

The following screenshot of the SCA tab shows an overview of scanned policies for an agent:

Available policies

Policies for the SCA module are written using the YAML format, which was chosen due to its focus on human readability, which allows the user to quickly understand and write their own policy files or extend the existing ones.

Many of the available default policies are based on CIS benchmarks, enriched with valuable information for every check.

Available policies list

When a Wazuh agent is installed, the system will only include the policy files supported by that particular Operating System. The following list shows all the default policy files available for the Operating Systems officially supported by Wazuh. These policies are all included with the Wazuh manager installation so they may be included in agent groups easily.

Policy Name Requirement
acsc_office2016_rcl System audit for Office 2016 vulnerabilities Microsoft Office 2016
cis_apache2224_rcl CIS Apache HTTP Server 2.2/2.4 Benchmark Apache configuration files
cis_win2012r2_domainL1_rcl CIS benchmark for Windows 2012 R2 Domain Controller L1 Windows Server 2012 R2
cis_win2012r2_domainL2_rcl CIS benchmark for Windows 2012 R2 Domain Controller L2 Windows Server 2012 R2
cis_win2012r2_memberL1_rcl CIS benchmark for Windows 2012 R2 Member Server L1 Windows Server 2012 R2
cis_win2012r2_memberL2_rcl CIS benchmark for Windows 2012 R2 Member Server L2 Windows Server 2012 R2
cis_rhel5_linux_rcl CIS Benchmark for Red Hat Enterprise Linux 5 Red Hat Systems
cis_rhel6_linux_rcl CIS Benchmark for Red Hat Enterprise Linux 6 Red Hat Systems
cis_rhel7_linux_rcl CIS Benchmark for Red Hat Enterprise Linux 7 Red Hat Systems
cis_apple_macOS_10.11 CIS Apple OSX 10.11 Benchmark MAC OS X 10.11 (El Capitan)
cis_apple_macOS_10.12 CIS Apple macOS 10.12 Benchmark MAC OS X 10.12 (Sierra)
cis_apple_macOS_10.13 CIS Apple macOS 10.13 Benchmark MAC OS X 10.13 (High Sierra)
cis_debianlinux7-8_L1_rcl CIS benchmark for Debian/Linux 7 and 8 L1 Debian 7 and 8
cis_debianlinux7-8_L2_rcl CIS benchmark for Debian/Linux 7 and 8 L2 Debian 7 and 8
cis_debian_linux_rcl CIS benchmark for Debian/Linux Debian systems
cis_sles11_linux_rcl CIS SUSE Linux Enterprise 11 Benchmark SUSE 11
cis_sles12_linux_rcl CIS SUSE Linux Enterprise 12 Benchmark SUSE 12
cis_solaris11_rcl CIS benchmark for Oracle Solaris 11 Solaris 11
system_audit_pw System audit for password-related vulnerabilities Password files
system_audit_rcl_mac System audit for web-related vulnerabilities N/A
system_audit_rcl System audit for web-related vulnerabilities N/A
system_audit_ssh System audit for SSH hardening SSH configuration files
win_audit_rcl Benchmark for Windows audit Windows
cis_win10_enterprise_L1_rcl CIS benchmark for Windows 10 Enterprise (Release 1709) Windows 10
cis_win10_enterprise_L2_rcl CIS benchmark for Windows 10 Enterprise (Release 1709) Windows 10
cis_mysql5-6_community_rcl CIS benchmark for Oracle MySQL Community Server 5.6 MySQL configuration files
cis_mysql5-6_enterprise_rcl CIS benchmark for Oracle MySQL Enterprise 5.6 MySQL configuration files

Policy files location

  • On Linux platforms, the default policy files are located under the default installation directory at /var/ossec/ruleset/sca.
  • On Windows platformss, the policy files are located under the default installation directory at C:\\Program files (x86)\\ossec-agent\\ruleset\\sca.

How to share policy files with agents

As described in the centralized configuration section, the Wazuh manager has the ability to push files and configurations to connected agents.

This feature can be used to push policy files to agents in defined groups. By default, every connected agent belongs to the default group, so we can use this group as an example.

In order to push a new policy from the manager it should be placed in the directory: /var/ossec/etc/shared/default , ensure the policy owner is ossec and then add the following block to the /var/ossec/etc/shared/default/agent.conf file:

<agent_config>

    <!-- Shared agent configuration here -->
    <sca>
        <policies>
            <policy>/var/ossec/etc/shared/your_policy_file.yml</policy>
        </policies>
    </sca>

</agent_config>

The <sca> block will be merged with the current <sca> block on the agent side and the new policy file will be added.

Current policy files configured to be run on the agent (either by default or by local configuration) may be disabled via the centralized configuration file /var/ossec/etc/shared/default/agent.conf as follows:

<agent_config>

    <!-- Shared agent configuration here -->
    <sca>
        <policies>
            <policy enabled="no">/var/ossec/etc/shared/policy_file_to_disable.yml</policy>
        </policies>
    </sca>

</agent_config>

Note

Remote policies are not allowed to run commands by default for security reasons. To enable it, change the sca.remote_commands of the internal options.

Creating custom SCA policies

As mentioned previously, the policy files have a YAML format. In order to illustrate shown below is a section of the policy file for SSH hardening:

policy:
  id: "system_audit_ssh"
  file: "system_audit_ssh.yml"
  name: "System audit for SSH hardening"
  description: "Guidance for establishing a secure configuration for SSH service vulnerabilities."
  references:
    - https://www.ssh.com/ssh/

requirements:
  title: "Check that the SSH service is installed on the system"
  description: "Requirements for running the SCA scan against the SSH policy."
  condition: "all required"
  rules:
    - 'f:/etc/ssh/sshd_config;'

variables:
 $sshd_file: /etc/ssh/sshd_config;

checks:
 - id: 1500
   title: "SSH Hardening - 1: Port 22"
   description: "The ssh daemon should not be listening on port 22 (the default value) for incoming connections."
   rationale: "Changing the default port you may reduce the number of successful attacks from zombie bots, an attacker or bot doing port-scanning can quickly identify your SSH port."
   remediation: "Change the Port option value in the sshd_config file."
   compliance:
    - pci_dss: "2.2.4"
   condition: any
   rules:
    - 'f:$sshd_file -> IN !r:^# && r:Port\.+22;'

As shown in this example, there are four sections, not all of them are required for a policy file:

Section Required
policy Yes
requirements No
variables No
checks Yes

Note

If the requirements aren’t satisfied for a specific policy file, the scan for that file won’t start.

Each section has their own fields that can be mandatory as described below:

Policy section

Field Mandatory Type Allowed values
id Yes String Any string
file Yes String Any string
name Yes String Any string
description Yes String Any string
references No Array of strings Any string

Requirements section

Field Mandatory Type Allowed values
title Yes String Any string
description Yes String Any string
condition Yes String Any string
rules Yes Array of strings Any string

Variables section

Field Mandatory Type Allowed values
variable_name Yes String Any string

Checks section

Field Mandatory Type Allowed values
id Yes Numeric Any integer number
title Yes String Any string
description No String Any string
rationale No String Any string
remediation No String Any string
compliance No Array of strings Any string
references No Array of strings Any string
condition Yes String all, any, any required, all required
rules Yes Array of strings Any string

It is recommended that new policy files be placed under the ruleset/sca directory.

Note

  • Remember that the value of the policy and check id fields must be unique, not existing in other policy files.

Information about variables

When setting variables in the variables section:

  • Make sure they start with $ character
  • Make sure they end with ; character

Example: $sshd_file: /etc/ssh/sshd_config;

Information about rules

General rule syntax

The rules field is where SCA dictates if a check is marked as passed or failed.

There are five main types of rules as described below:

Type Character
File f
Directory d
Process p
Commands c
Registry (Windows Only) r

In order to better understand the syntax of the rules, it is important to note that:

  • The type of a rule references the location where the rule will look for the content of the check. Every rule has to start with a location.
  • The location is commonly followed by the content to look for. It is accepted a literal string or a regular expression preceded by r: (the supported Regex syntax can be found here).
  • As explained before, the most common rules have the format type:location -> r:REGEX;. However, there are exceptions, for example, for Windows registries, we would have to add the registry key in the middle of the rule.
  • Each rule must end with the semicolon ; character.

The following examples illustrate this logic:

Rule syntax for files

  • Checking that a file exists - 'f:/path/to/file;'
  • Checking file content (whole line match) - 'f:/path/to/file -> content;'
  • Checking file content with regex - 'f:/path/to/file -> r:REGEX;'

Rule syntax for directories

  • Checking that a directory exists - 'd:/path/to/directory;'
  • Checking that a directory contains a file - 'd:/path/to/directory -> file;'
  • Checking that a directory contains files with regex - 'd:/path/to/directory -> r:^files;'
  • Checking that a directory contains files and its content - 'd:/path/to/directory -> file -> content;'

Rule syntax for processes

  • Checking that a process is running - 'p:process_name;'

Rule syntax for commands

  • Checking the output of a command - 'c:command -> output;'
  • Checking the output of a command with regex - 'c:command -> r:REGEX;'

Rule syntax for registries (Windows only).

  • Checking that a registry exists - 'r:path/to/registry ;'
  • Checking that a registry key exists - 'r:path/to/registry -> key;'
  • Checking a registry key content - 'r:path/to/registry  -> key -> content;'

Global operators for composed rules

When more than one term is necessary, two logical operators can be used to determine the accumulated result of a check (terms are separated by && inside a rule).

  • IN (included): This operator means that both the terms should be matched.
  • NIN (not included): The opposite operator, it means the rule is triggered if both terms are not matched.

Use cases

Composed rules:

  • Alert when there is a line that does not begin with # and contains Port 22 - 'f:/etc/ssh/sshd_config -> IN !r:^# && r:Port\.+22;'
  • Alert when there is no line that does not begin with # and contains Port 2222 - 'f:/etc/ssh/sshd_config -> NIN !r:^# && r:Port\.+2222;'

Other examples:

  • Looking at the value inside a file: 'f:/proc/sys/net/ipv4/ip_forward -> 1;'
  • Checking if a file exists: 'f:/proc/sys/net/ipv4/ip_forward;'
  • Checking if a process is running: 'p:avahi-daemon;'
  • Looking at the value of a registry: 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters -> MaximumPasswordAge -> 0;'
  • Looking if a directory contains files: 'd:/home/* -> ^.mysql_history$;'
  • Checking if a directory exists: 'd:/etc/mysql;
  • Check the running configuration of ssh to check the maximum authentication tries: 'c:sshd -T -> !r:^\s*maxauthtries\s+4\s*$;'
  • Check if root is the only UID 0 account 'f:/etc/passwd -> IN !r:^# && !r:^root: && r:^\w+:\w+:0:;'