Wazuh manager

The Wazuh manager is responsible for data analysis and alerting. It can forward alerts through syslog, emails, or integrated external APIs. See the data analysis documentation for more information on how Wazuh performs data analysis.

The Wazuh manager comprises several services and components that are responsible for various functions. These include Agent enrollment service, aggregating security events, decoding logs, evaluating rules, and alerting. It is also responsible for other functions such as validating the Wazuh agent's identities and encrypting communications between the Wazuh agent and the Wazuh server.

Agent enrollment service

The agent enrollment service is used to enroll Wazuh agents to the Wazuh manager. The enrollment service simplifies the enrollment of Wazuh agents and ensures that they are properly authenticated and configured to communicate securely with the Wazuh manager.

When a Wazuh agent is installed and started on an endpoint, it automatically contacts the Wazuh manager to initiate the enrollment process. The Wazuh manager generates a unique authentication key that encrypts its communication with the Wazuh agent. You can configure additional security measures for the enrollment process, such as password authentication, Wazuh manager identity verification, and Wazuh agent identity verification. Refer to the documentation on Wazuh agent enrollment for more information on the enrollment process.

Configuration

The <auth> block below shows an expanded agent enrollment service configuration in the /var/ossec/etc/ossec.conf file of a Wazuh server.

<ossec_config>
 <auth>
   <disabled>no</disabled>
   <remote_enrollment>yes</remote_enrollment>
   <port>1515</port>
   <use_source_ip>no</use_source_ip>
   <force>
     <enabled>yes</enabled>
     <disconnected_time enabled="yes">1h</disconnected_time>
     <after_registration_time>1h</after_registration_time>
     <key_mismatch>yes</key_mismatch>
   </force>
   <purge>yes</purge>
   <use_password>no</use_password>
   <ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
   <!-- <ssl_agent_ca></ssl_agent_ca> -->
   <ssl_verify_host>no</ssl_verify_host>
   <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
   <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
   <ssl_auto_negotiate>no</ssl_auto_negotiate>
 </auth>
</ossec_config>

Where:

  • <disabled> enables or disables the process of the Wazuh agent enrolling and authenticating with the Wazuh manager. The default value is no. The allowed values are yes and no.

  • <remote_enrollment> enables the Wazuh manager to accept connections from new Wazuh agents using TLS encryption on port 1515 by default. The default value is yes. The allowed values are yes and no.

  • <port> specifies the TCP port number for listening to connections. The default value is 1515. The allowed value is any port number between 0 and 65535.

  • <use_source_ip> defines whether to use the client's source IP address or the use of "any" to add a Wazuh agent. The allowed values are yes and no. When the value is no, the Wazuh agent can connect to the Wazuh manager even if the source IP used for enrollment changes. However, when the value is yes, the Wazuh agent cannot connect to the Wazuh manager if the source IP address changes.

  • <force> specifies the options to be configured for a Wazuh agent re-enrollment within its tag. For the re-enrollment to be successful, all the conditions must be met. The following options define the settings for the force option:

    • <enabled> specifies whether or not to force the insertion of a Wazuh agent if there is a duplicate name or IP address. If it is enabled, it will remove the old Wazuh agent with the same name or IP address. The default value is yes. The possible values are yes and no.

    • <disconnected_time> specifies whether a replacement will be performed for only Wazuh agents that have been disconnected longer than the value configured in the setting. The default value is 1h (one hour). The allowed value is any number greater than or equal to zero. It allows suffixes like s, h, m, and d to represent second, hour, minute, and day. The attribute setting enabled has the default value of yes, meaning replacement will only happen after the specified disconnection time is exceeded. The enabled attribute has two possibilities; yes and no.

    • <after_registration_time> defines the minimum time that must pass after the agent is registered before it can be replaced. The default value is 1h. The allowed value is any number greater than or equal to zero. It allows suffixes like s, h, m, and d to represent second, hour, minute, and day.

    • <key_mismatch> defines that the Wazuh agent replacement occurs when the key held by the Wazuh agent differs from the one registered by the manager. The default value is yes. The possible values are yes and no.

  • <purge> specifies whether the client keys will be deleted when Wazuh agents are removed. When the value is no, removed Wazuh agents will remain in the client keys file marked as removed. When the value is set to yes, the client keys file will be purged. The default value is yes. The possible values are yes and no.

  • <use_password> determines the use of shared password authentication. When the value is no, this option is disabled. When the value is set to yes, a shared password will be read from the /var/ossec/etc/authd.pass file. If this file does not exist, a random password will be generated and stored in the /var/ossec/logs/ossec.log file on the Wazuh server. See the using password authentication documentation for more information.

  • <ciphers> sets the list of ciphers for network communication using SSL. The default value is HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH.

  • <ssl_agent_ca> specifies the path to the CA certificate used to verify clients. It can be referred to as a relative path under the Wazuh installation directory or a full path. The possible value is any valid path.

  • <ssl_verify_host> toggles source host verification on and off when a CA certificate is specified. The client source IP address will be validated using the Common Name field. The default value is no. The allowed values are yes and no.

  • <ssl_manager_cert> specifies the path to the server SSL certificate. It can be referred to as a relative path under the Wazuh installation directory or a full path. The default value is etc/sslmanager.cert. The possible value is any valid path.

  • <ssl_manager_key> specifies the path to the server's SSL key. It can be referred to as a relative path under the Wazuh installation directory or a full path. The default value is etc/sslmanager.key. The possible value is any valid path.

  • <ssl_auto_negotiate> toggles whether or not to auto-select the SSL/TLS method. By default, only TLS v1.2 is allowed. When set to yes, the system will negotiate the most secure common method with the client. In older systems where the manager does not support TLS v1.2, this option will be enabled automatically. The default value is no. The allowed values are yes and no.

