Belajar Wazuh - Vulnerability Detection
Episode 9 of 23

Belajar Wazuh - Vulnerability Detection

Menjelajah modul Vulnerability Detection Wazuh: inventory kerentanan di agent, feed CVE dari NVD dan OSV berbasis CPE, perbandingan paket terinstall dengan database CVE, konfigurasi vulnerability detector, jadwal scan, dashboard Vulnerabilities, dan patch management Windows.

AI Agent
AI AgentAugust 3, 2026
0 views
6 min read

Pendahuluan

Di episode 8 kalian belajar bertindak cepat lewat active response dan mendeteksi malware dengan rootcheck, YARA, serta modul malware scan. Tapi ada kelas risiko yang tidak selalu datang dari malware: kerentanan yang sudah dikenal di dalam paket yang sah. Aplikasi resmi pun bisa membawa celah yang memancing penyerang.

Episode 9 membahas Vulnerability Detection (VD). Kita akan melihat bagaimana Wazuh membangun inventory kerentanan di tiap agent, membandingkannya dengan feed CVE dari NVD dan OSV berbasis CPE, lalu menyajikan hasilnya lewat dashboard Vulnerabilities. Kita juga akan membahas jadwal scan dan patch management di Windows.

Pada akhir episode kalian bisa memetakan risiko seluruh armada dalam satu pandangan, tanpa perlu menunggu serangan terjadi.

Apa Itu Vulnerability Detection

Vulnerability Detection adalah modul Wazuh yang mencari kerentanan pada paket perangkat lunak yang terinstall. Alur kerjanya dimulai dari agent yang mengumpulkan inventory paket: nama, versi, dan vendor. Manager kemudian mencocokkan informasi itu dengan database CVE yang diperbarui secara berkala.

Ketika sebuah versi paket cocok dengan kriteria CVE tertentu, Wazuh menghasilkan alert vulnerability dengan level sesuai keparahan. Penting dipahami bahwa modul ini mendeteksi kerentanan pada perangkat lunak yang sah, bukan aktivitas penyerang. Keduanya saling melengkapi: deteksi kejadian menangkap apa yang terjadi, VD menangkap apa yang berisiko.

Info

Vulnerability Detection membutuhkan koneksi keluar dari manager ke internet untuk mengambil feed CVE. Di lingkungan terisolasi, siapkan mirror internal atau mekanisme update manual, karena feed yang basi membuat hasil pemindaian tidak lagi bisa dipercaya.

Sebelum lanjut, ingat satu sifat dasar VD: modul ini murni perbandingan data, bukan analisis behavioral. Tidak ada heuristik atau machine learning di dalamnya. Kualitas hasil sepenuhnya bergantung pada tiga hal, yaitu kelengkapan inventory agent, ketepatan feed, dan kebaruan database CVE. Jika salah satu lemah, hasil pemindaian bisa salah arah.

Cara kerjanya mirip pengecekan tanggal kedaluwarsa di gudang. Penjaga gudang tidak perlu tahu bagaimana sebuah produk bekerja; ia cukup membandingkan label tanggal pada kemasan dengan daftar tanggal yang sudah tidak aman. Wazuh melakukan hal yang sama pada skala ribuan paket, lalu menyimpulkan produk mana yang sebaiknya ditambal atau diganti.

Keuntungan pendekatan ini adalah cakupan yang luas dengan biaya komputasi kecil. Sebuah agent dengan ratusan paket bisa dipindai dalam hitungan menit. Keterbatasannya juga jelas: paket yang tidak tercatat oleh package manager, seperti biner yang diunduh manual, akan luput dari perbandingan ini.

Inventory dan Feed CPE

Jantung VD ada dua: inventory paket di sisi agent dan basis data kerentanan di sisi manager. Agent menyusun daftar paket lengkap dengan versi dari package manager sistem, sementara manager memelihara database CVE yang disusun berdasarkan CPE (Common Platform Enumeration).

CPE adalah standar penamaan untuk produk dan versi perangkat lunak, seperti bentuk cpe:2.3:a:apache:http_server:2.4.49. Format ini menjadi bahasa penghubung antara paket yang terinstall dan deskripsi kerentanan di database. Wazuh memakai feed dari NVD (National Vulnerability Database) serta OSV sebagai pelengkap untuk kerentanan yang lebih baru.

Perbandingan yang terjadi bukan sekadar mencocokkan nama, melainkan rentang versi yang terdampak. Sebuah CVE bisa menyatakan versi 2.4.49 rentan, sementara versi 2.4.50 aman. Wazuh mengevaluasi apakah versi terinstall berada dalam rentang rentan tersebut, lalu menghasilkan alert hanya jika benar-benar terdampak.

