6 Cara Network Engineer Pantau Log Keamanan Server Pakai Zabbix Docker Real-Time

Coba tanya diri kamu sendiri: kapan terakhir kali kamu benar-benar buka file /var/log/auth.log di server kamu? Kalau jawabannya “nggak inget”, kamu nggak sendirian. Banyak sysadmin yang sibuk urus uptime dan performa, tapi lupa kalau log keamanan itu sering jadi jejak paling jujur soal apa yang sebenarnya terjadi di server mereka.

Sebagai Network Engineer yang udah bolak-balik pegang infrastruktur klien, di lapangan sering nemuin kasus server yang “kelihatannya baik-baik saja” padahal log-nya penuh percobaan login mencurigakan. Masalahnya bukan kurang niat, tapi kurang visibilitas real-time. Untungnya, kalau kamu udah punya Zabbix Docker buat monitoring performa, sebenarnya infrastruktur yang sama bisa langsung dipakai buat mendeteksi ancaman keamanan tanpa perlu beli tools tambahan yang ribet.

Artikel ini akan bahas tuntas cara memanfaatkan Zabbix Docker yang sudah kamu punya untuk jadi sistem deteksi dini serangan. Kita akan fokus ke studi kasus paling umum: serangan brute force lewat SSH. Yuk kita mulai dari fondasi arsitekturnya dulu.

1. Kenapa Wajib Pakai Zabbix Agent Active untuk Log Security?

Banyak orang yang udah pakai Zabbix Docker buat monitoring CPU dan memory, tapi belum ngerti bedanya mode passive dan active. Padahal buat urusan monitoring keamanan, pilihan tipe koneksi ini krusial banget.

Kelemahan Mode Passive di Konteks Keamanan

Di mode passive, alurnya begini: Zabbix Server yang inisiatif nanya ke agent secara berkala, biasanya tiap 1-5 menit sekali tergantung konfigurasi. Buat metrik seperti disk usage, delay segitu nggak masalah.

Tapi bayangkan kalau itu diterapkan buat log audit keamanan. Penyerang bisa saja sudah berhasil brute force password dalam rentang 2-3 menit itu, sementara Zabbix baru “nanya” ke agent setelah semuanya kejadian.

Keunggulan Mode Active untuk Deteksi Instan

Dengan tipe “Zabbix agent (active)”, arah komunikasinya kebalikannya. Agent di sisi target-lah yang proaktif mengirim data ke server, begitu ada perubahan baru di file yang dipantau.

Untuk kebutuhan monitoring keamanan real-time, ini jelas jauh lebih unggul. Begitu ada baris baru “Failed password” nongol di log, data langsung dikirim ke Zabbix Docker dalam hitungan detik, bukan menunggu siklus polling.

Gambaran Topologi Lengkap

Sebelum masuk konfigurasi teknis, mari kita samakan pemahaman soal arsitektur yang bakal kita bangun bersama:

• Mesin 1: Menjalankan Zabbix Docker via docker-compose, berperan sebagai pusat pengumpul data monitoring
• Mesin 2: Server fisik terpisah dengan Linux Host, dipasangi Zabbix Agent2 dan berperan sebagai target yang dipantau
• Koneksi antar keduanya lewat jaringan lokal langsung, baik pakai kabel LAN maupun switch
• Mesin 2 secara aktif mengirim isi log auth secara streaming ke Mesin 1 setiap kali ada baris baru yang cocok

Topologi seperti ini sebenarnya nggak jauh beda dari setup monitoring performa biasa yang mungkin sudah kamu punya. Bedanya cuma di jenis data yang dipantau dan cara agent berkomunikasi ke server.

2. Konfigurasi Sisi Server Target (Linux Host)

Sekarang saatnya praktik. Login ke Mesin 2, server fisik yang mau kita pantau log keamanannya, lewat SSH.

Memberi Izin Baca File Log ke User Zabbix