Restart the Wazuh manager via the command line interface with the following command whenever you make changes to the configuration file:

# systemctl restart wazuh-manager

Agent connection service

The agent connection service listens for events from Wazuh agents to establish and maintain a persistent and secure communication channel. The Wazuh agent uses this secure channel to send security data to the Wazuh manager for analysis. By default, the service uses the TCP protocol to secure communication between the Wazuh agent and the Wazuh manager.

Configuration

The block below is the default connection service configuration in the Wazuh server /var/ossec/etc/ossec.conf configuration file:

<ossec_config>
  <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>
  </remote>
</ossec_config>

Where:

  • <connection> specifies the type of incoming connection to accept. The default value is secure. The allowed values are secure and syslog.

  • <port> specifies the port to use to listen for events. The default port value is 1514 for secure connection and 514 for syslog connection. The allowed value is any port number between 1 and 65535.

  • <protocol> specifies the protocol to use for the connection. The default value is tcp. The allowed values are tcp and udp.

  • <queue_size> allows you to set the capacity of the remote daemon queue in the number of Wazuh agent events. The default value is 131072. The allowed value is an integer between 1 and 262144. The remote queue is only available for Wazuh agent events, not syslog events. This option only works when the connection is set to secure. To learn more about this configuration setting, check our documentation on the Wazuh queue.

More options can be found in the remote section of the Wazuh documentation.

Restart the Wazuh manager via the command line interface with the following command to implement changes, if changes are made:

# systemctl restart wazuh-manager

Verifying agent connection service

This section describes how to verify the operation of the agent connection service during the enrollment of a Wazuh agent. In this example, a Wazuh agent running on a Windows endpoint with IP address 192.168.71.125 connects to a Wazuh manager with IP address 192.168.71.203. During normal operation, Wazuh agents forward security events to the Wazuh manager over TCP port 1514, using the configuration detailed in the agent connection service configuration section above.

