How to Install and Configure Wazuh SIEM on Linux Server: Security Monitoring and Vulnerability Detection - ITFROMZERO - Share tobe shared! A hands-on guide to self-hosting Wazuh SIEM on Linux Server. Enable real-time File Integrity Monitoring (FIM), automate CVE vulnerability scanning, and block brute-force IPs with Active Response.

Table of Contents

Server Logs: When Thousands of Lines Become a Maze

If you manage more than three to five Linux servers, you are probably no stranger to that heart-stopping feeling: CPU usage suddenly spikes to 100%, or worse, you wake up one morning to find an unfamiliar webshell sitting right in your web source code. Before centralized logging, I had to SSH into every single box, running grep and lastb until my eyes went blurry. Nowadays, a quick glance at the dashboard is all it takes to see the full picture.

Many system administrators often confuse performance monitoring with security monitoring. Prometheus or Grafana will tell you when CPU hits 99%, but they have no clue who is brute-forcing your SSH port. Nor can they tell you which user just modified /etc/shadow, or whether your OpenSSL package contains a critical CVE vulnerability. That is precisely when you need a true open-source SIEM/XDR solution: Wazuh.

Core Architecture: How Wazuh Diagnoses Your System

Simply put, Wazuh acts as a miniature Security Operations Center (SOC). The system consists of four tightly integrated components:

Wazuh Indexer: A search and indexing engine based on OpenSearch. It stores and indexes all alerts and security event logs, capable of processing thousands of events per second.
Wazuh Server (Manager): The central brain. It receives logs sent from agents, evaluates them against more than 4,000 built-in security rules, scans the CVE database, and triggers automated responses.
Wazuh Dashboard: The intuitive web user interface. This is where you visualize attack patterns mapped to the MITRE ATT&CK framework, search logs, and manage all your endpoints.
Wazuh Agent: A lightweight daemon (consuming around 30-50MB of RAM) installed directly on target endpoints (Linux, Windows, macOS, or Docker containers). The agent monitors system logs, file integrity, and processes, forwarding findings to the Manager via port 1514 with TLS encryption.

Step-by-Step Hands-On: Deploying a Wazuh All-in-One Cluster

1. Hardware Requirements and Environment Preparation

For small to medium infrastructures (under 50 agents), running the Manager, Indexer, and Dashboard together on a single server (All-in-One) is the most cost-effective approach. Recommended hardware specifications:

Operating System: Clean 64-bit installation of Ubuntu 22.04 LTS or Debian 12.
Recommended Specs: Minimum 4 vCPUs, 8GB RAM, and 50GB NVMe SSD storage. The Wazuh Indexer (JVM) alone requires a baseline 4GB heap allocation.
For Tight Memory (4GB – 6GB RAM): You must configure at least 4GB of swap space. Without swap, the kernel OOM-killer will terminate the Indexer process right after boot.

# Create an emergency 4GB swap file to prevent service crashes
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

2. Installing Wazuh All-in-One Using the Official Script

Installing OpenSearch packages and managing certificates manually can easily lead to configuration conflicts. The safest and cleanest approach is to use the vendor’s official installation script, which automatically generates internal TLS certificates for the cluster components:

# Download the latest installation script
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh

# Run the installation in All-in-One mode (-a)
sudo bash ./wazuh-install.sh -a

This process takes about 5 to 10 minutes. Once completed, the terminal will display the admin username along with a strong, randomly generated password. Make sure to save this password immediately. If you accidentally closed the terminal, you can extract it from the backup archive:

# Extract administrator credentials if not saved
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Open your browser and navigate to https://<Wazuh-Server-IP>. Accept the self-signed SSL certificate warning, then log in to the Dashboard.

3. Connecting Agents from Client Servers

With the server ready, it is time to connect your target servers back to the command center.

In the Dashboard, open the top-left menu > Server management > Endpoints Summary > click the Deploy new agent button.
Select the client operating system (e.g., Ubuntu/Debian) and enter the static IP address of your Wazuh Server.
The system generates a complete command snippet. Simply paste that command into your client server terminal:

# Download the GPG key and add the official repository
wget -qO - https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

# Install the agent and set the Manager IP (replace with your Wazuh Server IP)
sudo WAZUH_MANAGER='192.168.1.100' apt-get install wazuh-agent -y

# Start and enable the service
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

Refresh the Dashboard. The Endpoints status will switch to a green Active state in under 10 seconds.

4. Enabling File Integrity Monitoring (FIM): Tracking Every Line of Code

FIM is one of Wazuh’s most powerful features. It continuously monitors SHA256 checksums, permissions, and file content. If an attacker injects a backdoor into /var/www/ or tampers with /etc/passwd, an alert triggers immediately.

To configure it, open /var/ossec/etc/ossec.conf on the client machine and add your sensitive directories within the <syscheck> block:

<syscheck>
  <!-- Perform a full scan periodically every 6 hours -->
  <frequency>21600</frequency>
  
  <!-- Enable real-time monitoring and record granular diffs of file changes -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/var/www</directories>
  
  <!-- Exclude framework log and cache directories to avoid alert noise -->
  <ignore>/var/www/*/storage/logs</ignore>
  <ignore>/var/www/*/runtime/logs</ignore>
  <ignore>/var/www/*/var/cache</ignore>
</syscheck>

The report_changes="yes" option is exceptionally useful. It captures the exact line-by-line text differences just like a git diff right within the web UI. Remember to restart the agent to apply the changes:

# Restart the agent after updating the configuration
sudo systemctl restart wazuh-agent

5. Automated Vulnerability Detection (CVE Scanning)

Instead of manually tracking security bulletins, Wazuh Manager automatically cross-references installed packages on client machines against the National Vulnerability Database (NVD) as well as security advisories from Canonical, Debian, and Red Hat.

Starting with Wazuh 4.8, this module has been substantially optimized. On the Wazuh Server, open /var/ossec/etc/ossec.conf to confirm the feature is enabled:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Navigate to the Dashboard, select the corresponding agent, and switch to the Vulnerability tab. You will see a complete list of CVEs with their specific CVSS scores. With clear severity ratings from Low to Critical, you know exactly which packages require an immediate apt upgrade, eliminating any guesswork.

6. Hands-On Defense: Blocking Brute-Force IPs with Active Response

Observation alone is not enough—turn Wazuh into an automated defense shield. If an IP address fails SSH authentication 8 consecutive times (triggering rule ID 5712 or 5720), Wazuh Server will instruct the agent to drop that IP immediately via the local firewall.

On the Wazuh Server, add the following block to /var/ossec/etc/ossec.conf:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712, 5720</rules_id>
  <timeout>600</timeout> <!-- Temporarily block the IP for 10 minutes -->
</active-response>

Save the file and restart the server using sudo systemctl restart wazuh-manager. From this point on, automated botnet scans will be shut down at the network layer, freeing you from sleepless nights monitoring logs.

Operational Best Practices

Moving away from manual SSH sessions toward centralized monitoring is a major milestone for sysadmins and DevOps engineers. Wazuh delivers capabilities on par with expensive commercial SIEM solutions without costing a single dollar in licensing fees.

Once your setup runs smoothly, the next logical step is integrating Webhooks to forward alerts to Telegram or Slack. Make sure to filter for alerts of Level 10 and above. This way, you receive instant notifications on your phone whenever an incident occurs, rather than being glued to your computer screen.