Wazuh 4.10: Panduan SIEM & HIDS Open Source untuk Linux Server (2026)

Diperbarui: 25 Agustus 2026

Wazuh adalah platform SIEM (Security Information and Event Management) dan HIDS (Host-based Intrusion Detection System) open source yang menyatukan deteksi ancaman, analisis log, monitoring integritas file, penilaian kerentanan, dan respons otomatis dalam satu stack. Untuk administrator Linux dan tim DevSecOps di 2026, Wazuh 4.10 memberikan alternatif tanpa biaya lisensi terhadap Splunk atau QRadar, dengan agen ringan yang dapat dipasang di server, workstation, container, dan node Kubernetes. Panduan ini membahas arsitektur, instalasi, konfigurasi rule, deteksi CVE, monitoring FIM, integrasi MITRE ATT&CK, dan best practice hardening produksi.

• Wazuh 4.10 (rilis Juli 2026) terdiri dari tiga komponen inti: Wazuh Manager, Wazuh Indexer (fork OpenSearch), dan Wazuh Dashboard, serta agen multiplatform untuk Linux, Windows, dan macOS.
• Instalasi tercepat menggunakan skrip wazuh-install.sh all-in-one. Pemasangan produksi harus dipisah per node dengan sertifikat TLS yang dihasilkan melalui wazuh-certs-tool.sh.
• Modul utama meliputi File Integrity Monitoring (syscheck), Rootcheck, Log Data Analysis, Vulnerability Detection berbasis CVE feed, Security Configuration Assessment (SCA) berdasarkan CIS Benchmark, dan Active Response.
• Wazuh memetakan alert ke framework MITRE ATT&CK v15 secara otomatis, memudahkan analis SOC memahami taktik dan teknik penyerang tanpa lookup manual.
• Setiap manager berdiri menangani sekitar 25.000 agen. Skala di atas itu memerlukan cluster manager dan indexer multi-node dengan sharding.
• Wazuh sepenuhnya gratis dan open source di bawah lisensi AGPLv3, tanpa fitur berbayar tersembunyi seperti pada versi Enterprise vendor lain.

Apa itu Wazuh dan bagaimana cara kerjanya?

Jujur saja, ketika pertama kali menyentuh Wazuh di project SOC internal beberapa tahun lalu, saya sempat skeptis: apa mungkin sesuatu yang gratis benar-benar sekelas platform enterprise? Ternyata, ya. Wazuh adalah platform keamanan open source unified yang menggabungkan kapabilitas XDR (Extended Detection and Response) dan SIEM untuk melindungi endpoint, workload cloud, dan container. Proyek ini bermula sebagai fork dari OSSEC pada 2015 dan berevolusi menjadi platform mandiri yang mengintegrasikan indexer berbasis OpenSearch, dashboard berbasis Kibana yang dimodifikasi, serta engine korelasi rule sendiri.

Pada 2026, versi mayor 4.10 memperkenalkan agent yang lebih hemat memori (rata-rata <40MB RAM), Vulnerability Detection dengan CVE 2024–2026 feed dari NVD dan Canonical, serta integrasi native dengan MITRE ATT&CK v15.

Cara kerjanya sederhana: agent yang dipasang di setiap host mengumpulkan log, memeriksa integritas file, memindai konfigurasi, dan mendeteksi rootkit, lalu mengirimkan data ke Wazuh Manager melalui port 1514/TCP (dienkripsi AES-256 dengan Blowfish-CBC secara default). Manager memproses data melalui ribuan decoder dan rule, mengklasifikasikan event menurut severity (0–15), dan mengirim alert ke Wazuh Indexer untuk penyimpanan dan pencarian. Dashboard menyajikan visualisasi real-time dengan filter untuk hunting ancaman, kepatuhan (PCI DSS, HIPAA, GDPR, NIST 800-53), dan investigasi forensik.

Berbeda dengan solusi log aggregation murni seperti Graylog, Wazuh menyediakan security content siap pakai. Ada sekitar 3.000 rule bawaan, aturan decoders untuk sistemd, sshd, sudo, kernel audit, Docker, Kubernetes, Nginx, Apache, MySQL, PostgreSQL, dan lebih dari 100 layanan lain. Ini membuat time-to-value jauh lebih pendek daripada membangun rule korelasi dari nol.

