Belajar Wazuh - Custom Rules & Advanced Detection

#Pendahuluan

Di episode 16, kalian memastikan komunikasi agent dan manager berjalan aman lewat mTLS dan sertifikat X.509. Kanal yang aman hanya bernilai jika ada sesuatu yang cerdas membaca apa yang lewat di dalamnya. Di episode inilah kecerdasan itu dibangun.

Rule bawaan Wazuh sangat baik untuk pola umum, tetapi setiap lingkungan punya keunikan. Aplikasi internal, format log sendiri, dan skenario serangan tertentu tidak selalu tertangkap oleh rule generik. Episode 17 mengajarkan cara menulis custom rules sesuai kebutuhan kalian.

Kita akan membuat rule untuk brute force, reverse shell, dan data exfiltration, memakai variabel serta dynamic fields, lalu mendalami advanced detection: korelasi lintas agent, alert overrides, enrichment GeoIP, dan integrasi threat intel feeds. Ini episode favorit para deteksi engineer.

#Kenapa Rule Bawaan Belum Cukup

Bayangkan sebuah aplikasi web internal yang log gagal loginnya tidak memakai format standar SSH atau Apache. Rule bawaan tidak akan mengenalinya karena formatnya asing. Di sinilah custom rules bekerja: mereka menangkap sinyal dari log yang hanya dimengerti lingkungan kalian.

Ada juga kasus di mana pola serangan begitu spesifik sampai menyebut nama file atau perintah tertentu yang hanya muncul di lingkungan tertentu. Rule bawaan tidak mungkin menebak semuanya, jadi kalian menuliskannya sendiri.

Prinsipnya sederhana: pahami dulu log yang kalian punya, lalu tulis rule yang menangkap perilaku mencurigakan di dalamnya. Jangan menulis rule tanpa melihat contoh log asli, karena hasilnya akan menjadi tebakan yang rapuh.

#Anatomi Rule Wazuh

Rule Wazuh ditulis dalam XML dan disimpan di direktori /var/ossec/etc/rules/. Rule custom sebaiknya diletakkan di local_rules.xml agar mudah dibedakan dari rule bawaan dan tidak tertimpa saat upgrade.

Blok <rule> selalu memiliki id dan level. Level menentukan seberapa penting alert, mulai dari 0 yang tidak dianggap sampai 16 yang kritis. Selain itu, rule bisa memakai elemen seperti match untuk mencocokkan teks, if_sid untuk bergantung pada rule lain, dan frequency untuk menghitung kejadian dalam jendela waktu.

Setelah menulis rule, wajib memvalidasi sebelum dipakai. Jalankan wazuh-analysisd -t untuk mengecek sintaks, lalu restart service agar rule aktif.

#Membuat Rule Brute Force Sendiri

Brute force adalah salah satu use case paling sering ditangani custom rule. Polanya khas: banyak kegagalan login dari sumber yang sama dalam waktu singkat, lalu satu keberhasilan di ujungnya.

Wazuh sudah punya rule untuk kegagalan login SSH. Kita tinggal membangun di atasnya dengan rule yang menghitung kejadian dan mensyaratkan sumber IP yang sama. Kombinasi frequency dan timeframe menjadi jantung deteksi ini.

Deteksi brute force SSH dalam 2 menit

<group name="local,ssh_bruteforce,">
  <rule id="100300" level="10" frequency="8" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <same_srcip />
    <description>Delapan kegagalan login dari satu sumber</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Rule di atas menunggu delapan event yang memicu rule 5710 dalam 120 detik dari sumber IP yang sama, lalu melaporkannya sebagai serangan brute force. Label MITRE ATT&CK ikut disertakan agar alert kaya konteks.

#Variabel dan Dynamic Fields

Rule yang baik tidak sekadar menempelkan teks, tetapi juga mengekstrak nilai dari event untuk dipakai di tempat lain. Wazuh menyebutnya dynamic fields, dan nilainya bisa disisipkan ke deskripsi alert.

Dynamic field ditulis dengan tanda $ diikuti nama field, seperti $(srcip), $(user), atau $(url). Nilainya diambil dari hasil decoding event, sehingga satu rule bisa menghasilkan deskripsi yang berbeda untuk tiap kejadian.

Dynamic fields di dalam deskripsi rule

<rule id="100301" level="5">
  <match>login attempted</match>
  <description>Login gagal untuk user $(user) dari IP $(srcip)</description>
  <group>authentication_failures,</group>
</rule>

Ketika event yang cocok masuk, deskripsi alert otomatis terisi nama user dan IP sumber yang relevan. Ini membuat analis membaca alert langsung tanpa membuka log asli.

#Rule Reverse Shell dan Data Exfiltration

Reverse shell adalah momen paling berbahaya dalam sebuah serangan: penyerang sudah mendapatkan eksekusi perintah di host. Deteksi dini sangat menentukan, dan audit perintah adalah sumber utamanya.

Dengan modul auditd yang aktif, setiap perintah yang dijalankan pengguna tercatat sebagai event. Rule bisa menangkap pola perintah yang identik dengan reverse shell, seperti memanggil shell interaktif tanpa terminal.

Indikasi reverse shell pada command line

<group name="local,reverse_shell,">
  <rule id="100302" level="14">
    <if_sid>80700</if_sid>
    <match>bash -i</match>
    <description>Kemungkinan reverse shell terdeteksi</description>
    <mitre>
      <id>T1059</id>
    </mitre>
  </rule>
</group>

