30 Wazuh Interview Questions

Wazuh is a free, open-source security platform that provides unified XDR and SIEM capabilities for threat detection, visibility, and compliance monitoring.

Its main components are:

• Wazuh Agent: Software installed on endpoints to collect security data and forward it to the server.
• Wazuh Server: Analyzes data from agents using decoders and rules, and manages agent configuration.
• Wazuh Indexer: A search and analytics engine (OpenSearch) that stores and indexes all security data.
• Wazuh Dashboard: A web interface for visualizing data, managing alerts, and configuring the platform.

Wazuh Agent: Lightweight software installed on the monitored endpoint (server, laptop, cloud instance). Its job is to collect security events, log data, file integrity information, and configuration changes, then forward this data to the Wazuh Server for analysis.

Wazuh Server (formerly Manager): The central analysis server. It receives data from all agents, decodes it, and matches it against rules to detect security issues or compliance violations. It also manages agent configuration and can be deployed in a cluster for high availability.

Wazuh Indexer: A search and analytics engine (fork of OpenSearch). It receives processed alerts from the Wazuh Server, indexes them, and stores them. This enables fast searching, data visualization, and historical analysis through the Wazuh Dashboard.

Wazuh collects logs from endpoints primarily through the Logcollector module on the Wazuh agent. The agent monitors specified log files by reading new lines as they are written, and can also collect Windows Event Logs (both classic and event channels), systemd journald logs on Linux, and macOS Unified Logging. For devices that cannot host an agent, the Wazuh server can receive logs remotely via syslog. The agent can also execute commands periodically and treat their output as log data. All collected logs are formatted, optionally filtered, and forwarded to the Wazuh server for analysis.

The Wazuh API is a RESTful API that provides a secure and centralized interface to interact with the Wazuh server. Its primary role is to allow administrators and automation tools to manage and monitor the Wazuh infrastructure programmatically. It enables tasks such as querying agent status, managing configurations, retrieving statistics, updating rules and decoders, and initiating responses like active responses, all through HTTP requests instead of manual command-line access.

To install Wazuh on Ubuntu, first update your system with sudo apt update && sudo apt upgrade -y and ensure curl is installed. Download the installation assistant script using curl -sO https://packages.wazuh.com/4.8/wazuh-install.sh && sudo bash ./wazuh-install.sh -a. The installation will automatically set up the Wazuh manager, indexer, and dashboard. Once complete, the terminal will display the admin credentials. Access the Wazuh dashboard via https://<your-server-ip> and log in with the provided username and password.

To install and register a Wazuh agent on Windows, open PowerShell as an administrator. Download the agent installer using:

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.2-1.msi -OutFile ${env:tmp}\wazuh-agent.msi

Install and register the agent with your Wazuh server IP:

msiexec.exe /i ${env:tmp}\wazuh-agent.msi /q WAZUH_MANAGER='YOUR_MANAGER_IP' WAZUH_REGISTRATION_SERVER='YOUR_MANAGER_IP'

Once installation completes, start the agent service:

NET START WazuhSvc

The agent will now connect to your Wazuh server and begin sending data.

The ossec.conf file is the main configuration file for the Wazuh agent. It defines how the agent operates, what data it collects, and how it communicates with the Wazuh server. Key purposes include specifying which log files to monitor, setting scan intervals for file integrity monitoring, configuring active response actions, defining the Wazuh server address for connection, and enabling or disabling modules like rootcheck and syscheck. Located at C:\Program Files (x86)\ossec-agent\ossec.conf on Windows and /var/ossec/etc/ossec.conf on Linux, any changes require restarting the agent to take effect.

Wazuh performs File Integrity Monitoring (FIM) through its Syscheck module. It monitors specified files and directories by periodically scanning them, calculating cryptographic hashes (SHA-1 or SHA-256), and storing baseline values. When files are created, modified, or deleted, Syscheck detects the change, recalculates the hashes, and sends an alert to the Wazuh server. It supports real-time monitoring using inotify (Linux) or ReadDirectoryChangesW (Windows), as well as scheduled scans, and tracks file attributes like permissions, ownership, and metadata.

Syscheck is the Wazuh agent module responsible for File Integrity Monitoring (FIM) . It scans files and directories, detects any changes to files, permissions, or hashes, and sends alerts to the Wazuh server.

Wazuh detects rootkits using its Rootcheck module. It performs system scans to identify anomalies and known rootkit signatures. Rootcheck detects hidden processes, files, and ports by comparing system calls against standard binaries. It checks the /dev directory for suspicious files, uses signature databases to identify known rootkits and trojaned binaries, and scans for unusual file permissions or network interfaces in promiscuous mode. When rootkit activity is found, alerts are generated and sent to the Wazuh server.