Perform the following steps to verify the operation of the connection service between the Wazuh manager and the Wazuh agent:

  1. Launch the command prompt on the Windows endpoint.

  2. Run the following command to list the connections on the endpoint:

    # netstat -a

    Active Connections

  Proto  Local Address          Foreign Address        State
    TCP    192.168.71.125:51787   a23-53-42-162:https    ESTABLISHED
  TCP    192.168.71.125:51788   a-0003:https           ESTABLISHED
  TCP    192.168.71.125:51789   a-0003:https           ESTABLISHED
  TCP    192.168.71.125:51790   a23-53-42-162:https    ESTABLISHED
  TCP    192.168.71.125:51791   192.168.71.203:1514    SYN_SENT

    This indicates that the Windows endpoint with IP address 192.168.71.125 has sent a TCP SYN_SENT packet and is waiting to establish a connection to the Wazuh server with IP address 192.168.71.203 on port 1514.

  3. Run the following command to view when the Wazuh server establishes a connection with the Wazuh agent:

    # netstat

    Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    192.168.71.125:3389    192.168.71.1:25743     ESTABLISHED
  TCP    192.168.71.125:51572   a23-64-12-19:https     CLOSE_WAIT
  TCP    192.168.71.125:51573   192.229.221.95:http    CLOSE_WAIT
  TCP    192.168.71.125:51694   192.168.71.203:1514    ESTABLISHED
  TCP    192.168.71.125:51699   192.168.20.103:ms-do   SYN_SENT
  TCP    192.168.71.125:51701   192.168.20.101:ms-do   SYN_SENT
  TCP    192.168.71.125:51703   20.231.121.79:http     SYN_SENT
  TCP    192.168.71.125:51704   192.168.20.125:ms-do   SYN_SENT

    The ESTABLISHED state confirms that the Wazuh agent has successfully connected to the Wazuh manager on TCP port 1514, indicating that the agent connection service is functioning correctly.

Analysis engine

The Wazuh analysis engine analyzes data on several log types such as Windows events, SSH logs, web server logs, and others. It uses decoders to identify the type of information being processed and rules to identify specific patterns in the decoded event. These rules could trigger alerts and response actions like blocking an IP address and removing malware.

The following subsections explain the Wazuh analysis engine process in detail, including data sources, decoding, and rule evaluation and alerting.

Data sources

Wazuh collects logs from various sources, allowing for comprehensive monitoring of all aspects of your IT infrastructure. This allows Wazuh to detect complex threats, reduce vulnerability exposure, ensure compliance with security policies, and respond swiftly to identified security incidents. Below are some of the common data sources supported by Wazuh:

  • Operating system logs: Wazuh collects logs generated by several operating systems, like Windows, Linux, and macOS. It can collect a variety of logs from Linux endpoints, including syslog, auditd, application logs, and others. On Windows endpoints, Wazuh collects Windows event logs from System, Applications, and Security event channels by default. Wazuh collects logs on macOS endpoints by using the macOS unified logging system (ULS). The macOS ULS centralizes the management and storage of logs across all system levels.

  • Syslog events: Wazuh collects logs from a variety of syslog-enabled devices, including Linux/Unix systems and network devices that do not require Wazuh agent installation.

  • Agentless monitoring: The Wazuh agentless monitoring capability monitors endpoints that do not support agent installation. It requires an SSH connection between the endpoint and the Wazuh server. This capability enables monitoring of files, directories, or configurations and running commands on the endpoint.

  • Cloud provider logs: Wazuh monitors cloud infrastructure by collecting logs and events directly from cloud service providers like AWS, Azure, Google Cloud, and Office 365. These include logs from cloud services such as EC2 instances, S3 buckets, Azure VMs, and more.

  • Custom logs: You can configure Wazuh to collect and parse logs from several applications and third-party security tools, including VirusTotal, Windows Defender, ClamAV, and more.

Decoding

Decoding is the process of analyzing structured or unstructured data, such as logs from different data sources, to extract meaningful information that can be used for monitoring and alerting. In Wazuh, decoding transforms raw log data into a structured format that the Wazuh manager can interpret and process.

The decoding process consists of two phases:

Pre-decoding phase

In the pre-decoding phase, the log analysis engine extracts syslog-like information such as timestamp, hostname, and program name from the log header. The pre-decoding phase simplifies the log structure and prepares it for further analysis. Consider the following sample log entry to illustrate the process of pre-decoding:

Feb 14 12:19:04 192.168.1.1 sshd[25474]: Accepted password for Stephen from 192.168.1.133 port 49765 ssh2
Demonstrating pre-decoding using wazuh-logtest

Perform the steps below on the Wazuh server:

  1. Run the Wazuh Logtest tool from the command line:

    # /var/ossec/bin/wazuh-logtest

  2. Copy and paste the sample log above and press Enter.

The extracted information after the pre-decoding phase is shown below:

Starting wazuh-logtest v4.14.2
Type one log per line

