Pagar permanen logrotate untuk btmp dan wtmp

Adityo Guni Waluyo17 September 202609.59

Server internet-facing menumpuk log login gagal tanpa guard. Satu drop-in logrotate, direktif su, dan gerbang logrotate -d menutup masalahnya permanen.

#logrotate #linux #ansible

Ringkasan

Server yang kena brute-force login bikin btmp dan wtmp bengkak cepat, bisa tembus ratusan MB sebelum rotasi mingguan jalan. Solusinya pasang logrotate dengan weekly plus maxsize 50M biar file besar diputar lebih awal, tambah su root utmp buat hindari error izin direktori. Validasi dulu pakai logrotate -d biar config salah ketahuan sebelum produksi.

Kenapa btmp dan wtmp bisa bengkak tanpa terasa

Pagi itu dashboard kolektor saya nunjukin pemakaian disk di server mail naik pelan-pelan. du -sh /var/log membuktikan: ada btmp.1 sebesar 108M plus file aktif btmp 47M. Waktu itu saya bersih-bersih manual, dan ceritanya sudah saya tulis di artikel sebelumnya. Masalahnya, membersihkan saja artinya kejadian yang sama pasti balik beberapa minggu kemudian. Yang kurang adalah pagar permanen: aturan logrotate khusus yang dipasang sekali, divalidasi sebelum aktif, lalu ditinggal.

btmp itu berkas berisi semua upaya login gagal, biasanya dibaca lewat lastb [3]. wtmp pasangannya: semua login dan logout, dirawat oleh login, init, dan getty [2]. Keduanya biner, bukan log teks, jadi isinya nggak kelihatan kecuali dibuka dengan perintah khusus. last -f /var/log/btmp.1 pun bisa dipakai buat mengintip isi arsip lama.

Server yang mangkal di internet dizalimi percobaan login tiap detik, dan tiap kegagalan nulis baris di btmp. Rotasi mingguan standar nggak menahan laju ini di antara jadwal: file bisa tembus ratusan megabyte sebelum hari rotasi tiba. Directive maxsize menutup celah ini; kalau file sudah lebih besar dari batas, logrotate memutarnya lebih cepat tanpa menunggu interval [1]. Beda dengan size yang mengabaikan jadwal sama sekali, maxsize tetap hormat pada interval tapi melonggarkan batas atasnya [1].

Isi pagar di /etc/logrotate.d/btmp-wtmp

Saya pasang satu drop-in file, bukan mengutak-atik /etc/logrotate.conf bawaan:

/var/log/btmp /var/log/wtmp {
    weekly
    maxsize 50M
    rotate 2
    compress
    create
    su root utmp
}

weekly plus maxsize 50M adalah pasangan kuncinya: jadwal normal mingguan, tapi file besar diputar lebih awal. rotate 2 dan compress bikin arsip nggak numpak, tinggal dua dan sudah dikempis. create tanpa argumen bikin file pengganti mewarisi mode, owner, dan group file aslinya [1]. Penting karena sshd dan login tetap butuh menulis ke file itu setelah rotasi, dan izinnya memang harus tetap ketat.

Baris su root utmp justru bagian yang paling sering dilewatkan. Di server itu /var/log group-writable, dan logrotate menolak memutar file di direktori seperti itu pakai identitas default-nya; man page menyarankan su untuk direktori yang kendalinya bukan murni root [1]. Issue resmi logrotate memakai pesan error persisnya: "parent directory has insecure permissions" [4]. Pesannya bunyi menakutkan, padahal maksudnya cuma satu: sebutkan identitas mana yang dipakai buat memutar. Pemilihannya nggak arbitrary: man page issue itu mencontohkan su mengikuti identitas direktori induknya [4].

logrotate -d sebagai gerbang sebelum dipasang

Sebelum file ini aktif, playbook saya memvalidasinya dulu dengan logrotate -d. Mode debug ini cuma simulasi: nggak ada file yang disentuh, state file juga nggak disinggung [1]. Murah, jadi layak ditempel di automation.

Run pertama ketangkap basah: gate menolak karena directive su belum ada, dengan error parent-directory yang sama seperti di atas [4]. Tambah su root utmp, jalankan lagi, lolos tanpa error. Run kedua di host yang sama: changed=0, pagarnya idempoten.

Tanpa gerbang itu, config yang salah baru ketahuan saat jadwal rotasi jalan dan gagal di production. Dengan gerbang, yang gagal cuma run playbook-nya, di waktu yang saya pilih sendiri. Kalau boleh keras: automation yang nulis config tanpa gerbang dry-run itu deploy berdasarkan harapan. logrotate -d cuma butuh satu baris di playbook, dan dia yang menangkap kesalahan directive saya sebelum sempat produksi.

Satu catatan penutup soal prioritas. Nggak semua log butuh perlakuan kayak gini, karena banyak yang sudah dijaga journald dengan vacuum cap. Tapi btmp dan wtmp beda: mereka di luar journald, ditulis langsung oleh sshd dan login, dan barisnya justru bertambah paling deras pas server sedang diserang. Justru di momen seperti itu file penuh sesak paling cepat. Pagar semurah ini layak dipasang di semua host yang punya SSH terbuka ke internet.