Decoders parse raw logs and extract relevant fields (like timestamp, IP, username) to make the data structured and readable for the Wazuh rules engine.

Rules in Wazuh are logical conditions that define which security events generate alerts. They are written in XML and structured hierarchically, grouped by rule ID and description. Each rule contains fields like level (severity 0-15), if_sid (to link with parent rules), and matching conditions such as match, regex, or field to identify specific log patterns. When an event matches a rule, it triggers an alert with the assigned severity level.

To create a custom rule in Wazuh:

1. Navigate to the rules directory: /var/ossec/etc/rules/ on the server
2. Create a new XML file, e.g., local_rules.xml
3. Define the rule using syntax:

   <rule id="100001" level="5">
     <if_sid>5710</if_sid>
     <match>failed password</match>
     <description>Custom failed login alert</description>
   </rule>

4. Use a rule ID above 100000 to avoid conflicts with default rules
5. Save the file and restart the Wazuh manager:

   systemctl restart wazuh-manager

The new rule will now be applied to incoming events.

Default rules are pre-installed Wazuh rule files (like 0005-ssh_rules.xml) that cover common security events, with rule IDs ranging from 1 to 99999. These are overwritten during updates and should not be modified directly.

local_rules.xml is a user-defined file specifically designed for custom rules without modifying default files. It uses rule IDs starting from 100000 to prevent conflicts. Custom rules here survive upgrades and override or supplement default rules when linked using if_sid.

Wazuh integrates with Elastic Stack or OpenSearch by forwarding security alerts and events for indexing, storage, and visualization. The Wazuh server uses Filebeat to send alerts directly to Elasticsearch or OpenSearch. Logstash can also be used to process data from the alerts file. Once indexed, Kibana or OpenSearch Dashboards provide visualization through the Wazuh plugin, which embeds management interfaces and security dashboards. Data is stored in indices like wazuh-alerts-*.

The Wazuh Indexer is a scalable search and analytics engine based on OpenSearch that stores and indexes all security data generated by Wazuh. It receives processed alerts and events from the Wazuh server and organizes them into indices, primarily using the wazuh-alerts-* index pattern. Each alert is stored as a JSON document, enabling full-text search, real-time analysis, and historical data retrieval. The indexer supports horizontal scaling through clustering, ensuring high availability and performance for large deployments.

To configure email alerts in Wazuh, edit the /var/ossec/etc/ossec.conf file on the Wazuh manager. In the <global> section, enable email notifications and specify the SMTP server, sender, and recipient addresses. In the <alerts> section, set <email_alert_level> to the minimum rule level that triggers an email. Save the file and restart the Wazuh manager using systemctl restart wazuh-manager.

Active Response is a Wazuh module that automatically executes predefined actions when specific security alerts are triggered. It enables real-time threat mitigation by running scripts or commands on the affected endpoint. Common responses include blocking an IP address with firewall rules, disabling a user account, or killing malicious processes. Active Response can be configured on both the Wazuh server and agents, with commands defined in the ossec.conf file.

To configure Active Response to block an IP address in Wazuh:

1. Verify that the firewall-drop command exists in /var/ossec/active-response/bin/ on the agent.
2. Edit the Wazuh manager configuration file /var/ossec/etc/ossec.conf and add an active-response block:

   <active-response>
     <command>firewall-drop</command>
     <location>local</location>
     <rules_id>5710</rules_id>
     <timeout>100</timeout>
   </active-response>

3. Restart the Wazuh manager:

   systemctl restart wazuh-manager

When triggered, the script adds an iptables rule to block traffic from the offending IP.

Wazuh supports compliance requirements like PCI-DSS by providing built-in rules, reports, and dashboards aligned with specific mandates. It maps security events to PCI-DSS requirements, such as file integrity monitoring for Requirement 11, log management and analysis for Requirement 10, and vulnerability detection for Requirement 6. The Wazuh dashboard includes pre-configured compliance panels that display relevant alerts and controls. It also generates compliance reports and enables continuous monitoring of systems to meet audit and security standards.

To monitor log files in Wazuh, configure the agent’s ossec.conf file by adding <localfile> entries specifying the log file path and format, then restart the agent service.

Agent grouping in Wazuh is a feature that allows you to organize agents into logical groups based on function, operating system, environment, or any custom criteria. Groups enable centralized and efficient configuration management by applying the same settings, rules, and policies to all agents within a group. When you update a group configuration, all agents belonging to that group automatically receive the changes without needing individual configuration. This simplifies administration and ensures consistency across similar endpoints.

