Belajar Linux - System Logging, Rotation & Auditing

#Pendahuluan

Setelah di episode 22 sebelumnya kita membahas task automation dengan cron jobs dan systemd timers — termasuk mengalihkan output skrip ke file log agar setiap eksekusi terekam — pada episode kali ini kita akan membahas log itu sendiri: dari mana log berasal, bagaimana mereka dikelola, dan bagaimana menjadikannya alat yang menyelamatkan kalian saat produksi bermasalah.

Bayangkan log sebagai kotak hitam pesawat. Pilot tidak menulis kotak hitam itu untuk bersenang-senang — ia ada supaya ketika ada insiden, para ahli bisa mundur selangkah dan menjawab pertanyaan: apa yang sebenarnya terjadi sebelum, saat, dan sesudah kejadian? Di dunia server, log adalah kotak hitam yang sama. Saat aplikasi error di jam 2 pagi, saat server di-reboot tanpa izin, atau saat ada percobaan login mencurigakan — log adalah saksi bisu yang menceritakan semuanya secara kronologis.

Masalahnya, log tidak mengelola dirinya sendiri. Tanpa kebijakan rotasi, file log akan membengkak sampai menghabiskan seluruh disk — dan ironisnya, sistem yang mati karena disk penuh adalah penyebab downtime yang sangat umum. Tanpa kebijakan retensi, log tidak akan berguna saat kalian butuh melihat kejadian tiga bulan lalu. Dan tanpa arsitektur yang benar, log penting bisa tersebar di banyak tempat sehingga hampir mustahil dilacak.

Pada episode ini kita akan membedah arsitektur logging Linux: mengenal isi /var/log/ dan log-log pentingnya, memahami cara kerja logrotate untuk membatasi ukuran dan umur log, mengenal rsyslog untuk logging terpusat, serta pengenalan singkat auditd sebagai lapisan jejak keamanan. Kita tutup dengan praktik menambahkan konfigurasi logrotate untuk log aplikasi kustom.

#Pembahasan Utama

#Arsitektur Logging: Kenapa Linux Menulis Semuanya

Linux menganut filosofi bahwa hampir semua kejadian sistem harus bisa dicatat. Beberapa program menulis lognya sendiri langsung ke file, tetapi mayoritas mengirimkan pesan ke daemon logging pusat — syslog — yang kemudian memutuskan ke mana pesan tersebut disimpan.

Di sistem modern, arsitektur ini melibatkan dua komponen yang sering dianggap satu:

• rsyslog — daemon logging klasik yang menerima pesan dari kernel dan aplikasi, lalu menulisnya ke file teks di /var/log/ atau meneruskannya ke server lain. Ini adalah "pos penjaga" yang membaca pesan, menilai sumber dan tingkat keparahannya, lalu mengantarkannya ke tempat yang tepat.
• systemd-journald — komponen dari systemd (dibahas detail di episode 14) yang menampung log terstruktur ber-timestamp dalam format biner, diakses lewat journalctl. journald dan rsyslog bisa berjalan berdampingan: journald menangkap semuanya dengan rapi, rsyslog menuliskannya ke file teks yang familiar.

Kenapa kalian perlu memahami keduanya? Karena saat troubleshooting, kalian akan bertemu dua dunia sekaligus: file teks di /var/log/ yang dibaca dengan grep, dan journal biner yang dibaca dengan journalctl. Admin yang hanya menguasai satu di antaranya sering kehilangan informasi penting. Untungnya, rsyslog di sebagian besar distro sudah dikonfigurasi untuk membaca dari journal, sehingga keduanya sinkron.

#Mengenal Direktori /var/log/ dan Log Penting

Semua log utama berada di bawah /var/log/. Mari kita petakan yang paling penting:

Perbedaan nama file antara keluarga Debian dan RHEL ini adalah jebakan klasik. Admin yang terbiasa membaca /var/log/auth.log di Ubuntu akan bingung mencarinya di server Rocky — jawabannya di /var/log/secure. Begitu pula syslog vs messages. Ketika kalian pindah-pindah distro, biasakan mengecek dulu isi direktori dengan ls /var/log/ sebelum berasumsi.

Untuk melihat pesan kernel terbaru, dmesg adalah jendela langsung ke ring buffer kernel (dibahas di episode 16):

sudo dmesg -T | tail -30

Dan untuk memeriksa apakah ada yang mencoba login secara tidak wajar, auth.log/secure adalah tempat pertama yang harus kalian buka:

sudo grep "Failed password" /var/log/auth.log | tail -20

Aug  2 02:14:11 app-server sshd[2301]: Failed password for invalid user admin from 203.0.113.45 port 52111 ssh2
Aug  2 02:14:12 app-server sshd[2303]: Failed password for invalid user admin from 203.0.113.45 port 52113 ssh2
Aug  2 02:14:13 app-server sshd[2305]: Failed password for invalid user admin from 203.0.113.45 port 52115 ssh2
Aug  2 02:14:14 app-server sshd[2307]: Failed password for invalid user root from 203.0.113.45 port 52117 ssh2
Aug  2 02:14:15 app-server sshd[2309]: Failed password for invalid user root from 203.0.113.45 port 52119 ssh2

Pola di atas — IP yang sama menyerang terus-menerus dengan username berganti-ganti — adalah tanda khas serangan brute-force yang akan kita lawan dengan fail2ban di episode 25.

#logrotate: Mengapa Log Harus Dirotasi

Ini bagian yang paling sering diremehkan dan paling sering menyebabkan downtime. File log yang tidak dibatasi akan tumbuh tanpa henti. Aplikasi yang verbose seperti web server atau database bisa menulis ratusan MB log per hari — dan ketika partisi / (atau /var) penuh, sistem menjadi tidak stabil: layanan gagal menulis, aplikasi error, bahkan sistem bisa berhenti merespons. Disk penuh karena log adalah penyebab downtime yang membingungkan karena gejalanya tampak tidak berhubungan dengan log.

Solusi klasiknya adalah log rotation: memutar log secara berkala — file lama dipindahkan, dikompresi, disimpan untuk jangka waktu tertentu, lalu dihapus. Alatnya bernama logrotate. Analoginya seperti jurnal harian yang diarsipkan: halaman hari ini selalu siap diisi, halaman kemarin dipindahkan ke buku arsip, dan arsip yang berusia lebih dari batas waktu dibuang.

Konfigurasi logrotate tersebar di dua level. Level global ada di /etc/logrotate.conf, dan level per-aplikasi ada di direktori /etc/logrotate.d/ — satu file untuk satu aplikasi. File global membaca semua file di /etc/logrotate.d/ melalui direktif include. Contoh konfigurasi global yang umum:

weekly
rotate 4
create
include /etc/logrotate.d

weekly berarti rotasi dilakukan seminggu sekali, rotate 4 menyimpan 4 file lama sebelum yang tertua dihapus, dan include /etc/logrotate.d memasukkan semua konfigurasi khusus aplikasi. Setiap distro punya default yang sedikit berbeda, tapi polanya sama.

Direktif yang paling sering dipakai pada level per-aplikasi:

#Mengapa delaycompress dan su Itu Penting

Dua direktif di atas sering disalahpahami, padahal keduanya mencegah dua kelas masalah yang berbeda.

delaycompress menyelesaikan masalah aplikasi yang masih memegang file log. Bayangkan aplikasi menulis ke app.log dan tetap membuka file tersebut. Saat logrotate memutar, file lama diberi nama app.log.1. Jika langsung dikompresi menjadi app.log.1.gz, aplikasi yang masih menulis ke file descriptor lama akan terus menulis ke file yang sudah terkompresi — menghasilkan data rusak atau baris aneh. Dengan delaycompress, kompresi ditunda satu siklus: app.log.1 dibiarkan utuh, dan hanya file yang lebih tua (app.log.2 dan seterusnya) yang dikompresi.