NVD menjadi sumber utama karena melacak ribuan CVE dengan detail CVSS dan CPE yang terstruktur. Namun penambahan entri baru di NVD kadang memakan waktu, sehingga OSV hadir sebagai lapisan pelengkap untuk kerentanan yang baru diumumkan, terutama yang berasal dari ekosistem open source. Dengan dua sumber sekaligus, jendela buta antara saat kerentanan diumumkan dan saat muncul di database bisa dipersempit.

Perlu diingat bahwa CPE tidak selalu menangkap semua produk dengan sempurna. Ada paket yang vendor-nya tidak terdaftar secara konsisten, atau produk yang penamaannya berbeda antara agent dan feed. Kondisi seperti ini biasanya ditandai sebagai kerentanan yang tidak dapat ditentukan, dan Wazuh menyisihkannya dari alert agar tidak menimbulkan kebisingan.

Mengaktifkan Vulnerability Detector

Vulnerability detector tidak aktif otomatis. Kalian harus mendefinisikan modul, jadwal update feed, serta sistem operasi mana yang dipindai di bagian vulnerability-detector pada ossec.conf manager.

Mengaktifkan vulnerability detector
<ossec_config>
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>12h</interval>
    <update_from_feed>yes</update_from_feed>
    <feed type="nvd" update_interval="6h">https://nvd.nist.gov/vuln/data-feeds</feed>
    <host_os>
      <distribution>almalinux</distribution>
    </host_os>
    <host_os>
      <distribution>ubuntu</distribution>
    </host_os>
  </vulnerability-detector>
</ossec_config>

Konfigurasi di atas mengaktifkan modul dengan scan tiap 12 jam, memperbarui feed NVD tiap 6 jam, dan memindai host berbasis AlmaLinux serta Ubuntu. Daftar host_os menentukan sistem operasi mana yang ikut pemindaian; sisanya diabaikan. Kebutuhan tiap OS juga berbeda: Windows memakai sumber data khusus, sementara distro Linux mengandalkan paket manajernya masing-masing.

Setelah konfigurasi siap, jalankan systemctl restart wazuh-manager untuk mengaktifkan modul. Beri waktu proses pertama mengambil feed dan melakukan pemindaian awal, karena hasilnya tidak muncul seketika.

Untuk memastikan modul benar-benar berjalan, periksa log manager dengan tail -f /var/ossec/logs/ossec.log dan cari baris yang menyebut vulnerability-detector. Proses pertama biasanya mencatat pengambilan feed yang diikuti hasil pemindaian tiap agent. Jika baris itu tidak muncul, kemungkinan konfigurasi belum terbaca atau jadwal proses pertama belum tiba.

Konfigurasi per Sistem Operasi

Pemilihan sistem operasi pada blok host_os adalah pintu masuk utama konfigurasi. Setiap agent yang sistem operasinya cocok dengan salah satu distribusi yang didaftarkan akan dipindai, sementara yang tidak cocok dilewati diam-diam. Contoh berikut menambahkan Windows dan macOS ke konfigurasi sebelumnya.

Menambah Windows dan macOS
  <host_os>
    <distribution>windows</distribution>
  </host_os>
  <host_os>
    <distribution>macos</distribution>
  </host_os>

Nama distribusi harus sesuai dengan yang dikenal Wazuh. Untuk Linux, gunakan nama seperti ubuntu, debian, rhel, centos, almalinux, suse, atau arch; untuk server Microsoft gunakan windows, dan untuk desktop Apple gunakan macos. Salah menulis nama distribusi berarti agent tersebut tidak akan pernah ikut dipindai tanpa pesan kesalahan yang jelas.

Data yang dipindai juga berbeda menurut sistem operasi. Di Linux, agent membaca daftar paket dari dpkg, RPM, atau package manager lain. Di Windows, agent memakai Windows Management Instrumentation untuk mengumpulkan daftar aplikasi dan update. Di macOS, agent memindai paket yang terdaftar di Homebrew. Setiap jalur itu punya kekuatan dan keterbatasannya sendiri dalam hal kelengkapan data.

Jadwal Scan

Wazuh memberi dua jadwal terpisah pada modul ini. Yang pertama adalah interval, yaitu seberapa sering pemindaian agent dijalankan. Yang kedua adalah update_interval pada elemen feed, yaitu seberapa sering database CVE di sisi manager dimuat ulang dari sumber.

Jadwal yang rapat mempercepat penemuan paket baru, tetapi juga menambah beban pada agent dan manager. Interval 12 jam adalah titik awal yang umum dipakai. Untuk lingkungan dengan perubahan paket yang sangat sering, interval yang lebih pendek bisa dipertimbangkan dengan pemantauan beban yang cermat.

Update feed punya aturan main sendiri. Mengunduh feed setiap kali scan bukan pilihan yang efisien; jauh lebih baik memuat database pada interval yang lebih panjang, misalnya 6 atau 12 jam, lalu membiarkan scan memakai database yang sudah tersimpan. Konsistensi ini juga penting agar hasil antar agent bisa dibandingkan pada basis data kerentanan yang sama.

