Logging & Monitoring
Centralised Logging: A Practical Starting Point for KaliLinux.net Labs
Start centralised logging in a Kali Linux lab using rsyslog and journald. KaliLinux.net shows a minimal collector setup for CTF and defence practice.

Saat bikin lab Kali Linux, perhatian biasanya lebih banyak ke nmap, Wireshark, atau Metasploit. Centralised logging jarang dapet porsi yang sama. Padahal itu keliru bangeet. Satu VM Kali aja bisa menghasilkan ribuan entri journal dalam satu sesi CTF, dan baca semuanya dari satu terminal makin ribet begitu ada mesin kedua yang ikut nimbrung di jaringan. KaliLinux.net udah bahas beberapa topik lab dan sertifikasi, dan panduan ini ngambil langkah pertama yang praktis: ngumpulin log dari node-node Kali ke satu tempat tanpa beli SIEM.
What counts as centralised logging in a small Kali lab
Centralised logging artinya log dari dua sistem atau lebih nyampe ke satu kolektor, biasanya lewat UDP atau TCP. Di lab kecil yang sah, kolektornya bisa berupa mesin Kali kedua yang jalanin rsyslog mode server. Nilai utamanya bukan di software-nya. Tapi di satu timeline. Waktu percobaan CTF nimbulin auth failure di satu VM, koneksi di VM kedua, dan error daemon di workstation Kali, urutan kejadian jadi penting. Satu tampilan gabungan bikin urutan itu lebih gampang direkonstruksi.
Di lab legal atau setup belajar sertifikasi, centralised logging bantu kamu:
- Gabungin log auth, service, dan daemon dari beberapa node Kali jadi satu aliran yang bisa dicari
- Ngurangin kemungkinan ada clue yang nyangkut di mesin yang lupa dicek
- Bikin catatan berbasis waktu buat aktivitas yang sah dalam writeup CTF
Nggak perlu infrastruktur pihak ketiga. Dua VM Kali dan satu jaringan host-only udah cukup.
Minimal setup with rsyslog and journald
Di instalasi default Kali 2024.1, systemd-journald aktif sebagai layanan logging lokal. Kamu bisa cek pesan lokal pakai journalctl -xe. Buat koleksi terpusat, rsyslog cocok karena bisa nerusin sekaligus nerima lewat TCP. Install di node Kali mana pun yang bakal ngirim log:
sudo apt update
sudo apt install rsyslog
Terus bikin aturan forwarding di /etc/rsyslog.d/ kayak gini:
*.* @@192.168.56.10:514
Tanda @@ dobel artinya TCP. @ tunggal artinya UDP. TCP jadi pilihan default yang lebih aman buat lab kecil karna bisa ngirim ulang paket yang ilang, meskipun tetap plain text kalo belum ditambah TLS. Jagain traffic-nya di jaringan host-only terisolasi atau VLAN lab privat. Kolektor butuh modul imtcp aktif dan aturan buat nyimpen pesan masuk. Contoh awalnya:
module(load="imtcp")
input(type="imtcp" port="514")
Restart rsyslog di kedua sisi, terus kirim tes pakai logger "central log test". Opsi sintaks lengkap ada di dokumentasi rsyslog
.
Reading the central stream without a SIEM
Begitu pesan mulai masuk, tail -f di file log kolektor biasanya udah cukup buat cek awal. Kalo kamu nerusin ke journald di kolektor, journalctl -f ngasih tampilan live yang sama. Pakai filter simpel dulu sebntar sebelum nyobain alat yang lebih berat. Contohnya:
grep "sshd" /var/log/remote.log | tail -n 20
Satu baris itu nunjukin aktivitas terbaru terkait SSH dari semua VM yang nerusin log. Tambah awk buat nampilin cuma timestamp dan host sumber kalo kamu butuh timeline yang ringkas. Wireshark bisa nangkep paket syslog kalo kamu curiga ada masalah konfigurasi, tapi traffic syslog yang belum dienkripsi nggak boleh lewat jaringan yang bukan kamu kendaliin.
Buat latihan defensive, centralised logging bukan tujuan akhir. Ini kebiasaan. Mesin Kali yang nyatet aksi sahnya sendiri ngasih kamu bukti buat writeup, cara lebih cepet buat nemuin misconfig, dan alur kerja ala SOC yang realistis. Tetep jaga scope di sistem yang kamu punya atau yang secara eksplisit diizinin buat dites.