Ini langkah yang sering terlewat oleh pemula. Secara default, user zabbix yang menjalankan service agent nggak punya izin baca file /var/log/auth.log, karena file ini biasanya cuma bisa diakses root atau grup tertentu.

Kalau langkah ini kamu lewatkan, item log monitoring bakal gagal terus dengan pesan error permission denied. Jalankan perintah berikut untuk menambahkan user zabbix ke grup yang tepat.

sudo usermod -aG adm zabbix

Beberapa distro Linux menggunakan grup log sebagai pemilik file auth, jadi sesuaikan kalau perlu.

sudo usermod -aG log zabbix

Setelah perintah ini dijalankan, service agent perlu di-restart supaya keanggotaan grup baru langsung terbaca.

sudo systemctl restart zabbix-agent2

Menyesuaikan File Konfigurasi Agent2

Buka file konfigurasi utama Zabbix Agent2 untuk mengatur ke mana data harus dikirim.

sudo nano /etc/zabbix/zabbix_agent2.conf

Ada tiga parameter yang wajib kamu perhatikan dan sesuaikan di file ini:

• ServerActive=192.168.33.254 — mengarahkan agent untuk secara aktif mengirim data ke Zabbix Server di Mesin 1
• Hostname=linux-target-security — nama unik yang harus sama persis dengan yang nanti kamu daftarkan di Web UI
• Server=192.168.33.254 — tetap diisi walaupun kita fokus ke mode active, buat jaga-jaga kalau ada passive check tambahan

Simpan file, lalu restart ulang service agent agar seluruh perubahan konfigurasi ini benar-benar aktif.

sudo systemctl restart zabbix-agent2
sudo systemctl enable zabbix-agent2

Deskripsi: “Tampilan terminal file konfigurasi zabbix_agent2.conf yang menunjukkan parameter ServerActive dan Hostname sudah diisi sesuai IP server monitoring.”

3. Setup Item Log Monitoring di Web UI Zabbix Docker

Setelah sisi agent beres, sekarang kita pindah ke Web UI Zabbix Docker untuk mendaftarkan host baru dan bikin item khusus pemantauan log.

Mendaftarkan Host Target

Buka browser, akses IP Mesin 1 kamu di port 8080. Masuk ke menu Data collection > Hosts, klik Create host.

Lengkapi form pendaftaran host dengan detail berikut:

• Host name: sama persis dengan Hostname yang tadi diisi di konfigurasi agent
• Host groups: buat grup baru, misalnya “Log Security Monitoring”
• Interfaces: isi IP fisik server target untuk dokumentasi, meskipun mode active nggak wajib butuh ini

Cara Mengatasi Error “No Matches Found”

Ini kendala klasik yang sering bikin pemula bingung saat baru pertama kali pakai Zabbix Docker. Ketika kamu klik tab Templates dan langsung ketik “Linux by Zabbix agent” di kolom pencarian, sering muncul pesan “No matches found”.

Penyebabnya sederhana: kolom Template Group belum diarahkan ke grup yang benar, jadi hasil pencarian jadi kosong. Ikuti langkah berikut supaya template kamu ketemu:

1. Klik tombol Select di samping kolom Templates, jangan langsung ngetik di kolom pencarian
2. Pada popup yang muncul, ubah dropdown Host Group menjadi Templates/Operating systems
3. Centang manual template “Linux by Zabbix agent active” sesuai kebutuhan mode active kita
4. Klik tombol Select untuk mengonfirmasi
5. Klik Add di bagian bawah form untuk menyimpan host baru ini

Membuat Item Baru untuk Memantau Auth Log

Sekarang bagian terpenting: bikin item yang secara spesifik memantau file /var/log/auth.log. Klik host yang baru dibuat, masuk ke tab Items, lalu klik Create item.

Isi form item dengan konfigurasi berikut:

• Name: kasih nama yang jelas, misalnya “Monitoring Failed SSH Login”
• Type: pilih Zabbix agent (active)
• Key: masukkan key berikut persis seperti ini

