Wazuh sering dipasang karena terlihat seperti solusi yang lengkap: agent di endpoint, server untuk analisis, indexer untuk menyimpan alert, dan dashboard untuk membaca hasilnya. Masalah biasanya muncul setelah instalasi selesai. Dashboard penuh warna, tetapi tim belum tahu alert mana yang harus ditindaklanjuti, siapa yang menerima notifikasi, dan berapa lama data akan disimpan.
Wazuh bukan pengganti proses incident response. Ia adalah sensor, mesin korelasi, dan tempat kerja untuk investigasi. Nilainya baru terlihat ketika deployment, aturan deteksi, retensi data, dan jalur eskalasi dirancang sebagai satu sistem.
Wazuh sebenarnya menyelesaikan masalah apa?
Wazuh mengumpulkan telemetri dari server, workstation, cloud instance, container, dan sumber log tertentu melalui agent atau integrasi agentless. Data itu dianalisis oleh Wazuh server, dikirim ke Wazuh indexer, lalu dibaca melalui Wazuh dashboard. Arsitektur resminya membedakan tiga komponen pusat tersebut dari agent yang berjalan di endpoint.
Kapabilitas yang umum dipakai meliputi security event analysis, file integrity monitoring, vulnerability detection, system inventory, configuration assessment, malware detection, dan active response. Daftar fitur ini bukan berarti semua fitur harus diaktifkan sekaligus. Terlalu banyak kolektor dan aturan sejak hari pertama justru menghasilkan noise, storage cepat penuh, dan alert fatigue.
Arsitektur deployment yang masuk akal
Untuk lab atau lingkungan kecil, all-in-one deployment cukup praktis. Wazuh server, indexer, dan dashboard berada pada satu host. Konsekuensinya jelas: kegagalan host memengaruhi seluruh plane monitoring, dan beban indexing dapat mengganggu proses analisis.
Untuk lingkungan menengah, pisahkan komponen pusat setidaknya secara logis atau fisik. Wazuh server menerima dan menganalisis event, indexer menangani penyimpanan dan query, sedangkan dashboard menjadi antarmuka operasional. Pada skala besar, Wazuh server dan indexer dapat dibuat cluster agar throughput serta fault tolerance tidak bergantung pada satu node.
| Model | Cocok untuk | Risiko utama |
|---|---|---|
| All-in-one | Lab, PoC, sedikit endpoint | Single point of failure dan resource contention |
| Single-node terpisah | Lingkungan menengah | Operasional lebih kompleks, tetapi isolasi beban lebih baik |
| Cluster | Event tinggi dan kebutuhan availability | Biaya, sizing, TLS, dan troubleshooting lebih berat |
Jangan mengekspos indexer ke internet. Endpoint agent hanya perlu mencapai service yang memang diperlukan, sementara dashboard sebaiknya berada di belakang reverse proxy, VPN, atau jaringan admin. Port default yang perlu direncanakan antara lain 1514 untuk koneksi agent, 1515 untuk enrollment, 9200 untuk indexer, dan 443 untuk dashboard. Port tersebut bukan alasan untuk membuka seluruh host firewall.
Deployment Docker: cepat bukan berarti selesai
Wazuh menyediakan deployment Docker dengan satu container untuk komponen pusat pada skenario single-node. Sebelum menjalankan Compose, periksa batas kernel dan resource host. Indexer membutuhkan virtual memory map yang memadai; dokumentasi Wazuh menggunakan vm.max_map_count=262144 sebagai prasyarat penting pada host Docker.
sudo sysctl -w vm.max_map_count=262144
printf 'vm.max_map_count=262144\n' | sudo tee /etc/sysctl.d/99-wazuh.conf
sudo sysctl --systemGunakan repository dan tag versi yang sudah ditentukan, bukan image dengan tag yang berubah tanpa kontrol. Simpan certificate, password indexer, dan konfigurasi deployment di luar repository publik. Untuk production, pin versi image, gunakan volume yang dipantau kapasitasnya, dan pastikan backup benar-benar dapat direstore.
Enrollment dan segmentasi agent
Agent mengirim data ke Wazuh server melalui koneksi agent. Pisahkan kelompok agent berdasarkan fungsi dan tingkat kritikalitas: production server, database, workstation, DMZ, dan cloud workload. Pengelompokan ini membuat konfigurasi lebih mudah dikelola dan membantu membedakan baseline normal dari perubahan berisiko.
Enrollment harus dikontrol. Jangan menaruh password enrollment atau key agent di skrip yang dapat dibaca semua user. Gunakan kanal aman, batasi akses ke port enrollment, dan hapus agent yang sudah tidak dimiliki organisasi. Agent yang statusnya disconnected bukan otomatis insiden, tetapi harus memiliki prosedur untuk membedakan host mati, firewall berubah, dan agent sengaja dihentikan.
File Integrity Monitoring tanpa membanjiri dashboard
File Integrity Monitoring atau FIM membandingkan kondisi file terhadap baseline dan memberi alert ketika file dibuat, diubah, atau dihapus. Fitur ini berguna untuk direktori konfigurasi, binary penting, dan web root. Namun memonitor seluruh filesystem biasanya menghasilkan terlalu banyak event yang tidak relevan.
<syscheck>
<directories check_all="yes" report_changes="yes" realtime="yes">
/etc/ssh
/etc/sudoers.d
/var/www/app/config
</directories>
</syscheck>Daftar direktori harus mengikuti threat model. Direktori cache, log yang berubah setiap detik, dan folder upload pengguna memerlukan perlakuan berbeda. Jika semua perubahan dianggap kritis, operator akan belajar mengabaikan alert. Baseline harus dibuat setelah konfigurasi host dinyatakan bersih, bukan setelah attacker sudah mengubahnya.
Log collection dan tuning rules
Wazuh dapat membaca log sistem dan aplikasi, tetapi mengirim semua log mentah ke indexer bukan strategi analisis. Mulai dari sumber yang memiliki nilai investigasi tinggi: authentication log, sudo, SSH, firewall, reverse proxy, database audit, dan log aplikasi yang memuat actor serta request identifier.
Rule bawaan membantu memulai, tetapi tetap perlu tuning. Naikkan level hanya jika event benar-benar memerlukan tindakan. Buat exception untuk aktivitas administrasi yang sah dengan kondisi yang sempit: akun, host, waktu, dan command yang jelas. Hindari whitelist berbasis substring yang terlalu luas karena dapat menutupi variasi serangan.
| Masalah | Perbaikan |
|---|---|
| Alert SSH terlalu banyak | Gabungkan threshold, sumber IP, dan status autentikasi; bedakan internet-facing host |
| Alert admin dianggap noise | Tambahkan identitas change window dan audit ticket, bukan whitelist global |
| Log aplikasi sulit diinvestigasi | Standarkan timestamp, actor, action, resource, result, dan request ID |
Vulnerability detection bukan patch management
Vulnerability detection membantu menemukan paket atau komponen yang memiliki kelemahan berdasarkan inventory dan feed yang tersedia. Hasilnya adalah daftar prioritas, bukan bukti bahwa patch telah diterapkan. Tim tetap perlu memvalidasi exposure, kompensasi kontrol, impact terhadap layanan, dan jadwal perubahan.
Jangan mengurutkan pekerjaan hanya berdasarkan severity. Kerentanan kritis pada host yang tidak dapat diakses dari jaringan relevan berbeda dengan kerentanan high pada server publik yang memproses data penting. Gabungkan severity, exposure, exploitability, asset criticality, dan ketersediaan mitigasi.
Active Response: otomatisasi yang harus dibatasi
Active Response dapat menjalankan tindakan ketika rule tertentu terpenuhi, misalnya memblokir alamat IP atau menonaktifkan akun. Ini berguna untuk skenario yang kriterianya sempit dan dapat dibalik. Ini berbahaya jika dipasang sebagai respons default untuk event yang belum dituning.
Setiap respons otomatis perlu memiliki timeout, mekanisme rollback, dan pemilik. Jika operator tidak dapat menjelaskan cara membuka blokir saat jam darurat, otomatisasi tersebut belum siap production.
Retensi, kapasitas, dan backup
Storage indexer harus dihitung dari event per second, ukuran event, replica, retention, dan overhead index. Retensi 90 hari bukan angka default yang aman; ia harus dibandingkan dengan kebutuhan investigasi, kebijakan organisasi, dan kapasitas disk.
Pantau disk usage, heap, latency query, indexing errors, agent count, dan queue. Backup dashboard saja tidak cukup. Data alert dan konfigurasi harus memiliki strategi pemulihan yang diuji. Restore drill lebih penting daripada sekadar memiliki file snapshot.
Playbook minimum sebelum go-live
- Inventarisasi endpoint dan kelompokkan berdasarkan kritikalitas.
- Tentukan lima skenario prioritas: brute force, perubahan file kritis, privilege escalation, malware, dan service exposure.
- Pasang agent pada subset kecil endpoint yang representatif.
- Validasi event normal selama change window dan tuning rule.
- Uji alert sampai dashboard, notifikasi, dan ticketing.
- Uji satu active response yang reversible.
- Ukur ingestion, disk growth, query latency, dan agent disconnect.
- Dokumentasikan owner, severity, SLA respons, dan prosedur rollback.
Kapan Wazuh bukan pilihan terbaik?
Wazuh bukan jawaban otomatis untuk semua kebutuhan security monitoring. Jika organisasi membutuhkan korelasi lintas cloud dan SaaS dengan volume besar, managed SIEM dapat mengurangi beban operasi indexer. Jika fokus utama hanya metrics dan tracing aplikasi, observability stack lebih tepat. Jika tidak ada orang yang memantau alert, instalasi Wazuh hanya menambah sistem yang harus dirawat.
Pilihan self-hosted memberi kontrol biaya, data, dan konfigurasi, tetapi menambah pekerjaan untuk sizing, patching, certificate, backup, retention, dan incident response. Managed service mengurangi beban platform, tetapi biaya ingestion dan ketergantungan vendor harus dihitung. Keputusan yang baik mengikuti volume event dan kapasitas tim, bukan popularitas alat.
Practical takeaways
- Mulai dari aset kritis dan skenario serangan, bukan dari semua fitur.
- Gunakan all-in-one untuk lab; pisahkan komponen ketika beban dan availability mulai penting.
- Jangan membuka indexer ke internet dan jangan menyimpan secret di repository.
- Tuning rule adalah pekerjaan inti, bukan pekerjaan setelah semuanya selesai.
- FIM efektif pada direktori terpilih; monitoring seluruh filesystem biasanya menciptakan noise.
- Active Response harus reversible, sempit, dan memiliki rollback.
- Ukur kapasitas indexer dan lakukan restore drill sebelum menyebut deployment siap production.
