Siapa yang masuk ke mesin: log login
Di mana melihat login yang berhasil dan gagal, cara membaca last, lastb, dan journalctl, cara melacak tindakan melalui sudo, dan cara mengatur penyimpanan log.
Diperbarui 23 Agustus 2026
Setiap login ke sebuah mesin meninggalkan jejak. Mampu membaca jejak tersebut dalam lima menit adalah yang membedakan tinjauan insiden yang tenang dari sekadar dugaan.
Ringkasan singkat
last -a -n 20
lastb -a -n 20
lastlog
who
w
last menampilkan login yang berhasil beserta alamatnya, lastb — percobaan yang gagal, lastlog — kapan setiap pengguna terakhir kali login. who dan w menampilkan siapa yang sedang berada di mesin saat ini.
Jika lastlog menampilkan tanggal login untuk pengguna sistem seperti www-data, itu alasan serius untuk menyelidiki.
Jurnal systemd
journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50
Baris penting:
| Baris | Arti |
|---|---|
Accepted publickey for artem | Login berhasil dengan kunci |
Accepted password for root | Login berhasil dengan kata sandi — alasan untuk khawatir |
Failed password for invalid user admin | Brute-force terhadap nama yang tidak ada, kebisingan latar |
Disconnected from authenticating user | Percobaan dibatalkan |
Di Debian dan Ubuntu, peristiwa yang sama diduplikasi di /var/log/auth.log; di AlmaLinux, di /var/log/secure.
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
Ratusan percobaan gagal per hari pada alamat publik adalah hal normal. Yang tidak normal adalah hal lain: login berhasil dari alamat yang tidak Anda kenali. fail2ban membantu mengatasi kebisingan tersebut.
Apa yang dilakukan setelah login
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
Riwayat perintah tidak dapat diandalkan: mudah dihapus, dan tidak tercatat selama sesi non-interaktif. Log sudo jauh lebih jujur — dikelola oleh sistem, bukan oleh shell. Argumen lain yang mendukung skema "pengguna biasa plus sudo" yang dijelaskan dalam artikel pengguna dan sudo.
Audit tingkat kernel secara penuh:
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
Penyimpanan
Secara default, jurnal systemd dapat berada di memori dan hilang saat reboot. Itu buruk untuk tinjauan insiden. File /etc/systemd/journald.conf:
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
Batas ukuran wajib ada: jurnal yang telah memakan disk akan menghentikan layanan.
Kesalahan umum
| Kesalahan | Konsekuensi | Solusi |
|---|---|---|
| Jurnal tidak disimpan antar reboot | Jejak hilang | Storage=persistent |
Hanya mengandalkan .bash_history | Data mudah dipalsukan | Periksa log sudo dan auditd |
| Tidak membatasi ukuran jurnal | Disk penuh | SystemMaxUse |
| Menganggap kebisingan brute-force sebagai peretasan | Alarm palsu | Lihat Accepted, bukan Failed |
Jika Anda menemukan login berhasil dari alamat orang lain, log di mesin itu sendiri tidak lagi dapat dianggap andal: siapa pun yang login bisa saja telah mengeditnya. Ikuti artikel tanda-tanda kompromi dan anggap mesin tersebut harus diinstal ulang.