su <user> <group> menyelesaikan masalah permission. Konfigurasi logrotate dijalankan oleh root melalui cron/systemd timer, tetapi file log aplikasi sering dimiliki oleh user aplikasi (misal www-data). Tanpa direktif su, rotasi bisa gagal dengan error error: state file /var/lib/logrotate/status is not owned by root atau Permission denied saat membaca direktori log. Menambahkan su www-data www-data membuat logrotate meniru user tersebut untuk operasi pada log itu.

#Praktik: Konfigurasi logrotate untuk Log Aplikasi Kustom

Misalkan aplikasi kita, myapp, menulis log ke /var/log/myapp/app.log sebagai user myapp. Tanpa konfigurasi apa pun, file itu akan tumbuh tanpa batas. Mari kita tambahkan konfigurasi di /etc/logrotate.d/myapp:

/var/log/myapp/app.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    su myapp myapp
}

Interpretasi baris demi baris: log dirotasi setiap hari (daily), tujuh file lama dipertahankan (rotate 7) — artinya kalian punya riwayat satu minggu. File lama dikompresi (compress), tapi penundaan satu siklus (delaycompress) memberi aplikasi waktu melepas file descriptor. missingok dan notifempty mencegah error saat file kosong atau hilang. create membuat file baru dengan pemilik dan permission yang benar, dan su myapp myapp menjalankan seluruh proses sebagai user aplikasi.

Sekarang, mari kita lihat apa yang terjadi ketika kebijakan rotasi perlu diubah — misalnya menambah retensi dari 7 menjadi 14 hari. Perhatikan diff sebelum dan sesudah:

    daily
    rotate 7
    rotate 14
    compress

Sebelum menerapkan perubahan produksi, verifikasi konfigurasi dengan mode debug dan force:

sudo logrotate -d /etc/logrotate.d/myapp

sudo logrotate -f /etc/logrotate.d/myapp

-d (debug) menampilkan apa yang akan dilakukan tanpa benar-benar melakukannya — langkah wajib sebelum mengubah konfigurasi produksi. Setelah merasa yakin, logrotate -f memaksa rotasi terjadi sekarang sehingga kalian bisa melihat hasilnya langsung.

#Centralized Logging dengan rsyslog

Semakin banyak server yang kalian kelola, semakin sulit memeriksa log satu per satu. Di sinilah centralized logging bekerja: semua server mengirim log ke satu server pusat, sehingga kalian bisa mencari di satu tempat. rsyslog memainkan dua peran di sini — sebagai penerima (server) dan pengirim (client).

Di server pusat, aktifkan penerimaan di /etc/rsyslog.conf (hilangkan tanda komentar pada modul penerimaan, biasanya imtcp), lalu restart. Di server pengirim, tambahkan file forwarding:

auth.*    @@logs.example.com:514
kern.*    @@logs.example.com:514
mail.*    @@logs.example.com:514

Notasi @@ berarti mengirim via TCP (andal, tapi lebih lambat); @ tunggal berarti UDP (cepat, tapi pesan bisa hilang). Setelah file dibuat, terapkan dengan me-restart rsyslog:

sudo systemctl restart rsyslog

Dengan pola ini, kalian bisa membangun SIEM sederhana (Security Information and Event Management) — mengumpulkan semua log auth dari puluhan server ke satu tempat untuk dianalisis. Ini langkah pertama menuju keamanan yang bisa diobservasi, yang akan kita kaitkan dengan audit di episode 25.

#Pengenalan Singkat auditd: Jejak yang Tidak Bisa Diingkari

Log biasa mencatat apa yang seharusnya terjadi menurut aplikasi. auditd mencatat apa yang benar-benar terjadi di level kernel — setiap panggilan sistem yang memenuhi aturan audit. Ini membedakan audit logging dari logging biasa: auditd menangkap aktivitas bahkan dari proses yang mencoba menyembunyikan diri dari aplikasi.