log[/var/log/auth.log,"Failed password",,,skip]

Biar kamu paham bukan cuma copy-paste, mari kita bedah key ini satu per satu. Parameter pertama adalah path file yang dipantau, parameter kedua adalah string pattern yang dicari yaitu “Failed password”, dan parameter terakhir skip memastikan Zabbix cuma mengirim baris baru yang match, bukan seluruh isi file dari awal setiap kali agent restart.

• Type of information: pilih Log
• Update interval: biarkan pengaturan default karena mode active akan otomatis push data begitu ada perubahan

Klik Add untuk menyimpan konfigurasi item ini.

Deskripsi: “Form pembuatan item baru di Zabbix Docker dengan Key log auth.log Failed password dan tipe Zabbix agent active sudah terisi lengkap dan siap disimpan.”

4. Studi Kasus: Simulasi Serangan Brute Force SSH

Sekarang saatnya buktikan setup kita bekerja dengan mensimulasikan skenario serangan yang realistis. Ini bagian yang paling saya suka jelasin ke klien, karena hasilnya kelihatan langsung.

Bagaimana Serangan Ini Biasanya Terjadi

Bayangkan ada penyerang dari luar jaringan lokal kamu yang mencoba masuk lewat SSH port 22. Mereka nggak tahu password yang benar, jadi mereka pakai script otomatis untuk mencoba ratusan kombinasi secara berurutan dalam waktu singkat.

Setiap percobaan yang gagal akan otomatis tercatat sebagai baris baru di /var/log/auth.log, kira-kira seperti berikut:

Failed password for root from 198.51.100.22 port 41290 ssh2
Failed password for admin from 198.51.100.22 port 41291 ssh2
Failed password for root from 198.51.100.22 port 41292 ssh2

Kalau nggak ada sistem monitoring yang memantau ini secara real-time, log seperti ini bisa numpuk berhari-hari tanpa ada yang notice. Padahal ini indikator jelas ada serangan brute force yang lagi berlangsung di server fisik kamu.

4. Studi Kasus: Simulasi Serangan Brute Force SSH

Sekarang saatnya buktikan setup kita bekerja dengan mensimulasikan skenario serangan yang realistis. Ini bagian yang paling saya suka jelasin ke klien, karena hasilnya kelihatan langsung.

Bagaimana Serangan Ini Biasanya Terjadi

Bayangkan ada penyerang dari luar jaringan lokal kamu yang mencoba masuk lewat SSH port 22. Mereka nggak tahu password yang benar, jadi mereka pakai script otomatis untuk mencoba ratusan kombinasi secara berurutan dalam waktu singkat.

Setiap percobaan yang gagal akan otomatis tercatat sebagai baris baru di /var/log/auth.log, kira-kira seperti berikut:

Failed password for root from 198.51.100.22 port 41290 ssh2
Failed password for admin from 198.51.100.22 port 41291 ssh2
Failed password for root from 198.51.100.22 port 41292 ssh2

Kalau nggak ada sistem monitoring yang memantau ini secara real-time, log seperti ini bisa numpuk berhari-hari tanpa ada yang notice. Padahal ini indikator jelas ada serangan brute force yang lagi berlangsung di server fisik kamu.

4. Studi Kasus: Simulasi Serangan Brute Force SSH

Sekarang saatnya buktikan setup kita bekerja dengan mensimulasikan skenario serangan yang realistis. Ini bagian yang paling saya suka jelasin ke klien, karena hasilnya kelihatan langsung.

Bagaimana Serangan Ini Biasanya Terjadi

Bayangkan ada penyerang dari luar jaringan lokal kamu yang mencoba masuk lewat SSH port 22. Mereka nggak tahu password yang benar, jadi mereka pakai script otomatis untuk mencoba ratusan kombinasi secara berurutan dalam waktu singkat.

