Belajar Kerberos - Monitoring dan Logging

#Pendahuluan

Di episode 21 kalian menutup gerbang: enkripsi AES saja, preauth diwajibkan, lifetime pendek, keytab diamankan, dan serangan umum dipetakan. Tapi semua pertahanan itu buta tanpa penglihatan. Serangan tidak mengetuk pintu — mereka masuk lewat anomali yang kelihatan hanya jika kalian memantau log dan metrik.

Episode 22 membangun "mata" realm: logging di sisi KDC dan klien, analisis log untuk membaca sinyal kegagalan, alat monitoring seperti ELK dan Grafana, serta metrik yang harus selalu dalam pengawasan. Di sinilah deteksi yang disebutkan di episode 21 menjadi operasional.

#Logging di Sisi KDC

KDC MIT Kerberos menulis semua aktivitas ke log yang bisa dikonfigurasi penuh. Semua pesan — autentikasi, otorisasi, dan error — berkumpul di satu tempat sehingga bisa dianalisis.

#Lokasi dan Konfigurasi Log

Konfigurasi logging dilakukan di bagian [logging] pada /etc/krb5.conf (atau kdc.conf):

kdc — log utama aktivitas KDC: semua AS_REQ, TGS_REQ, dan hasilnya.
admin_server — log perubahan yang dilakukan lewat kadmin (addprinc, modprinc, delprinc).
default — log library Kerberos di sisi mesin (klien dan service).

Selain FILE, tujuan bisa berupa SYSLOG:severity:facility untuk meneruskan ke syslog (misalnya SYSLOG:INFO:LOCAL0), atau DEVICE=/dev/null untuk membuang output. Memakai syslog memudahkan integrasi dengan SIEM nantinya.

#Log Levels

Log KDC tidak punya level DEBUG/INFO yang bisa dipilih per-module seperti aplikasi web. Tingkat detail diatur lewat:

Severity syslog (INFO, ERR, NOTICE) saat memakai SYSLOG:.
Pesan pesan yang diklasifikasikan KDC: INFO untuk keberhasilan, ERR untuk kegagalan.
Debug mendalam saat butuh jejak lengkap, misalnya menaikkan logging di sisi klien atau memakai KRB5_TRACE (dibahas di bagian klien).

#Autentikasi, Otorisasi, dan Error

Log KDC menampung tiga kategori utama:

Log autentikasi — setiap permintaan tiket: siapa meminta TGT, dari IP mana, enctypes yang dipakai, dan apakah berhasil.
Log otorisasi — permintaan service ticket (TGS_REQ): principal mana meminta akses ke layanan mana.
Log error — kegagalan: preauth gagal, principal tidak ditemukan, clock skew, enkripsi tidak cocok.

Cuplikan berikut menunjukkan pola pesan yang akan sering kalian temui (format bisa bervariasi antar versi, perhatikan isinya):

Pola log KDC (contoh)

AS_REQ alice@EXAMPLE.COM from 10.0.0.50: PREAUTH_FAILED
TGS_REQ alice@EXAMPLE.COM: S_PRINCIPAL_UNKNOWN
AS_REQ 10.0.0.51: CLOCK_SKEW: time is off by 360 seconds
ISSUE: authtime ... alice@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM

#Logging di Sisi Klien

KDC bukan satu-satunya sumber log. Sisi klien sering menyimpan jawaban yang tidak terlihat di log server — misalnya saat permintaan tidak pernah sampai ke KDC.

#KRB5_TRACE untuk Debugging

Variabel lingkungan KRB5_TRACE membuat library klien menuliskan jejak lengkap setiap langkah Kerberos ke file yang ditunjuk. Gunakan KRB5_TRACE=/dev/stdout untuk melihat langsung:

Trace klien dengan KRB5_TRACE

export KRB5_TRACE=/dev/stdout
kinit alice@EXAMPLE.COM

Jejak ini menunjukkan seluruh alur: pencarian realm, penemuan KDC, pengiriman AS_REQ, enctypes yang ditawarkan, sampai hasil akhir. Ini alat nomor satu saat autentikasi gagal dengan alasan yang tidak jelas.

#Debugging Sisi Klien dan Log Aplikasi

Log library mengalir ke tujuan default di [logging] (misalnya krb5libs.log).
Aplikasi berbasis GSSAPI menulis log sendiri; cari gssapi atau kerberos di konfigurasi logging aplikasi (misalnya modul Apache, SSH, NFS).
SSSD menyimpan log lengkap di /var/log/sssd/ — saat SSSD gagal mengambil tiket, jejaknya ada di sana, bukan di KDC.

#Analisis Log

Log KDC yang baik akan menceritakan masalah sebelum user sempat melaporkannya. Kenali pola berikut:

Pola di log	Arti	Tindakan
`PREAUTH_FAILED` berulang	Password salah atau preauth bermasalah	Verifikasi password, periksa waktu
`CLOCK_SKEW`	Selisih jam lebih dari toleransi 5 menit	Sinkronkan dengan NTP segera
Enctypes tidak cocok	Klien hanya menawarkan enkripsi lemah	Bandingkan `klist -e` dan konfigurasi KDC
`Principal not found in Kerberos database`	Principal tidak terdaftar	Periksa ejaan realm dan akun
`Ticket expired`	Tiket sudah lewat masa berlakunya	Ulangi `kinit`, periksa lifetime

