Belajar Wazuh - Rules & Decoders

#Pendahuluan

Di episode 5 kalian belajar memonitor dan menganalisis log dari agent yang sudah terhubung ke manager: melihat event mentah, menelusuri dengan query, dan menyusun agregasi untuk menemukan anomali. Pada titik itu pertanyaan besarnya masih terbuka, yaitu bagaimana Wazuh memutuskan bahwa sebuah event layak dijadikan alert.

Episode 6 menjawab pertanyaan itu dengan membedah dua komponen inti deteksi: decoders dan rules. Decoders mengubah log mentah menjadi data terstruktur, lalu rules menentukan apakah data tersebut mencurigakan. Kita akan membahas struktur local_decoder.xml dan local_rules.xml, format syslog dan JSON, cara membuat custom decoder, berbagai tipe rule, serta skala level 0 sampai 15 sebagai bahasa prioritas alert.

Di akhir episode kalian tidak hanya bisa membaca XML rule, tetapi juga bisa menulis decoder dan rule sendiri untuk aplikasi yang tidak punya integrasi bawaan. Itu keterampilan yang membuat Wazuh jauh lebih berguna di lingkungan nyata, karena selalu ada aplikasi internal yang format lognya hanya dipahami tim sendiri.

#Alur Pipeline Deteksi

Sebelum masuk ke sintaks, kita perlu paham posisi decoders dan rules dalam alur kerja Wazuh. Event mengalir dari kolektor di agent menuju manager melalui beberapa tahap: decoding, rule matching, lalu storage dan alerting. Tahap decoding menormalkan log; tahap rule matching menilai hasil normalisasi tersebut.

File decoder bawaan tersimpan di direktori /var/ossec/etc/decoders/ pada manager, sedangkan rules bawaan berada di /var/ossec/etc/rules/. Saat kalian ingin menambah logika sendiri tanpa mengotak-atik file bawaan, tempat yang tepat adalah local_decoder.xml dan local_rules.xml. Keduanya dijamin dibaca oleh Wazuh dan aman untuk di-edit.

#Anatomi Decoder

Decoder di Wazuh ditulis dalam XML dan selalu diawali elemen decoder dengan atribut name. Tiga anak elemen yang paling sering dipakai: prematch untuk filter cepat, regex untuk mengekstrak field, dan order untuk memberi nama pada hasil ekstraksi sesuai urutannya.

<decoder name="custom-syslog">
  <prematch>^syslog: </prematch>
  <regex>^syslog: \s+(\S+): (.*)$</regex>
  <order>program_name, log</order>
</decoder>

Pada contoh di atas, prematch memastikan hanya log yang diawali kata syslog yang ditangani decoder ini. regex kemudian menangkap dua bagian: nama program dan isi pesan. order memberi label program_name untuk bagian pertama dan log untuk bagian kedua. Field yang sudah diberi nama inilah yang nanti dibaca oleh rule.

Perlu dicatat bahwa prematch bersifat opsional tetapi sangat disarankan. Tanpa prematch, Wazuh menjalankan regex terhadap setiap event, yang membuang sumber daya pada manager berskala besar. Dengan prematch yang selektif, regex hanya dievaluasi untuk event yang relevan, dan decoder lain diabaikan lebih cepat.

#Format Syslog dan JSON

Dua format log yang paling sering ditemui adalah syslog dan JSON. Format syslog tradisional menyimpan facility, severity, timestamp, hostname, dan pesan dalam satu baris teks. Wazuh sudah punya decoder bawaan untuk format ini, sehingga log dari rsyslog atau syslog-ng langsung dikenali tanpa konfigurasi tambahan.

Untuk aplikasi modern, JSON jauh lebih umum karena strukturnya rapi dan mudah diparsing. Wazuh menangani log JSON dengan mencocokkan prematch berupa kurung kurawal pembuka, lalu memetakan setiap key tingkat atas menjadi field dinamis secara otomatis.