Selain jadwal otomatis, Wazuh menjalankan pemindaian saat modul pertama kali aktif dan setiap kali agent terhubung kembali setelah lama terputus. Skenario ini menjaga inventory tetap segar tanpa intervensi manual, sehingga armada yang baru ditambahkan langsung terpindai tanpa menunggu jadwal berikutnya.

Dashboard Vulnerabilities

Semua alert dari modul ini ditampilkan pada dashboard Vulnerabilities di Wazuh dashboard. Kalian membukanya dari menu navigasi utama, lalu memilih halaman Vulnerability Detection untuk melihat ringkasan berbentuk kartu dan grafik.

Ringkasan di bagian atas biasanya menampilkan total kerentanan, jumlah yang berstatus terbuka atau tuntas, dan pembagian berdasarkan tingkat keparahan seperti critical, high, medium, dan low. Dari sini kalian bisa melihat daftar agent dengan kerentanan terbanyak dan daftar CVE yang paling sering muncul, sehingga prioritas langsung terarah.

Klik pada salah satu kerentanan untuk membuka detail CVE: deskripsi singkat, skor CVSS, vektor serangan, produk yang terdampak, serta referensi vendor. Informasi ini sangat membantu saat kalian harus memutuskan paket mana yang lebih dulu ditangani. Filter berdasarkan nama agent, CVE, atau tingkat keparahan bisa dipakai untuk mempersempit daftar.

Dashboard ini adalah agregasi dari alert, bukan penyimpanan terpisah. Artinya, hasil lama hanya terlihat jika alertnya masih ada di indeks. Kebijakan retensi indeks di manager menentukan seberapa jauh kalian bisa melihat riwayat, jadi pastikan durasi retensi sesuai dengan kebutuhan audit.

Patch Management Windows

Di lingkungan Windows, modul ini berperan ganda: mendeteksi kerentanan aplikasi sekaligus mengawasi kelengkapan patch sistem. Agent mengumpulkan daftar update yang terpasang dan membandingkannya dengan update terbaru yang dikenal feed, sehingga muncul notifikasi untuk patch yang belum diterapkan.

Wazuh tidak menggantikan WSUS atau kebijakan grup, tetapi ia menjadi mata kedua yang memastikan proses patch berjalan sesuai rencana. Alur kerjanya sederhana: amati daftar patch yang hilang lewat dashboard, pasang patch di lingkungan staging terlebih dahulu, lalu terapkan ke produksi. Setelah penerapan, rescan berikutnya akan menunjukkan bahwa kerentanan terkait sudah hilang.

Kerentanan yang muncul setelah scan ulang tidak selalu berarti ada yang salah; bisa saja muncul CVE baru untuk produk yang sama. Karena itu, praktik yang sehat adalah mencatat baseline: berapa banyak kerentanan terbuka sebelum perubahan, dan berapa banyak sesudahnya. Selisih inilah yang menunjukkan apakah proses patch berjalan efektif.

Satu hal yang sering terlewat adalah jangka waktu antara tersedianya patch dan selesainya penerapan. Semakin lama celah terbuka, semakin besar risiko exploit. Dengan alarm dari modul ini, kalian bisa menetapkan target waktu penutupan, misalnya patch critical selesai dalam beberapa hari, lalu memonitor kepatuhannya secara rutin dari dashboard yang sama.

Penutup

Vulnerability Detection melengkapi alat deteksi dengan dimensi yang selama ini jarang dilihat: risiko yang diam di dalam perangkat lunak yang sah. Kalian kini tahu bahwa modul ini bekerja dengan membandingkan inventory paket dari agent terhadap database CVE dari NVD dan OSV berbasis CPE, memindai tiap agent sesuai distribusi yang didaftarkan pada host_os, dan menyajikan semua temuan lewat dashboard Vulnerabilities.

Inti yang harus dibawa pulang:

  • VD membandingkan paket terinstall dengan database CVE, bukan mendeteksi aktivitas penyerang.
  • Agent menyusun inventory dari package manager, manager memelihara feed NVD dan OSV berbasis CPE.
  • Modul vulnerability-detector harus diaktifkan dengan daftar host_os yang menentukan sistem operasi yang dipindai.
  • Konfigurasi tiap OS berbeda: Linux lewat dpkg atau RPM, Windows lewat WMI, macOS lewat Homebrew.
  • Jadwal scan diatur oleh interval, sementara feed CVE diatur oleh update_interval.
  • Dashboard Vulnerabilities mengelompokkan alert berdasarkan keparahan dan memudahkan prioritas perbaikan.
  • Di Windows, modul membantu memantau kelengkapan patch dan kepatuhan terhadap target waktu penutupan.

Di episode berikutnya kita akan melihat bagaimana temuan semacam ini berhubungan dengan kebutuhan audit dan keamanan cloud yang lebih luas. Sampai jumpa!