Arsitektur Wazuh 4.10: Manager, Indexer, Dashboard, Agent

Stack Wazuh 4.10 terdiri dari empat komponen utama yang dapat dijalankan pada satu server (all-in-one) atau didistribusikan untuk skala produksi. Memahami peran masing-masing itu penting sebelum menentukan topologi deployment Anda.

Wazuh Manager

Otak dari sistem. Menerima data dari agen, menjalankan analisis, menghasilkan alert, dan mengorkestrasi Active Response. Manager dapat berjalan sebagai master atau worker dalam mode cluster untuk load balancing. Layanan utamanya adalah wazuh-manager.service yang mengelola daemon internal seperti wazuh-analysisd, wazuh-remoted, wazuh-monitord, dan wazuh-modulesd.

Wazuh Indexer

Fork dari OpenSearch 2.x yang menyimpan alert dan data telemetri dalam indeks berbasis waktu (wazuh-alerts-4.x-YYYY.MM.DD). Indexer menyediakan API REST untuk query dan mendukung sharding, replikasi, serta Index State Management untuk retention otomatis. Untuk deployment kecil (<500 agent), satu node cukup. Untuk enterprise gunakan tiga node atau lebih dengan quorum split-brain protection.

Wazuh Dashboard

Fork dari OpenSearch Dashboards dengan plugin Wazuh yang menambahkan modul spesifik seperti Threat Hunting, Vulnerability Detection, MITRE ATT&CK, Regulatory Compliance, dan Configuration Assessment. Dashboard berkomunikasi dengan Wazuh Manager API (port 55000/TCP) untuk manajemen agent dan dengan Indexer (port 9200/TCP) untuk query data.

Wazuh Agent

Software ringan berbasis C yang berjalan sebagai wazuh-agent.service. Konsumsi resource-nya rendah: sekitar 30–50MB RAM dan <1% CPU pada kondisi normal. Agent tersedia untuk Linux (RPM, DEB, tarball), Windows, macOS, AIX, dan Solaris. Untuk container, tersedia image resmi wazuh/wazuh-agent yang dapat dijalankan sebagai DaemonSet di Kubernetes.

Cara install Wazuh di Ubuntu 24.04 dan Rocky Linux 9

Untuk lab, PoC, atau deployment kecil (<100 agent), skrip all-in-one resmi adalah cara tercepat. Skrip ini menginstal Manager, Indexer, dan Dashboard pada satu server dengan sertifikat self-signed. Persyaratan minimum: 4 vCPU, 8GB RAM, 50GB storage SSD, dan Ubuntu 22.04/24.04, Debian 12, Rocky/AlmaLinux 8/9, atau Amazon Linux 2023.

# 1. Unduh skrip installer resmi (verifikasi checksum di documentation.wazuh.com)
curl -sO https://packages.wazuh.com/4.10/wazuh-install.sh

# 2. Jalankan instalasi all-in-one dengan opsi -a (all)
sudo bash ./wazuh-install.sh -a

# 3. Skrip akan menampilkan kredensial admin di akhir instalasi.
# Simpan file wazuh-install-files.tar yang berisi passwords.txt dan sertifikat.
# Contoh output:
# --- Summary ---
# You can access the web interface https://<wazuh-dashboard-ip>
# User: admin
# Password: <RANDOM_STRING>

# 4. Buka firewall untuk port yang diperlukan
sudo ufw allow 443/tcp   # Dashboard HTTPS
sudo ufw allow 1514/tcp  # Agent enrollment & data
sudo ufw allow 1515/tcp  # Agent registration
sudo ufw allow 55000/tcp # Manager API

Untuk deployment produksi, jangan gunakan mode all-in-one. Pisahkan node dan buat sertifikat khusus untuk setiap komponen. Alur produksi resmi menggunakan wazuh-certs-tool.sh dengan file config.yml yang mendefinisikan hostname dan IP setiap node, sehingga TLS mutual authentication bekerja lintas node.

# Contoh config.yml untuk cluster tiga node
nodes:
  indexer:
    - name: node-1
      ip: 10.0.1.10
    - name: node-2
      ip: 10.0.1.11
    - name: node-3
      ip: 10.0.1.12
  server:
    - name: master
      ip: 10.0.1.20
      node_type: master
    - name: worker-1
      ip: 10.0.1.21
      node_type: worker
  dashboard:
    - name: dashboard
      ip: 10.0.1.30