Kasus penggunaan klasiknya: memantau akses ke file sensitif. Ingin tahu siapa yang membaca, menulis, atau mengubah atribut /etc/passwd, /etc/shadow, atau /etc/sudoers? auditd bisa menjawab dengan presisi.

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity

Rule di atas ditulis ke /etc/audit/rules.d/audit.rules, lalu reload. Arti -w (watch) file tertentu, -p wa memantau operasi write dan attribute change, dan -k identity memberi label untuk pencarian. Setelah aktif, kalian bisa mencari semua kejadian yang menyentuh file tersebut:

sudo ausearch -k identity

Untuk ringkasan laporan, aureport -au menyajikan statistik:

sudo aureport -au

#Kesalahan Umum (Common Pitfalls)

1. logrotate tidak berjalan. Paling sering terjadi karena cron dinonaktifkan, timer logrotate ter-mask, atau sistem menjalankan anacron dengan konfigurasi yang tidak kompatibel. Verifikasi dengan menjalankan logrotate secara manual dan mengecek timestamp file log.

2. delaycompress diabaikan untuk aplikasi yang masih menulis. Menghapus delaycompress padahal aplikasi masih membuka file lama = file terkompresi yang rusak. Simpan delaycompress untuk aplikasi apa pun yang tidak bisa diandalkan melepas file descriptor-nya.

3. Lupa direktif su. Konfigurasi yang menargetkan log milik user non-root akan gagal dengan error permission di state file. Tambahkan su <owner> <group> agar logrotate meniru user pemilik log.

4. Mencampur format log Debian vs RHEL. auth.log vs secure, syslog vs messages. Alih-alih berasumsi, periksa ls /var/log/ terlebih dahulu — atau lebih baik, lakukan centralized logging agar semua masuk satu tempat.

5. Menghapus log secara manual dengan rm. Ketika file log yang sedang ditulis dihapus, aplikasi tetap memegang file descriptor dan ruang disk tidak dibebaskan sampai aplikasi restart — dan file baru mungkin dibuat dengan permission salah. Selalu gunakan logrotate atau truncate, bukan rm.

#Penutup

Pada episode 23 ini, kalian telah membedah arsitektur logging Linux secara menyeluruh. Kita mengenal dua komponen utama — rsyslog yang menulis ke file teks dan journald yang menyimpan log terstruktur — lalu memetakan /var/log/ dan log pentingnya: syslog/messages, auth.log/secure, boot.log, dan dmesg. Kita membahas logrotate: mengapa rotasi wajib, bagaimana /etc/logrotate.conf dan /etc/logrotate.d/ bekerja, dan direktif seperti daily, rotate, compress, missingok, delaycompress, serta su. Kita juga mengenal centralized logging dengan rsyslog dan lapisan audit dengan auditd.

Poin kunci yang perlu kalian bawa:

• Log adalah kotak hitam server — tetapi hanya berguna jika dikelola: dirotasi, disimpan dalam jangka waktu yang benar, dan bisa dicari.
• /var/log/auth.log (Debian) = /var/log/secure (RHEL); kenali perbedaan nama antar distro.
• logrotate dijalankan oleh penjadwal — pastikan cron/timer logrotate selalu aktif.
• delaycompress melindungi file yang masih dipegang aplikasi; su mencegah kegagalan permission.
• Centralized logging (rsyslog forwarding) dan auditd mengubah log dari arsip pasif menjadi alat investigasi aktif.

Sekarang kalian tahu bagaimana membaca kondisi server dari log. Di episode 24 selanjutnya, kita akan memakai kemampuan itu untuk hal yang paling menegangkan bagi admin: System Performance Tuning & Troubleshooting — mengidentifikasi bottleneck saat server lemot atau down, membaca load average dengan benar, menganalisis memori dan disk I/O dengan vmstat dan iostat, memahami OOM killer, serta mengelola swap. Sampai jumpa!