Membaca Log Server: journald, auditd, dan Deteksi Intrusi di VPS

Ketika server bertingkah aneh, satu-satunya saksi yang tidak berbohong adalah log. Masalahnya, log VPS Linux tersebar di beberapa tempat, formatnya berbeda-beda, dan sebagian besar isinya adalah aktivitas normal yang mengganggu. Artikel ini menunjukkan cara membaca log server dengan journald, rsyslog, dan auditd, serta pola apa yang patut dianggap percobaan intrusi.

1. Peta Log di VPS Linux Modern

Sebelum mencari, ketahui dulu letaknya:

• /var/log/auth.log (Debian/Ubuntu) — login SSH, sudo, su, kegagalan autentikasi.
• /var/log/syslog — pesan umum sistem, termasuk service manager.
• /var/log/kern.log — pesan kernel: driver, OOM killer, aturan firewall yang me-log.
• /var/log/nginx/ dan /var/log/apache2/ — akses dan error web.
• /var/log/mysql/ atau /var/log/postgresql/ — koneksi dan query lambat.
• Journal systemd — terstruktur, terindeks, disimpan di /var/log/journal (persisten) atau /run/log/journal (RAM).

Aktifkan persistensi journal agar log tetap tersimpan setelah reboot:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
sed -i 's/^#\?Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
systemctl restart systemd-journald
journalctl --disk-usage

2. journalctl: Cara Bertanya yang Benar

journalctl bukan grep yang lebih lambat, ia database terindeks. Bedanya terasa saat Anda butuh waktu presisi:

journalctl --since "2026-11-04 02:00" --until "2026-11-04 04:00"
journalctl -u ssh --since "-3 hours" -p warning
journalctl -k -b -1                       # kernel log boot sebelumnya
journalctl _PID=1234 --no-pager
journalctl -u nginx -f                    # follow seperti tail -f

Filter yang sering menolong saat insiden:

journalctl -p err..alert --since today
journalctl --since "10 min ago" | grep -iE "segfault|oom|killed process"
journalctl -u docker --since "-1 day" | grep -i "Restarting"

Bila disk hampir penuh, kuotakan journal agar log tidak menghabiskan ruang dan memicu outage:

SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=2month

3. auth.log: Gerbang yang Paling Banyak Dicoba

Mulai dari ringkasan, bukan dari baris mentah. Hitung kegagalan dan kelompokkan per IP:

grep -c "Failed password" /var/log/auth.log
grep "Failed password" /var/log/auth.log | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head -20
zgrep "Failed password" /var/log/auth.log.*.gz | wc -l

Lalu yang paling penting: apakah ada yang berhasil masuk? Gabungkan jejak keberhasilan dengan waktu dan sumber:

grep "Accepted" /var/log/auth.log | tail -20
last -n 25
lastb -n 25

Contoh pola yang harus ditindak:

Nov 04 03:41:07 vps sshd[4121]: Failed password for root from 45.132.19.4 port 44212 ssh2
Nov 04 03:41:09 vps sudo:  adminops : TTY=pts/0 ; PWD=/tmp ; COMMAND=/bin/bash
Nov 04 03:41:22 vps sshd[4188]: Accepted publickey for deploy from 45.132.19.4 port 51000 ssh2

Baris kedua — eksekusi /bin/bash melalui sudo dengan direktori kerja /tmp — adalah sinyal yang lazim pada sesi interaktif manusia, tapi kombinasinya dengan login publik dari IP yang sama sekali baru dan percobaan root yang gagal sesaat sebelumnya adalah kronologi yang harus diperiksa malam itu juga.

Catatan: IP 45.132.19.4 di atas hanya contoh. Biasakan membandingkan dengan daftar IP kerja Anda sendiri sebelum panik; banyak "serangan" ternyata laptop kantor yang mengganti koneksi ke VPN dengan exit node berbeda.

4. auditd: Jejak yang Tidak Bisa Dihapus Pelaku dengan Mudah

Log biasa punya kelemahan: file log bisa di-truncate oleh pelaku yang sudah punya akses root. auditd memisahkan pencatatan dari proses yang diawasi dan mendukung mode immutable. Pasang dan buat aturan dasar:

apt -y install auditd audispd-plugins
auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/shadow -p wa -k identity
auditctl -w /etc/group -p wa -k identity
auditctl -w /etc/sudoers -p wa -k scope
auditctl -w /etc/sudoers.d -p wa -k scope
auditctl -w /root/.ssh/authorized_keys -p wa -k sshkey
auditctl -w /etc/ssh/sshd_config -p wa -k sshd
auditctl -a exit,always -F arch=b64 -S execve -k exec

Simpan aturan di /etc/audit/rules.d/ agar bertahan reboot, lalu muat dengan augenrules --load. Cara membaca hasilnya:

ausearch -k sshkey --start today
ausearch -m user_auth --start recent | tail -30
aureport -x --summary | head -20
aureport -au --summary -i | head

aureport -x --summary memberi daftar perintah paling sering dieksekusi — biasanya langsung terlihat bila ada binari aneh di /tmp atau /dev/shm yang tidak seharusnya ada di server Anda.

5. Web Log: Mencoba Scanning dan Eksploit

Akses log web adalah tempat percobaan exploit paling sering tertangkap. Cari pola berikut:

grep -E "(%2E%2E|\.\./|\.\.\\\\)" /var/log/nginx/access.log | head
grep -Ei "(wp-login|xmlrpc|/admin|/phpmyadmin|.env|/vendor/.php)" /var/log/nginx/access.log | wc -l
grep -Ei "(union select|sleep\(|or 1=1|

awk '{print $7}' /var/log/nginx/access.log | sort -u | wc -l
awk '{print $1, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -5

#!/bin/sh
d=$(date +%F)
{
  echo "date: $d"
  echo "auth_fail: $(grep -c 'Failed password' /var/log/auth.log)"
  echo "ssh_accept: $(grep -c 'Accepted' /var/log/auth.log)"
  echo "http_5xx: $(grep -c ' 5[0-9][0-9] ' /var/log/nginx/access.log)"
  echo "listen: $(ss -tulpn | grep -c LISTEN)"
} >> /var/log/baseline.log

cat /etc/logrotate.d/nginx
logrotate -d /etc/logrotate.conf   # dry-run, jangan langsung -f

apt -y install logwatch
logwatch --range Today --output mail --service "Disk Space" --service "Filesystems"
echo '/etc/cron.daily/00logwatch' # otomatis berjalan harian