{"event":"login","user":"arman","src_ip":"192.168.1.20","status":"failed"}

Dari satu baris JSON di atas, Wazuh otomatis menyediakan field bernama event, user, src_ip, dan status. Rule bisa langsung memeriksa nilai field tersebut tanpa perlu regex tambahan. Ini membuat penulisan rule untuk aplikasi berformat JSON jauh lebih cepat dibanding log teks biasa.

#Membuat Custom Decoder

Misalkan tim kalian menjalankan aplikasi billing yang menulis log seperti billing-app: user arman invoice 1042 failed. Tidak ada decoder bawaan yang mengenalinya, jadi kita buat sendiri. Strateginya dua lapis: decoder pertama mengenali nama program, decoder kedua mengekstrak field di dalam pesannya.

<decoder name="billing-app">
  <program_name>^billing-app</program_name>
</decoder>
 
<decoder name="billing-app-fields">
  <parent>billing-app</parent>
  <regex>^user (\S+) invoice (\d+) (.*)$</regex>
  <order>user, invoice_id, action</order>
</decoder>

Decoder kedua menggunakan atribut parent untuk menempel pada decoder pertama. Regex menangkap tiga field: user, invoice_id, dan action. Setelah menyimpan perubahan, uji decoder ini menggunakan wazuh-logtest dari terminal manager:

wazuh-logtest
billing-app: user arman invoice 1042 failed

Jika pola regex cocok, wazuh-logtest menampilkan field hasil decoding beserta rule yang cocok. Bila tidak ada rule, muncul pesan bahwa event tidak dikenali. Setelah puas dengan hasilnya, restart manager agar perubahan decoder aktif: systemctl restart wazuh-manager.

#Anatomi Rule

Setelah data terstruktur, giliran rules menentukan keputusan. Rule ditulis dalam XML dengan atribut id dan level. Body rule berisi kondisi, dan semua kondisi yang tertera harus terpenuhi agar rule aktif. Kondisi yang paling umum adalah match, decoded_as, field, dan group.

<rule id="100001" level="8">
  <decoded_as>billing-app-fields</decoded_as>
  <match>failed</match>
  <description>Pembayaran berstatus failed</description>
  <group>billing,</group>
</rule>

Rule di atas aktif hanya jika event hasil decoding berasal dari decoder billing-app-fields dan mengandung kata failed. Saat kedua kondisi terpenuhi, Wazuh menghasilkan alert level 8. Atribut description menjadi judul alert di dashboard, sedangkan group memberi label klasifikasi untuk korelasi lintas rule.

Untuk log JSON, kondisi bisa ditulis langsung terhadap field dinamis menggunakan elemen field dengan atribut name, misalnya membandingkan nilai src_ip dengan alamat tertentu. Ini jauh lebih ekspresif dibanding menebak pola teks, dan menjadi alasan utama banyak tim lebih menyukai format JSON.

#Tipe-Tipe Rule

Wazuh membagi rules ke dalam beberapa kategori berdasarkan fungsinya. Memahami kategorinya membantu kalian membaca ruleset bawaan dan memilih pola yang tepat untuk kebutuhan sendiri.

• Rule match: mencocokkan string atau regex pada event, seperti contoh billing di atas. Paling sederhana dan paling banyak dipakai.
• Rule filter: berfungsi sebaliknya, menekan event yang memenuhi pola tertentu. Biasanya mengandalkan if_sid untuk menjadi anak dari rule lain.
• Rule syscheck: menangani event dari modul FIM, misalnya perubahan file, permission, atau owner. Umumnya bergabung pada group syscheck.
• Rule vulnerability: dihasilkan modul vulnerability detector saat paket terinstall cocok dengan CVE. Bergabung pada group vulnerability-detector.
• Rule scan: mendeteksi aktivitas probing seperti port scan dan vulnerability scan, umumnya bergabung pada group attack dan recon.

Contoh rule filter yang menekan event percobaan rutin:

<rule id="100010" level="0">
  <if_sid>100001</if_sid>
  <match>recurring-test</match>
  <description>Event percobaan rutin, diabaikan</description>
</rule>

Karena level-nya 0, event yang cocok dengan rule ini tidak menghasilkan alert sama sekali, sekaligus menggantikan rule induk 100001 untuk event tersebut. Teknik ini sangat berguna untuk meredam false positive yang berasal dari aktivitas yang memang disengaja, seperti health check berkala.

#Skala Level 0 sampai 15

Level adalah bahasa universal prioritas di Wazuh. Level menentukan seberapa serius sebuah event, dan menjadi dasar dashboard, filter, hingga pemicu active response. Berikut rentang yang perlu diingat:

• Level 0: tidak menghasilkan alert, dipakai untuk filter dan suppression.
• Level 1 sampai 2: notifikasi sistem berprioritas rendah.
• Level 3: event sukses, seperti login berhasil atau akses diberikan.
• Level 4 sampai 5: peringatan keamanan ringan, misalnya serangan diblokir.
• Level 6 sampai 7: ancaman sedang, seperti error tidak biasa yang berulang.
• Level 8 sampai 9: ancaman berat, misalnya indikasi intrusi atau upaya berulang.
• Level 10 sampai 12: sangat berat, biasanya membutuhkan penanganan segera.
• Level 13 sampai 15: kritis, serangan sedang berlangsung dalam skala besar.

Level yang kalian tetapkan harus konsisten dengan konsekuensinya. Level tinggi bukan sekadar peringatan tampilan, tetapi juga menentukan apa yang dilihat tim pertama kali, seberapa cepat otomasi merespons, dan berapa banyak noise yang dihasilkan.

#Group dan Klasifikasi

Atribut group memberi dimensi kedua pada rule selain level. Melalui group, sebuah rule bisa dikaitkan dengan taksonomi keamanan: authentication_failed untuk kegagalan login, syscheck untuk integritas file, attack untuk pola penyerangan, hingga standar compliance seperti gdpr dan pci_dss.

Satu rule bisa terdaftar di beberapa group sekaligus dengan memisahkannya menggunakan koma. Group inilah yang nanti dimanfaatkan dashboard compliance untuk menghitung seberapa banyak alert terkait sebuah regulasi. Jadi menetapkan group dengan cermat sejak awal akan menghemat banyak waktu saat menghadapi audit.

Prioritisasi alert di tim SOC biasanya digabungkan dari dua sumbu ini: level menentukan urgensi, group menentukan kategori eskalasi. Misalnya semua event group authentication_failed dengan level 8 ke atas langsung diteruskan ke analis, sementara event level 5 cukup masuk antrean review harian.

#Penutup

Episode ini menutup celah antara log mentah dan keputusan keamanan. Kalian sekarang paham bahwa decoder adalah lapisan normalisasi yang mengubah log menjadi field, sedangkan rule adalah lapisan penilaian yang mengubah field menjadi alert. Custom decoder dan custom rule membuka jalan untuk mendeteksi apa pun yang khas di lingkungan kalian.

Inti yang harus dibawa pulang:

• Decoder menormalkan log mentah menjadi field terstruktur melalui prematch, regex, dan order.
• Log syslog dan JSON sudah didukung luas; JSON otomatis menghasilkan field dinamis.
• Custom decoder ditulis di local_decoder.xml dan diuji dengan wazuh-logtest sebelum restart manager.
• Rule memadukan kondisi decoded_as, match, dan field untuk menghasilkan keputusan.
• Level 0 sampai 15 menentukan prioritas alert, sedangkan group menentukan klasifikasinya.
• Rule filter berlevel 0 adalah senjata utama meredam false positive.

Di episode 7 kita beranjak ke File Integrity Monitoring: bagaimana Wazuh mengawasi perubahan file penting secara realtime dan terjadwal, membedakan file yang sah dan mencurigakan, serta melaporkan setiap penambahan, modifikasi, dan penghapusan. Sampai jumpa!