To troubleshoot a disconnected Wazuh agent:

• Verify the agent service is running: systemctl status wazuh-agent (Linux) or check Services (Windows)
• Confirm network connectivity from agent to manager: telnet <manager_ip> 1514 or 1515
• Check agent logs at /var/ossec/logs/ossec.log (Linux) or C:\Program Files (x86)\ossec-agent\ossec.log (Windows)
• Verify the manager IP is correctly set in the agent’s ossec.conf
• Confirm agent is registered: sudo /var/ossec/bin/agent_control -l on the manager
• Restart both agent and manager services
• Check manager logs at /var/ossec/logs/ossec.log for connection errors
• Ensure firewall allows TCP/UDP on ports 1514 and 1515

The ports required for communication between Wazuh components are:

• 1514 / TCP or UDP: Used for agent to manager communication, sending events and alerts. TCP is recommended for reliable delivery, UDP for lower overhead.
• 1515 / TCP: Used for agent enrollment and registration with the manager.
• 1516 / TCP: Used for manager cluster communication between master and worker nodes.
• 55000 / TCP (or custom): Used for the Wazuh API on the manager.
• 9200 / TCP: Used for communication between the manager (via Filebeat) and the Wazuh Indexer.
• 443 / TCP: Used for accessing the Wazuh Dashboard web interface.

Wazuh performs vulnerability detection by collecting system inventory data (OS and installed applications) from agents using the Syscollector module. The Wazuh server then correlates this data with a continuously updated vulnerability feed from the Wazuh Cyber Threat Intelligence platform, which aggregates CVE information from sources like vendor security feeds and the NVD. When a match is found between an installed software version and a known vulnerability, the server generates an alert. Results are displayed in the Wazuh dashboard with severity levels and affected package details.

Centralized configuration is managed from the Wazuh server and pushed to agents in bulk. It allows you to define settings in shared agent groups (e.g., Windows, Linux), ensuring consistency across multiple endpoints without manual intervention on each agent.

Local configuration is defined directly in each agent’s ossec.conf file. It overrides centralized settings for that specific agent, giving granular control when an individual endpoint requires unique configurations different from its group.

• Use pre-shared keys (default): During agent enrollment, a unique SSL key is generated and shared, encrypting all traffic between agent and manager.
• Configure TLS 1.2 or higher: Ensure both manager and agents are configured to use strong TLS protocols and ciphers.
• Enable agent authentication: Agents must authenticate using their key before joining, preventing unauthorized connections.
• Restrict enrollment: Limit agent registration to known IPs or use enrollment passwords.
• Use TCP instead of UDP: TCP provides reliable, connection-oriented communication with better security.
• Network segmentation: Isolate Wazuh traffic on a dedicated management network.
• Firewall rules: Restrict access to manager ports (1514, 1515) only to trusted agent IPs.
• Regular key rotation: Periodically regenerate agent keys to limit exposure.

• Back up configuration files and critical data before starting.
• Check the release notes for breaking changes and upgrade order requirements.
• Upgrade the Wazuh manager first, then agents, indexer, and dashboard.
• Use the official upgrade assistant script when available: wazuh-install.sh -u.
• Test in a staging environment before production.
• Upgrade agents gradually using centralized agent upgrades from the Wazuh dashboard or manually in batches.
• Verify functionality after each component upgrade before proceeding.

Wazuh integrates with other SIEM platforms primarily through its Integrator module, which forwards alerts to external systems. It uses RESTful API communication, allowing third-party platforms to query security data and manage agents programmatically. Wazuh supports log forwarding via Syslog or Filebeat to send security events to external SIEMs for correlation. For SOAR integration, it connects with platforms like Shuffle and TheHive to automate incident response workflows. Wazuh also supports custom integrations through Python scripts for services like MISP for threat intelligence correlation, and provides pre-built connectors for cloud platforms and ticketing systems. These methods enable bidirectional data exchange, alert enrichment, and centralized security monitoring across heterogeneous environments.

• Use agentless where possible to reduce agent overhead on endpoints.
• Limit log sources monitored by each agent to essential files only.
• Adjust scan intervals for FIM and vulnerability detection to balance frequency and load.
• Tune rule levels to suppress low-severity or noisy alerts.
• Cluster the Wazuh manager for horizontal scaling and load distribution.
• Optimize database settings for the Wazuh indexer, including shard allocation and refresh intervals.
• Increase system resources (CPU, RAM, disk I/O) for indexer and manager nodes.
• Use compression in Filebeat to reduce network bandwidth.
• Implement log rotation and retention policies to manage disk space.
• Monitor performance metrics and adjust configurations based on observed bottlenecks.