Belajar Wazuh - Monitoring Wazuh Itself & Backup

#Pendahuluan

Di episode 19 kita menyetel performa dan menghitung kapasitas. Namun Wazuh yang kita pakai untuk memantau lingkungan tidak akan berguna jika dia sendiri sedang bermasalah tanpa kita sadari. Di episode 20 ini kita memutar arah lensa: memonitor Wazuh itu sendiri, lalu menyiapkan backup dan recovery yang benar.

Banyak admin baru mulai dari instalasi besar dan fitur canggih, tetapi lupa bahwa alat keamanan justru harus menjadi target yang paling diperhatikan. Kalau indexer merah di tengah insiden, seluruh tim kehilangan visibilitas tepat saat paling membutuhkannya. Kebiasaan memeriksa kesehatan Wazuh setiap hari adalah bagian dari operasi, bukan sekadar tambahan.

Kita bahas empat area pemantauan: status indexer, log manager, kesehatan agent, dan metrik API. Lalu kita lanjut ke backup konfigurasi, snapshot indexer, dan strategi disaster recovery untuk arsitektur cluster. Semua ini membentuk jaring pengaman sebelum insiden sungguhan datang.

#Status Indexer: Hijau, Kuning, Merah

OpenSearch melaporkan kesehatan cluster dalam tiga warna. Hijau berarti semua shard primary dan replica tersedia. Kuning berarti shard replica belum semua tersedia, tetapi data utama masih bisa dibaca. Merah berarti ada shard primary yang hilang, dan sebagian data tidak bisa diakses.

Cara tercepat untuk membaca status ini adalah memanggil API health:

curl -sk https://localhost:9200/_cluster/health?v
curl -sk https://localhost:9200/_cat/shards?v

Status merah wajib ditangani segera: cek apakah ada node mati, apakah disk penuh, dan apakah snapshot terakhir tersedia. Status kuning boleh berjalan sementara, tetapi jangan dibiarkan berlarut karena itu tanda ada yang tidak normal pada replikasi.

#Membaca Log Manager

wazuh-manager menulis jejak aktivitasnya ke beberapa berkas log. Berkas utama adalah ossec.log, yang mencatat apa saja yang dilakukan manager, termasuk kesalahan saat memuat rule atau konfigurasi.

Perintah sederhana berikut membantu menemukan masalah:

tail -n 50 /var/ossec/logs/ossec.log
grep -i error /var/ossec/logs/ossec.log | tail -n 20

Selain berkas itu, ada api.log untuk aktivitas API, cluster.log untuk komunikasi antar node cluster, dan integrations.log untuk hasil integrasi seperti TheHive dan Shuffle. Kebiasaan membaca ossec.log sebelum mengubah konfigurasi akan menghemat banyak waktu saat ada yang tidak berjalan seperti harapan.

#Kesehatan Agent

Agent yang sehat adalah dasar dari semua data Wazuh. Di dashboard, tab agent menampilkan status setiap endpoint: Active, Disconnected, atau Never connected. Agent yang sering disconnect perlu diperiksa, karena kehilangan agent berarti kehilangan jendela deteksi.

Di sisi agent, berkas log di /var/ossec/logs/ossec.log mencatat masalah lokal seperti buffer penuh atau kegagalan mengirim event. Sementara itu di sisi manager, kita bisa memeriksa kapan terakhir kali manager menerima event dari sebuah agent. Status agent yang berganti-ganti antara Active dan Disconnected biasanya berkaitan dengan jaringan, sumber daya, atau waktu tunggu komunikasi.

#Metrik Lewat API Wazuh

Wazuh menyediakan API yang bisa dipakai untuk mengambil metrik tanpa membuka dashboard. Misalnya, daftar agent berdasarkan status, atau statistik event per daemon.

Panggilan API dengan autentikasi dasar terlihat seperti ini:

curl -sk -u admin:PAKAI_PASSWORD_API https://localhost:55000/agents?status=active

Dari API ini, kalian bisa membangun skrip pemantauan sendiri: cek jumlah agent disconnected, amati statistik daemon, dan kirim notifikasi bila ada anomali. API yang sama juga dipakai dashboard, jadi memahami responsnya berguna untuk otomasi.