# Generate seluruh set sertifikat
sudo bash ./wazuh-certs-tool.sh --all

Deploy Wazuh Agent ke Linux server dan container

Setelah manager berjalan, langkah berikutnya adalah mendaftarkan agent. Pada 2026, metode yang direkomendasikan adalah agent enrollment otomatis menggunakan password bersama, yang mengeliminasi kebutuhan mendaftarkan setiap host secara manual di manager. Pendekatan ini cocok untuk Infrastructure as Code menggunakan Ansible, Terraform, atau Puppet.

# Instalasi agent di Ubuntu 24.04 dengan enrollment otomatis
WAZUH_MANAGER="10.0.1.20" \
WAZUH_AGENT_GROUP="linux-servers" \
apt-get install wazuh-agent

# Enable dan start service
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

# Verifikasi status koneksi
systemctl status wazuh-agent
tail -f /var/ossec/logs/ossec.log | grep -i "connected"

Untuk deployment massal di infrastruktur cloud, gunakan cloud-init atau user data script. Contoh berikut mendaftarkan agent secara idempoten dan mengatur label agent berdasarkan tag instance:

#!/bin/bash
# Cloud-init snippet untuk AWS EC2 (Ubuntu 24.04)
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.10.0-1_amd64.deb
WAZUH_MANAGER="wazuh.internal.corp" \
WAZUH_REGISTRATION_SERVER="wazuh.internal.corp" \
WAZUH_REGISTRATION_PASSWORD="$(aws ssm get-parameter --name /wazuh/enrollment --with-decryption --query Parameter.Value --output text)" \
WAZUH_AGENT_GROUP="prod,web" \
WAZUH_AGENT_NAME="$(hostname -f)" \
dpkg -i ./wazuh-agent_4.10.0-1_amd64.deb

systemctl enable --now wazuh-agent

Untuk container security, jangan pasang agent di dalam container aplikasi. Sebaliknya, gunakan pola host-agent: pasang Wazuh Agent di host Docker atau di node Kubernetes sebagai DaemonSet dengan akses ke /proc, /var/run/docker.sock, dan runtime socket. Ini memberikan visibilitas ke seluruh workload tanpa membebani setiap container. Untuk visibilitas lebih dalam ke perilaku container, kombinasikan Wazuh dengan Falco untuk runtime security container Kubernetes yang menggunakan eBPF untuk deteksi syscall.

Konfigurasi File Integrity Monitoring (FIM)

File Integrity Monitoring (FIM), atau syscheck dalam istilah Wazuh, adalah salah satu fitur paling berharga untuk deteksi kompromi dan kepatuhan PCI DSS Requirement 11.5. Modul ini menghitung hash MD5, SHA-1, dan SHA-256 dari file yang dipantau, menyimpan baseline, lalu menghasilkan alert setiap kali terjadi perubahan pada isi, permission, ownership, atau atribut extended attributes.

Konfigurasi FIM ada di /var/ossec/etc/ossec.conf pada agent (atau via agent.conf yang dipush dari manager). Berikut konfigurasi realistis untuk server web Linux yang memantau direktori sistem kritis dengan mode real-time menggunakan inotify:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency> <!-- Scan penuh setiap 12 jam -->

  <!-- Pantau file konfigurasi sistem secara real-time -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes" check_all="yes">/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes">/bin,/sbin</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/root/.ssh</directories>

  <!-- Whodata (audit-based) untuk melacak siapa yang mengubah file -->
  <directories whodata="yes" check_all="yes">/var/www/html</directories>

  <!-- Kecualikan file yang berisik -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore type="sregex">\.log$|\.swp$</ignore>

  <nodiff>/etc/ssl/private.key</nodiff>
</syscheck>

Mode whodata="yes" memanfaatkan Linux Audit Framework untuk mencatat proses, user, dan PID yang melakukan perubahan (bukan hanya apa yang berubah, tetapi siapa). Kalau Anda sudah men-deploy auditd sebagai Linux Audit Framework, whodata memanfaatkan infrastruktur yang sama tanpa konflik. Restart agent setelah perubahan config: systemctl restart wazuh-agent.

Vulnerability Detection dan CVE feed 2026