Setiap percobaan yang gagal akan otomatis tercatat sebagai baris baru di /var/log/auth.log, kira-kira seperti berikut:

Failed password for root from 198.51.100.22 port 41290 ssh2
Failed password for admin from 198.51.100.22 port 41291 ssh2
Failed password for root from 198.51.100.22 port 41292 ssh2

Kalau nggak ada sistem monitoring yang memantau ini secara real-time, log seperti ini bisa numpuk berhari-hari tanpa ada yang notice. Padahal ini indikator jelas ada serangan brute force yang lagi berlangsung di server fisik kamu.

Membangun Trigger Custom dengan Fungsi last()

Item log yang sudah kita buat tadi baru sebatas mengumpulkan data mentah, belum ada mekanisme alarm otomatis. Kita perlu bikin Trigger yang akan menyalakan alert kalau pola serangan terdeteksi.

Masuk ke tab Triggers pada host yang sama, klik Create trigger. Beri nama yang deskriptif, misalnya “SSH Brute Force Attempt Detected”.

Untuk bagian Expression, jangan ketik manual dari nol. Klik tombol Add, lalu cari item log yang sudah kamu buat tadi, misalnya “Monitoring Failed SSH Login”.

Zabbix akan otomatis membangun expression menggunakan fungsi last(), yang mengambil nilai baris log paling baru yang masuk ke item tersebut. Hasilnya kira-kira seperti berikut.

last(/Debian-Testing/log[/var/log/auth.log,"Failed password",,,skip])=0

Sedikit koreksi penting di sini: karena item log kita sudah difilter dengan pattern “Failed password” di dalam key-nya, setiap baris baru yang masuk ke item ini sudah pasti merupakan baris yang match. Jadi last() di konteks item log bukan mengembalikan angka 0 atau 1, melainkan konten teks baris log terakhir yang tertangkap.

Artinya, expression yang lebih tepat untuk mendeteksi kemunculan baris baru cukup begini, karena keberadaan nilai baru pada log item yang sudah difilter itu sendiri sudah menandakan ada percobaan gagal login.

last(/Debian-Testing/log[/var/log/auth.log,"Failed password",,,skip])<>""

Kalau kamu mau trigger baru menyala setelah beberapa kali percobaan gagal berturut-turut dalam rentang waktu tertentu, bukan cuma satu baris saja, gunakan fungsi count() sebagai pembanding tambahan lewat Add sekali lagi di Expression Constructor, lalu gabungkan dengan operator and. Berikut contoh kombinasinya untuk deteksi lebih dari 4 kali percobaan gagal dalam 1 menit terakhir.

count(/Debian-Testing/log[/var/log/auth.log,"Failed password",,,skip],1m)>4

Set Severity ke level High atau Disaster, tergantung seberapa sensitif server target kamu. Untuk server produksi yang penting, saya selalu sarankan pakai level Disaster supaya tim langsung ambil tindakan begitu notifikasi masuk.

Melihat Alert Muncul di Dashboard Problems

Setelah simulasi serangan dijalankan dan lebih dari 4 percobaan gagal terdeteksi dalam 1 menit, kamu akan melihat perubahan langsung di menu Monitoring > Problems.

Berikut yang biasanya terjadi di dashboard Zabbix Docker kamu:

• Baris baru muncul berwarna merah menyala sesuai tingkat severity yang di-set tadi
• Nama trigger “SSH Brute Force Attempt Detected” langsung tampil beserta timestamp kejadian
• Kolom Age menunjukkan durasi masalah ini masih berlangsung sejak pertama kali terdeteksi
• Kalau media type notifikasi seperti Telegram atau email sudah aktif, pesan otomatis langsung terkirim ke tim kamu

Bagi kamu yang berprofesi sebagai Network Engineer, kecepatan deteksi seperti ini adalah bukti nyata bahwa infrastruktur monitoring yang sudah ada bisa dioptimalkan lebih jauh dari sekadar cek uptime. Ini value tambahan besar buat klien atau perusahaan tempat kamu bekerja.