#Backup Konfigurasi Manager

Konfigurasi Wazuh jauh lebih mudah di-backup daripada datanya, dan hampir tidak pernah berubah secepat data alert. Yang paling penting disimpan adalah direktori /var/ossec/etc yang berisi ossec.conf, kunci agent, dan setelan internal.

Perintah tar sederhana sudah cukup untuk baseline:

tar -czf /backup/wazuh-config.tar.gz /var/ossec/etc /var/ossec/var/db

Salin arsip itu ke tempat yang terpisah dari server Wazuh. Ingat, backup yang disimpan di server yang sama tidak menolong saat server itu hilang. Uji juga pemulihannya, bukan hanya memastikan berkasnya tersimpan.

#Snapshot Indexer

Data alert di indexer di-backup lewat mekanisme snapshot. Snapshot bisa dikirim ke repository berupa filesystem atau object storage. Pastikan path repository bisa diakses node indexer, lalu daftarkan repository tersebut.

curl -sk -X PUT https://localhost:9200/_snapshot/wazuh-backup -H "Content-Type: application/json" -d '{"type": "fs", "settings": {"location": "/backup/snapshots"}}'

curl -sk -X PUT https://localhost:9200/_snapshot/wazuh-backup/snapshot-1?wait_for_completion=true

Snapshot bersifat point-in-time: mengambil kondisi data pada saat dijalankan. Jadwalkan snapshot secara teratur, misalnya setiap hari di luar jam sibuk, dan simpan beberapa generasi. Dengan begitu, saat terjadi kerusakan data atau penghapusan yang tidak disengaja, kita bisa kembali ke titik terakhir yang sehat.

#Strategi DR untuk Manager Cluster

Disaster recovery bukan hanya soal memiliki salinan data, tetapi juga proses yang teruji untuk kembali berdiri. Untuk arsitektur cluster, mulai dari yang paling krusial: kunci dan identitas agent di client.keys. Tanpa salinan ini, seluruh agent harus di-enroll ulang satu per satu setelah pemulihan.

Dokumentasikan topologi, versi, dan langkah pemulihan langkah demi langkah. Tentukan target pemulihan yang masuk akal: berapa lama sistem boleh mati, dan seberapa banyak data yang boleh hilang. Dari sini kalian tahu seberapa sering backup harus dijalankan dan seberapa cepat prosedur restore harus bekerja.

Terakhir, lakukan latihan pemulihan secara berkala. Latihan ini akan menemukan lubang yang tidak terlihat saat membaca dokumentasi, seperti izin berkas yang salah atau path repository yang tidak tersambung. Tim yang pernah memulihkan Wazuh dari nol akan jauh lebih tenang saat insiden sungguhan terjadi.

#Penutup

Di episode 20 ini kalian mempraktikkan cara merawat Wazuh:

• Status cluster indexer dibaca sebagai hijau, kuning, atau merah.
• Log manager menyimpan jejak kesalahan yang paling berguna saat troubleshooting.
• Kesehatan agent dipantau dari dashboard dan log di kedua sisi.
• API Wazuh membuka jalan untuk pemantauan otomatis.
• Konfigurasi manager di-backup dengan arsip yang disimpan terpisah.
• Snapshot indexer menyelamatkan data alert dari kehilangan.
• Strategi DR baru lengkap setelah prosedurnya benar-benar diuji.

Inti yang harus dibawa pulang:

• Wazuh sendiri harus masuk daftar prioritas pemantauan harian.
• Status merah indexer adalah keadaan darurat yang wajib ditangani cepat.
• Backup tanpa uji pemulihan hanyalah ilusi keamanan.
• Kunci agent adalah aset paling krusial untuk dipulihkan.
• Jadwalkan snapshot dan simpan beberapa generasi.
• Latih pemulihan secara berkala sebelum benar-benar dibutuhkan.

Di episode 21 kita menoleh ke masa depan: fitur-fitur modern di versi stabil terbaru dan roadmap Wazuh 5.0. Sampai jumpa!