Wazuh 4.10 mengganti modul Vulnerability Detector legacy dengan mesin baru bernama Vulnerability Detection yang jauh lebih efisien dan akurat. Modul ini bekerja dengan mengumpulkan inventori paket dari setiap agent (via syscollector), lalu mencocokkan versi paket dengan CVE feed dari Canonical, Debian Security Tracker, Red Hat Security Data API, dan NVD (National Vulnerability Database). Pendekatannya mirip dengan cara Trivy memindai kerentanan container Docker, hanya saja Wazuh menerapkannya pada host yang sedang berjalan.

Untuk mengaktifkan pada Wazuh 4.10, edit /var/ossec/etc/ossec.conf di manager:

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

<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://10.0.1.10:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/wazuh-indexer/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/wazuh-indexer/certs/admin.pem</certificate>
    <key>/etc/wazuh-indexer/certs/admin-key.pem</key>
  </ssl>
</indexer>

Setelah aktif, alur kerjanya begini: agent mengirim daftar paket, manager mencocokkan dengan feed, lalu hasil disimpan sebagai state di indeks wazuh-states-vulnerabilities-*. Anda dapat memfilter berdasarkan CVSS score, severity, atau CVE ID di modul Vulnerability Detection di dashboard. Query API contoh untuk mengambil semua CVE Critical:

# Ambil token JWT
TOKEN=$(curl -sk -u admin:password -X POST "https://localhost:55000/security/user/authenticate" | jq -r .data.token)

# Query semua kerentanan Critical di agent 001
curl -sk -H "Authorization: Bearer $TOKEN" \
  "https://localhost:55000/vulnerability/001?severity=critical&pretty=true" | jq '.'

Menulis custom rules dan decoders

Meskipun Wazuh menyediakan ribuan rule bawaan, hampir setiap organisasi perlu menulis custom rules untuk aplikasi internal atau untuk menekan false positive. Rule ditulis dalam XML dan disimpan di /var/ossec/etc/rules/local_rules.xml, sementara decoder di /var/ossec/etc/decoders/local_decoder.xml. Jangan pernah mengedit file rule bawaan di /var/ossec/ruleset/ karena akan tertimpa saat upgrade. Ini pelajaran mahal yang biasanya cuma diajarkan satu kali.

Contoh: mendeteksi login berhasil ke aplikasi web internal setelah beberapa kegagalan berturut-turut (pola brute force yang sukses menembus):

<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<decoder name="myapp-auth">
  <program_name>myapp</program_name>
</decoder>

<decoder name="myapp-auth-fail">
  <parent>myapp-auth</parent>
  <regex>LOGIN_FAILED user=(\S+) ip=(\S+)</regex>
  <order>user, srcip</order>
</decoder>

<decoder name="myapp-auth-ok">
  <parent>myapp-auth</parent>
  <regex>LOGIN_OK user=(\S+) ip=(\S+)</regex>
  <order>user, srcip</order>
</decoder>

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="myapp,authentication_failed,">

  <rule id="100200" level="5">
    <decoded_as>myapp-auth-fail</decoded_as>
    <description>MyApp: Login gagal untuk user $(user) dari $(srcip)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

  <rule id="100201" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100200</if_matched_sid>
    <same_source_ip />
    <description>MyApp: Brute force terdeteksi dari $(srcip)</description>
    <group>authentication_failures,pci_dss_10.2.4,</group>
  </rule>

  <rule id="100202" level="12">
    <if_matched_sid>100201</if_matched_sid>
    <if_sid>100200</if_sid>
    <description>MyApp: Brute force BERHASIL, login OK setelah percobaan gagal berulang</description>
    <group>authentication_success_after_bruteforce,</group>
  </rule>

</group>

Active Response: memblokir IP secara otomatis

Active Response memungkinkan Wazuh mengeksekusi skrip pada agent atau manager sebagai respons terhadap alert. Use case paling umum adalah memblokir IP penyerang di firewall setelah rule brute force terpicu. Wazuh menyertakan beberapa skrip built-in seperti firewall-drop (menggunakan iptables/nftables/firewalld) dan host-deny (menambahkan ke /etc/hosts.deny).

<!-- Di ossec.conf manager -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763,100201,100202</rules_id>
  <timeout>1800</timeout> <!-- Blokir selama 30 menit -->
</active-response>