Data exfiltration mengikuti pola serupa. Perhatikan perintah yang memindahkan data ke luar, kombinasi pembungkusan arsip dengan transfer jaringan, atau pengiriman data ke alamat yang tidak dikenal. Kuncinya adalah membangun profil perintah normal dulu, lalu menandai yang menyimpang.

#Alert Overrides

Kadang rule bawaan memilih level yang tidak cocok dengan kebijakan kalian. Ada yang terlalu berisik sehingga analis jadi tuli, atau terlalu rendah untuk peristiwa yang kalian anggap penting. Alert overrides menyelesaikan ini.

Cara kerjanya sederhana: tulis ulang rule dengan id yang sama dan atribut overwrite="yes", lalu berikan nilai baru untuk atribut yang ingin diubah. Atribut yang tidak ditulis mempertahankan nilai aslinya.

Menurunkan level rule yang berisik

<rule id="2407" level="5" overwrite="yes">
  <description>Kegiatan syslog rutin yang dipantau</description>
  <group>overridden_syslog_group,</group>
</rule>

Dengan override, kalian tidak perlu menghapus rule bawaan atau menonaktifkan seluruh file. Satu blok kecil di local_rules.xml sudah cukup untuk menyesuaikan perilaku sesuai kebutuhan tim.

#Multi-Agent Correlation

Sejauh ini kita bicara korelasi dalam satu host. Padahal serangan sering menyebar: satu sumber mencoba menerobos banyak server sekaligus. Secara default, penghitung frequency hanya menghitung event dari agent yang sama, sehingga pola lintas host luput.

Wazuh menyediakan opsi global_frequency untuk menghitung event dari semua agent sekaligus. Gabungkan dengan same_srcip, maka kalian bisa mendeteksi upaya brute force terdistribusi yang tidak akan terlihat jika tiap agent berdiri sendiri.

Korelasi lintas agent dengan global_frequency

<group name="local,distributed_attack,">
  <rule id="100303" level="12" frequency="20" timeframe="300">
    <if_matched_sid>5710</if_matched_sid>
    <global_frequency />
    <same_srcip />
    <description>Brute force tersebar ke banyak agent dari satu sumber</description>
  </rule>
</group>

Perlu diingat, global_frequency bekerja di tingkat manager, bukan cluster. Pada deployment yang sangat besar, pertimbangkan pembagian beban agar korelasi tetap ringan.

#GeoIP Enrichment

IP sumber yang hanya berupa angka kurang informatif. Enrichment GeoIP menambahkan negara, kota, dan koordinat ke alert, sehingga analis langsung melihat dari mana sebuah koneksi berasal tanpa mencari di database eksternal.

Wazuh memakai database GeoIP yang diunduh dan disimpan di sisi manager. Modul geoip diaktifkan lewat ossec.conf, lalu aturan pemetaan menentukan alert mana yang diberi data lokasi.

Mengaktifkan enrichment GeoIP

<ossec_config>
  <geoip enabled="yes" mode="fast" count="10" data_path="/etc/geolite2">
    <ruleset>
      <rule file="/var/ossec/etc/ossec-geoip.conf">
        <rules>
          <rule id="100300">geoip</rule>
          <rule id="100303">geoip</rule>
        </rules>
      </rule>
    </ruleset>
  </geoip>
</ossec_config>

Ingat untuk memperbarui database GeoIP secara berkala, karena batas negara dan alokasi blok IP berubah seiring waktu. Database yang basi membuat kesimpulan lokasi menjadi menyesatkan.

#Integrasi Threat Intel Feeds

GeoIP menjawab pertanyaan dari mana, sedangkan threat intel menjawab apakah sumber itu dikenal berbahaya. Wazuh bisa dihubungkan ke berbagai feed ancaman untuk memperkaya setiap alert.

Integrasi paling populer adalah VirusTotal, yang memeriksa hash berkas terhadap koleksi antivirus global. Konfigurasinya cukup sederhana dan menghasilkan field tambahan pada alert syscheck.

Integrasi VirusTotal sebagai threat intel

<ossec_config>
  <integration>
    <name>virustotal</name>
    <api_key>API_KEY_ANDA</api_key>
    <group>syscheck</group>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

Selain VirusTotal, kalian bisa memakai file daftar reputasi IP lewat <list>, atau mengarahkan alert ke layanan threat intel lain memakai custom integration. Pilih feed yang relevan dengan ancaman yang dihadapi, karena setiap permintaan API juga membawa biaya.

#Penutup

Episode 17 mengajarkan kalian menulis custom rules dan menghadirkan advanced detection. Kita membuat rule untuk brute force, reverse shell, dan data exfiltration, memakai variabel serta dynamic fields, lalu mendalami alert overrides, korelasi lintas agent, enrichment GeoIP, dan integrasi threat intel feeds.

Inti yang harus dibawa pulang:

• Rule custom ditulis di local_rules.xml dan wajib divalidasi dengan wazuh-analysisd.
• Kombinasi frequency dan timeframe menangkap pola brute force.
• Dynamic fields membuat deskripsi alert selalu relevan dengan kejadian.
• Overrides menyesuaikan level rule tanpa menghapus rule bawaan.
• global_frequency menghitung event dari semua agent sekaligus.
• GeoIP dan threat intel memperkaya alert dengan konteks eksternal.

Deteksi di tangan kalian sudah sangat tajam, tetapi deteksi tanpa respons hanya menghasilkan deretan alert. Di episode 18, kita akan menghubungkan Wazuh ke TheHive untuk case management dan Shuffle untuk orkestrasi, membangun alur incident response yang utuh. Sampai jumpa!