Feb 14 12:19:04 192.168.1.1 sshd[25474]: Accepted password for Stephen from 192.168.1.133 port 49765 ssh

**Phase 1: Completed pre-decoding.
        full event: 'Feb 14 12:19:04 192.168.1.1 sshd[25474]: Accepted password for Stephen from 192.168.1.133 port 49765 ssh'
        timestamp: 'Feb 14 12:19:04'
        hostname: '192.168.1.1'
        program_name: 'sshd'

Decoding phase

In the decoding phase, the Wazuh analysis engine applies decoders that match the log content. Decoders extract relevant fields such as usernames, IP addresses, ports, error codes, or URLs. For the sample SSH log, the following decoders, located in the /var/ossec/ruleset/decoders/0310-ssh_decoders.xml file, are used:

<decoder name="sshd">
  <program_name>^sshd</program_name>
</decoder>

<decoder name="sshd-success">
  <parent>sshd</parent>
  <prematch>^Accepted</prematch>
  <regex offset="after_prematch">^ \S+ for (\S+) from (\S+) port (\S+)</regex>
  <order>user, srcip, srcport</order>
  <fts>name, user, location</fts>
</decoder>

The sshd decoder matches the program name, while the decoder sshd-success extracts Stephen, 192.168.1.133, and 49765 from the sample log.

Demonstrating decoding using wazuh-logtest

Perform the steps below on the Wazuh server:

  1. Run the Wazuh Logtest tool from the command line:

    # /var/ossec/bin/wazuh-logtest

  2. Copy and paste the sample log in the pre-decoding phase and press Enter.

The extracted information after the decoding phase is shown below:

Starting wazuh-logtest v4.14.2
Type one log per line

Feb 14 12:19:04 192.168.1.1 sshd[25474]: Accepted password for Stephen from 192.168.1.133 port 49765 ssh

**Phase 1: Completed pre-decoding.
        full event: 'Feb 14 12:19:04 192.168.1.1 sshd[25474]: Accepted password for Stephen from 192.168.1.133 port 49765 ssh'
        timestamp: 'Feb 14 12:19:04'
        hostname: '192.168.1.1'
        program_name: 'sshd'

**Phase 2: Completed decoding.
        name: 'sshd'
        parent: 'sshd'
        dstuser: 'Stephen'
        srcip: '192.168.1.133'
        srcport: '49765'

Rule evaluation and alerting

Once a log is decoded, the Wazuh manager evaluates it against a ruleset. Wazuh rules are defined in XML files and can be customized to meet different monitoring and compliance requirements. Each rule defines conditions that, when matched, generate alerts.

For example, rule 5715 matches the decoded SSH log shown in the previous section. This rule is defined in the /var/ossec/ruleset/rules/0095-sshd_rules.xml file on the Wazuh server.

<rule id="5715" level="3">
  <if_sid>5700</if_sid>
  <match>^Accepted|authenticated.$</match>
  <description>sshd: authentication success.</description>
  <mitre>
    <id>T1078</id>
    <id>T1021</id>
  </mitre>
  <group>authentication_success,gdpr_IV_32.2,gpg13_7.1,gpg13_7.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_10.2.5,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

Where:

  • <rule id="5715" level="3"> specifies the rule ID as 5715 and the rule level as 3. The rule ID is a unique identifier for the rule, while the level represents the severity level of the event when the rule matches.

  • <if_sid>5700</if_sid> specifies a dependency on another rule with ID 5700. The rule will only be evaluated if rule 5700 has matched previously.

  • <match>^Accepted|authenticated.$</match> matches any log entry that starts with "Accepted" or ends with "authenticated.".

  • <description>sshd: authentication success.</description> describes what the rule detects. In this case, it indicates a successful SSH authentication.

  • <group>authentication_success,pci_dss_10.2.5,</group> assigns the rule to the authentication_success and pci_dss_10.2.5 groups.

By default, the Wazuh server generates alerts for any rule with a level above 2. In this scenario, the log triggers an alert because the rule level is 3, and this will be visible on the Wazuh dashboard.

You can create custom decoders and rules to analyze logs not supported by default. To learn how to create custom rules and decoders, refer to the custom rules and the custom decoders documentation.