Konfigurasi di atas akan memblokir IP sumber selama 30 menit setiap kali rule 5763 (SSH brute force built-in), 100201, atau 100202 (custom rules kita di atas) terpicu. Setelah timeout, aturan firewall otomatis dihapus. Untuk lingkungan produksi, pertimbangkan whitelist IP internal (VPN, subnet manajemen, load balancer) via file /var/ossec/etc/lists/ agar tidak ada risiko memblokir IP legitimate. Saya pernah tidak sengaja memblokir subnet load balancer karena lupa whitelist, dan itu kejadian yang tidak ingin Anda ulangi pada Jumat sore.

Pemetaan MITRE ATT&CK dan compliance

Sejak versi 4.3, Wazuh menyertakan pemetaan native ke framework MITRE ATT&CK. Setiap rule yang relevan diberi tag dengan technique ID (misalnya T1110 untuk Brute Force, T1053 untuk Scheduled Task, T1078 untuk Valid Accounts). Modul MITRE ATT&CK di dashboard menyajikan matriks navigator yang menyoroti technique yang aktif terdeteksi di environment Anda, memudahkan gap analysis coverage detection.

Wazuh juga menyertakan template compliance untuk PCI DSS v4.0, HIPAA, NIST 800-53 Rev.5, GDPR, TSC (Trust Services Criteria), dan GPG13. Setiap rule dapat memiliki tag compliance yang secara otomatis muncul di dashboard Regulatory Compliance. Ini melengkapi audit CIS Benchmark dengan Lynis dengan menambahkan continuous monitoring di atas point-in-time assessment.

Modul Security Configuration Assessment (SCA) menjalankan cek konfigurasi berbasis policy YAML mirip Lynis, tetapi dengan hasil terintegrasi ke Wazuh Indexer. Policy default meliputi CIS Benchmark untuk Ubuntu 20.04/22.04/24.04, RHEL 8/9, Debian 12, dan Docker CE. Skor kepatuhan agent muncul otomatis di halaman detail agent.

Wazuh vs OSSEC vs Splunk vs Elastic Security

Wazuh sering dibandingkan dengan OSSEC (nenek moyangnya), Splunk Enterprise Security, dan Elastic Security. Tabel berikut merangkum perbedaan utama untuk membantu Anda memilih yang tepat:

Kriteria	Wazuh 4.10	OSSEC 3.7	Splunk ES	Elastic Security
Lisensi	AGPLv3 (gratis)	GPLv2 (gratis)	Komersial	Elastic License (freemium)
Biaya tahunan (100 host)	$0	$0	~$50k+	$0–$25k
SIEM built-in	Ya	Tidak	Ya	Ya
Vulnerability Detection	Ya (built-in)	Tidak	Add-on	Terbatas
Dashboard	OpenSearch fork	Analogi (3rd party)	Splunk Web	Kibana
MITRE ATT&CK mapping	Native	Tidak	Ya	Ya
Cluster support	Ya	Terbatas	Ya	Ya
Cloud-native (K8s DaemonSet)	Ya	Terbatas	Ya	Ya

Singkatnya: Wazuh unggul untuk tim yang butuh SIEM+HIDS+Vuln Detection tanpa biaya lisensi, dengan community yang aktif. OSSEC cocok untuk deployment super-minimalis tanpa dashboard. Splunk masih menjadi standar enterprise untuk tim dengan budget besar. Elastic Security cocok kalau Anda sudah menggunakan ELK stack untuk observability.

Hardening deployment Wazuh untuk produksi

Setelah Wazuh berjalan, jangan berhenti di konfigurasi default. Berikut checklist hardening produksi yang telah kami terapkan di deployment multi-tenant dengan ribuan agent:

• Rotasi kredensial: Ganti password admin, kibanaserver, dan seluruh internal-users setiap 90 hari dengan wazuh-passwords-tool.sh. Simpan di HashiCorp Vault atau AWS Secrets Manager, bukan di file cleartext.
• Sertifikat TLS proper: Ganti sertifikat self-signed dari installer dengan sertifikat dari internal CA atau Let's Encrypt (jika dashboard exposed). Set periodic reminder untuk renewal.
• Segmentasi jaringan: Tempatkan Wazuh di VLAN manajemen terpisah. Jangan pernah expose port 55000 (API) atau 9200 (indexer) ke internet. Hanya port 443 dashboard yang boleh, itu pun di belakang reverse proxy dengan authentication tambahan.
• Backup rutin: Snapshot indeks OpenSearch harian ke S3 atau MinIO menggunakan Snapshot Lifecycle Management (SLM). Backup juga /var/ossec/etc/ dari manager untuk melindungi custom rules dan config.
• Log retention: Konfigurasi ISM (Index State Management) untuk memindahkan alert lebih tua dari 30 hari ke warm/cold tier dan menghapus setelah 1 tahun (atau sesuai kebijakan compliance Anda).
• Health monitoring: Pantau health Wazuh sendiri dengan Prometheus + Grafana menggunakan Wazuh Prometheus Exporter. Alert jika queue penuh, disk usage >80%, atau agent status disconnected massal.
• Update rutin: Ikuti GitHub release page Wazuh untuk patch security. Wazuh 4.10 memiliki EOL sekitar Q3 2027, jadi upgrade path perlu direncanakan.

Untuk dokumentasi resmi terkini, konsultasikan Wazuh Official Documentation yang selalu memiliki referensi rule ID, konfigurasi ossec.conf lengkap, dan panduan troubleshooting per komponen.

Pertanyaan yang Sering Diajukan

Apakah Wazuh benar-benar gratis untuk penggunaan komersial?

Ya. Wazuh dilisensikan di bawah AGPLv3 dan sepenuhnya open source, termasuk untuk penggunaan komersial. Tidak ada versi Enterprise berbayar dengan fitur tersembunyi. Wazuh Inc. menawarkan support berbayar dan managed cloud (Wazuh Cloud), tetapi seluruh fitur produk tersedia di versi self-hosted.

Apa perbedaan utama Wazuh dan OSSEC?

Wazuh dimulai sebagai fork OSSEC pada 2015 dan telah berkembang jauh melampaui aslinya. Perbedaan utama: Wazuh menyertakan indexer dan dashboard native (OSSEC tidak), Vulnerability Detection built-in, integrasi MITRE ATT&CK, cloud-native deployment (Kubernetes DaemonSet), API REST modern, dan release cadence aktif. OSSEC 3.7 masih dimaintain tetapi dengan fitur set jauh lebih terbatas.

Berapa banyak agent yang dapat ditangani satu Wazuh Manager?

Satu Wazuh Manager standalone dengan spesifikasi 8 vCPU dan 16GB RAM dapat menangani sekitar 15.000 sampai 25.000 agent, tergantung volume event per detik (EPS). Untuk skala lebih besar, gunakan cluster manager mode master-worker dan indexer multi-node dengan sharding. Deployment enterprise dengan >100k agent umumnya menggunakan 3 sampai 5 worker manager dan cluster indexer 5+ node.

Apakah Wazuh dapat menggantikan antivirus tradisional?

Tidak sepenuhnya. Wazuh unggul dalam deteksi berbasis perilaku dan log (HIDS), FIM, vulnerability assessment, dan analisis konfigurasi, tetapi tidak melakukan real-time malware scanning berbasis signature seperti ClamAV atau EDR komersial. Best practice adalah menjalankan Wazuh berdampingan dengan solusi antivirus atau EDR. Wazuh dapat mengintegrasikan alert dari ClamAV, VirusTotal, dan YARA rules untuk memperkaya deteksi.

Bagaimana cara mengintegrasikan Wazuh dengan Slack atau email untuk alert?

Wazuh mendukung integrasi Slack, PagerDuty, Jira, dan webhook generik melalui blok <integration> di ossec.conf manager. Untuk email, konfigurasi blok <global> dengan SMTP server, dan gunakan tag <email_alerts> untuk menentukan level severity yang memicu notifikasi. Filter dengan <email_alerts> per rule group untuk menghindari alert fatigue: hanya level 10+ yang sebaiknya dikirim via email.

Apakah aman men-deploy Wazuh Agent di container produksi?

Untuk container aplikasi (misalnya container web app), tidak direkomendasikan. Ini akan membebani image dan melanggar prinsip single-process container. Pendekatan yang tepat adalah men-deploy agent di host node Docker/Kubernetes sebagai DaemonSet dengan volume mount ke socket runtime. Dengan cara ini satu agent per node memantau semua container di atasnya, sekaligus memberikan visibilitas host-level yang tidak bisa didapat dari dalam container.