Failed authentication attempts: lonjakan PREAUTH_FAILED dari satu IP atau satu user adalah sinyal brute force atau password-spray.
Clock skew errors: muncul berulang berarti infrastruktur waktu bermasalah — KDC menolak tiket dari mesin yang jamnya melenceng.
Encryption type mismatches: kegagalan berulang dengan isyarat enkripsi menandakan klien lama atau konfigurasi downgrade.
Principal not found errors: sering terjadi karena salah realm, salah ejaan, atau SPN belum terdaftar.
Ticket expiration issues: tiket yang kedaluwarsa di tengah job panjang biasanya karena lifetime terlalu pendek atau renew tidak diatur.

Note

Pola log KDC bisa berbeda-beda antar versi MIT dan antara MIT dengan AD. Fokus pada isi pesan — PREAUTH_FAILED, CLOCK_SKEW, S_PRINCIPAL_UNKNOWN — karena teks khasnya cukup konsisten untuk dijadikan aturan deteksi.

#Alat Monitoring

Log saja belum cukup bila tersebar di ratusan host. Gabungkan dengan alat agregasi dan visualisasi:

Splunk / ELK untuk agregasi log: semua log KDC dan klien diteruskan ke satu tempat — lewat rsyslog atau syslog-ng di sisi KDC menuju Elasticsearch/Loki, atau langsung ke Splunk. Di sinilah deteksi anomali dari episode 21 dijalankan sebagai rule.
Grafana untuk metrik: visualisasi metrik real-time. Prometheus bisa mengambil metrik host (CPU, memory, load) dan metrik kustom hasil parsing log KDC.
Custom monitoring scripts: script sederhana yang mengekstrak jumlah AS_REQ sukses/gagal per menit dari log KDC dan mengekspornya ke Prometheus.
SIEM integration: semua alert yang berbau keamanan — anomali tiket, downgrade enkripsi, perubahan delegation — diteruskan ke SIEM untuk korelasi dengan data lain.

#Metrik yang Dipantau

Metrik adalah detak jantung realm. Awali dengan yang paling berdampak:

Metrik	Cara mengukur	Indikator masalah
Auth success/failure rates	Hitung dari log AS_REQ/TGS_REQ	Lonjakan gagal = brute force atau misconfig
KDC performance	Latensi respons AS_REQ, CPU KDC	KDC lambat = kapasitas mendekati batas
Database load	Waktu query `kdb5_util`, ukuran database	DB membengkak = kebijakan retensi perlu audit
Ticket issuance rate	Jumlah tiket per menit	Peningkatan tajam = lalu lintas baru atau anomali
Service response times	Waktu hingga service menerima tiket	Memburuk = masalah jaringan atau KDC

Authentication success/failure rates adalah metrik keamanan utama: distribusi normal gagal vs sukses harus stabil; perubahan mendadak memicu investigasi.
KDC performance mengukur seberapa cepat KDC menjawab; mulailah dengan menambahkan replica KDC saat latensi memburuk (topik episode 24).
Database load memantau kesehatan database principal; pertumbuhan tak wajar menandakan akun liar.
Ticket issuance rate mencerminkan volume autentikasi; nilai ini jadi baseline untuk mendeteksi serangan permintaan tiket massal.
Service response times menunjukkan pengalaman end-user: tiket sampai atau tidak tepat waktu.

Script kustom sederhana: hitung AS_REQ sukses per menit

tail -f /var/log/krb5kdc.log | grep -c "ISSUE" | while read n; do echo "asreq_ok $n"; done

Script semacam ini mudah disambungkan ke Prometheus textfile collector dan divisualisasikan di Grafana — dari sana, alerting tinggal selangkah lagi.

#Penutup

Episode 22 ini memberi kalian penglihatan: konfigurasi logging KDC di [logging], jejak klien dengan KRB5_TRACE, analisis pola kegagalan seperti PREAUTH_FAILED, CLOCK_SKEW, dan S_PRINCIPAL_UNKNOWN, hingga alat monitoring (ELK, Grafana, SIEM) dan metrik kunci yang wajib dipantau.

Inti yang harus dibawa pulang:

Arahkan log KDC, admin server, dan library ke file atau syslog via [logging] di krb5.conf.
KRB5_TRACE=/dev/stdout mengungkap seluruh alur autentikasi dari sisi klien.
Kenali pola log: PREAUTH_FAILED untuk password, CLOCK_SKEW untuk waktu, S_PRINCIPAL_UNKNOWN untuk principal.
Pantau metrik utama: rasio sukses/gagal, performa KDC, dan ticket issuance rate — dan beri alert.

Di episode 23 kalian akan memakai semua mata ini untuk menyembuhkan: Troubleshooting Kerberos — memetakan error umum ke solusinya, teknik debugging dengan KRB5_TRACE dan klist -e, hingga masalah jaringan dan keytab. Sampai jumpa!