5. Optimasi Lanjutan Setelah Alert Aktif

Deteksi cuma langkah awal. Sebagai praktisi infrastruktur, kamu juga perlu tahu langkah tindak lanjut supaya sistem monitoring ini makin matang.

Kombinasikan dengan Automasi Blocking

Zabbix Docker memang kuat di sisi visibilitas, tapi bukan alat pemblokiran otomatis secara default. Buat mitigasi aktif, kombinasikan setup ini dengan tools seperti Fail2Ban yang bisa langsung memblokir IP penyerang di level firewall begitu ambang batas tertentu terlampaui.

Kalau kamu butuh referensi lebih detail soal hardening server dan konfigurasi firewall lanjutan, kamu bisa cek artikel terkait lainnya di tecotechno.com yang membahas topik keamanan infrastruktur secara mendalam.

Bikin Dashboard Khusus untuk Tim Non-Teknis

Selain trigger teknis, ada baiknya kamu susun dashboard terpisah yang lebih mudah dibaca buat tim manajemen atau non-teknis. Tampilkan ringkasan seperti jumlah percobaan login gagal per hari, daftar IP paling aktif mencoba brute force, dan status keseluruhan sistem.

Dashboard seperti ini bikin laporan monitoring keamanan kamu lebih mudah dikomunikasikan ke stakeholder yang nggak paham detail teknis. Kalau kamu tertarik dengan pendekatan konsultasi infrastruktur monitoring skala enterprise, tim di semarsoft.com juga sering membahas studi kasus serupa dari sisi implementasi bisnis.

Sesuaikan Threshold Sesuai Kondisi Lapangan

Threshold 4 kali dalam 1 menit ini cukup ketat, jadi ada kemungkinan memicu false positive dari user yang salah ketik password sendiri berkali-kali. Lakukan review berkala terhadap riwayat alert untuk menyesuaikan angka ini dengan kondisi nyata di lapangan kamu.

Kalau kamu punya banyak user yang sering typo, mungkin perlu naikkan threshold jadi 6 atau 8 kali. Tapi kalau server kamu menyimpan data sensitif dan jarang diakses user legit lewat SSH langsung, threshold 4 kali sudah pas untuk deteksi dini yang agresif.

Kesimpulan: Zabbix Docker Bisa Lebih dari Sekadar Monitoring Performa

Kita sudah bahas tuntas bagaimana Zabbix Docker yang mungkin sudah kamu pakai buat monitoring performa, ternyata bisa dioptimalkan jadi sistem monitoring keamanan yang tangguh. Mulai dari alasan wajib pakai mode agent active, setup izin akses log audit di Linux Host, sampai konfigurasi item log dengan key khusus untuk memantau file auth.log secara real-time.

Simulasi serangan brute force yang kita praktikkan membuktikan bahwa trigger custom dengan fungsi find() benar-benar efektif mendeteksi pola serangan dalam hitungan menit. Ini jauh lebih baik dibanding baru sadar ada masalah setelah server fisik kamu benar-benar kebobolan.

Buat kamu yang berprofesi sebagai sysadmin atau Network Engineer, memanfaatkan Zabbix Docker untuk kebutuhan security seperti ini adalah cara cerdas memaksimalkan infrastruktur yang sudah ada tanpa perlu investasi tools baru. Satu platform, dua fungsi sekaligus: performa dan keamanan.

Ke depannya, kamu bisa eksplorasi lebih jauh soal membuat trigger custom lain untuk pola serangan berbeda, seperti percobaan akses ke port yang nggak seharusnya terbuka atau anomali traffic mencurigakan lainnya. Fondasi deteksi real-time yang sudah kamu kuasai lewat Zabbix Docker di artikel ini akan selalu jadi bekal berharga buat menjaga infrastruktur kamu tetap aman dan terpantau.

Jika Ada Kendala Setup bisa kunjungi artike setup dan Klik Di Sini